How to plan a project

Here's an article I wrote a few years back showing how to plan a computer systems validation project. The methodology works for any project and it's the way I've been successfully planning projects for twenty years.

Project management techniques are universal. The proven, time-honored disciplines that make up project management can be effectively utilized and applied by virtually any manager, leader, or team member—regardless of industry, profession, or job title. The same skills I have used to develop and bring medical devices to market I have used to remodel my home and, most recently, validate pharmaceutical systems.

As Vice President of Project Management at QPharma, I train my project managers in a system I have developed over the years called Progressix^SM. The word is derived from three concepts central to my teaching:

1. Progressive elaboration. The concept that a project needs to be elaborated progressively as we move from Idea^*, to Purpose^*, to Objective^*, to Work Breakdown Structure*, to Responsibility Matrix^*, to Schedule^*, to Budget^*, to Risk Analysis^* to full Project Plan^*. The project continues to be elaborated through execution and into closeout. (I first learned this order of project elaboration 9 years ago through a class I took from Cadence Management Corporation and have used it successfully since.)
2. Six honest serving men. I use a poem from Rudyard Kipling to illustrate the key things that need to be known about a project to ensure a good, manageable plan.

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

3. Progress. Using the Tuckman Model, progress is made when the team moves from an awareness phase (which Tuckman refers to as FORMING*) through a conflict / control phase (STORMING*), a cooperation phase (NORMING*), and, finally, a productivity phase (PERFORMING*). This concept is evident with any group and is particularly useful in project teams.

So how do I go about this progressive elaboration? Let me use the example of a computer system validation we recently planned for a client. I became involved in a project that was already underway, because it was in trouble and the client had seen the success I had at projects in other departments.

The project was a corrective action tracking system. I was present at a very contentious meeting where two sides, the Clinical and the Information Services departments, were pointing fingers about how the project should progress. The meeting was very acrimonious, with little likelihood of any work being accomplished in the future.

Someone suggested I intervene, so I asked a simple question: “Who is the project manager?” Two hands rose, and I nodded, expecting them to glare at one another. But they had a different problem. One said she was the project manager from the programming group, and the other claimed to be the project manager from the users’ group. They added that they loved working together. I announced, however, that there can be only one project manager, and they needed to decide who it would be. The programmer was decided upon.

I requested that all the project participants, including the users and heads of the clinical and IS^* departments, be present the following week at an all-day project kick-off session, which I would facilitate. They all agreed and, when the meeting time was decided, I sent out an agenda as shown below:

AGENDA

Time	Item	Led by..
9:00 – 9:05	Check in at room, Introductions	Bruce
9:05 – 9:15	Icebreaker exercise	Bruce
9:15 – 9:30	Project Background	IS & clinical heads
9:30 – 10:00	Project Objective	Bruce
10:00 – 10:30	List of Deliverables	Bruce
10:30 – 10:45	Break
10:45 – 12:00	Work Breakdown Structure	Bruce
12:00 – 1:00	Working Lunch
12:00 – 2:00	Responsibility Matrix	Bruce
2:00 – 2:15	Break
2:15– 4:30	Schedule	Bruce

I arrived early, and posted my responsibility matrix and schedule charts on all the walls. People were slow to arrive (is this an IT thing or is it just me?), but they were all present just before 9:30. I scanned the room and, sure enough, Clinical was on one side, IT on the other.

I started with introductions and then we went into a quick icebreaker exercise, which melted rather than broke the ice in that room. The one I chose was participant bingo, where I had a 5 x 5 matrix filled out with things like: “Drives a red car; Has more than three children; Loves the show Survivor,” etc. People tried to achieve Bingo by taking it around and getting people to sign their names in the appropriate box.

Next, I entered the six serving men scenario by answering the first question: WHY? Both department heads were 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, was easily answered as only the US offices, nowhere else in the worldwide offices of this company

Then I took over. The room was clearly in a FORMING mode,
(polite, high morale, not much work going on), typical in a kick-off meeting. But they were used to STORMING outside this room, and I knew I had to get them through that stage to reach the NORMING and eventually PERFORMING stages. I typically accomplish this through the use of a project objective session. Not that I expected the team to continue PERFORMING from this point on. I just needed 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 I use is the NASA space program. I asked all the members of the room if they could remember back 40 years to the speech John Kennedy made to the nation about the space program. “Could they remember the project objective of the Apollo program?”

Some remembered, “Put a man on the moon.” Another remembered, “Before the end of the decade.” I had to remind them of the part that increased the complexity of the project: “Return him safely.” I informed them that Kennedy never told the American people what he told Congress: that the project would cost “Ten billion dollars.” (Even that was not the true objective. NASA predicted twenty billion dollars; Kennedy knew he couldn’t get this in one shot, so he asked for ten.) Eventually we had the whole 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 $20 Billion.”

The NASA objectives, I went 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.

I asked the team to come up with an objective for this project that met the same standards as NASA. I asked them to throw out words that they would like to see on the project objective, and I wrote these all on the white board with no challenge or editorializing. This is where peoples’ agendas came out, and I could predict which department they represented 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 had started.

I then explained 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 $20 billion for it. Still, people will live without seeing the golf ball hit on the moon.

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

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

During this session I kept a flip-chart open to a blank page with the heading “ISSUES & ASSUMPTIONS.” I recorded all assumptions being made as we refined the scope. Any issues that surfaced that we were unable to resolve in a few minutes, I recorded here for future resolution.

