Project Planning 1.1: Project Tracking - Plan for it Now!

[Also available as a Podcast]

Project tracking is an important element of control on any project. During the project, you need to be able to measure and report on progress against project deliverables, and roll-up that information into higher and higher levels, until you often end up with a high-level dashboard for the Project Sponsor and other executives (red light, green light, yellow light). And in the long run, you need to be able to know when you have actually finished the project, and if you have succeeded in achieving the project goals.

Sounds straightforward, right? But as you probably already know, it is not quite so simple. There are many projects that do not track enough information, and others that track too much. All of this tracking requires effort, by the individual team members, their team leaders, the Project Manager, and those who receive the status reports.

Asking people to spend "overhead" time on activities like status reporting when they do not see any direct relation to what they are doing, and how it is used can be another big problem - if they do not see value in doing it, it becomes a "chore" that they would rather not do - so they may delay doing it, not do it at all, or worse, "fake it".

Sometimes all that effort results in only a cursory glance at the highest levels. So why bother with it? Or the information can become so disassociated due to poor structuring when it is rolled up that it becomes effectively meaningless. This problem can be a related to how you have structured your Project Plan, and also your approach to tracking. That, of course helps nobody.

So what do we track, how do we track it - and most importantly, how do we plan for it and what do we do with it?

In this session we will explore the essentials of Practical Project Tracking - what you will need to manage your project, satisfy the reporting needs of your stakeholders, and be able to tell, in the end, if your project was successful.

Practical Project Tracking

Note: I have introduced this topic immediately following the Project Kickoff rather than leaping straight into Project Plan development, because deciding what you are going to - and how you are going to track it - go hand in hand. If you build the Project Plan and then think afterward about how you might track it, you have actually started backwards and may need to do some re-structuring. You need to be prepared and thinking about tracking first - before you build the detailed plan.

If you have read any of my other articles, you will know that I like to keep things simple. I have managed some very complex projects, so it is not the projects that are simple - but any processes you use within the project team should be simple, clear and easy to follow. Make something simple and people might actually use it. Make things complicated, and you are fighting a losing battle because people will resist it. They may make a half-hearted attempt to do it at the beginning, but usage will generally fall off over time. Or the number of errors introduced because people do not understand it or how to use it will soon make any information collected unreliable.

In fact, I like to think that the more complex the project is, the simper the processes the PM introduces need to be. People's heads will be so full of all the other complex detail, it can be a relief to follow some simple steps a few times a week. They might even come to enjoy providing status to you! (Well, OK, maybe not - but they will be less likely to see it as a burdensome chore).

So keep it simple. But in saying that - you can produce some very complex statistics and other project measures using data that is collected with simple processes - so this is by no means "dumbing it down".

1. Why Track?

There is an old saying that goes "you get what you inspect", or alternately "you get what you test". If you have no way of determining what is happening on the project, what has been completed, and what issues there are that might trip you up, how can you make sure you are on track? If you are not looking (or not looking in the right places), things will continue along quite merrily - until they sail right off the cliff.

The basic purpose of tracking, put simply, is to be able to answer these three questions:
- Do we know where we are now (what we have done up to this point)?
- Are we still going in the right direction, and what obstacles might be in the way?
- How will we know when we get there?

If we have enough information to answer these three questions, whatever form(s) it might take, then we can take corrective actions if necessary, and fine tune the next steps to catch up, and/or to keep the project on track.

Another aspect of tracking and measurement is analysis/review - no point collecting information if you are not going to do anything with it. The Project Audit may see a clear path to failure in your detailed records, but it is better that you use the best information available to stay on top of things and, like a GPS, do minor course corrections as you go - vs having to backtrack a long way when you have gone too far off the planned route.

1a. Ask the Question: Why do you need it?

The next thing you need consider when planning to track your project is: "What will we do with the status information?"

"Easy" you say - "we use it to manage the project." Well, yes and no. You need to consider your stakeholders - yourself (as the PM), the project team, the Sponsor, and any other key people in your Stakeholder map that are (A)ccountable or that need to be (I)nformed on the progress of the project, and made aware of any issues that need to be escalated to them, decisions that need to be made, etc.

