(Project Performance Management Baseline Reporting)
By Randy Tangco, PMP, CSM
Abstract
When I gave my first project status report, I had a shock. I proudly reported that my project is all green. However, the project sponsor responded by saying, “All green? Are you selling Christmas trees or running a project?” ”What does ‘all green’ mean?” She was right. What does it mean when we say a project is green or for that matter yellow or red.
This scenario is really a challenge as the goal of project status reports would be to submit accurate pictures of the project. Providing a status report that a project is either green or not is a challenge especially for project managers in a plan-driven environment. There must be a better way to accurately report what made the project yellow or red based on the project performance. There are many factors that affect the status of the project; the scope, the schedule, the resources, the money/budget and skills of the project delivery team. Since most plan-driven project uses the MS project as a tool, we will try to explore some techniques we can use to get a more accurate picture of a project. This article will mainly use MS project as a tool of reference but does not restrict the use of other tools such as primavera, HP PPM, @Task, and others.
The Challenge
What is really the challenge in tracking the performance of the project? It begins the moment you start development of your project plan (the “whats” of your project). Using the MS project tool, you would most likely try to translate the content of your work breakdown structure and the deliverables of the software development life cycle (SDLC) process you follow for software projects. The succeeding steps would be to sequence the activities/tasks to establish dependencies (predecessors/successors). You have to make sure that the dependencies are established at the task level and not at the summary level and all tasks have both predecessor and successor (no orphan task).
You would then enter the names of the project team members into the plan and assign resources names to the project activities/tasks. It is suggested that when you are building the project plan, always account for the resource availability when you are building project plan as this also determines the final duration of your project. It is also good practice to get some numbers regarding the cost of each of the project resources. This also helps set the stage for cost tracking exercise.
Now that you are done doing some basic setup, you are now ready to go into activity sequencing. Work with the team on this as it is critical that the activities are correctly sequenced and dependencies properly established for each activity/task in the project plan. Please ensure that once you are done that you don’t have any orphan activity/task. An orphan activity is one that does not have either an input from a preceding task or an output. It is also good practice to have contingency to cover the estimated risk for the project; you will eventually have a planned date and a negotiated date. The planned date is the date your team is aiming to complete the project without contingency while the negotiated date includes the approved contingency. The negotiated date is usually what you inform your stakeholders to set the right expectation. If you would ever have to reveal both the planned and negotiated dates to your stakeholders, begin the conversation with the negotiated date before discussing the planned date. Most people remember the first info you provide more than the second one.
Now that you have built the plan and created a picture of the schedule and cost, you need to submit this to the project stakeholders for approval and base lining. Now you are set to go execute your project activities.
Project Tracking
The project is now in motion and project activities/tasks are being worked on by your project team mates. Every week you will be asking for project progress report from them. Some ways of getting a picture of where the project is during a status meeting is to ask the team where we are. Some would recommend that a simple statement of “on track”, “in progress” or “late” would be sufficient. Some would ask percent complete information from the project team. The recommended practice is to ask how many hours have been spent for an activity during the week and the percent complete is automatically calculated by the tool you are using. The owner of the activity would have given his/her estimate during the project planning process and by capturing the actual hours spent by a human resource, you automatically get a picture of where your project is in terms of the estimated effort. It is also suggested that you ask your team to report physical percent complete to have a better view of progress. A project team member might report he has spent 40 hours already out of the 80 hours estimated which will give you an indication that his task/deliverable is 50% complete. However, he might only written 25 test cases of our 100 test cases that needed to be done; this is just about 25% physical complete. By having these two sets of data you can easily spot a problem. You also need to do some walking around to observe the team progress just in case something is not reported to you during your status meeting. BTW, walking around and talking to your project team mates helps because you will immediately catch if they are doing something outside of the project scope of work. An example would be a project human resource is supposed to be working on your project and you find out he is busy working on a maintenance item. This type of deviation may not sound serious but if left uncheck, it can cause you your timeline.
Are the above methods sufficient to capture the actual picture of the project? I think you will need additional tools to track cost and schedule performance. The first thing I did was to create a dashboard out from my MS project. Please refer to figure 1. As you can see in the below figure, task ID 0 gives you an over-all picture of where your project is and you can also get more detailed as you look at the progress of each summary task. As you can see you can even see the status of a specific task in your project plan.
This technique was first published in PMConnection. To view the instructions on how to implement this, go to the PMConnection website and click on the link on “Displaying Task Schedule Status Indicators in MS Project.
The dashboard gave me a way to do empirical inspection of my project plan and track possible causes of delay. This approach enabled me to forecast a date of completion by simply looking at the value in the finish column of the MS project tool. This method becomes challenging when the project is complex with many deliverables involved
The Solution
I had been doing a lot of research and one day I had the opportunity to meet Walter Lipke, the creator of the Earned Schedule (ES) method of project tracking. He was generous enough to introduce me how ES works and taught me through it daily until we finished his course on it. I began to apply it using the ES templates Walt provided. However, I still found it challenging moving data from MS project to the templates for analysis purposes. I was thinking how to integrate this knowledge into the MS project tool and being a non-VB script programmer, I have a problem. I went through the ES tools available in the ES website and tried the MS project ES plug-in from Project Flight Deck. This gave me the answer to my questions. I was able to better monitor and control my plan-driven projects using it. The plug-in enabled me to better provide status reports to all my project stakeholders with complete transparency. I was able to specifically pin-point the cause of the delay in the project and implement the appropriate management action needed to put the project back on track. Please see figure 2 for an example of the report I got from the ES plug-in. The sample figure indicated that I have an estimated nine periods or months to complete it when I started the project. The schedule variance column indicated that sometime in July I am about 0.046 months behind and our estimated completion of the project will be about 9.14 months. This info enabled me to specifically look at our July deliverables and talk to my project team about the causes of our delay if any and what can we do to recover. We discussed solutions ahead of time before the problem becomes serious due to the advance info I got from the report below. If you will notice, the efforts made by the project team to recover the setbacks in July enabled the project to be ahead of schedule when we entered August. The below report showed that we are not ahead of schedule.
The newer version of the plug-in allows you to select the granularity of your report to either monthly or weekly. This feature allows you to better generate reports for specific stakeholder audience. The newer version also allows you to select and track specific tasks/deliverables from the project plan and only track a small portion. I think this gives you an advantage if you are running a project that as hundreds or thousands of activities in it.
The only thing I was looking for is to be able to generate reports on a daily basis but kind of burdensome because you will have a very large report generated if you do this.
Conclusion
When we are assigned to be a project manager, there are many activities that come with that role and one of the critical components is the tracking of the project performance as most projects are driven primarily by schedule then by cost. I chose to use the ES method because of the benefits it gave me that enabled me to better lead my team. There are other techniques and tools out there for more sophisticated purposes such as having the capability to do Monte Carlo simulation. However, we have to choose the best applicable one based on our own constraints. We also must always practice adding management contingency in all our projects as a protection to the risk impacts; we should have a planned finished date and a negotiated finish date. The negotiated finish date includes schedule and cost contingency for the known and unknown risk in our projects.
Great post! I read about Earned Schedule a few years ago and thought it was an interesting concept. Great to see how it matured. Now, if only you had a solution for team members who fudge the numbers on their progress reports. 🙂
Thanks for taking the time to write this. I still use Basecamp and generally love it but the philosophy of your driving point is a great one.