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