The Regenerate Web

I was reading on Random Thoughts of a CTO this post "Are you focused on what's really important on a project?". I really liked where he was going with this. I wholeheartedly agree with Skip's statements about projects and outcomes. In this post, I am exploring what I see as some of the contributing factors to this phenomenon.

The problem with project management as a discipline of practice (profession?) is that it tends to be more focused on the mechanics of the project process, than on the usage of that process as a means to an end.

The mechanics of projects include schedules, budgets, plans, issues, dependencies, estimates, and the like. Notice that none of these artifacts actually have anything to do with the end product that will be delivered. One of the assumptions of project managers is often that minding the delivery of value is someone elses responsibility. Many shops have SDLC processes in place to try to keep rails around this. Sarbanes-Oxley, unfortunately, has caused us to focus on documentation of mediocre practices, rather than practicing excellence in value delivery. Most places that I have worked do not have the maturity to measure project delivery against the original value (promises) propositions set forth in the charter or funding justification. The project schedules that are established may be driven by client expectations (initiated by marketing or competition) and yet they become more important than getting the value that was promised.

Moreover, sometimes management is improperly incented (MBO) to get some objective completed on time and under budget. I have never been incented to deliver value. Have you? I would expect that most of you focus on delivering value, because you get satisfaction from knowing that the end user or customer received what you promised.

As a manager of a application software program (integration, deployment, maintenance and support) I consistently find that my team is asked to make compromises (reduce the value of delivered product) to align with budget and cost. The longer term cost of this is never measured and rarely understood by management. This cost can be ascribed to throw-away work or delivery of work product that is already obsolete. Tell me you've never seen it or done it, and I'll call you a liar.

As some wise software dude once said, "There is never enough time to do it right, but there is always plenty of time to do it over."

Interestingly in the industry where project management discipline grew up (construction industry?) because the product is tangible, and the results of compromise can be serious (collapsing buildings), there are bodies of oversight to prevent such compromises. Is it the mere intangibility of technology products that leads us to see compromises and short cuts as a way to maintain budgets and schedules. Or is it because the budget and the schedule are the most tangible parts of the project?