Team Roles

Dan placed a new transparency on the projector. It was the same as the previous one, except that each oval had a title. He pointed to the top oval, titled Product Management. "Jane, Product Management is your role. You represent the customer to the team and the team to the customer. Your main task is to make sure we meet the needs of the customer."

Jane had been writing, but she looked up to ask, "And just who is the customer that I am representing?"

"Often, the customer and the user may be the same person, but many times they aren't. The best way to identify the customer is to look for the person or persons whose direct needs you're trying to meet. So, within the Ferguson and Bardell organization, who is directly concerned with the firm's ability to track time and billing effectively?"

Jane thought for a moment. "I started to say 'me,' because I certainly have an interest in it. But it seems to me that the CFO is the person whom the management team holds ultimately responsible for time and billing, so I'd say he's also the customer."

Dan nodded. "Exactly right. As the Product Management person on the team, you represent both your department, Accounting, and our ultimate customer, the CFO. Your goal is first, to understand completely the needs of the customer, and then, to lead the team to a shared vision of both those needs and a way to meet them. Now you see why your ability to write code is not the issue. You are here because of your ability to understand the customer's needs, to communicate them to us, and to keep us focused on meeting those needs."

Jane nodded that she understood, so Dan moved on to the next oval on the circle. "Program Management is next, and that is my role. I am responsible for delivering the right product at the right time. This means that my Program Management role owns and drives the schedule, the features, and the resources for the project."

"That sounds just like the old role of Project Manager!" Tim said.

"It is similar, but there are some key differences. Remember, this is a team of peers. Everyone is responsible for the success of the project, not just me. In addition, because everyone's viewpoint is equally valid as they fulfill the work of their particular role, I can't simply dictate what I think or want. To accomplish the goals of Program Management, I have to act as a leader, facilitator, and coordinator of the project, but not the boss."

"So in other words, you can't throw your CIO weight around in here," Tim commented, smiling.

"That's right. Only within the tasks of my role do I have the authority." He turned to the transparency and pointed to the next oval down. "This is the role of Development. Bill, this is your baby, as you might expect. Your tasks are to participate in the design phase as technical consultant, helping us to see what is doable, and then to build the application based on the design and vision the team comes up with."

"So in other words," Bill said, "I listen to the requirements from Jane, then get my guys and gals together, build it, and give it to her, right? That sounds pretty similar to what we are doing now."

"That's only part of the picture," said Dan. "There are other pieces, other roles, that you also have to relate to, which will make the process different than the one you are used to. One of these," he continued, pointing to the next oval, "is the Testing role. Marta, that's your job." Marta began writing as Dan listed her tasks. "It is up to you to design and carry out testing plans and to track the status of the application in terms of quality. We should be able to ask you at any time for a list of issues remaining in the application, and you should know what they are. The bottom line is, your goal is to portray the status of the product accurately, at any time, by clearly stating what is wrong and what is currently right with the product."

Before Marta could respond, Bill exploded. "Do you mean to tell me that Marta, who is new to Ferguson and Bardell and who doesn't write code herself, is going to be testing what my folks write?"

Dan nodded. "That's exactly what I mean, Bill, and if you think about it, you'll see it makes good sense. The same person can't be in charge of both coding and testing, simply because of the inherent conflict of interest. You need the independent verification—someone to tell you the unvarnished truth, someone who hasn't been involved in the coding so they don't miss something through familiarity. As for not being able to write code—that doesn't matter. Your people will write the code; Marta's job is to figure out ways to test what you write. That's where her engineering background, as well as her organization and attention to detail, will be invaluable."

Turning to Marilou, Dan pointed to the next oval. "Marilou, this is you—User Education. Just as Jane is the go-between in the team-customer relationship, you are the link between the RMS team and the users of the application. You will take part in the design phase, helping us to understand what the users need and what the feature set should be. Your primary responsibility, though, will be to design and develop the support systems for the product, including the Help system, and to plan and carry out the training."

Making some notes, Marilou asked, "I think I know already, but tell me: What is the difference between the customer and the user?"

Jane spoke up, "That's easy. The customer pays for it, while the users use it!" Everyone laughed, including Dan. "Actually, that's correct, Jane, at least partially. The customer typically has a business problem that the application is designed to fix. So, the customer is willing to throw resources of some sort—money, time, labor—at the problem. The users themselves may not have the need, at least in the same way as the customer, but the users are the ones who will actually be using the application to meet the need. The requirements of the customer and the users may be very different, and perhaps even contradictory. That's why we have two roles on the team to deal with them."

Tim had been fidgeting impatiently in his chair, and finally could wait no longer. "Okay, Dan, everyone else has an assignment, a role. What's mine?"

