After the fireworks of the previous meetings, the final Envisioning Phase meeting was somewhat anticlimactic.

First, Dan presented the some documents describing the basic project structure. Most of it was informational: who filled what role, the team's contact information and e-mail addresses, and so forth. There was a section on change control that explained the process the team would use to manage changes to documents. There was also a schedule showing when status reports were due and to whom, which Jim Stewart liked.

Next, the team looked at the risk assessment document. "Do you have any more information on the risk of saturating the network with the RMS application?" Dan asked Tim.

Tim put a transparency on the overhead projector. It showed a graph of network traffic over the past two weeks. "I went back and pulled the logs off our monitoring software, put them into Excel, and created this graph," Tim began. "As you can see, on most days we have two usage peaks: around 10:00 A.M. and around 1:30 P.M. Typically, we run around 55 percent load during those times, with bursts up to 85 percent. If all 800 of our employees try to hit this application at the same time, we could have a problem, depending on where the app is located and what sort of activity they are working on. On the other hand, the odds that all 800 will be updating their hours at the same time are pretty small, so I think we'll be okay."

"But Tim," Marilou interjected, "doesn't it also depend on how the application accesses the database? If the application has to reconnect for every record it sends, then even if only 250 people send 50 records at the same time, it could be a real mess." It was obvious to everyone in the room that Tim hadn't thought about that, and he looked concerned. "Bill?" he said, turning to the director of development. "What about it?"

Bill passed the question off to Sam and Beth. "What about it, you two?"

Sam was grinning when he replied, "How would it be if no matter how many users access the system at the same time, they look like only one user to the database? Would that solve part of our network traffic problem?" Everyone was surprised except Bill, who suddenly seemed to think of something significant. He winked at Sam and then turned to Tim. "Don't worry, Mr. Network Manager, I think Sam's onto something that will save your network from exploding."

"How can you have multiple users look like only one to the database? That's not possible," said Marilou. Bill turned to Dan. "Didn't I read something about building proof-of-concept systems in the Planning Phase?" Dan nodded. "Well, then, everyone, let's just leave this problem for the proof-of-concept folks to deal with. Then we'll know for sure."

Dan looked around the group. Everyone seemed content with that approach except Marilou, who just shrugged and said, "I'll believe it when I see it, but I'm willing to wait. Let's move on."

Following that, the team walked through the Vision Document one last time. Dan had sent everyone the changes from the last meeting, and then had incorporated the feedback into a final document. After some minor adjustments, the team approved the document. Dan turned to Jim. "Does it have your approval as well?" he asked.

Jim paused a moment. "Yes, it does. I feel like I'm going out on a limb here, because I've always had to push to get features I wanted into the software, and you all are asking me to trust you on this. But, I'm intrigued with the process you're following, and I want to give you enough room to either succeed gloriously or fail miserably. I'm in."

"Good," said Dan, as the team members looked at one another with grins of success. "I think I speak for the entire RMS team when I say that, as our customer, we want you to hold us to our commitments. In return, we want you to be fair in your acknowledgement when we have met or exceeded a goal. Is it a deal?"

"Absolutely," said Jim emphatically.

"Then, the Vision Document is approved," Dan said, as he put a final transparency on the projector. "The Vision Approved Milestone is the first major milestone in the Development Process Model. We have completed the deliverables, and all that is left is to be sure we all agree on these six points."

He read each point in turn—the reason for RMS; the expected outcome; the feasibility, goals, and constraints for the project; the opportunities and risks; and the structure—and asked each person to state his or her agreement. As the team moved through the six points, Dan tried to ensure that everyone was heard and that everyone was in solid agreement on each point.

When the entire team had expressed agreement on all the points, Dan turned off the projector and leaned against the credenza. "Alright, gang, last question. And this same question will conclude each of our other major milestone meetings. Do we go ahead, or not?"

The group obviously hadn't been ready for such a question. Jane seemed to speak for all of them when she said, "I thought that was already decided when we went through the agreement questions."

Dan shook his head. "No, Jane, it's possible to work through those agreement questions and still come out realizing that the cost/benefit ratio isn't there, or there is some overriding concern that is a showstopper. Plus, we've got to have a positive commitment from each of you, not just a de facto commitment based on simply not disagreeing. So, I ask again—should we go forward with RMS?"

One by one, the team members and Jim Stewart said, "Yes." When they were finished, Dan summarized. "We each agree, then, that we should move into the Planning Phase for the RMS project." He made a note. "I'm documenting the group's decision to go to the Planning Phase. We are now beginning that phase."

The RMS project team and its customer exchanged smiles, handshakes, and high-fives all around as Dan began gathering up his notes and handouts. "Enjoy it now," he thought. "The real work is about to begin."

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

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net