Improvements to review team processes
Hello All, (Disclaimer: - my comments below are my personal view, and don't relate to the views of the Board or other Board members) Just following up on my comments about the structure of review teams. I am in favour of making review teams more open - (ie option 2) which consists of a fixed number of members and an open number of participants. It avoids the situation where it is the usual suspects that are on every review team. My concern though is that a review team basically comes up with a list of requirements for improvements. The larger and more inclusive the group - the larger the list of requirements. Unless a requirement conflicts with another requirement it is likely to be added to the list. I think we should explicitly note that review teams should be required to provide a prioritised set of requirements. This is always harder to do, but is the real work that needs to be done. The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit. My comment comes from a long experience managing software projects where there are always more requirements than resources to implement those requirements in a reasonable time frame. We are doing new releases of critical parts of the organisation on a cyclical basis - and need to ensure we focus on the key requirements for each release. In terms of whether this is a new idea - I am trying to create a balance between allowing review teams to be larger and more inclusive, and ensuring we don't get an unrealistically long list of requirements that can't be implemented in a timely or cost effective fashion. Regards, Bruce Tonkin
Folks, As Bruce said, he expressed his personal opinion. He suggested three things: o Fixed number of members o Open to participation by others o Prioritization of the recommendations Also speaking for myself and not on behalf of the whole board but with the experience of having been a co-selector of the ATRT2, I think it matters how many people are involved, particularly when f2f meetings are involved and travel expenses are provided. As a rule of thumb, there are big difference between, say, a group of 8, a group of 12, a group of 16, a group of 20 and a group of 24. As the group gets larger, it becomes harder and harder to make arrangements, to make sure everyone has spoken and to reach consensus. Openness and broad participation are important, but efficiency and effectiveness are also important. Steve On Jul 17, 2015, at 7:33 AM, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Hello All,
(Disclaimer: - my comments below are my personal view, and don’t relate to the views of the Board or other Board members)
Just following up on my comments about the structure of review teams.
I am in favour of making review teams more open – (ie option 2) which consists of a fixed number of members and an open number of participants. It avoids the situation where it is the usual suspects that are on every review team.
My concern though is that a review team basically comes up with a list of requirements for improvements. The larger and more inclusive the group – the larger the list of requirements. Unless a requirement conflicts with another requirement it is likely to be added to the list.
I think we should explicitly note that review teams should be required to provide a prioritised set of requirements. This is always harder to do, but is the real work that needs to be done.
The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit.
My comment comes from a long experience managing software projects where there are always more requirements than resources to implement those requirements in a reasonable time frame.
We are doing new releases of critical parts of the organisation on a cyclical basis – and need to ensure we focus on the key requirements for each release.
In terms of whether this is a new idea – I am trying to create a balance between allowing review teams to be larger and more inclusive, and ensuring we don’t get an unrealistically long list of requirements that can’t be implemented in a timely or cost effective fashion.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
+1 to Steve so long as the number is not reduced to the extent of being too small to ensure diversity in the group. Regards Sent from Google nexus 4 kindly excuse brevity and typos. On 18 Jul 2015 5:31 pm, "Steve Crocker" <steve@shinkuro.com> wrote:
Folks,
As Bruce said, he expressed his personal opinion. He suggested three things:
o Fixed number of members
o Open to participation by others
o Prioritization of the recommendations
Also speaking for myself and not on behalf of the whole board but with the experience of having been a co-selector of the ATRT2, I think it matters how many people are involved, particularly when f2f meetings are involved and travel expenses are provided. As a rule of thumb, there are big difference between, say, a group of 8, a group of 12, a group of 16, a group of 20 and a group of 24. As the group gets larger, it becomes harder and harder to make arrangements, to make sure everyone has spoken and to reach consensus. Openness and broad participation are important, but efficiency and effectiveness are also important.
Steve
On Jul 17, 2015, at 7:33 AM, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Hello All,
(Disclaimer: - my comments below are my personal view, and don’t relate to the views of the Board or other Board members)
Just following up on my comments about the structure of review teams.
I am in favour of making review teams more open – (ie option 2) which consists of a fixed number of members and an open number of participants. It avoids the situation where it is the usual suspects that are on every review team.
My concern though is that a review team basically comes up with a list of requirements for improvements. The larger and more inclusive the group – the larger the list of requirements. Unless a requirement conflicts with another requirement it is likely to be added to the list.
I think we should explicitly note that review teams should be required to provide a prioritised set of requirements. This is always harder to do, but is the real work that needs to be done.
The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit.
My comment comes from a long experience managing software projects where there are always more requirements than resources to implement those requirements in a reasonable time frame.
We are doing new releases of critical parts of the organisation on a cyclical basis – and need to ensure we focus on the key requirements for each release.
In terms of whether this is a new idea – I am trying to create a balance between allowing review teams to be larger and more inclusive, and ensuring we don’t get an unrealistically long list of requirements that can’t be implemented in a timely or cost effective fashion.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Seun, Thanks. Yes, a team could, at least in principle, be too small. I didn’t address that side of the “engineering problem” because we’re NEVER in danger of too few people :) Steve On Jul 18, 2015, at 12:40 PM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
+1 to Steve so long as the number is not reduced to the extent of being too small to ensure diversity in the group.
Regards
Sent from Google nexus 4 kindly excuse brevity and typos.
On 18 Jul 2015 5:31 pm, "Steve Crocker" <steve@shinkuro.com> wrote: Folks,
As Bruce said, he expressed his personal opinion. He suggested three things:
o Fixed number of members
o Open to participation by others
o Prioritization of the recommendations
Also speaking for myself and not on behalf of the whole board but with the experience of having been a co-selector of the ATRT2, I think it matters how many people are involved, particularly when f2f meetings are involved and travel expenses are provided. As a rule of thumb, there are big difference between, say, a group of 8, a group of 12, a group of 16, a group of 20 and a group of 24. As the group gets larger, it becomes harder and harder to make arrangements, to make sure everyone has spoken and to reach consensus. Openness and broad participation are important, but efficiency and effectiveness are also important.
Steve
On Jul 17, 2015, at 7:33 AM, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Hello All,
(Disclaimer: - my comments below are my personal view, and don’t relate to the views of the Board or other Board members)
Just following up on my comments about the structure of review teams.
I am in favour of making review teams more open – (ie option 2) which consists of a fixed number of members and an open number of participants. It avoids the situation where it is the usual suspects that are on every review team.
My concern though is that a review team basically comes up with a list of requirements for improvements. The larger and more inclusive the group – the larger the list of requirements. Unless a requirement conflicts with another requirement it is likely to be added to the list.
I think we should explicitly note that review teams should be required to provide a prioritised set of requirements. This is always harder to do, but is the real work that needs to be done.
The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit.
My comment comes from a long experience managing software projects where there are always more requirements than resources to implement those requirements in a reasonable time frame.
We are doing new releases of critical parts of the organisation on a cyclical basis – and need to ensure we focus on the key requirements for each release.
In terms of whether this is a new idea – I am trying to create a balance between allowing review teams to be larger and more inclusive, and ensuring we don’t get an unrealistically long list of requirements that can’t be implemented in a timely or cost effective fashion.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hi Steve and Bruce, I think the IANA transition presents a unique dilemma in terms of the requirements for obtaining a good product and the time frames within which we should work and whereas the suggestions you make have been tried and tested , we might just need to work with the current 'broad based all inclusive' model to attain our objectives. I think the co-chairs and various appointed representatives from the SO's and AC's have done a great job which is a result of the experience gained serving in their respective communities. That said you have a valid point. Best Regards On 7/18/15, Steve Crocker <steve@shinkuro.com> wrote:
Seun,
Thanks. Yes, a team could, at least in principle, be too small. I didn’t address that side of the “engineering problem” because we’re NEVER in danger of too few people :)
Steve
On Jul 18, 2015, at 12:40 PM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
+1 to Steve so long as the number is not reduced to the extent of being too small to ensure diversity in the group.
Regards
Sent from Google nexus 4 kindly excuse brevity and typos.
On 18 Jul 2015 5:31 pm, "Steve Crocker" <steve@shinkuro.com> wrote: Folks,
As Bruce said, he expressed his personal opinion. He suggested three things:
o Fixed number of members
o Open to participation by others
o Prioritization of the recommendations
Also speaking for myself and not on behalf of the whole board but with the experience of having been a co-selector of the ATRT2, I think it matters how many people are involved, particularly when f2f meetings are involved and travel expenses are provided. As a rule of thumb, there are big difference between, say, a group of 8, a group of 12, a group of 16, a group of 20 and a group of 24. As the group gets larger, it becomes harder and harder to make arrangements, to make sure everyone has spoken and to reach consensus. Openness and broad participation are important, but efficiency and effectiveness are also important.
Steve
On Jul 17, 2015, at 7:33 AM, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Hello All,
(Disclaimer: - my comments below are my personal view, and don’t relate to the views of the Board or other Board members)
Just following up on my comments about the structure of review teams.
I am in favour of making review teams more open – (ie option 2) which consists of a fixed number of members and an open number of participants. It avoids the situation where it is the usual suspects that are on every review team.
My concern though is that a review team basically comes up with a list of requirements for improvements. The larger and more inclusive the group – the larger the list of requirements. Unless a requirement conflicts with another requirement it is likely to be added to the list.
I think we should explicitly note that review teams should be required to provide a prioritised set of requirements. This is always harder to do, but is the real work that needs to be done.
The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit.
My comment comes from a long experience managing software projects where there are always more requirements than resources to implement those requirements in a reasonable time frame.
We are doing new releases of critical parts of the organisation on a cyclical basis – and need to ensure we focus on the key requirements for each release.
In terms of whether this is a new idea – I am trying to create a balance between allowing review teams to be larger and more inclusive, and ensuring we don’t get an unrealistically long list of requirements that can’t be implemented in a timely or cost effective fashion.
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Barrack O. Otieno +254721325277 +254-20-2498789 Skype: barrack.otieno http://www.otienobarrack.me.ke/
participants (4)
-
Barrack Otieno -
Bruce Tonkin -
Seun Ojedeji -
Steve Crocker