However brilliant your concept, however well your project is planned, your program will never see the light of day unless you bring the right people together. The more ambitious the project the more crucial people will be. Yet even with a modest project, you will need responsible beings to fulfill four basic functions:
♦ Technical creativity
♦ Coordination and progress
♦ Resource accounting
These form the steering committee, some of whom may wear two hats. Keep the development team lean. Additionally, you may need an end-user representative or market researcher plus anyone who has experience on a similar project. Make sure that every department that should be represented is represented.
When making your selection, remember it is vital that the people get along together. Introduce them in a social setting and see what happens. If they gel, you can look forward to shorter meetings with more agreement, and you will find it surprisingly easy to arrange times for them to meet. Figure 3-1 provides an illustration of how the process should flow.
Write an individual job description for each member and go over it with each. Revise and agree on the details before you hold your first meeting. If the result leaves you with a lean hand of trumps, discard the wrong suits and pick suitable replacements from the pack.
If you are the chairman, your job is not to do all the work but to coordinate the rest of the steering committee. Each member should be invited to explain his role to the rest. Thus, the business case for the project should be advanced by the marketing manager. It is his or her job to convince the others of the relevancy and importance of the proposed project. It is everyone else's role to question the marketing manager until the case is sufficiently refined for agreement so the meeting can move on.
The technical representative should give a rundown of the main components of the programmers' work, explaining where the writing is straightforward or may be bought in, and where they anticipate future difficulty. The purpose is not to sow doubt but to dispel any unrealistic expectations.
The person responsible for day-to-day progress should explain how he will be setting up milestones and monitoring progress, what he will do if a key programmer drops off the project, or how they will tackle items they would like to buy in but are precluded from by some conflict of patents.
With project meetings it is vital to keep the momentum going. When everyone else has made their case, the Chairman should sum up and make a statement on behalf of the highest level of management expressing why they believe in the project and giving highlights of the resources they are putting at the committee's disposal. The meeting can then turn toward organizing a development schedule, penciling in from and to dates, and setting up progress meetings with the aim of coming together within a few days to create the product development plan.
Was this article helpful?