Rapid Project Startups

Do you have a complex project ahead of you and not sure how to begin? This is a specialty of Round Table Project Management. We have facilitated hundreds of these for over 20 years. Call us in for a Rapid Project Start-up.

Using Progressive Elaboration, we take the full core team through a series of workshops that result in a fully planned project in one day.

The results of the workshops are the following elements of a comprehensive project plan

  • Project Objective
  • Scope (Deliverables, Measures, Exclusions)
  • Work Breakdown Structure
  • Responsibility Matrix
  • Schedule
  • Issues, Risks, Assumptions

 All of these will be documented in two files:

  1. An MS-Word document that shows everything but the Schedule in words and graphical content.
  2. An MS-Project Gantt chart that shows the full schedule with notes attached showing all the risks, issues, and assumptions on the relevant tasks.

Read below for details of how one of these Rapid Project Start-ups progresses.

We start with some poetry from Rudyard Kipling that exposes the team to the questions we will receive answers to during the course of the session:

I keep six honest serving men

They taught me all I knew

Their names are WHAT and WHY and WHEN

And HOW and WHERE and WHO

After reciting the poem, we promise the team that we will have the answers to these six questions by the end of the day.

The Agenda looks like this for a one-day Start-up session:

AGENDA

Time                      Item                                                           Led by..

9:00 – 9:05      Check in at room, Introductions       Round Table PM

9:05 – 9:15      Icebreaker exercise                                 Round Table PM

9:15 – 9:30      Project Background                               Management

9:30 – 10:00     Project Objective                                   Round Table PM

10:00 – 10:30  List of Deliverables                                Round Table PM

10:30 – 10:45  Break 

10:30 – 12:00  Work Breakdown Structure              Round Table PM

12:00 – 1:00  Working Lunch 

12:00 – 2:00 Responsibility Matrix                            Round Table PM

2:00 – 2:15 Break 

2:15– 4:30 Schedule                                                     Round Table PM

We start with introductions and then go into a quick icebreaker exercise.

Next, I enter the six serving men scenario by answering the first question: WHY? All team members are able to speak their piece. Why are we doing this project? Why is it important to the company? Why is it important to the various departments and participants? During this project background session, the location of the project, WHERE, is defined and documented.

The room is usually in a FORMING mode, (polite, high morale, not much work going on), typical in a kick-off meeting. But they need to get through the STORMING stage to reach the NORMING and eventually PERFORMING stages. We typically accomplish this through the use of a project objective session. Not that we expect the team to continue PERFORMING from this point on. We just need them to get through this planning day and get a feel for how a PERFORMING team works.

To determine the first part of WHAT, the model we use is the NASA space program. We ask all the members of the room if they can remember back 40 years to the speech John Kennedy made to the nation about the space program. “Can you remember the project objective of the Apollo program?”

Some remember, “Put a man on the moon.” Others remember, “Before the end of the decade.” We have to remind them of the part that increased the complexity of the project: “Return him safely.” We inform them that Kennedy never told the American people what he told Congress: that the project would cost “Twenty billion dollars.” (Even that was not the true objective. NASA predicted forty billion dollars; Kennedy knew he couldn’t get this in one shot, so he asked for twenty.) Eventually we have the whole NASA project objective on the board.

“To achieve a manned lunar landing and safe return of the astronaut by the end of 1970, at a cost not to exceed $40 Billion.”

The NASA objectives, we go on to explain, have some very stringent rules:

  • They include the three project constraints:
    1. Scope (To achieve a manned lunar landing and safe return of the astronaut)
    2. Schedule (by the end of 1970)
    3. Cost (at a cost not to exceed $20 Billion)
  • They are no more than 25 words. Market research had proven that people have difficulty remembering more than 25 words verbatim.
  • They are understandable and specific.
  • They were agreed to unanimously by the project team members and sponsors.

We ask the team to come up with an objective for this project that meets the same standards as NASA. We ask them to throw out words that they would like to see on the project objective, and we write these all on the white board with no challenge or editorializing. This is where peoples’ agendas come out, and we can guess which department they represent by listening to their ideas of a project objective. “Meet FDA requirements.” Must be Quality. “Improve user interfaces?” Sounds like the user group. “Simplify code.” IT is in the house. The STORMING has started.

We then explain that the first men on the moon did more than land there and fly back. They walked around, drove a lunar buggy, picked up rocks, hit golf balls. All these things were part of the project, but were not considered to be the key project objectives that must be visible for all to consider the project a success. They could hit a golf ball in Florida, but people are not going to pay $40 billion for it. Still, people will live without seeing the golf ball hit on the moon.

So we ask them to look at all the items written on the board and decide which belong in the 25-word objective, and which belong in the rest of the project scope, further back in the documentation. Not forgotten, simply de-emphasized.

They start classifying the statements as Objective versus Scope, but I always look back at the author of each statement for permission to de-emphasize their words. One by one they agree, sometimes changing an objective statement to include part of their wish before moving it.

During this session I keep a flip-chart open to a blank page with the heading “ISSUES, RISKS & ASSUMPTIONS.” We record all assumptions being made as we refine the scope. Any issues that surfaced that we are unable to resolve in a few minutes, we record here for future resolution. We often have to remind the team that we are PLANNING the project now, not EXECUTING it. We’ll resolve most of these issues later on as we execute the project.