Your reporting requirements may be for two main groups (the Project Team and "the Sponsor and all the rest of them"), or you may have several distinct groups that you need to report to. The information that you need to provide may also differ from stakeholder group to stakeholder group.

Let's consider this further.

- As the PM, you know what types of information you typically collect on a project "of this type" to ensure you have enough information, in a timely enough fashion, to make sure the project stays on the rails, moving in the right direction, and that you still look to be "in scope/on budget/on schedule" etc.

- The others are a little harder. You might guess at what they might want, because on the last project the stakholder groups, the sponsor etc all wanted particular information. But a better idea is to ask them what they want. Each stakeholder group may need different slices or views of information - some may want to just see the financials to-date. Some might want to see overall progress as %completion, and the CEO may just want a red/green/yellow dashboard. Give each group exactly what they want - and not more than they are asking (at least for now - they may refine their reporting needs later). You should also ask them how often they want the information reported (weekly, bi-weekly, monthly, quarterly, etc).

Still not clear on what they are looking for exactly? Ask them to provide you an example from another project, or have them draw it out for you (or they describe it, you draw it, and they validate it). You may find out that the information they require might actually affect the evolving stucture of your project plan. (They may want overall or detailed status by particular stages of a long-term project, or by major deliverable groups, etc). The more you know now, the easier it will be to make sure that your project plan/WBS meets your needs - but also does not become a headache when trying to report to stakeholders.

Tip: This will become an important part of your Communication Plan.

Once you have a perspective on what the different stakeholders need, plus what you need to manage the project, you are in a much better position to figure out what you do - and don't  - need to collect in terms of information, and how you might go about structuring it. You may find that you can simply "roll up" detailed status in the project plan to satisfy some of their needs. Or you might need to do some more typing - i.e. if they need to take action on anything in the CRAIDL, particularly Issues, Decisions and Risks.

Note: We won't cover the actual Project Plan development in this session, so just keep this information on tracking in mind as you think about your project plan.

- Who needs to provide the information? This may seem obvious, but take some time to think about it. Is it the Team Lead? Or the individual team members? Or more likely a combination of both? I suggest that it depends on what the information is, and also what tools you might have available.

For anything in the CRAIDL, the updates will tend to be "textual" - that is, not firm facts and figures, but descriptions of the issues, risks, decisions that need to be addressed, or are holding things up because they have not been addressed, and the status/disposition of previously raised items. This type of information is more suitable for the Team Lead to collect and provide to the PM on larger projects; if you have a smaller project then each team member could be doing this themselves.

For progress updates against the plan tasks/deliverables, either effort-based or calendar-based, ideally this will be fed back into the project management tool "at the source". I don't tend to trust progress updates that say "55% complete" as the sole measure; often the percentage is based on gut feeling and is not meaningful. However, "projected delivery date" and "actual hours" are generally more useful measures. If 48 hours of an 80 hour estimated deliverable have been  expended on the task we can calculate 60% completion. (Sometimes it might not be, example for a deliverable that involves initial delivery and test/revision cycles, the overall estimated hours is not useful for seeing if the "first delivery" is on track; you would need to break it down).

A note of caution: Some sponsors/stakeholders tend to ask for specific information "on every project" the same way, every time. Do not be afraid to challenge them to think about what they really need this time - they might in fact need all of it, or they might only need a part of what they normally ask for on this project. Just asking this question can save you hundreds of hours of effort if you are producing status information that is not actually used. In addition, you will get better sponsor/stakeholder involvement and participation - because they see you as caring about what is important to them, and that you are being a good project steward and efficient with their time and the project $. 

Of course, this could end up with you providing more information than they previously had, depending how your discussion goes. But if you are a clever and practical PM, you will offer up metrics and information you are already needing or planning to do anyway. And they may be so delighted with your suggested status reporting that makes their lives so much easier, they may take you to lunch - or more importantly, approve the inevitable change requests you really need later on without too much trouble.

2. What should we Track?

