CIOZone.com - Professional Network for CIOs and IT Professionals

Reprinted from Keep the Joint Running.

Bare Bones Project Management was supposed to be nothing more than a lightweight summary of standard project management practice. A few years and several hundred seminar participants later, it turns out that it is, in fact, more than that. Unlike traditional IT project management it asks project managers and project teams to take responsibility, not only for completing projects, but for their success as well.

Who knew that would be controversial.

Professional project managers understand that completing even the simplest project is hard, and the job only gets more difficult from there. So as a matter of survival, they develop a laser-like focus on making sure their teams finish all deliverables on time and within the project budget.

The Bare Bones methodology asks for more. In addition to managing budget, duration and deliverables it also recommends project managers insist on clarity with respect to:

• What “major goods” - increased revenue, decreased cost or better-managed risk - the project will contribute to, and how.

• What success looks like … not just completion, but business success.

• What will change in the business to make success happen (the project’s goals).

This approach leads to two challenges, one practical, the other philosophical.

Practical things first: Accept the above and you accept that a project’s goals and deliverables must each be complete. In properly defined projects, if you achieve all of the goals you must achieve the revenue, cost and/or risk objectives that are the point of the project.

And, in properly defined projects (or multi-project initiatives), if you provide all promised deliverables then you must achieve all of the goals.

To illustrate, imagine you’re managing a project whose ostensible purpose is to install the supply chain module of your company’s ERP suite. In most companies the project team would limit its role to implementing the module and configuring it so it meets all business requirements. Do that and the project will have been successful.

Except that it won’t have been successful. Complete? Sure. But no business benefit happened, and according to the usual methodologies, that’s Someone Else’s Problem.

Bare Bones starts with the point of it all. Supply chain projects, for example, usually contribute to the bottom line by reducing costs, and secondarily by managing risk, reducing both the likelihood of supply-chain interruptions and their impact should they occur.

Project goals (business changes) come next, and implementing the software is one, but hardly the only one. The test of the goals is that if you achieve them all then the business benefit must show up. Implemented software doesn’t get you there by itself. Quite a few other business changes have to take place:

• The supply chain must be managed according to modified or altogether changed processes.

• Employees must take on different roles based on the modified processes.

• Employees must become competent to perform their new roles, which is different from their knowing how to operate the new software.

• Very likely, the compensation structure must change to eliminate “perverse incentives” that will drive managers to subtly sabotage the change effort.

• Possibly the old organizational structure will prove incompatible with the new processes and require changing as well.

If these aren’t all defined as goals - either of the project or, better, of a collection of small, closely linked projects - then the effort will fail, even if it “successfully” completes according to the scope/budget/schedule formula.

With this set of project goals it’s clear the list of deliverable must be expanded as well: Software (and documentation) won’t do the job without new process designs, a training plan, new position descriptions, compensation surveys and recommendations, a new organizational chart, and a business change management plan.

Sound intimidating? It should. Business change is never easy.

But if you’re tempted to waive this off, preferring the old methods where everything except the software is Someone Else’s Problem, consider this:

When business change and bottom-line benefit don’t end up happening, who do you think will receive the blame? The business department that failed to implement new processes?

Or you as project manager, for “delivering software that doesn’t solve our problems”?

I’d advise taking responsibility for project success as well as completion, even though you lack the commensurate authority.

Which is the philosophical problem mentioned earlier: Authority is supposed to accompany responsibility. It’s a lovely philosophy, easily applied to all situations except those that involve getting something important done.

If you disagree, consider Sales. Sales representatives have no authority over their customers.

Think that lets them off the hook?

 

---

 

Robert Lewis is president of IT Catalysts, Inc., a consultancy focused on improving IT organizational effectiveness and integration with the enterprise. Contact him at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .

 

---

Copyright 2009, IS Survivor Publishing, all rights reserved.

Comment on this article

Only registered users can write comments.
Please login or register.