Murphy’s Law does not have to be a universal constant when managing projects!

A LinkedIn question this week asked whether Murphy’s Law is inevitable on projects.

The very definition of a “project” favors the conditions for things to go wrong as we are striving to create a unique product, service or result.

In addition, projects (most constructive ones at least!) would appear to run counter to the second law of thermodynamics as they are an attempt to bring order to chaos or to reduce entropy.

Given these conditions, one would expect that Murphy would run rampant in projects, and in many organizations this seems to be the case.  I’m not a fan of pessimistic project management as that state of mind can result in a self-fulfilling prophecy.  Blind optimism isn’t an appropriate state of mind either.  Instead, Murphy’s Law should validate the need for project and resource management practices:

• Right-sized project risk management can help to reduce the impact and magnitude of uncertainty – Murphy could still apparate, but by thinking through (realistic) scenarios on what could go wrong, responses can be developed to reduce the likelihood of firefighting.
• A work breakdown structure and project schedule provide a model for what will be delivered and in what sequence activities will be performed.  This reduces the potential points of impact from uncertainties when compared with a project where the team “just does it”.
• Striving to plan resource allocation at sane levels (at or below 100% on a weekly basis) means that if Murphy does strike, team members might actually have capacity to deal with it.  If you’ve already planned resource allocation beyond 100%, no such capacity exists and you will simply make Murphy stronger by introducing further risk through resource fatigue,  morale issues or burnout.
• Kickoff and regular status meetings provide an opportunity for team members, sponsors & stakeholders to reinforce their alignment towards the shared vision for the project.  This is akin to the approach used by many animals to protect themselves from predators (a very material form of Murphy’s Law!) – solidarity provides security and stragglers are usually picked off.
• Conducting retrospectives or lessons learned sessions on a regular basis (and not just at project closure) can cultivate and disseminate organizational knowledge which can also help to reduce Murphy’s visits.

Through consistent use of PM practices, you too can embrace Captain Kirk’s belief “I don’t believe in the no win scenario”!

 

 

Using the 80/20 resource rule to help justify strategic IT projects

A challenge for some CIOs is securing funding for strategic IT projects if they have to lobby for this funding against profit-generating or customer-facing projects from other functional areas.

Selling such projects based on risk mitigation or operating cost control might sometimes work, but the first assumes that the costs of the project is outweighed by the expected cost of risk realization while the second might result in the CIO’s feet being “held to the fire”.

A different spin on justifying some IT projects might be to evaluate whether they address the common issue of 80% of IT resources being dedicated to maintaining the base asset (a.k.a. “keeping the lights running”).  If the majority of potential project resources are diverted towards operational or tactical initiatives, this reduces the number of strategic projects that require IT resources.  And as most modern business transformational projects have some reliance on technology, this can result in  competitive disadvantage.

Based on this, one approach to justify expenditures on certain IT projects might be to emphasize increasing (potential) availability of IT resources for strategic work.  A baseline can be derived if your department is doing time capture – calculate utilization over a three to six month period for two standard “buckets” of work: operations or tactical work that maintains existing service levels and strategic project work.

Reducing operational resource burden by upgrading or replacing a critical system might entail a one time “hit” to fund the systems replacement project but will provide an increase in sustained resource availability towards strategic work.  This is not a “smoke & mirrors” sell – assuming utilization metrics can be calculated, it should be possible to objectively assess whether expected benefits were realized or not.

Demonstrating how a greater percentage of transformational projects could be delivered by investments in strategic IT projects is another progressive tools towards improving the IT engagement model with the rest of the business.

Agile has NOT “jumped the shark” with PMI’s latest certification!

In late 2011, PMI plans to launch their latest certification, the PMI Agile Certified Practitioner.

PMI supporting agile methods by offering such a certification should be taken positively, however, many cynics and naysayers may not agree.

There might be the perception that a stereotypically “heavy” PM association would only support agile as a pathetic attempt to stay relevant or (for those that are even more cynical) to make more money from “certification-chasers”.

Here’s why the development and implementation of the PMI-ACP certification is a good thing for agile.

1. PMI’s standards and the certifications that are aligned with them focus less on low-level implementation details and more on providing a broad understanding of good practices.  This addresses one of the challenges many organizations face when adopting agile methods – they sometimes focus too much on implementing specific methodologies and less on embracing the guiding principles & philosophy behind them.
2. For traditional companies that may be hesitating about investigating agile approaches given some of the hyperbole and fanaticism exhibited by some “fringe” agileistas, PMI’s support for agile will provide some additional sponsorship and credibility.
3. The inclusion of the Agile Manifesto within the certification content pays homage to the origins of the movement and emphasizes its core values and principles.
4. One of its objectives (as taken directly from PMI’s certification content outline) is “to show that the practitioner has the capacity to lead basic Agile project teams”.  PMI does not try to claim that certified practitioners will be able to successfully manage complex agile projects OR to successfully introduce agile methods into waterfall organizations.
5. The content for the certification does not advocate or focus on any one specific methodology (e.g. Scrum, Extreme Programming).

Given the large numbers of agile practitioners and the stated objectives for the certification, it would have been challenging for PMI to have designed the PMI-ACP certification process to mimic the PgMP (which includes the use of a panel review and a multi-rater assessment).

As I wrote in an earlier article, knowledge-based certifications are not ideal, but this still represents a positive move for PMI.