A few days later, the morning sky peeled back the morning gloom on my face. My gallop into the office was making a slight sheen a sweat appear on my forehead. The meeting we have scheduled for this morning got me anxious for the first time in a long time. I grabbed Gary, our software salesman, guru, from the lobby and lead him to our main conference room.
Preparations for Project Planning
Yesterday, Jim and I reviewed the planning process Gary suggested. He had once been in a similar position. He was under tremendous pressure to do more work, in less time, with the same resources. And, stay within budget.
He said his approach was based on the latest critical chain project network building guidelines. I didn’t know there was such a thing. As clear and concise as these guidelines were, they were not build for speed. Through many project network building sessions, Gary was able to streamline and extract the essence of each step and fine tune the steps. We need only the least effective dose required to get the intended results.
Project Planning Objectives
The intended results are to translate the project content available at the time into a good enough project plan which all participants could live with. “Remember this, he said, “you will never have all the information you need to start a project, but there only a few things you must insist on. The pre-planning information. You have good reasons to insist because the customer will not get what they want otherwise. There is a way to get almost everyone to see this, but we’ll discuss it later.”
Another reason I like Gary is that he volunteered to lead the project planning for today’s meeting. I asked, “Are you ready? The meeting starts in about 20 minutes.”
“Last night I reviewed the latest pre-planning information which came in from all the internal and external customers. I was surprised they reviewed the information,” said Gary.
“That’s because the Mayor made a special appeal on our behalf and encouraged all parties to make this project their highest priority,” I said.
I looked behind me and Jim entered the room out of breath. He said, “R&D can’t make the meeting this morning and wants to postpone it until later this afternoon. I didn’t think you wanted to do that, so I asked them for the tasks they wanted to add to the project plan. They gave me some time lines for completing their research, too. But, I’m worried they won’t be ready when we need them to be.”
Gary interrupted, “Without the project plan in place, we don’t know when we need anything. There are ways to model the project so that the work that is at high risk of delay can be moved off the critical chain. This means those tasks are not determining the duration of the project and can be done in parallel with other tasks. You may be right, but let’s not worry about what is or isn’t a high priority yet.”
While Gary connected to the conference room projector and fired up his laptop, I went to find more coffee. Jim followed me out and said, “I’m curious to see how Gary handles all the objections bound to come up from those who manage projects the conventional way. Actually, that will be everyone on the call except us.”
“I’m curious, too. But, look at how he helped us see the light so far. Although, we made an effort to understand our problems and look for a solution, he was able to cover many of our concerns. The fact that almost everyone adds safety time to their tasks creates environment with identical issues. Most companies uses the critical path method, and so no one has a clue about the load on their resource pool. Almost everyone will be looking for a solution to their issues, whether they know it or not. It’s an opportunity, right?”
More members of our project team have arrived; our procurement manager, our senior wireless engineer, and software development wiz kid. Jim was going to be the project manager for this project. Our CEO was nowhere to be found; out creating headaches for someone else.
July 20th @ 10:00am
As more and more faces flash on the screen, I open the meeting. A warm welcome to everyone and a brief introduction of myself, the folks in the room, and a quick review of the project. Each person on the phone added their name and position to the others. I’m glad to see the customer’s project manager, Lieutenant Rollins, Jim’s counterpart, who also brought along the Chief of Police. Another sign that this project is an important one for them. And, for us.
Finally, I introduce Gary as our project planning specialist. He will be facilitating the planning session. He will be helping us reach a consensus on the project tasks, responsibilities and timelines.
Gary thanks me and says, “Labor Day is on Monday, September 7 this year. That’s about six weeks away, exactly 47 days. If we don’t work weekends, that’s 36 days. I’ll be your project planning facilitator, but I’ll need everyone’s help to create a good enough schedule. Good enough means we’ll use the information we have today to plan the project. And, good enough means we also have the flexibility to make adjustments along the way.”
“Thank you all for taking your time to review our pre-planning request and getting your comments back to us. You’ll see as we go along where each piece of information will be used. Any questions?”
Silence. Someone’s dog barks in the background. The faces on the screen go blank as if waiting for the judges ruling on innocence or guilt.
“We’ll try to get this plan done in one go, but if we need to take break, feel free to say so. Let’s me open the planning screen in the software. You’ll see that I already entered the project’s name, a sentence describing the project, selected Jim as our project manager, and set the due date for September 7th.
A Repeatable, Reliable Planning Process
“As Steven Covey says, start with the end in mind. By starting with the project’s goal, we will work from right to left and add the necessary tasks required to reach the goal. We’ll use complete sentences to describe the task, with an action verb minus the subject. We’ll continue working backwards until we reach a task we could start on today. Let me show you want I mean.”
I watch Gary add a blank task to the left of the objective task. He asks the group, “What must be finished immediately before this task, the objective, can be achieved?”
After a brief discussion with the Lieutenant, Gary adds the task description. She’s added a task about making final review of the system’s performance and signing the acceptance document. Gary writes it in. Next, he asks the group, “What must be finished immediately before this task (the one we just added), can start?”
The Lieutenant offers up another task. Gary writes it in. He asks the group, “What must be finished immediately before this task (the one we just added), can start?”
It’s a little repetitive, I admit, but it is putting people in a familiar groove; setting a pace.
Our wireless engineer adds something about conducting a final stress test of the network. Gary writes it in. He asks the group, “What must be finished immediately before this task (the one we just added), can start?”
I marvel at how the planning screen is filling up with tasks. It appears like a backbone of a large fish, minus the rib bones.
Beyond the Backbone Tasks
We reach a task that could be started today. Gary says, “That’s the end of the project’s backbone. Next, we’ll add tasks required to build the skeleton, other task paths, by working backwards along the backbone.”
He points to a task and asks the group, “What must be finished immediately before this task can start?”
This process continues until no one has any more tasks to add. Gary asks me to read the network from the left-most tasks looking for more tasks to add. Before I do, he says, “We are looking for two things: 1) missing dependencies, and, 2) dependencies that we don’t need. The key is to confirm the correct flow of work as it is passes along from task to task. Also, this is my definition of a task. A group of activities, having a prescribed duration and scope, performed by one or more resources, enabling other resource(s) to start doing their work.”
I start reading the tasks from left to right; changes are made.
But, Gary is not done checking things. He says, “Let’s check every task against the project objective and scope requirements.”
Jim brings up on the screen the pre-planning document and runs down the list of the agreed upon information. As Jim reads each element, Gary is identifying which task in the project network it relates to. He also pauses on the risk elements and adds tasks which may mitigate the risk. Even more tasks are changed, combined or added to the network.
July 20th @ 12:00pm
After two hours, a break is called as we realize all the key points of the pre-planning document are reflected in the plan. That was the least painful way to get collaboration and consensus on a large project I have ever been involved with. With everyone’s involvement, we started with clarifying the goal statement. With the end in our collective minds, we worked backwards, from right to left, building the project backbone.
Once the backbone was in place, we could add some more tasks and clarify others. While I read out loud the resulting network from left to right, everyone was able to hear the story of the project. We all listened for any story line gaps and filled them. The icing on the cake was when Jim reviewed all the key pre-planning details while confirming they were in the project network.
Next, Gary said to me, “We’ll start adding the resource types and task durations next. This will be as enlightening as this morning was.”