IT departments have long faced the problem of having projects spiral out of control. After creating an initial project specification, going through the process of getting it approved and starting the implementation process, “one more thing” invariably creeps up. Over the life of the project, “one more thing” grows and multiplies, creating projects that are more expensive to deploy, take longer, and end up being more complicated.
In a response to this, some IT directors have started issuing limitation documents. Instead of just spelling out the project’s specifications, the document also spells out what will not be part of the project. Furthermore, the document may also include a list of additional features that could be included, detailing the time and cost of adding them, as well as listing the sign-offs required for the change to be made.
These limitation documents are extremely effective at controlling changes and limiting IT project deployment costs. However, there is also a cost to this efficiency. The documents become tools that IT departments can use to bludgeon the rest of the company with repeated refusals to do additional work. There’s a fine-line between refusing to change a project to avoid additional cost and delay, and refusing to make tweaks simply because the department doesn’t want to do additional work.
Unfortunately, given the nature that many companies work, the latter case comes into play with some projects. Especially if the relationship between the IT team and other departments is already strained, these documents can make a bad situation worse. With this in mind, while controlling project scopes is a reasonable thing to do, setting up hard and fast rules can require input from high-level management to ensure that the company’s needs are always met, balancing the cost of changes against the realities of a rapidly changing business and technological environment.