20

Dec

System Design 101: Clear Requirements Help Reduce Project Cost

Posted by: Jeremy Reither

An ounce of prevention is worth a pound of cure. That famous Ben Franklin quote has a lot of applications, and somehow centuries after it was first recorded, it even extends to the design and development of websites and other information systems. No matter how you define the systems development life cycle (SDLC) (w) – the process followed to develop a quality system – among the first steps are ‘Feasibility Study’ and ‘Analysis.’ Now I won’t bore you with the details, but the moral of this story is that it pays to think things through before jumping into a new project.Some people will tell you that they just don’t have any interest in the details of “how things work,” that they’re “big picture” people, and they’re not particularly detail oriented. So often, these “big picture” people are also the “big idea” people – those who think up the great projects in the first place. What those individuals often do is jump too quickly into the “build” phase of the SDLC. This may not be a problem if the “big picture” person is conceptualizing and building the system himself, but the minute you have other stakeholders involved, it becomes important – even critical – to understand and document the requirements of the system to be built.

Sure, analysis and documentation take work. And nobody is pretending that a 100 hour project requires the same amount of upfront analysis as a 10,000 hour project. But it’s important to know that any misalignment in understanding between project team members can result in those individuals heading in different directions with the project. And by the time those disconnects are identified they cost much more to fix than the would some up front time spent level-setting (fixing these disconnects is often called “re-work“). An old quote, while probably not entirely accurate to the number, illustrates this rule:

“The cost to catch a mistake and make a change at the time of writing the requirements specifications may be $10, and during the design $300. While the product is being built, the error may cost $3000; after the product has been delivered, the mistake could cost as much as $15,000 to fix, and possibly much more in losses to the client because the product didn’t work.” [Management Analytics (Note 7: Steward87)]

One challenge can be that the “big picture” people do not have an interest or see the benefit in up front detailed analysis. In these cases those responsible for the feasibility study and requirements analysis have to be prepared to explain the value of the work they’re doing. Unrealistic deadlines are another common enemy of the analysis phase (and therefore the project). Too often stakeholders are anxious for a project to begin, so they set aggressive project deadlines for completion before any analysis is done. Deadlines can be set for analysis to be completed, but overall project deadlines should at least be re-evaluated after analysis (and each subsequent SDLC phase) is complete.

We are involved in a project at the moment in which the project owner has temporarily halted the requirements analysis phase in order to move forward with graphic design mock-ups. It seems like a few steps are being skipped – but the design mock-ups are required for sales presentations, and the idea is not to develop the system based on these mock-ups. However, as they say “appetite comes with eating,” and I can already see people getting sucked in to the design phase before we finish the prerequisite analysis phase. As project manager, I serve as a sort of foreman or general contractor, so it is my responsibility to bring the team back and have them put their analysis hats back on as soon as the current sales effort is complete. Ensuring that a quality product is developed on time and on budget is my primary concern. And I’m going to keep those goals in sight by focusing on issue prevention, and avoiding the need for cure.