Well, there are many things you can track. There are any number of formulas for calculating project status, ROI, progress and performance. The ones you will need to use will depend on the reporting needs for your project. You can get pretty sophisticated - even with some basic data points. Note: This is not a discussion on the application and use of those forumulas - there are a number of very good books on the topics of advanced measurement and analysis.

There are three main types of information that can be collected/measured:
a) Hard data (dates, hours, budget vs actuals, defect rates, number of versions, etc)
b) Objective information (Risks, Issues, Decisions, Descriptive status reporting)
c) Subjective measures (customer satisfaction, "mood" of the client, etc).

On a project of any significant size, you will need to consider all three categories; for smaller ones just the first two.

Hard Data Measures
At the simplest level, information is commonly collected for the following
- Completed tasks/deliverables [to date, or this period]
- Tasks/deliverables in progress
- Tasks/deliverables coming up next
- Actual hours expended (to date) vs Estimated
- Actuals vs Budget to date
- Deliverable progress vs estimate (we are going to be 2 days early, or 7 days late) 
- Progress by duration (half the time is spent, we should be half way to completion, or not)

Objective Data Measures
The other important things to remember to track, manage and get updates on regularly are in tucked away in the CRAIDL.
Constraints: Any impacting the team that need to be discussed?
Risks: any new ones identified, or recorded risks have occurred (Risk Event) or are more likely to soon?
Assumptions: As we go through the project we may need to correct assumptions or add new ones.
Decisions: Are there new ones that need to be made? Any outstanding that are holding up progress? What were the results of the recent decisions? etc.
Lexicon: This may seem a minor detail, but if there is new jargon, buzzwords or acronyms, remember to update the Lexicon. This will also feed the Communication Plan.

Subjective Measures
On longer projects, you will generally need to do some periodic subjective measures such as customer satisfaction, client or department/stakeholder group mood, and perception of deliverable quality. There have been countless projects that have delivered to specification, on time and on budget - and failed because it did not meet the subjective success measures. Of course we are not saying scope and requirements are irrelevant - they most definitely are not - but if you have a finger on the overall pulse of the client, the stakeholders/end users and pay attention to the big picture, you may have a better chance of introducing or getting a change request approved that will end up with a better result for the client - and you (as team/vendor).

Adding it up
As you see from the above, not all of your status tracking may be directly connected 1:1 to items in your Project Plan WBS. Of course they relate to it, and impact it - but some types of information will not fit easily into common project management software tools for "rolling up" to higher levels. You still need to track it though.

You can also come up with other measures that you might want or need to track, so the above list is not necessarily "complete" for all projects.

And of course, the scale of your project factors into this too - there is a significant difference to the tracking performed on a 1 month project involving 3-5 people vs a multi-year, multi-department project involving a 30+ member project team. Generally the shorter the project, the less you need or want to track - otherwise you are doing more "overhead" than "doing the project". But in the larger projects, without the tracking and cross-checking measures in place, you will quickly lose control of the project.

In short, you should only track what you need, and no more - the critical bits you know you need to do as a responsible PM, and also enough information to satisfy the stakeholders, and to ensure a smooth flow of information.

3. How do we track it?

This is a tricky one. It is difficult to find any one system that will handle tracking the three information types in one place, or in relationship to each other. I have myself built various custom project tracking tools on larger projects to try to fill the gaps, by combining the WBS identifiers/names in a database with the CRAIDL, as an integrated cross-referenced solution. That definitely helped manage the project; the team leads all had access to the database from their own PCs. It worked very well for status reporting and meetings, and discussions where we could then identify the CRAIDL items assocated with a given WBS item, or the reverse - all WBS items impacted by a given risk. It was relatively sophisticated - it tracked status updates and effective dates as transactions for all activity related to the CRAIDL items in the database.

However, it did not have all of the "hard" data - parts of it were there, but the actual hours and financials were done separately.

And no, I'm not selling a system - it's not for sale - it was MS Access 2003 based, customized for the project, and did not scale well beyond the LAN. I just bring it up as an example of what can be done, and there may be value for you in doing something similar as well.

