The Secret Phase
Ask anyone in technology sector for the basic phases of any project, and they will say requirements, design, construction, test, production implementation and post-production implementation.
Requirements define the “what”. Design defines the “how”. Construction creates or improves the technology to be delivered. Test ensures that what was requested in the requirement phase has been delivered and functions as designed. Production Implementation moves the technology into a live state for it to be used by its customers. Post Production Implementation allows all to keep a watchful eye over the technology in order to be certain that it is performs as envisioned, and to verify that it does not create any unintended consequences.
However, there is a “secret phase” that many technologists have not formally identified, or choose to ignore. By not understanding this secret phase, project estimates and timelines often go underestimated. The secret phase is ‘Requirements Clarification’. Before everyone begins commenting that requirements clarification is embedded in the requirements phase as detailed requirements documents, covered with a function specification documents, or that it is embedded in the design phase, please allow a moment for additional explanation.
“While technologists do their very best to consider if the requirements are feasible, they are not yet in a design frame of mind”
A well run requirements phase will include members of the technical community to ensure that what was asked, can be delivered. While technologists do their very best to consider if the requirements are feasible, they are not yet in a design frame of mind. A funny thing happens once the design phase starts though. Development managers and technical architects begin to use a different part of their brain as they create the framework for the solution. It is when they begin this thought process that they often discover that they have a lot questions.
As more detailed questions arise, more discussion and documentation is often required, thus causing a delay in the milestones of the design phase. While the questions are very important, they can lead to increases in scope, clarifications to the requirements, change requests, and design ambiguity. This secret phase, if not properly planned for, can cause overages in cost and time.
The secret phase must be planned before the project begins. Accounting for this hidden time using contingency in design phase estimates and buffers in the timeline works when there is sufficient data regarding how much additional time and cost this secret phase requires. Where companies allow it, high level design can sometimes begin before the requirements document goes through its final review. Doing so brings the design thought process forward, which also brings the additional questions regarding the requirements into the requirements phase. With this solution, some additional time will need to be accounted for, as the requirements phase may extend.
Each project team will need to assess the right solution to account for this recurring problem.
Once a team can acknowledge the secret phase, they can begin to devise solutions to account for it. It is when we deny that the secret phase exists and that our costs and timelines seem to grow out of control. However, when we see the project process with fresh eyes, we can find its risks and plan properly for them.