The High Cost of Change in Technology Projects

I have an older brother who, like many an older brother, liked to tease me. I found it to be a source of frustration as a child, but now look back on our interactions with amusement.

One frequent disagreement between my brother and me was over the television. While I was watching television, my brother would sit on the floor in front of the screen and block my view. My reaction was usually a direct request of, “Can you move?” My mistake! Responding literally, my brother would sway back and forth metronomically, intermittently blocking my view. You can imagine my annoyance! Further, this all occurred before the invention of DVRs, which meant I couldn’t pause the show until the standoff was over.

To get an unobstructed view of the TV, my young mind constructed the solution: “If I can get my brother to move, I can see the screen again.” And, had I made my request in the form of an outcome, I would have yielded the desired result: “Stop blocking my view of the TV!”

I offer this humorous example of fraternal strife because it illustrates (in a small way) the flawed approach organizations sometimes take to technology projects. These issues are manifested in the planning portion of a project and response to change.

Common Problems

There are some common problems to consider when approaching technology projects. Having the proper process goes a long way to addressing issues to which even the best organization can fall prey:

• Ambiguous requirements: I start here because this is the problem young me had—I was not clear about my desired outcome. A good project team should be able to focus users on what they need, not what they think to be the solution (because those are often mismatched).
• Lack of user involvement: It is so important to have the actual employees who will be the most frequent users of the technology to be involved. They can tell you the environment in which the technology will be used and the process which will employ it. It is a mistake to have a “management representative” provide the requirements on their behalf.
• Creeping requirements: Also known as “scope creep,” this is a hard one to tackle. On many projects users ask for new features before they use the already developed features. This is where an agile project approach helps because getting useable technology into your users’ hands sooner is remarkably clarifying. It truly helps them to see what they need and often what they don’t.
• Minimal planning: While agile approaches can be very useful, they can also lull project teams into a sense of complacency. Agile allows teams to focus on high value requirements, but is not an excuse to poorly plan. A skilled agile project team can help find the right balance between planning and execution.

Change Will Happen

Major projects have some level of change, so it is important to plan for when it will happen, not if it will happen. When I consider change, I think back to a slide presented by one of my Carnegie Mellon professors that graphically addressed the cost of change. The bar chart illustrated what is obvious: that the further a project progresses the more expensive the change will be.

It is much less expensive to address a change in requirements during planning. Every additional step—design, coding, testing and deployment—adds more pre-work and thus more cost. Proper definition of requirements saves time and money. When a potential change is surfaced, it is important for the team to evaluate whether it is needed, if it truly adds value and it demonstrably important.

Proper Approach is Key

It is for these reasons (and many more) that the proper approach to a technology project is critical for success. The proper team will have the experience to approach the true end users in a way to help them to articulate the outcome and define success. There is no one formula for project success, but following some basic tenets will help to create the environment for a successful project that avoids pitfalls and efficiently deals with change.