For the "hard data" there are a variety of collection methods:
- Hours expended [timesheets] - coded by task or task group
- Per-task updates in the WBS

You might have an integrated solution like Project Server that allows you to do all of your time entry and task level updates in one place - if so this is great; the fewer touch-points the better. 

If you just have a standalone tool like MS Project, definitely structure your plan so that it is simple for you to apply the status updates from your team - your own time is very important - you need to be running the project and communicating with the team, and spending "only just enough" time as is needed for your status reporting tasks. (Note that this part of your definied activities and should be in the communication plan - it only becomes "overhead" if you have to spend too much time doing it).

Tip: Whatever you do, design your measures/collection methods so that it is only input once. It definitely will be a chore if anyone has to put the same type of information in more than once.

The CRAIDL items can be tracked by spreadsheet, or put into a database. Or you may already have a system that will do this. I would recommend, however, that you try to track it in a database on larger projects - it will make the ongoing management easier, and more importantly, more visible. If you have the information quickly available when a risk event occurs, for example, and you know which items will or can be impacted, you are better able to respond.

The important thing is that you, as the PM, need to determine the best way for you to have the information collected, and that it comes to you in a usable form without too much manipulation. You will also want to ensure that form also lends itself to feeding "up" to the various stakeholders as well.

I made it a goal to be able to produce the various status reports in less than an hour a week; of course some automation helps (and I spent many "free time" hours building the system up front, but it did pay off as the project ran for more than 3 years). But even doing something as simple as providing a status reporting template to the team leads that they can easily fill in - and you can copy/paste into your master report - is a big step in the right direction.

These days, I am dealing with high-volume, shorter duration projects, and they have their own unique reporting needs. Again, I built a system - based on Sharepoint - to suit our specific needs; it does not have all of the CRAIDL elements this time, but it has been structured so that there are minimal touch-points for team members (less of a chore), and has a sophisitcated workflow engine to keep things running smoothly. It supports near-live status reporting, because team members updating status and hours are immediately available as they complete their tasks. It has also been structured to serve as the project system/business support stystem, and drives invoicing as well. Financial audit? Capacity Plan/Forecast? No problem - query to a spreadsheet and all of the detail is there for you to work with. 

Note: If you are interested in doing a system like this yourself, I have a free 9-part Sharepoint series on "Custom Project Systems on a Shoestring". Your specific needs will likely differ but the methods and principles will be the same.

What about the Project Plan?

At the beginning we mentioned there may be impacts on your project plan design, dependent on what you need to do for status reporting. This specifically applies more to the "hard data" measures, where you want to make sure that you can "roll up" the data to higher levels in a form that both makes sense to you, and to your sponsor/stakeholders.

There are many ways to build a project plan, all of them reasonable - but if you know how you are going to need to report status and progress, you will make different decisions on how you structure your WBS. 

- Will your top levels be functional areas?

- Will you have stages and then functional areas?

etc.

There will be further discussions on this topic in the next session - Project Planning 1.2: Building a Practical Project Plan.

Summary

 I hope you have found this session useful for your [upcoming] projects. As you can see it is difficult to describe a specific concrete solution that will satisfy everybody and all projects. But that, I think, is the point - on each project, you need to assess the lay of the land, and determine from the beginning what you will need to do for this particular project - and how much tracking will be needed. The goal is that fine balance of "just enough".

A final note - if you think that tracking some particular bit of information would be worthwhile because it "feels right" (or it kept you up at night thinking about it), even though can't see a direct reason right now - do consider including it. Your experienced gut may be telling you something. If you find later on that there are some things that need "less" tracking, you can taper their use off. But it is hard-to-impossible to go back and collect information after the fact - i.e. months later, if you did not do it in the first place.

And of course - think about who is going to be providing you all that information. Be wise in your requests on their time, and also make it visible how their information contributes to the overall health and success of the project.

So plan your tracking and measures, but be practical about it.

Good luck with your projects.

Project Planning Series
Previous article: Project Planning 1.0: The Importance of the Project Kickoff

Gary Nelson, PMP
Gazza Consulting Services