The secret to IT project success

Other than being full of thorns, project management is rarely rosy, so Gertrude Stein probably wouldn’t have said, “Project management is project management is project management.”

But it might be. Then again …

As we discussed previously, a “project” is any activity that requires more than one person, calls for orchestrating multiple interconnected tasks, produces tangible items, and has a deadline. As such, project management includes such disparate activities as house-building, maintaining aircraft, creating advertising campaigns, developing commercial software, and what we used to incorrectly refer to as “IT projects.”

Which leads to the question: Are the kinds of projects we in IT have to deal with similar enough to house-building, maintaining aircraft, and so on that we can make use of standard project management methods?

Why completion is only the beginning

By the above definition, IT is certainly operating in the realm of the project. But here’s the difference, and it cuts to the essence of what project management methodologies are all about: Standard management methods were developed to handle projects for which the tangible products are the point of undertaking them. They have intrinsic value — a house to sell, a safe aircraft to fly, persuasive marketing that pitches products, and so on. If the project delivers these work products on time and within the original budget, the project has been successful.

Our projects are quite different. Even when we called them “IT projects,” we knew the software we delivered wasn’t the point. The point was always business change and improvement. It’s just that in our pre-enlightenment days, we figured our job was delivering software that satisfies the business requirements. Changing the business was someone else’s problem.

That isn’t the case anymore. If you want to run a next-generation IT department — heck, if you want to run a this-generation IT department — project teams had better be up to their eyeballs in the business of business change.

What we’re undertaking are business change projects; otherwise, what’s the point? In other words, the work products provided by the projects we’re involved in — or, if they’re bigger, the multiproject initiatives or multi-initiative strategic programs — have no tangible value of their own. They’re enablers of change. That’s it. The responsibility for putting them to use belongs to the manager in charge of whatever part of the company is supposed to improve its operating practices — which can’t start until just after the project, initiative, or program is finished.

While completion is the same as success for most projects, in business change projects, completion and success are decoupled. Moreover, accountability for completion and success themselves are decoupled. The former belongs to the project manager, and the latter belongs to the operational manager — the person in charge of the business function the project is intended to improve.

Which is why the answer is “yeah but”: Project management theory (Gantt, PERT, critical path and critical chain) and the various frameworks that organize them into complete practices (PMBOK, PRINCE2, and my own “Bare Bones” approach, among others) are entirely appropriate for achieving project completion. When it comes to the kinds of projects we in IT have to deal with, they’re necessary conditions for success, but not sufficient conditions for success.

Business change: IT’s recipe for success

It’s actually even worse because operational managers aren’t experts in business change. Quite the opposite — they’re experts in business staying the same. That’s their job: to perfect the way things are right now and to get work out the door as efficiently as possible.

It’s worse yet because of a central fact of IT’s existence: If anything goes wrong, we’re left holding the bag. What actually happened doesn’t matter, and there’s no use arguing that the software we built “satisfied the requirements” and met the specifications. Something went wrong, and software was involved. It must be IT’s fault.

As business situations go, this one is big-time ugly. There is a path to success, but you can’t get there if you limit yourself to standard project management methodologies. Here are the additional ingredients you’ll need to go beyond delivering software to making business change happen.

Business change ingredient No. 1: Define success

This isn’t complicated, is it? If you want to make business change happen, you need to figure out what the change will look like. This is what disciplines like Lean, Six Sigma, and Theory of Constraints are for. And it’s why Advice Line has advocated so strongly for a radical redefinition of the business analyst role.

Business change ingredient No. 2: Take responsibility for success

Here’s a seemingly fine distinction. If the project manager’s job is done when the project is complete, and if making business change happen is the operational manager’s job, and the operational manager can’t start until the project finishes, holding the project manager accountable for successful change is entirely inappropriate.

But holding someone accountable is to impose external oversight. Nothing stops the project manager from taking personal responsibility for doing everything possible to set the stage for success. Taking responsibility comes from within — an entirely different matter.

Business change ingredient No. 3: Incorporate business change management in every project

Project management pushes change into an organization. If that’s the beginning and end of things, the organization will push the change right back, not because employees naturally resist change (taken as a whole, they don’t) but because organizations stabilize into internally reinforcing configurations. They’re built to be what they are.

Business change management is the discipline that identifies what it is about the organization that will cause the organization to resist a particular change. It then goes about figuring out what to do about inherent resistence to change. Without business change management, very few attempts to change the business will have any chance of succeeding, and every one that does will increase resistance to the next.

Business change ingredient No. 4: Make implementation a project, led by the operational manager

Implementation is one of those activities that can be a project but doesn’t have to be a project. It does require the coordination of multiple tasks. It requires the efforts of more than one person. It can have a deadline, but doesn’t have to have a deadline. As for well-defined, tangible work products, while defining “work is now done the new way” as a tangible work product might be a bit of a stretch, it isn’t entirely unreasonable.

So make it a project. Doing so means everyone knows when it’s supposed to happen. Doing so means everyone knows what steps are needed to make it happen. Doing so means everyone knows who is accountable for making it happen.

By making the operational manager responsible for managing the project, the company achieves two important results. The first is that instead of change being imposed on an operational manager who has every logical right to claim it’s a bad idea, the operational manager gets to own the change.

And it results in operational managers learning how to make change happen as a natural complement to their day-to-day operational responsibilities.

This story, “The secret to IT project success,” was originally published at InfoWorld.com. Read more of Bob Lewis’s Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.