In whatever time is allotted for defining the project, create a simple process for answering the planning questions. If possible, each perspective (business, technology, and customer) should have one person with expertise in that area driving the research of information, generating ideas and proposals, and reviewing her thoughts with peers from other perspectives. The trick is to keep this small enough to be productive, but large enough in perspective to be broad and comprehensive. A group of 10 people will be much less effective at discussing issues and developing team chemistry than a group of 5 (see Chapter 9).
From experience, I'd rather deal with the bruised egos of those who are not main contributors to planning than include too many people and suffer a year or longer on a poorly planned and heavily compromised project. The mature people who you do not include will understand your reasons if you take the time to explain them, and the immature will have an opportunity for growth, or motivation to find employment better suited to their egos.
If you're using planning deliverables like the ones I briefly described earlier in this chapter, the goal of the planning group should be to create and publish those documents for the team. The planning phase (see Figure 3-3) ends only when those documents (or more importantly, the decisions they contain) are completed.
A draft version of each planning ...