Team Roles and Their Phase Responsibilities

Dan put another transparency on the projector that showed a table with the four phases on the left and blank boxes beside each phase "We've already spent some time on the MSF Development Team Model, and each of you has studied the material explaining what your roles and responsibilities are. Now I want to tie those roles to the MSF Development Process Model." He moved to where he could write on the transparency and continued. "As Program Management, I'm responsible for the overall progress of the project. But each of you is individually responsible for driving a certain phase to completion. Based on what you know about your roles, who do you think is responsible for the Envisioning Phase?"

"That would be me, wouldn't it?" answered Jane, copying the transparency's diagram into her notes for the day. "I mean, since Envisioning is where the project team and the customer build a common vision, and since I am the one responsible for dealing with the customer, my role as Product Management should be responsible for the Envisioning Phase and the Vision Approved Milestone."

The rest of the team was nodding as Dan said, "Exactly right, Jane. The Product Management role is responsible for leading the team forward to the first milestone." He wrote Product Mgr. in the first box, then continued, "Do you all remember what I said about special seating plans—that I had one, but it was for only one person? This responsibility is what I was referring to. Beginning next time, Jane, I want you to sit at the head of the table and to run our meeting."

Marilou leaned over and said, "Hey, you're moving up in the world, girl!"

Jane looked doubtful. "I don't know about that, Dan," she said, looking around the room at the other team members. "I'm not sure I should do that. I don't know very much about some of these areas."

"Yes, but you know the customer better than any of us, and that makes you eminently qualified to help us build the vision we need. Don't worry, Jane; I'll be giving you some help and pointers as we go along. And don't forget, this is a good team."

He wrote his own name in the second blank box on the transparency, next to Planning. "The Program Management role has the overall responsibility for the project, but also has the specific responsibility for the Planning Phase. A good Program Manager actually starts planning the day he is enlisted to run the project."

Dan turned back to the transparency. "Let's jump to the third phase, Developing. I think we can all name at least one person who is responsible for that phase."

Bill Pardi stirred in his seat. "Guess that would be me, now wouldn't it?" he said gruffly. "Since this is a development project, glad we finally got the developers involved." It was obvious to the rest of the team that Bill still wasn't convinced of the value of using the MSF Development Process Model. The other team members looked at Dan, who answered Bill with a tight smile.

"Actually, Bill, you'll see in a moment that you and your folks are involved much sooner than you think. However, first, we need to finish assigning roles to phases." Bill shrugged, and Dan continued. "We've got six roles on this team, and only four phases, which means some phases have responsibilities that are carried out by more than one role. Which role do you think works with you on Developing, Bill?" Bill and the rest of the team looked around, trying to figure out who else would be needed in the Developing Phase. "I'll give you a hint," said Dan. "It's someone that mature developers always want to hear from."

Bill furrowed his brow as he thought through the possibilities. Finally he said, "It seems to me that us code jockeys should listen to every one of the groups you people represent. Customers, operations folks, testers—they're all important to the work."

Dan nodded approvingly and said, "That's true, Bill, and that's one of the reasons MSF is structured the way it is—to make sure each of those groups is represented. But, when you are actually building the application, there is one group whose concerns should be paramount in your mind as you work."

Again, Bill's face showed his concentration. "Users! We're supposed to work with the users as we build it!" Suddenly he realized that Marilou represented users on the team, and he turned to face her. "That means you and I will be working together." The memory of calling her an "Excel-clicker-turned-trainer" flashed through his mind, and he wondered if she remembered also.

Marilou just laughed and placed a hand on his sleeve. "Don't worry, Bill. Even we 'Excel-clickers' can help you 'code jockeys' when it comes to users. I promise not to write any code unless you ask me to." The rest of the team laughed, and Tim stage-whispered to Bill, "She got you, old man." Bill just looked flustered.

"Actually, it makes sense for the User Education and Development roles to work together in the Developing Phase," said Dan as he wrote the role names in the box on the transparency. "Marilou will take early versions of the application to begin training the users, and she will bring their feedback back to Bill and his team so they can incorporate it into their work as appropriate." He turned to Bill. "Your work will be better, Bill, with the users involved as you build, rather than having them simply send you complaints once the app is rolled out."

Tim said to Bill, "Hey, this is a good deal for you, guy. You've got someone like Marilou to deal with the users, rather than having to do it yourself. They love her, and they'll talk to her. She meets with them, brings you back the info, and you put their ideas in as you go. You're a hero, and you didn't even have to stop being your old grumpy self." Everyone laughed good-naturedly at that, and even Bill smiled.

Tim then said to Dan, "Based on what's left, I bet my Logistics Management role and Marta's Testing role take the lead for the last phase, right?"

Dan wrote the two roles in the last block and said, "That's right, Tim. First we test the app, and then we deploy it. It's Marta's job to make sure the app is ready for the users, and it's your job to figure out how to get it to them. When you are both done, this version will be finished."

"Cool," said Tim, leaning back in his chair again. "I guess that means Marta and I can take it easy till then."

"Not so fast," said Dan, placing another transparency on the projector. "You've forgotten about iterations within a single version." Tim's chair came down with a thud, and he looked up at Dan with a puzzled expression, as did the rest of the team.

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: