An Illustrative Anecdote

In 1623, in the midst of a war with the Catholic Poles, the King of Sweden, King Gustav Adolphus II, launched his most formidable and impressive battleship, the Vasa. The ship was festooned with carvings and ornate structures that were intended to intimidate his enemy into retreat. Unfortunately, 15 minutes into its maiden voyage, amid much fanfare and pageantry, the Vasa keeled over and sank to the bottom of Stockholm's harbor, killing about 30 of its crewmen and astounding a shocked throng that was keen to celebrate the king's newly christened flagship.

The designer (who had died during the Vasa's construction) was blamed for having designed the ship with too little ballast, but recently, a new theory is gaining ground as to the real reason for the Vasa's demise. After the designer died, King Adolphus decided that he wanted a second row of gun ports (where the cannons stick out) added to the ship. Apparently, he had seen an English ship with this configuration and simply had to have it on his new flagship. The ship was designed to accommodate only one row of gun ports; of course, no one wanted to tell that to the king. More gun ports equals more guns equals a top-heavy ship.

The ship was raised and refloated in 1961 and now sits in a museum in Stockholm where tourists can marvel at this 300-year-old monument to scope creep.

Scope creep is the tendency for projects to start small, seemingly well defined, and then become big, complex, and poorly documented by the end. Scope creep is the single most intractable problem software developers must deal with because its roots are tied up in issues of interpersonal communications, expectation management, and psychology, among other issues. In short, understanding and managing scope creep are human disciplines, not a matter of ones and zeros, and it requires a different set of skills than those that must be applied to designing software and writing code. Scope creep is sometimes exacerbated because people with otherwise good intentions start projects without documenting requirements in sufficient detail. Good requirements gathering and documentation of those requirements are essential in order to manage scope creep. I say “manage” and not “eliminate” because scope creep is inherent in any project.

In the e-business world, requirements often shift underneath you while you're working. Just as King Adolphus decided late into the project that he needed one more row of gun ports, your internal or external customer may decide that his requirements have to change. How do you avoid your project ending up at the bottom of the harbor 15 minutes after launch? Proper project management keeps a project on track. Be true to the requirements originally set out, but be nimble enough to react and change—to roll with the punches.