The secret to IT project success

For most projects, completion is success. But in IT, getting it done is only the beginning

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 ...

[ Also on Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

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.

1 2 Page 1
Page 1 of 2