Team Model

The MSF team model describes a team of peers working in interdependent and cooperative roles. There are six project team roles, each with a specific mission, and each of which can be occupied by a team of individuals. Figure 4 depicts the relationships between the different roles.

Figure 4: The MSF Team Model

It's important to distinguish this team of peers approach from a traditional hierarchical approach. In the MSF team model, each project role is responsible for different milestones in the life cycle development process. Here's a brief summary of the primary mission of each of the six project roles:

• Product Management. Establish and sustain the business case for the project. Product management needs to have strong business analytical skills and will generally play the role of advocate for the product's end-users.
• Program Management. Overall responsibility for the application's functional specification and manage the day-to-day coordination required for successful application deliver. Program management needs to have traditional project management skills, and will need to trade off product management/user requests for additional functionality against development's ability to meet agreed to deadlines.
• Development. Develop and deliver a responsive system that complies to the functional specification.
• Test and Quality Assurance (QA). Independently verify compliance with all project team deliverables.
• User Education. Design, develop and publish hard-copy and on-line system documentation, including instructional materials.
• Logistics. Ensure smooth roll-out, installation, and migration to the operations and support groups.

Just because you're working on a large project doesn't mean you have a large team in place. One of the challenges in adapting an applications development framework such as MSF is mapping a full-blown team model like the one described here to a project group that might only consist of three or four people. Fortunately, it's not necessary to have separate individuals occupying each of the project's separate roles. If roles are to be combined, you should keep in mind that some roles are naturally synergistic with others, while some combinations should be avoided.

For example, even the brashest programmer would probably agree that the development and test/QA teams should be different people. Similarly, since product management is the advocate for the end-user and program management is responsible for the project deadlines, these two roles would be risky to combine. Table 3 shows risky and synergistic combinations of roles.

Table 3 Good and bad combinations of roles

According to our envelope-back calculations, this grid implies that the minimum number of team members required for an adherence to the MSF approach is three.