"As you can see, the Planning Phase lies between the Envisioning and Developing Phases. The purpose of Planning is to take the common vision we built in Envisioning and transform it into concrete plans for Developing. It's one thing to say, 'We want an application that does thus-and-so.' It's another thing entirely to be able to say, 'And this is how we're going to build it.'
"To get from the vision to the plans, here is the process we will follow." The next transparency showed a flow chart. "First, we'll work our way through the MSF Design Process, which I'll talk about in a minute. The output of that work goes into the main deliverable for Planning, the Functional Specification. Based on the Functional Spec, we then develop a Master Project Plan and a Master Project Schedule. Those three documents—the Specification, the Plan, and the Schedule—drive the Developing Phase. Any questions so far?"
"So the Functional Spec is where we get down to the nitty-gritty detail of the application?" asked Marta.
"That's right," said Dan. "Only when we've agreed on that can we finalize our plans for the remainder of the project, and only after we've finalized our plans can we do the final schedule." He turned to a new page in his project notebook. "Does anyone remember where the plan and schedule come from?"
Marta and Marilou both began thumbing furiously through their notebooks, and Marta mumbled, "I seem to remember something about 'top-down versus bottom-up scheduling,' but I can't find it."
Tim leaned over to look at Dan's notebook, then leaned back toward Marta and stage-whispered, "Try page 56." He grinned at Dan as everyone else turned to the correct page, and Marta said triumphantly, "The project plan and schedule are a compilation of our individual plans and schedules."
"Exactly right," said Dan, smiling, "even if you did get help from the peanut gallery over here." He put a new transparency on the overhead. "Let's take a look at what each of you is supposed to focus on during this phase, and what plans and schedules you each deliver."
|Product Management||Requirements gathering; in charge of conceptual design||Communications||Communications|
|Program Management||Overall design; in charge of logical design; Functional Spec||Master Project Plan||Master Project Schedule|
|Development||In charge of physical design; proof-of-concept work||Development||Development|
|User education||Analyzes user needs; user support plans; evaluate design for usability||User education and support; usability testing||User education and support; usability testing|
|Testing||Evaluate design for testability; methods and metrics for bug/issue tracking||Testing; bug/issue tracking||Testing|
|Logistics||Evaluate design for deployability, manageability, supportability, and total cost of ownership||Deployment; support||Deployment; support|
Dan explained the deliverables each of them was responsible for. "The final deliverable is a revision of the Master Risk Assessment Document, which we'll do toward the end. Any questions?"
Marta and Marilou raised their hands at almost the same time, but Marilou put hers down again. "I bet you're going to ask the same thing I am, so you go ahead." Marta turned to Dan. "Looking at these deliverables, I'm not sure I know how to pull this off. I'm not a developer. How do I evaluate the design for testability, for instance? And how does Marilou evaluate for support?"
"Good questions, Marta. The short answer is that I've got some extra material for both of you, along with some books for you to look through. I'll also be working with both of you individually, just as I have with Jane on her conceptual design work, which we'll see in a moment. And I'll give you the contact information for the people who filled these roles on the project at my old law firm. They said you could call them if you needed to."
Marilou gave a thumbs-up. "I figured you'd have planned ahead, Dan. Thanks!"
"Not a problem. Remember, I want you all to be successful. Now let's take a look at how we design an application."