After we have refined the list of objective items to a minimum, we forge trial objective statements, which the room critiques and revises until we have a sentence that everyone can stand behind. We insist on unanimous agreement to the objective, over some people’s wishes to put the earlier objectives to a vote. Our goal is to have no one leave the room thinking, “That’s not my objective.” When we have agreed to the final objective and read it aloud a couple of times, we cover it up and ask the room to repeat it. We do this by reciting it together. They all repeat it verbatim, and there are pleased looks around the room. We have reached the NORMING stage of group development. The group takes a break on this high point and there is always a lot of mingling at this time.

When we reconvene, we go through the second part of WHAT this project consists of, by listing the deliverables. These are the tangible things (Documents, Web pages, finished product, etc.) which are handed over at the completion of a project. There are also deliverables used during a project, like a house’s blueprints, prototypes, or a project Gantt chart.

The next session shifts focus to HOW. The Work Breakdown Structure (WBS) requires the participants to figure out the tasks needed to complete the deliverable. For example, the IQ protocol requires the following tasks: Draft IQ Protocol, Review IQ Protocol, Edit IQ Protocol, Review IQ Protocol, Approve IQ Protocol, Authorize IQ Protocol, Enter IQ Protocol into Document Control System. The format we use for a WBS is a noun for each deliverable, (to emphasize that no work takes place at this level) and a verb-noun format for the task (to define what needs to be done to complete this task).

To complete this session, we place Post-it notes around the room with the deliverables we had identified and ask the participants to place Post-its with tasks vertically underneath the deliverables. They naturally gravitate to the deliverables of the most interest to themselves. We show them how to do it with the Project Plan deliverable, and let them go. We wander around offering help and reminding them of the verb-noun format to use. We tell them not to worry too much about order since they are Post-its and can be moved easily later.

Occasionally, they ask us how far to break down a task. We tell them three rules of thumb:

  1. The 8/80 rule. No tasks should take less than 8 or more than 80 hours.
  2. Reporting Period Rule. No task should be longer than the distance between two status meetings
  3. The “if it’s easier” rule. Break it down further if it makes it easier to assign responsibility, to estimate, or to track.

We remind them that these are rules of thumb, not to be strictly followed but something that they could refer to when asking: “Should we break the task down further?”

By getting team participation in this session we increase the feeling of ownership the team members have for this project. When they are all finished, we ask each person to present their deliverable breakdown to the rest of the room for critique. The question we ask frequently during this is, “If you do all those tasks, will that deliverable be complete?” This often generates more tasks. When all the deliverables are presented, we ask the question: “If you do all those tasks, will the project be complete?” Often the answer is “No”, and we have to add deliverables and more tasks. The walls are soon full of tasks and the team gets a good feel for how big this project is and what other people are contributing to the project’s success. This is another great high point in the planning session and, before long, phones are coming out and people are taking pictures of the WBS.

The next part is to determine WHO will do all these tasks. We use a tool called the Responsibility/Effort Matrix. All the team member names are placed on the Y-axis and the task Post-its are placed on the X-axis. The deliverable Post-its are placed above the group of tasks they represent to show the connection. Where these lines intersect, responsibility for a task is indicated in three ways: “No contribution”, “Responsible” or “Involved.” We announce a task to the room, and someone volunteers that it is their responsibility to see that task to completion. They may not do all the work; just ensure that it is completed.

We place an R at the intersection of that activity and person. Then we ask that person if they need help, and they indicate other people or others volunteer. We look to the people indicated and allow them to volunteer before placing an I  at those intersections.

We never assign or allow anyone to be assigned to an activity. This session must be done voluntarily, once again to increase ownership in the project. People who make a commitment in front of their peers are more likely to live up to this commitment when it comes time to complete that task.

We take a break and when we re-convene, we have the wall plastered with blank Gantt charts. The tasks are written in on the Y-axis and dates are written along the top X-axis. We take the first task of the first deliverable and ask the person who had taken responsibility for it two questions:

  1. What are you waiting on to start this task?
  2. How long will it take to complete it?

We draw in bars to represent this start date, duration and linkage, as I would in Microsoft Project. Often we are questioned why we don’t do this on a laptop and give the following answer: “On a laptop only one or two people can see what is going on. Projecting the display, still only allows the room to see about 30 tasks. This wall display allows everyone to participate (anyone can pick up a pen and make changes) and you will see the entire project when we’re done. No amount of scrolling in Microsoft Project will give you that view.”

There is, of course, a practical upper limit to how many activities can be scheduled using the hand technique. After about 200 tasks, we move to the projected MS-Project Gantt chart.

We plot the entire schedule with the team’s input, adding all the linkages between tasks and seeing how this drives the end date of the project. We start to see how the management mandated end date we stated when we drafted the Project Objective may or may not be achievable.

The last thing we do is take all the Issues and Assumptions and map these to project tasks. This is accomplished by numbering them, and placing numbers next to their respective tasks. This means that the Issue or Assumption becomes visible on this task, and that the person responsible for this task is also responsible for the issue.

We take all the charts back to our office and generate a Microsoft Word document containing the Objective, Background, WBS and Responsibility Matrix, as well as an Microsoft Project Gantt chart.

The project has been progressively elaborated in one day using our six honest serving men: WHAT, WHY, WHEN, HOW, WHERE and WHO.

Most projects can be planned in one day, some go to two and there are some major new pharmaceutical development projects that take a couple of weeks to plan. But these latter projects require us to sit one-on-one with subsets of the core team to go over the schedules of their activities, not the full team.