RMS Project Calendar and Initial Goals

"Boy, when you said two months, you weren't kidding, were you?" said Bill. He continued, "Do you honestly think there is any way we can make these deadlines?"

"Bill, we won't know the definitive answer to that until we get further into the planning process. Remember, scheduling belongs in the Planning Phase. But we can set up a high-level, tentative schedule now, simply to give us a framework on which to base our planning. That's what I've done here."

"Let's see," said Jane, as she sketched the calendar on her notepad. "Looks like you've got a week and a half for Envisioning, another week and a half for Planning, three weeks for Developing, and two weeks for Stabilizing. I bet that boils down to one iteration for Envisioning, one for Planning, two for Developing, and one for Stabilizing. How close am I?"

Dan smiled and said, "Exactly right, Jane. Your accounting background serves you well."

Marta asked, "What about the goals for each iteration, Dan? You mentioned we needed to set those up front."

"Yes, and I've got a tentative set of goals right here," Dan answered as he handed out a paper diagram to the team. Looking at the copy in front of him, Dan continued, "I've listed the development goals for each iteration first, as those are probably the easiest to grasp.

"In the first iteration—the one done during the Envisioning Phase—our development goal is to build a prototype. A prototype is a visual mock-up of what we think the app should look like. It is a tool for communicating with the customer, and is only the interfaces. Bill, do you think your team can do a prototype in roughly a week?"

"With all the visual tools we have, are you kidding? Interfaces we can do," said Bill.

"Great. So our primary goal for the first iteration is to build the prototype and use it as a vehicle to create a vision of what the RMS product can be. Now, on to the iteration done within the Planning Phase. Here, our development goal is to build a proof-of-concept version of the application. This version is where we work out the critical design and architecture questions, and prove that our design is doable. The proof-of-concept version is almost the functional opposite of the prototype. The prototype was all interfaces; the proof-of-concept is all the critical guts of the app: data access, back-end products, things like that."

"I get it," said Bill, warming to the discussion. "Then in the iterations done during the Developing Phase, we build an alpha version and a beta version of the application, right? That's just like we've done before, but "—Bill was beginning to get excited—"this time our alpha is really way ahead because of the work we've already done! We can simply take the interfaces from the prototype and the technical design of the proof-of-concept and put them together with some connecting objects. Using this MSF Development Process Model, our alpha will be almost like our first beta in past projects."

"Exactly, Bill. You've got the idea," said Dan. "Then, in our final iteration, we incorporate any issues that Testing and Logistics have found, and we're at our golden release. And then we're done."

Everyone was silent for a moment. Finally, Jane spoke up. "Well, if I'm going to start driving this process forward, I guess the first question is, where do we go from here?"

"Good question, Jane," Dan replied. "That's the Path-Forward Assignments at the end of the agenda. Before we go there, let's see if anyone has a question." He paused. After a moment, Tim raised his hand. "Yes, Tim?"

Tim said, "Dan, this looks great. I mean, the idea of turning a project this quickly is so exciting, I know I am already pumped. But, it's also a pretty radical departure from our past practices, and I'm still struggling to get a handle on it. I bet the others are, too." There were nods of agreement around the table. Tim continued, "Do you have any examples of this process, any sample documents, for instance? Something showing how a particular team laid out its goals would be helpful."

Dan nodded and said, "Tim, one of the best ways to understand the MSF Development Process Model and the iterations within it is to watch another project team work through it. That's why the handouts I've prepared this time are the deliverable documents from another team's project. I happen to know the program manager on that project, and he said I could share them with you."

As Dan said this he began to smile, and Tim exclaimed, "You were the program manager! These are documents from your old law firm!"

"Yes, and I haven't cleaned them up very much, so you'll get to see just how green I was then," said Dan. "We were all new at it, but we were still able to turn a project in six months when most people thought it would take three years. Granted, we wound up doing two more versions over the next year before we got the application where we wanted it, but we still delivered the core functionality in the first version. I got permission from the directing officer of the law firm to share these with you, and I hope that they help you get a grasp of these concepts."

He noticed that Marta seemed troubled. "Marta, you look like something is bothering you. Is there something I can clear up?"

"No, not right now. I want to look over the documents you mentioned; then I may want to come and talk with you."

Everyone noticed the tone of her voice, but Dan decided to act as if he hadn't. "That's fine. My door is always open to you or anyone on this team. Just stop by, and we can set something up." She nodded and remained silent.

Dan turned back to the group. "Any other questions? No? Then let's move on to our Path-Forward assignments.

"Everyone should pick up a set of documents from the box on the credenza and read them before our next meeting on Wednesday morning. Based on your reading and on what you know of RMS at this point, each of you should come up with at least one goal for your area for each iteration. I want you to e-mail those goals to me by tomorrow morning so that I can give you some feedback on them before the Wednesday meeting. They won't be our final goals, but they'll be a start.

"Bill, you need to line up people to help you with the prototype. We'll want to start it after the work we do on Wednesday. And Jane, would you stay for just a moment? I want to explain use cases to you, so you can work on them for the next meeting. Everyone understand? Okay, we're done. Next meeting is Wednesday morning, same time and place. Marilou, your turn for the doughnuts, okay?"

As the meeting broke up, Dan couldn't help but notice the contrast between Marta and the rest of the team. Everyone was talking about RMS, sharing ideas, discussing possible goals, getting excited about the work—everyone, that is, except Marta. After picking up her packet from the credenza, she had looked at the others for a moment before walking silently out of the room. Dan thought, "Great! Just when I finally get Bill Pardi to buy in, I get a new problem on the horizon. I sure hope she talks to me before the next meeting so we can deal with whatever it is."

Unfortunately, she didn't. As a result, the meeting on Wednesday took a direction no one could have anticipated.