Anytime you’re building something where there are unknowns, a scope needs to be defined. Project scope helps to control expectations, costs and milestone dates. Despite careful planning, however, a common failure on large technology projects is scope creep. Scope creep is an ever advancing list of features, functionality and enhancements that go beyond original plans. When expectations are “the best, cutting edge, the most maintainable”, execution of the project can become impossible.

There is likely no better example of extreme scope creep than in government projects. While a private company would go bankrupt or feel the pinch much sooner, many government agencies do not. Confounding that issue is the number of stakeholders in a project. “Too many cooks spoil the broth” is fitting when you consider the number of internal stakeholders for large-scale system implementations.

$1 billion evaporated into thin air

In terms of colossal project failures due to scope creep, recent news of the Air Force scrapping a $1 billion dollar ERP implementation is mind-boggling. Originally scoped at $88 million in 2005, this project increased in scope and cost until it collapsed under its own weight, 7 years later. That’s a billion dollars and 7 years of time with no new system to show. It’s not like the Air Force is a stodgy government institution. Progressive in their thinking, they’re actually cutting edge on initiatives like social media and their approach to commenting online.

Our industry is just as susceptible to this issue. Below, I have assembled some common reasons for scope creep, how they apply to website development and what can be done to fight them.

Oh! Just one more thing…

The most obvious killer of budgets and timelines is adding on features, processes, or functions that all parties hadn’t previously agreed on. While these features are often evaluated for application in the initial scoping, later on that scrutiny may not be as stringent. If the project is going well, the temptation to add new bells and whistles is ever present.

Similarly, towards the end of a project, it always seems like there’s just one more thing that could be added on, tweaked, polished, or enhanced. If these features are individually validated against the goals of the project and found to be worthwhile, they often slip in. Often, however, features at the end of a project are added without the clarity that was present in the initial phases. Resist the urge to add too much frosting on the cake.

Perfection and completeness

Scope creep isn’t just a government issue. Private companies do it as well. A fantastic example is the video game, Duke Nukem Forever. 3D Realms’ prior game took a year and a half to develop, while Duke Nukem Forever famously spanned 15 years! Development bankrupted the original developer and another had to pick up the torch to finish it, albeit with poor results. The original developer had too much money, not enough pressure and too high a focus on perfection, completeness, and using only bleeding edge technology. There’s a development concept of “good enough” that needs to be exercised ruthlessly.

When perfection and completion are the goals, cost and time to complete spiral out of control. If you’re not building the Taj Mahal or Great Wall of China, you can execute more cleanly and quickly with a broader vision of success. 3D Realms wanted a fully interactive environment for their video game – the ability to interact with any object. The problem is that the time it took to produce this kind of completeness meant that basic game tenets, like moving around, as well as how fun the game was to play, got neglected. By focusing on completeness of one aspect of the game, more fundamental attributes took a hit.

Establish measurable goals

I feel like I talk about this constantly… establish real, measurable goals as part of any technology project. “Making the website nicer looking” isn’t a great goal, because there’s no finish line or measurement. “Generating more leads and prospective employee resumes” is awesome, because it’s measurable and you can use those goals to help guide the scope of the project. You don’t need a flash intro movie to get more leads. But one might be led to believe it would be necessary to make the website more visually appealing. If you don’t have any goals set up yet, don’t despair. At least they’ll be somewhat easy for you to define. Upon a review of the FAA’s $40 billion dollar NextGen air traffic control system, auditors commented, ”Without goals and metrics, FAA could pursue and implement capabilities that fail to produce the desired results.” In layman’s terms, this means they could blow a whole bunch of tax money on things that don’t really matter.

Don’t compromise on mission killing requirements

The project is a slam dunk. We’re going to use cutting edge technology, slick design, a maintainable setup – and we’re going to do it in 3 months. But, we need to run it on a 4 year old Windows PC at the customer’s office. It’s firewalled. We don’t have administrative rights to troubleshoot should anything go wrong. And the IT guy is going to be working on something else that he/she thinks is more important when we’re in our launch window.

This would be the time you need to start asking “why?” Are there any sensitive materials on the website? Do we need to be secure, or can we compartmentalize the sensitive information somewhere else? Ultimately, security too is not a checkbox, but a scale. One one end of the scale, you have convenient and easy. On the other you have secure and hard. With websites, a certain amount of security costs almost nothing. Beyond that base level, you look at skyrocketing costs and a reduction in maintainability and agility. Mission killing requirements come from more avenues than just security. In my time, I’ve heard:

  • We want to use a flash front-end, but have it maintained with a CMS backend.
  • We need the account creation process to mirror how we do it with paper and fax machines, and we can’t change our process to match what every website on earth does.
  • We’d like to search engine optimize the website, but there’s only one guy who can make code changes to the site and he doesn’t believe in SEO.


Here’s one I’m guilty of, failure to launch. My blog post is 99% complete, sitting in draft mode. . .and. . . .the timing’s just not right. Or I need to tweak the formatting just a little. Or I need to use the latest screenshot of an application. Or I want to get a quote from a customer. The same thing happens with websites. You keep thinking of more things that need to be perfected or tweaked or added on, and the launch gets dragged out. If you think about it, the design on your website is aging. The technology is aging. And all of these elements have a finite shelf life. The other thing to consider is how much better the new website is compared to the old one. You know the one that’s painful to update, lacking in features, and generally ugly? Your new one is better, right? So quit stalling and get that new one up!