Rosenffeld Media - PMH034 - https://www.flickr.com/photos/rosenfeldmedia/albums/72157683706336861
Whenever a spreadsheet project takes longer than expected to complete or ends up costing much more than the original estimate, "scope creep" is usually given as the reason. At least that is what the people involved will say publicly. In private, users blame the developer for taking too long and not delivering what was promised, while developers blame the users for constantly changing the deliverables.
The more likely explanation is that both the user and the developer share some of the blame for the end result. It is convenient to cite scope creep, but what does that mean?
Simply defined, scope creep means the requirements of the project increase as the project progresses, beyond what was originally planned. So scope creep occurs when the requirements of the project are not properly managed.
In this series of articles, I am going to examine all aspects of project requirements based on my experience in developing many spreadsheet financial models and management tools for clients in a wide variety of industries.
This article will identify some of the warning signs that the project requirements are not being properly managed and scope creep is beginning to occur.
Take a moment to examine your project and ask if any of the following apply to you:
The project's vision and scope are not clearly defined.
The client is too busy to meet with the developer to discuss the project requirements.
The decision-maker at the client company is not involved in the process, but delegates participation to a subordinate. Although the subordinate claims to speak for the decision-maker, in fact, the subordinate has no authority and is not able to accurately represent the client's needs.
Project requirements are documented in writing.
The client claims all requirements are critical and have equal importance, so they refuse to prioritize their list of needs.
Developers are forced to make guesses as to the deliverables because they have to deal with missing and/or ambiguous information. In such cases, both the developer and client bear responsibility - the client must be clear on what is needed. If the client is not clear on requirements, it is the developer's responsibility to press for answers until there is complete clarity on requirements.
Conversations about the final product focus more on the user interface, with less consideration given to what information the spreadsheet is supposed to provide.
The client signs off on the project proposal, only to constantly make changes as the project progresses.
As requirements change the client and developer do not provide additional resources or change the expected functionality, so the project scope - cost and time - just continues to increase.
The client requests a very specific functionality, which the developers create, but the function is never tested or used.
A requirement is completed exactly as described in the project proposal but the client is not satisfied with the result. This requires additional modifications, cost, and time, all of which could have been avoided if the requirement was properly structured in the first place.
All of the preceding occur because there is an expectation gap between what developers think they are supposed to build and what the clients really need.
In his article "Defect Prevention: Reducing Costs and Enhancing Quality" Mukesh Soni provides information which underscores how critical it is to get the requirements right at the beginning of the project:
"The System Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the coding stage."
"Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only mor probable but also are more severe and more difficult to remove."
Division of Defects Introduced into Software by Phase
Source - Computer Finance Magazine
Software Development Phases / Percent of Defects Introduced
Requirements / 20%
Design / 25%
Coding / 35%
User Manuals / 12%
Bad Fixes / 8%
Origin of Software Defects
(Source: Crosstalk, the Journal of Defense Software Engineering)
Ray Panko, well known for his research into spreadsheet errors did a study in Spreadsheet Development Error and found that planning errors accounted for 82% of errors in spreadsheets developed.
Panko and Aurigemma (2010) used a new taxonomy to categorize errors in spreadsheets developed during an experiment. They individually categorized errors in 39 spreadsheets, then compared their results. They jointly classified 85 of the 88 errors the same. An important conclusion is that domain-related logic errors were far more common than execution errors (slips and lapses), constituting four errors in five.
Make sure you capture all requirements, that all requirements are specific as to task and deadlines to avoid unnecessary costs and delays, and to ensure a successful, timely completion of your project.