Review of the MSF Development Team Model

The next transparency, titled Team Goals for Success, had six bullets. "I want us to shoot for these six goals for project success," said Dan. "See what you think of them." He read the goals out loud. "Satisfied customers. Delivery within constraints. Delivery to specifications based on user requirements. Only release the software after addressing all known issues. Enhanced user performance. And finally, smooth deployment and ongoing management." He turned to the group. "The contention of MSF is that no project can be called a success unless all six of these goals are met. My question for all of you is, are these valid goals?"

"Sure, they're great goals, Dan, but I've never seen any project come close to meeting all six of them!" Jane exclaimed. "Aren't these just a little too optimistic?"

"Not only that, but some of them seem contradictory," Tim added. "How do you satisfy your customers, deliver within constraints, and deliver to specifications that you got from the users? It's not possible to do all of those on the same project, is it?"

"That's the beauty of the framework," Dan answered, taking a step out from behind the projector. "I've seen this work. I've seen a project team use MSF on a large project and succeed because of it. At my last firm, we put in a client tracking system and used the MSF approach to do it. If you asked anyone associated with that project, they would tell you that all six goals were achieved. I'm telling you, it can be done. And here's how we're going to do it." He switched to a transparency that displayed six ovals arranged in a circle.

Dan turned to the group. "This model represents the six roles on an MSF project team. Each of you is here to fill one of these roles. Before I tell you what the roles are and which role is assigned to each of you, I want to point out something about this diagram.

"There are two types of project teams. The kind you are probably familiar with is the hierarchical type, where one person is the Project Manager and everyone else reports to him or her. The problem with that is that the only person on the team who is ultimately responsible, and who therefore is highly motivated to make the project a success, is the Project Manager.

"The model we are going to use is represented by these ovals. You'll notice that all of them are the same size and that they are all related to each other in the same way. In other words, they are equals. This is a team of peers. Each person on this team is equally important, and each is equally responsible for the success or failure of the project. You'll also notice that each oval is a different color. Each person on the team has a role and a responsibility. As we move through the project, responsibilities will become clearer, but for now, just understand that each one of you has a role on the team that only you can fulfill. Now, let's look at the roles."

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: