Three metrics that every CIO should demand…

A common concern I hear from IT executives is that they are not getting the project or resource information they need.  Sometimes, when asked what their reporting requirements are, they are not sure what to focus on.  Even worse, sometimes there is so much data produced through project and operational processes that the CIO is overwhelmed by minutiae and conflicting information.

Here are three resource or project-related measures that can provide a starting point for a metrics program:

1) The relative percentage and costs of actual effort spent by IT resources working across three standard work categories – operations (“keep the lights running”), service requests or “small” changes and projects (tactical or strategic).  This data can be accurately captured if the staff track their time, but if not, at least have the functional managers estimate utilization and apply blended rates to calculate costs.  The benefit of this measure is that it enables benchmarking against similar organizations in your industry.  It also provides a cost for supporting the “base asset” which can facilitate decision making regarding upgrades, replacements and technology standards.

2) Actual return compared with expected return on completed projects.  To keep things simple, set a deadline of one year after projects have completed to be used as the measurement period.  Hopefully your organization has a governance model in place that requires project requestors to quantify expected business value – if so, then you should also ensure that projects are responsible for delivering the measurement capabilities to capture actual benefits.  Even if you are unable to quantify the actual vs. expected values using hard dollars, you can start simple – score projects based on the degree to which they met expected business objectives, and calculate an aggregate score for each year and divide that by the maximum score for the year.  This metric can start to identify causes for poor returns – project delivery issues (e.g. cost or schedule overruns) or project intake issues (e.g. over-inflated business cases) which in turn can help you focus improvement efforts where you will get the best results.

3) How “busy” is your department?  Give yourself one point for every staff member or team that is at or near 100% utilization.  Take away one point for every staff member or team that is either more than 15% underutilized or more than 15% overworked.  Divide this score by the best possible score to get a percentage for optimal utilization.  The value of this metric is to highlight not only overallocations but also underallocations – both situations are undesirable as they both represent the department is not getting optimal “bang for the buck”.

Using these three measures a CIO can answer the questions:

1. Are we working on the “right” things?

2. Are we delivering value?

3. Are we fully utilizing our staff?

Overcoming Newton’s First Law of Project Management

A client of ours raised a concern yesterday that reminded me that Newton’s First Law applies to more than just physics – in the absence of net force, PM practices do not change.  The corollary is that inconsistency in PM practices tends to increase rather than decrease over time.

What sometimes contributes to this is the Broken Window (a.k.a. Monkey-see, Monkey-do) syndrome combined with the well intentioned desire to avoid imposing bureaucracy or micro-management on staff.

A challenge for many organizations is that they don’t have metrics in place to be able to justify improvements to PM practices by demonstrating quantitative improvements to profitability or other operational performance indicators.  This results in change reluctance as potential intangible benefits are offset by very tangible perceived risks.

However, one has to remember that the converse is also true – an outcome of successful change is a greater appetite for more change.  Organizations with a successful project management capability improvement program are able to foster a culture that abhors lethargy.

So how do you get your change pendulum swinging?

If you try to get the millstone of PM inertia to move through brute force, even with strong executive sponsorship and support you will fail.  On the other hand, if you adopt a strategy based on introducing incremental changes in a manner that offsets net new effort or costs on staff with “some” perceived benefits, and if you are able to reward early converts to the “new way” such that they become advocates, your PM change initiative can become self-sustainable

Stakeholder analysis – a valuable source for risk identification

A few months ago I wrote an article describing how stakeholder analysis can be facilitated through risk assessment – the reverse also holds true.  The 4th edition of the PMBOK Guide echoes this as a Stakeholder Register is considered one of the inputs into the Identify Risks process.

Ideally, your key stakeholders will all be available to participate in risk identification and analysis workshop, but if they are unable to do so, their impacts on your project must be considered.

Risk is uncertainty that matters, and a large contributor toward project uncertainty are the assumptions that have been made.  Some of those assumptions are the perceptions of key stakeholder influences and feelings about your project.  You can imagine the negative impacts that might occur if you assumed that a key stakeholder is positively oriented towards your project, when in fact, they are secretly plotting its failure!

This is one of the reasons why successful change projects (regardless of whether those are process, construction or product development in nature) are usually characterized by thorough stakeholder analysis and regular, open communication between the project team and key stakeholders.

Sometimes it may be difficult to get a stakeholder to share their true feelings directly with you or your team – this is a situation that benefits from a positive relationship with your sponsor or with other stakeholders as they may be able to provide you with these insights or may even be willing to meet with a reluctant stakeholder themselves to elicit this information.

If you are unable to get this information, or suspect that a stakeholder may not be as open as you would like, treat them as a source of risk – assess what possible effect they could have on your project’s objectives or constraints, what is the likelihood of them acting in a negative (or positive if we are considering the opportunity-side of risk management) manner, and how best can you detect this situation and respond to it?

It is too easy to focus on your primary customers, your sponsor and your project team when planning & managing a challenging project.  The original definition of stakeholder denoted a person who temporarily holds money or property while its owner is being determined.  Ignore your stakeholders, and the property you’ll put at peril could be the success of your project!