Decision Making: Trusting Your Data

Your information is only as good as the effort you put into keeping it current. What you need is project data.

What you learn from your data can be the difference between managing by the skin of your teeth and managing your projects as a professional PM; making decisions based on facts.

It is the difference between following every goose-chase, looking for the ones that might put your project at risk, and identifying the real risks quickly and early.

In order for ‘information’ to become project ‘data’ it must be documented.

Project data is any documented information related to your project, e.g., project plans, business cases, PMO documents, emails, logs, presentation decks, minutes, agendas, status updates, etc.

Project data is not hallway conversations, meeting discussions, gossip, innuendo, hearsay, body language, or tone of voice. Verbal information remains just that until the commitment to document it is made. It is more difficult to deny something that was written than to deny something that was said.

The value of the information is directly related to the level of commitment behind it. When project information is documented it is published for public scrutiny and does not rely on the accuracy of individual memories.

Using the Pareto rule, 80% of the problems are the result of 20% of the issues. To find that 20% you need to gather, organize, validate and analyze your project data. Mine the 20% that will give you the biggest bang for your buck and delegate the rest.

This could be interpreted as ‘passing the buck’, but at the end of the day your job is to manage the project, not to personally solve every single issue that arises. The 20% usually has a component whose consequences would directly affect the scope, schedule, cost or quality of the end product and, by this definition, falls under the jurisdiction of the PM to address. The remaining will generally fall within the realm of responsibility of the Subject Matter Experts (SMEs), requiring a greater depth of knowledge/experience than a PM would typically possess.

After all, every project has a team. Each team member is responsible and accountable for their deliverables and it’s the PM’s job to leverage their skills, talents and strengths by assigning them the issues to manage that they are best suited to resolve.

For example, a working project plan with an unusually high number of tasks that are locked with “Start No Earlier Than” or “Start No Later Than” constraints will hide impacts to the critical path, particularly if these tasks have predecessors and successors.

Locked-down tasks are common and often done this way due to a lack of experience with project management applications like Microsoft Project. However it may also be done to intentionally give the false impression to unsuspecting stakeholders that certain key tasks, or milestones, are on track. In reality, delays to other related tasks, even if updated in the project plan, will never show you the TRUE state of the project.

This is a big yellow flag and should bring the status of the project into question. This is an example of using your data to drive decision-making. If your focus is too far down in the weeds (solutioning) this can be missed until it is too late to recover without going RED. The net impact is that this may bring a greater level of scrutiny to your project.

If you can’t clearly articulate (and back up with data) your project’s critical path and total slack in terms of number of days or weeks before your critical path is negatively impacted, your project plan data needs to be cleaned up.

Well, this ‘data’ is all over the place. How do I pull it all together in a way that makes it meaningful? At the end of the day, all data leads back to the project plan. This is your hub and baseline. The data is always reviewed and validated within the context of ‘how does this impact my scope, costs, schedule, quality of deliverable, or quality of my team’s performance?’

How often should you validate your data? If you’re working on a large project with a minimum lifecycle of six months to a year, anything more frequent than weekly is likely to be a waste of time. The numbers of mission critical issues that can crop up in that time are likely to be few. Less than monthly is too long for a potential risk to fester before it gets noticed.

Why should you spend your time validating and reviewing data? The real question is, ‘where is your time best spent?’ Meetings are excellent for validating existing information or to uncover new information followed by documentation. Consensus is vital to ensuring that the issues are clearly understood and your data is validated.

The real win is not whether you spend the time validating your data. Rather it is how efficient you become at it. For example, how you file away your information will directly impact the time it takes for you to find, analyze, and act on it.

You may have a project administrator who can do this in addition to the meeting bookings and minutes that they may be tasked to do. Depending on the size of your project (and the expected Net Present Value of the business case) this resource may be fully cost justified. A well-trained, dedicated project admin is worth their weight in gold!

For those who do not have that luxury, there are tools out there to analyze your data, (Gantt Charts, PERT Charts, WBS Charts, etc.) a simple to use but well designed filing system (paper and electronic) can reduce the time spent doing this from hours to minutes. Any tool that you can use to capture, process and analyze your data is one worth spending money on.

Once you’ve spent the time validating your data, you need to take advantage of it. You need to mine your data, find the ‘nuggets’ that will separate you from the pack, and make your decisions with conviction.