After we had refined the list of objective items to a minimum, I forged trial objective statements, which the room critiqued and revised until we had a sentence that everyone could stand behind. I insisted on unanimous agreement to the objective, over some people’s wishes to put the earlier objectives to a vote. My goal was to have no one leave the room thinking, “That’s not my objective.” When we had agreed to the final objective and read it aloud a couple of times, I covered it up and asked the room to repeat it.

“Implement an automated system for Client-US to track all CAPAs* that fulfills:

-Quality Systems requirements

-applicable government regulations

-our commitment to the FDA

by 11/30/2001”

They all repeated it verbatim, and there were pleased looks around the room. We had reached the NORMING stage of group development.

The group took a break on this high point and there was a lot of mingling this time.

When we reconvened, we went through the second part of WHAT this project consisted of, by listing the deliverables. These are the tangible things (usually documents in a validation project) which are handed over at the completion of a project. There are also deliverables used during a project, like a house’s blueprints, or a project Gantt chart. We came up with 22 deliverables including URS, FS, DS, IQ Protocol, IQ report* etc.

	The next session shifted 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 I 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, I placed Post-it notes around the room with the deliverables we had identified and asked the participants to place Post-its with tasks vertically underneath the deliverables. They naturally gravitated to the deliverables of the most interest to themselves. I showed them how to do it with the Project Plan deliverable, and let them go. I wandered around offering help and reminding them of the verb-noun format to use. I told them not to worry too much about order since they were Post-its and could be moved easily later.

Occasionally, they would ask me how far to break down a task. I told 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.

I reminded them that these were 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 I increased the feeling of ownership the team members had for this project. When they were all finished, I asked each person to present their deliverable breakdown to the rest of the room for critique. The question I asked frequently during this was, “If you do all those tasks, will that deliverable be complete?” This often generated more tasks. When all the deliverables were presented, I asked the question: “If you do all those tasks, will the project be complete?” Once again the answer was “No”, and we had to add deliverables and more tasks. The walls were soon full of tasks, and I had to place a call to the office to bring more charts, as I could see the project was far bigger than I had estimated. (Part of the WBS is shown below.)

The next part was to determine WHO would do all these tasks. I used a tool I learned from Cadence Management Corporation: The Responsibility Matrix. All the team member names were placed on the Y-axis and the task Post-its were placed on the X-axis. The deliverable Post-its were placed above the group of tasks they represented to show the connection. Where these lines intersected, responsibility for a task was indicated in two ways: “Responsible” or Contributor.” I announced a task to the room, and someone volunteered that it was their responsibility to see that task to completion. They may not do all the work; just ensure that it is completed.

I placed a dot enclosed in a circle at the intersection of that task and person. Then I asked that person if they needed help, and they indicated other people or others volunteered. I looked to the people indicated and allowed them to volunteer before placing a dot at those intersections.

I never assign or allow anyone to be assigned to a task. This session must be done voluntarily, once again to increase ownership in the project.

At this point, everyone remarked on the immensity of this project and their role in it. They were sobered and started questioning the date in their objective. I reminded them that this was a management-mandated date. When we finished the day’s session we would know the date we could reasonably complete the project and there were steps we could take to reconcile the two.



(One page of the Responsibility Matrix)



We took a break and when we re-convened, I had the wall plastered with blank Gantt charts. The tasks were written in on the Y-axis and dates were written along the top X-axis. I took the first task of the first deliverable and asked the person who had taken responsibility for it two questions: What are you waiting on to start this task? How long will it take to complete it?

I drew in bars to represent this start date, duration and linkage, as I would in Microsoft Project. I was questioned why I didn’t do this on a laptop and gave 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.”

The PERFORMING stage we had achieved at the end of the Responsibility Matrix session quickly degenerated back into STRORMING when we began defining relationships between the deliverables. The clinical group claimed that these deliverables were complete; the IT group insisted that they needed to be revisited before moving on to other deliverables. I was forced to plot a network diagram at the deliverables level. This is not exactly the right thing to do, since only tasks can be linked properly. However, I managed, in the time allowed, to show which deliverables needed to be complete before others could begin. Once the team had agreed to this network and we were back in the NORMING stage, we could continue with the schedule.



One page of the network diagram



 

I plotted the entire schedule with their input, and the groans increased as they saw the timeline moving further and further from the objective date. When we finished, the date showed August instead of the November date for which we originally hoped. However, all the participants knew that there was no date padding going on. We might be able to bring the timeline back to June or July, but there was no way this project could be completed in two months.

The last thing I did was take all the Issues and Assumptions and map these to project tasks. This was accomplished by numbering them, and placing numbers next to their respective tasks. This meant that the Issue or Assumption would become visible on this task, and that the person responsible for this task was also responsible for the issue.

I took all the charts back to my office and generated an Microsoft Word document containing the Objective, Background, WBS and Responsibility Matrix, as well as an Microsoft Project Gantt chart*.

The project had been progressively elaborated in one day using my six honest serving men: WHAT, WHY, WHEN, HOW, WHERE and WHO. It was an eleven-month rather than a two-month project with some serious issues clouding it. The clarity this process gave to the project was enough to allow senior management to decide to cancel it and spread the resources out onto the other 13 projects we are currently managing for this client.

I was also able to salvage the WBS from this project and use it as a starting point for the rest of these projects, saving a significant amount of time on those kick-off meetings.