When you first get a Global Positioning System (GPS) wayfinder for your car, it takes a bit of time to get used to trusting the device.
GPS systems often ignore the efforts of traffic planners who have carefully routed around built-up areas, for instance: all the GPS calculates is the current fastest route.
Sometimes that’s on the bypass road; sometimes it’s through the centre of a town (because so much of the traffic does route itself around the bypass). You have to learn to ignore the road signs and follow the GPS to get full value from it.
Ah, but we’re human, and so many of us can’t resist either driving a part of a route according to our rules.
We follow the signs even while the unit is saying not to, or we go a certain way because we like to.
At first the GPS unit starts telling you you are off its route, urging you to turn around. It doesn’t take long, however, for the unit to do the pragmatic thing, and recalculate your route to the stated destination from where you are, not where you started. In other words, it again becomes a useful guide.
Compare this to the way we handle projects.
We start the project with a project plan, that lays out the route to a successful completion. We charge the project manager with getting all those involved to make their moves on time and on budget.
This is just like the GPS, with the project manager as the GPS and the participants in the projects acting as the driver of the vehicle.
The project inevitably deviates from the plan.
The project manager goes into react mode, trying to get it back on the plan: “could you maybe get this done by Tuesday and still have next Friday’s deliverable on schedule?”
Generally, this doesn’t work. We end up finishing the project as per plan, with the slight exception of time: it’s as though we finished our journey, but hours late.
We don’t, in other words, replan the project.
Let’s take a common situation: a meeting to finalize a set of actions and get the business area to accept the work has to happen before we can move on.
This could concern requirements, it could concern design, it could concern acceptance of testing: it doesn’t matter what kind of checkpoint we’re talking about.
The meeting doesn’t occur: “too busy to do it, let’s reschedule”. Then the rescheduled date occurs, but the decision-maker can’t attend and sends a delegate who has no authority to say “yes” or “no”. Work stops; the project is derailed.
If we replanned the project at this point, the project manager should, at the first occurrence, warn in her or his status report that the schedule is being compromised.
At the second occurrence the business sponsor should be notified that the project needs to be rethought to ensure it continues to deliver the planned benefits cash flow stream — and that any further delays will result in a recommendation to shelve the effort, since the problem lies in the sponsor’s area.
While waiting, the project manager should then figure out how to deliver the financial goods as promised (or how much has been permanently lost).
Tough to do? Absolutely — and utterly essential.
The typical best-in-class organization makes a small single digit (4-6%) return on the capital it invests in IT projects across the entire project portfolio; mediocre organizations are around the 0% return. This, of course, when you calculate in the project slippage and its effects.
Why on earth do we go through writing business cases, presenting them, prioritizing projects and so on if we care so little about achieving the results?
Considering that the hurdle to be prioritized in most companies is around the 15-20% annualized return mark, that’s a lot of wasted potential, especially considering that in most organizations we spend time with there are perfectly good projects in the 6-8% return range where execution would not be an issue.
An enterprise only improves at execution if it is made to.
Just as the driver must learn to yield to the GPS to get full value from it, so, too, the business and the IT area must learn to yield to the plan.
The plan is the priority item: if you are overloaded, it’s because you are either unwilling to prioritize your time appropriately and say “no” to other things, or you had no capacity to execute on this project, in which case it should never have been released for execution.
One key reason I tell clients to move the project management function into a corporate office (and away from IT solution development) primarily because, for it to be effective, it must lead the way, like the annoying voice of the satellite navigation GPS when you depart from its route, in challenging current behaviour.
It won’t get better on its own, so you might as well begin.