PM Quote of the Day — Dietrich Bonhoeffer

If you board the wrong train, it is no use running along the corridor in the other direction

Podcast on barriers to successful IT/CRM

Michael Krigsman over at IT Project Failures hosted the first in what he hopes will be a regular series of “Town Hall” podcasts (here)  It was originally supposed to be a meet-up, but the weather was dodgy at best so the session went virtual. 

Anyway, Paul Greenberg moderated an excellent discussion that covered a lot of ground.  As Michael notes, Paul’s CRM background focused the conversation

…on issues drawn from customer relationship management. CRM brings together core business functions — how a company interacts with customers — with technology intended to streamline and improve those relationships. Since these goals are business-oriented, CRM offers excellent examples of non-technical failures connected with technology implementation projects. For example, one participant noted corporate managers sometimes deploy CRM hoping to control end-users, who in turn reject the system in a predictable failure. 

Be warned… I jump in at about the 30 minutes mark!

Projects can die a good death

Hello.  My name is Inigo Montoya.  You killed my project.  Prepare to die.

Hello. My name is Inigo Montoya. You killed my project. Prepare to die.

Nice to see that projects are being ended more often than I would have thought.  Michael Krigsman (here) points to a survey (here) where just under 45 percent of the surveyed organizations claimed to have ended a IT project before it was fully implemented.

Roughly half of these projects were stopped for business-related reasons: changed priorities or business needs or because they didn’t align with business strategy.  Another 40 percent were ended because of what sound like project execution issues: they didn’t deliver as promised or were over budget.

A big miss IMO, is that the survey results don’t note the phase in which these projects were ended or how much of the budgeted cost was spent.  That would have given more insight into how effective the portfolio review processes really were.

Based on my experience, projects stopped for business reasons experience a quick and efficient death.  Any rudimentary portfolio process — even if informal — usually catches these issues earlier and dispatches them in such a way that all know that it was the right thing to do.  Sadly, poorly executed projects often become undead zombies or vampires — hiding and spending in the dark — until someone finally puts a stake in their hearts (FYI, zombie execution techniques here).

Troubled Projects and Engaging Change Stakeholders

Glen at Herding Cats (here) points to a Center of Business Practices study (here) on the causes of troubled projects.  I’ve posted on some of our own findings about project success (here and here), but I haven’t elaborated on what we’ve found about the composition of change control boards.  Below is an extract from a comment I made on Glen’s post:

Our project debrief analyses have consistently found that the right level of executive presence on change control boards is essential to ensure change is managed, not simply documented. In fact, the lack of such a presence (or regular absences) marks the project as a potential escalation.

When a senior manager vets the prioritization of changes by focusing the project team on the project’s goals and intended outcomes — one should usually find scope, time, and resource changes easier to manage (with fewer, more salient change orders). It also keeps the business invested in the project. Many IT shops resist this measure, but it works wonders once they “get it”. 

Getting out from under in projects

Excellent short post by Stacey Douglas on Exit Strategies as part of Project Plans.  Here is how she closes the post:

The inability to gracefully shut down one project when it needs to be shut down is a huge risk to your overall portfolio and to the company itself. Most of the time, the plan may be very simple, but working with your sponsor and stakeholders to identify how to recognize when the project needs to be shut down and what the process is very sensible, holistic risk avoidance for all involved.

She makes a perceptive point about mitigation plans and other risk responses.  When preparing risk responses, we tend to focus on how we will manage an individual risk event — most risk responses are aimed at ensuring that the risk event won’t happen or the impact will be lessened.  In other words, most approaches are aimed at preventing project exits.  It is rare that any contigency or mitigation plan looks at what to do if the project is stopped, never mind advocating termination as a risk response!

We address this topic in our project closure process; but we don’t account for project stoppage explicitly enough.  I’m taking an action item to take a fresh look at how we handle this within project and programs; as well as how we drive project termination in our portfolio monitoring and controlling process.

Corner Cutting Survey Results: Risk Monitoring

The corner cutting poll’s third answer (at a low 12 percent) is “On-going risk monitoring and control”.  That result was quite a surprise to me.  Neglecting to perform risk activities beyond initial identification and analysis is one of the most common project mistakes that we see.  Surprise at when risks become issues — or when they become so likely to happen that they should be managed as issues — is a consistent marker of troubled projects.

In our experience, we get a great start in risk management and start our projects with an excellent list of risk events.  Furthermore, we usually will have done good quantitative and qualitative analyses, though appropriate risk response planning is less systematic (which is why it was a poll question).

Any ideas why this came in so low?  Maybe it’s just that Crossderry readers are very sharp and would never miss something so critical :-)   That shameless pandering aside, I’m wondering whether this result was driven by some characteristics of the poll:

  • Was it clear that multiple answers could have been given?
  • Did respondents understand the implied distinctions drawn among the various risk management processes?
  • Was the answer worded well?
  • Was there another risk-related answer that would have worked better?

PM Quote of the Day — Collette

What a wonderful life I’ve had! I only wish I’d realized it sooner

In many of my roles I’ve dealt with problem projects and people. But while I’m good at fixing broken things, that skill is a mixed blessing.

The reason is that something in my nature makes it easier to focus on the negative than the positive. This trait stems from my desire to control and conquer things. In that light, problems can seem more interesting than things that are working well. The sense of satisfaction of “making things right” is much greater than “keeping things right”, at least for me.

That attitude can infect my day-to-day life. I must consciously cultivate gratitude for what I have now, today. Otherwise, I quickly become restless, irritable, and discontented. I start looking around for broken things to fix; or even worse, I start breaking things so that I have something to fix .

Just doing something as simple as stopping for a second and asking “What am I grateful for now?” is enough to break that destructive chain.

Follow

Get every new post delivered to your Inbox.

Join 1,402 other followers

%d bloggers like this: