Is Delivery Date the Only Thing

In the September 2007 Issue of the PM Network there is an article titled "The Need to Speed". According to th article a survey of project managers around the globe that indicates that there seems to be a problem with on time delivery of IT projects. When you look at the cold hard reality of things, this should not really come as surprise to anyone. Aside from the fact that the article never mentions how the deadlines were set and by whom, the article concerns me because of it's suggestions on ways to address projects coming in after deadline.

Even though the advice is listed as the opinions of the people who took a survey, the fact that these particular answers are being pointed out in the article, causes the information to take on a little more importance.

The statement in the article that really caught my attention, and confirmed my fears that traditional PM thought and training is focused on the wrong thing is this statement below:

"More than one - third of EMEA-based executives agreed with that assessment, but are particularly frustrated with changed made mid-stream, so they advocated ignoring changes to business requirements as a means of speeding up project delivery."

Huh??? Ignore changes to business requirements to get the project done on time? Ah yes, this is the focus on that magical iron triangle - scope, time, and cost. Here's the problem with that: you can deliver a project on time, under budget and with the agreed upon scope, and still entirely underwhelm your customer. I humbly suggest that we have been measuring project success using the wrong metrics. Scope, time, and cost are important, but the truly meaningful measure is really value produced by the project. It incorporates the sides of the iron triangle and goes a step further by measuring how the project improved the state of the organization be it through added revenue, reduced costs, or protection of existing revenue.

You see change happens. Business requirements will and should change throughout the course of a project. There are at least a couple of reasons for this.

• First off, for any project that lasts any considerable amount of time (even as short as three months) it is very possible that business conditions change during the life of the project. If the environment in which the project is happening changes, the characteristics of the project necessary for it to provide value is likely to change as well.
• Perhaps more frequently the "changes" that people see in requirements is really a result of better understanding of the requirements. This happens frequently when the team suffers from the desire to avoid uncertainty by identifying to the nth degree all requirements at the very beginning of the project. Changes occur because details were established before the team had the appropriate information to properly make those decisions. And often the people making those decisions are not aware of all the relevant details needed to make a decision.

So how do you get around this problem? Don't define requirements in great detail at the beginning of the project. Doing so creates a requirements inventory, and limits the options that are available for design.

And always keep in mind, if deliver something on time that completely misses the mark for what the customer wanted, is it really a success?