Project drift: How to deal with IT’s silent project killer

Whether it’s a technology or vendor challenge, project enhancement creep, or issues with IT or business user personnel, there are any number of ways for an IT project to drift off course and lose initial purpose and momentum.

How do you detect project “drift,” and what steps can you take to correct course?

The Cambridge Dictionary defines drift as “to move slowly, especially as a result of outside forces, with no control over direction,” and for CIOs and project managers, that’s exactly the point: Projects can drift without you even realizing it because the drift is gradual, though continuous, pulling you down another stream with great risks of losing project control if you don’t course-correct in time.

What are some of the outside forces that cause IT projects to drift? The most common include:

• A change at a vendor, such as the introduction of a new software release that must now be incorporated, lengthening the project timeline and requiring additional user training;
• A change of mind by business stakeholders on the initial list of requirements for the project, which will extend project timelines if incorporated;
• A series of project enhancement “tweaks” that look innocent on the surface but add up to the point where they impact timelines or deliverables; or
• A shift in the business that impacts the project.

Because most of these changes come from outside IT, there might be limited direct control that CIOs and project managers have over them. But there are ways IT leaders can deal with project drift to limit its adverse impact on projects or, if impact is inevitable, to deal with that impact constructively.

Here are three key strategies IT and project leaders can use to get back on track.

Stop project enhancement creep as soon as it starts

Project managers and CIOs can sometimes fail to notice or intervene when the first project enhancement requests set “enhancement creep” in motion.

This kind of drift can start innocently enough — for example, when a user requests a simple button for a simple function to be added to a screen — but as users push for more and greater enhancements, timelines and deliverables of projects that do not undergo significant revisions will be adversely affected.

As soon as enhancements surface, CIOs and project leads should push for a meeting to discuss the enhancements and their effect on the project. When management and business users are made aware early of the impacts enhancements have on project timelines and deliverables, everyone can collectively decide whether project enhancements should be “frozen” until the project is delivered in its initial phase or whether it makes sense to incorporate the requested enhancements and redraw the project timelines for deliverables as a result.

Always renegotiate

Renegotiating project timelines and deliverables goes hand in hand with having that early meeting with stakeholders about project enhancements, because taking on significant new enhancements will lengthen project timelines and will contribute to budget overruns.

Business managers know this, but they also want to get as much functionality from a project as they can. What they do then is have their staff “trial run” a project and provide feedback like, “This is nice, but I’d really like to see this, too,” or, “No, we can’t use this. We need to also build an interface to system XYZ.”

These requests often come when IT is expecting feedback primarily on minor system bugs that need to be resolved, but business users don’t always see it that way. Instead, they view QA as a “systems acceptance” test — i.e., will they accept the project as is, or is it insufficient for their needs?

Early in my IT career as a programmer, I witnessed this scenario firsthand. We were building an order-entry system, and users kept changing their minds, insisting on more and more enhancements. The project was so rife with enhancements that it was almost impossible to know when it would complete. Instead of calling for a meeting and renegotiating the project timeline, the CIO and project manager tried to absorb all these changes without changing project deliverable dates. The project didn’t make its timelines. Instead, it ultimately failed and was cancelled. Both the project manager and the CIO lost their jobs.

The bottom line is: Always renegotiate when project enhancements impact project commitments. That said, I’ve met a number of CIOs who are extremely hesitant to have a renegotiation session. Don’t be one of them.

Require more from your project sponsors

In 2023, McKinsey research revealed that 53% of projects were not delivered on time, and that of the projects that failed, 13% of failures were due to unclear objectives and lack of focus, while another 9% of failures were due to shifting requirements and technical complexity.

Kudos to IT, because these numbers reflect an overall improvement in project execution from the past, but there’s still room for improvement when it comes to managing project drift away from original project requirements.

First, project requirements should always be detailed out in a requirements document, even if you are using agile as a software development methodology. The project requirements baseline document can illustrate to users and IT when project drift occurs so that projects can be revised or stopped.

Second, the CIO and project manager should call regular meetings with users so all can monitor project progress and see where project drift is beginning to occur. Then, if a project needs to be reformed or renegotiated, all stakeholders are there to come up with an approach and commit to it.