Is your project information System of Record the grapevine?

I’ve written a few posts about the challenge of achieving compliance with consistent project management practices.

One concept I have not written about is the Project Information System of Record (I’ll let you get a Bart Simpson-level kick out of the obvious four letter acronym!).  For those of you that are not from an IT background or have not heard this term before, Wikipedia manages to sum it up quite well as being the authoritative data source for a given piece of information.

When project management procedures are properly institutionalized and these procedures are supported or automated by appropriate systems (read Vaughan Merlyn’s post on the topic of appropriate tools) the Project Management Information System becomes the Project Information System of Record.

Executives treat project information gathered through the grapevine or in elevator conversations as hearsay, and they go to the PM Information System to understand what’s really going on.  That message percolates through the ranks of stakeholders, sponsors and project teams such that the staff responsible for entering and updating project data in the PM Information System know that they need to keep the information A) Current and B) Accurate.

On the other hand, when executives ignore the PM Information System and readily accept project information through other means, they are sending the clear message that the PM Information System is a pale substitute for the grapevine.

The mantra for PM Information Systems should be “If executives swear by it, compliance should follow”.

Communication, communication, communication…

One of Alec Baldwin’s key lines in Glengarry Glen Ross is the line he spits out to the sales team: “Always be closing”.  No, this article is not about to draw comparisons between project managers and shady salespeople – at least not those that try to follow PMI’s Code of Ethics.

What it does get me thinking about is the simplicity of that three-letter acronym “ABC” – if we had to boil project management down to a single word, which would best represent our multi-faceted profession?

My vote is for Communicating – after all, we are taught in most foundation PM courses that communication represents the lion’s share of what PM can be distilled to (whether or not you subscribe to the 90% rule).

Think back to the last project you worked on that got into trouble – I’m betting that a contributing cause as well as a key solution to the issues could be traced to communications.

This is why our profession is both an art and a science – were it purely science, a computer could plan and execute a complex project perfectly well.  One of the more interesting episodes from the first seasons of Star Trek is The Galileo Seven – it illustrated that putting a logic-driven, seemingly emotionless individual in charge of a group of human beings did not always result in cooperation or optimal problem solving.

How about some other choices?  None really comes close to distilling what we do as well as communicating, but you could consider: controlling (only if you are a megalomaniac), calming (you’re a PM, not a psychologist) or collaborating (good try, but that’s just one way to get to a decision).

Risk assessment provides another input into stakeholder analysis

A challenge faced by project managers is identifying and analyzing the wants & desires of the stakeholders for their projects.

It’s hard enough to elicit full requirements from your primary project customer, but when you are trying to understand the over & hidden needs and concerns of stakeholders that may not be directly involved with your project this gets even murkier.

There are a variety of techniques that one can employ to gather requirements from stakeholders, but it is worth drawing attention to one method that might be overlooked: risk assessment.

Dr. David Hillson refers to risk as “uncertainty that matters” and it is the last word in that phrase that I am focusing on.

When you ask a stakeholder directly for his or her input or perceptions of your project, you may not get a straight or honest answer.

However, when you engage your stakeholders in a risk identification & assessment session, you may find that they will open up more than they would in a one-on-one setting.

When they are presented with a risk identified by someone else, pay attention to their assessment of its potential impact or probability – this can start to give you an idea of their overall bias towards or against your project as well as to understand what their specific “hot buttons” might be.

When their turn comes to identify or brainstorm risks, this can provide you with a glimpse into their concerns as well as their overall risk bias – both of these are useful inputs into your stakeholder analysis and can help you define the stakeholder management & communication approach that you’d want to use with them.

Stakeholder analysis can often feel like you are searching for enemy soldiers in a tunnel without the benefit of night-vision goggles, but appropriate use of risk identification and assessment techniques can help to shed some light on this crucial step in project planning.

Holistic earned value – a better metric for evaluating project portfolio performance?

We’ve all felt it – that sinking feeling in your stomach that tells you something is wrong.  During the last Ice Age, it might have been experienced when our ancestors heard the growl of a saber-tooth tiger.  These days, it is that preternatural sense you get when your project doesn’t seem quite “right”.  There is nothing wrong with instinct, but it is important to remember that “gut feelings” are driven by a part of the brain that has not evolved in thousands of years, so we need something more objective to assess project health.

Earned value is a best practice approach to evaluating project performance based on the correlation between expended costs & effort and delivered accomplishments.  However, it is not a holistic metric and does not consider criteria such as:

- Is what you are delivering still expected to create true business value?

- What about the impact of project issues?

- What about the potential impact of project risks on future work items?

Perhaps it is time to consider enhancing earned value to provide more coverage…

Start by taking each work item and give it a weighting based on a prioritization done by the customer on its relative value – must have deliverables would be weighted much higher than the nice-to-have ones.  By doing this, you can ensure that a waterfall-style project that is heavy on documentation early on will not be able to claim significant earned value until the customer starts to see real results.

You can further extend this by building in the impact of issues and risks – issues should be affecting actual costs.  The key change is to identify the work items than a particular issue impacts so as to properly allocate issue resolution costs.  Risks on the other hand would affect budgeted costs – expected impact values should also be allocated at the work package level instead of at the project level.

The key with this approach is that the value or priority-based weights, as well as the risk based updates will cause the budgeted side of your earned value calculation to change more frequently than it would with the classical approach.

By taking this approach, earned value management can be extended for use in agile methodology projects as well as traditional waterfall lifecycle ones.  It will also help to reduce the number of metrics that need to be tracked at the portfolio level to a handful.