Dan pointed to the last oval. "This is you: Logistics Management. You're our link to the operations staff. It will be your task to plan and manage the deployment. With that in mind, you should be watching for support and management issues as we do the design work. You will support the product during the beta phase, and then you will train the help desk folks to support the product once it is deployed." His expression turning serious, he continued, "Tim, this is a growth opportunity for you. This is more management than hands-on work. I picked you to do it because I think you have what it takes to be an excellent manager someday, and I want you to begin understanding and using MSF now." Tim nodded.

Dan displayed the last transparency. "Remember the six goals for the project? I'm sure it occurred some of you that the six goals and the six roles might be related. Here's how they interact.

"Jane, in the Product Management role, you are responsible for satisfied customers. In the Program Management role, I am responsible for delivering RMS within project constraints. Bill, you and your group are responsible for delivery to product specs. Marta, your role keeps us from releasing until all known issues have been addressed. Marilou, your role ensures enhanced user performance. Finally, Tim, you are responsible for smooth product deployment." He turned back to the group. "Any questions?"

Bill had been alternately rearranging his papers and tapping his pencil, seeming to get more and more agitated as the assignments were handed out. He burst out, "I don't get it, Dan. It looks to me like you've taken everything that the development staff is used to doing and parsed it out to non-developers. We've got an accounting person setting the vision, a newbie engineer overseeing testing, and an Excel-clicker-turned-trainer gathering user requirements! What's left for me and my staff to do, for heaven's sake?"

"In one word, Bill—develop," Dan replied, keeping his voice level. This was the fight he'd expected, the tooth that had to come out, and better he did it quickly and calmly, rather than slowly and loudly. "In the MSF materials, the point is driven home again and again that many of these roles can be assigned to the same person, doubling up roles if necessary. The one role that must stand on its own is Development. 'Leave the developers alone so they can develop.' That's the goal.

"Bill, by moving these responsibilities to other team members, you and your staff can do what you do best: write killer code. Your job is to write an application that meets the vision, the customer requirements, the user requirements, the deployment requirements, and the maintenance requirements, and to do it in such a way that we don't notice your work at all—like a finely balanced hand-tool that feels so right we just pick it up and go to work. Or, if we do notice it, we are innately pleased at the craftsmanship of it. Frankly, Bill, MSF may be the best thing that's ever happened to developers."

Still not convinced, Bill replied, "Well, I sure hope you've planned about six months for this, because with all this 'teamwork' stuff and all that requirements junk, it'll take us at least that long to get this thing designed and written."

Dan smiled. "Make it one-third of that, Bill. Two months." Bill's jaw dropped open as Dan continued, "We're going to have a tested, working application on line in two months. And we're going to walk the entire MSF process along the way."

Bill spluttered, "That can't be done! There's no way we can meet all those requirements you listed earlier—customer, user, whatever else it was—and get it done in two months!"

Dan paused and recalled having the same conversation with the Enterprise Architecture team. "Bill, that's a very common reaction with those new to MSF. My honest answer is, you're right. We can't. So part of our process is going to be learning what to do with that reality. That comes later." He turned to the agenda. "For now, we have two final agenda items. First, questions and answers. Are there any questions?" Everyone looked somewhat shell-shocked, and Dan hadn't expected any questions at this point. The questions would come as the team warmed to the project and to each other.

"Great. Then our last item is Path-Forward Assignments. For now, those are fairly simple. Each of you is to take the binder I've given you, and by our next meeting, you are to review the Development Team Model material that we outlined today and study the Development Process Model material. I expect you all to know the responsibilities of your role and how they relate to the project as a whole. I may also make some individual assignments, so watch your e-mail. We will meet back here Thursday morning, same time, ready to move into the first phase of the project as laid out in your materials. See you then."

As the members of the newly constituted RMS Project Team gathered up their things and moved to the credenza to pick up their binders, Dan called Bill over. "Bill, you remember when you called Marilou an—let's see, how did you phrase that? Oh yes—an Excel-clicker-turned-trainer?" Bill nodded, slightly embarrassed. "Well, Marilou's a little more than just an Excel-clicker. She actually has both her CNE and MCSD. She does training because she loves it. So when you talk about 'cranking out code,' she's done a little bit of that herself. Thought you'd like to know."

Bill's face dropped as he digested this information. Watching Marilou as she was leaving, he said, "Thanks for telling me privately, Dan. That could have been embarrassing if you or she had corrected that stupid remark I made in the meeting."

"Not a problem, Chief. Wouldn't ever want to embarrass one of my staff in public. Just wanted you to have the real picture." Dan gathered up his materials and the last binder, and turned back to Bill. "In fact, my goal in this is to make you look good, Bill. If we work together on this MSF thing, I think you'll be pleasantly surprised at how good it will make your developers look when it's done."

"If it can do that," he said, "then I guess even this old Navy dog can learn a new trick or two." The two men smiled at each other as they parted ways, binders in hand.

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: