Detailed plans are the enemy. … Project plans that extend past 90 days are as accurate as TV weather predictions. … It’s why users often reject technology that gives them what they asked for: By the time the technology is delivered, it’s no longer what they need. … Scope creep should be mandatory. Without it, IT’s relevance comes into question. Why Tech Projects Fail: 5 Unspoken Reasons, Informationweek, April 22, 2013.

I do really love the quarterly releases or quarterly projects, but I’ve done a lot of software and IT plans that extended well past 90 days (well over a year) and they worked out as planned. However, the trick at making these work — at least in my experience — is as the quote suggests, and that is the longer the project the more we need to plan in requirements updates.

After one huge 18 month project, delivered on time with good quality, I was visited by a “tiger team” of people only peripherally involved in the project who were working on lessons learned. I gave them all my data on requirements. Off they went to record for all time our experience in requirements management.

Several weeks later they blasted out a PowerPoint set that showed that our mega-project had massive requirements creep and that was a bad thing and the root cause of all evil. My senior manager, somewhat perplexed as it was a successful project, asked me to take a look at the report. I was use to this kind of data mangling, so I wasn’t too worried.

The team had taken my data, rearranged it significantly, and built some slides that made it look like we had a tsunami of changes. Now, our history in this business was projects that were late and buggy. The almost always stated reason why we had this problem was that we always added significant requirements to the project. It was claimed that these added requirements are what caused us to consistently run late and to be of low quality. Their conclusion was that we had done it again.

Do you see the problem? The problem was that the project was delivered on time and with good quality, both of which were highlighted by our equally surprised but happy customers. I highlighted to the tiger team that if what they said was true, then either it was not the root cause of all our past problems or that maybe we didn’t have massive requirements creep.

Actually, we had roughly the same amount of requirements creep as in previous projects. As an 18 month project, we inevitably had multiple changes of insight, changes of market, changes of available technology, and changes always of something. We rolled these changes into the project as they happened. We used all the classic “change management” practices (including just saying “no!”) and they folded into the project just fine.

Humorously, when I’ve emphasized in early planning how we can accommodate changes or late delivered requirements, influential people in this same organization would accuse me of planning for failure. This is one of those situations where I’m on the fence about mentioning out loud how we plan to handle these kinds of risks. I’m big into brutal honesty, but too many otherwise talented people would go crazy when we showed how a “waterfall planned” mega project would adapt to project imperfections and changes. They had a mindset that it had to all be fixed at milestone zero, and the measure of merit was that nothing ever changed. That was a well-planned project for them. Well, no it wasn’t … but that mindset was part of our challenge to overcome.

See related Don’t Be Taken For Granted Be Brutally Honest

We need to plan for changes in requirements. Even with agile two-week project schedules, we need to be prepared to adapt to remain successful. We certainly can do consistently successful projects for longer than 90 days, but it is all about smart management and understanding of our requirements. That understanding includes recognizing that things change, and so planning for and adopting scope creep should indeed be mandatory.

How do you handle scope creep on your projects and how well is that working for you?