Follow the Russian Advice When Dealing with Project Requirements
The Russian proverb “Trust, but verify” should be heeded by all sage project directors particularly on requirement matters. That means that corporations simply need to verify their project objectives and plans against market demands before putting them into action to avoid mishitting what the market dictate because there are 37 percent of organizations believing that inaccurate requirements is a primary contributor to project failures according to the PMI report “2014 Pulse of the Profession Study”. An earlier investigation “2011 Strategies for Project Recovery” by PM Solutions made a more alarming allegation that requirement issues was the number one reason for troubled projects.
What Spark Incorrect Project Requirements?
To understand why so many projects execute against wrong sets of requirements, one has to dissect the process that creates them to explicate the reality that the requirements in their final form are effectually project objectives that govern project executions; they are not the ones taken verbatim from the customers or the market through surveys and interviews. To be more precise, the original market calls are cascaded through a set of transliterations that morph customer aspirations consecutively into business requirements, project requirements, project objectives, and in the end project plans that are finally implemented to satisfy market interests. Besides the hidden danger of translation gaffe in this process that one can easily imagine, another factor that adds fuel to the fire is that market fluctuations, which are not uncommon these days, may not get trickled down into project plans properly. This could cause the projects to lose the opportunity to rectify appropriately to match with the shifted market conditions.
The typical stakeholders and how they are involved in the requirements pass down process described below will help reveal where miscounts could crop up in the various transcription efforts.
- Marketers (product managers, account managers, client managers, relations managers, marketing managers, etc.) need to transcribe customer asks into business requirements that not only address the market needs but also are in line with their companies’ business strategies and capabilities.
- Business analyst (or project director, also called program manager, if the corporation does not have a business analyst position) must map the business requirements into project requirements, or sometimes into multiple sets of project requirements when they are too large to be handled by one project, or when it is more befitting to have them separately addressed in successive stages because of strategy or limitations like hunger marketing, capacity, and readiness.
- Project director must ensure that correct requirements are churned out eventually at the project level to guarantee project deliverables to be fulfilling market demands. Additionally when the project requirements are complex or interrelated among themselves, the project director needs to partition them into multiple interdependent subsets such that each becomes the starting requirements of a project that will be handled by a project manager under the director’s guidance.
- Project manager converts project requirements into project objectives, breaks them down into tasks, creates a corresponding project plan complete with its project triangle (scopes, schedules, and resources) for these tasks, and finally gets the project doers (functional team members) to commit to the project plan.
It is therefore quite easy to understand that oversights are prone to emerge with a process involving many stakeholders and transcription endeavors. Thus a call for building a wise mechanism into the process is in order to safeguard translation quality.
The Trust but Verify Rule for the Requirement Translation Process
The key job to contain requirement translation jitters for the project director is to make sure that all stakeholders involved in the transcriptions collaborate properly under the trust but verify principle. Below is a simple illustration of what collaboration means in this context.
After the marketers develop business requirements based on the market inputs they have received, they validate with the customers, or with partners or vendors who represent the voice of the customers (VOC), to ensure that their business requirements meet their customers’ petitions. The ratified business requirements from the marketers are then handed over to the business analyst to transform into project requirements. The project requirements completed by the business analyst are then reviewed and approved by the marketers before being forwarded to the project director. The project director splits the project requirements into sets of interrelated subsets and passes them onto project managers. Then each project manager respectively takes a project requirements subset and rewrites them into project objectives which are inspected and endorsed by the project director before further broken down into tasks for which a project plan is developed to guide their executions.
It must be noted that if rewritten requirements are not endorsed by the preceding stakeholder during any one of the translation phases, a change in the antecedent requirements may be necessary to regain alignment. When requirements are changed at any stage, they in turn need to be reauthorized by the stakeholder in its prior step in a backward fashion trekking through the process until the marketers, who are at the beginning point of the process, recertify the modified business requirements with the customers, partners, or vendors. Furthermore, when a market fluctuation affects the requirements, the marketers are obligated to inform the project director to halt the projects if they are already in motion, and wait for the reshaped project requirements from the business analyst to review and decide if a minor objectives and project plans amendment is sufficient to assimilate the edits and if it is suitable to leverage any completed project works. If the requirement revision necessitates a clean slate, the revamped requirements must be remapped into new sets of project objectives and their respective project plans again.
Corporations cannot cut corners because the stake is high if their projects do not execute against the right objectives and end up delivering against displaced market stipulations. In essence, any adjustment made downstream must trigger calibrations upstream until all respective alterations on business requirements, project requirements, project objectives, and project plan are in unison before the projects resume their executions.
It is always easier said than done for almost anything complex. To succeed in this feat, merely having the aforementioned process developed is not enough, project directors must be truly empowered by the top brass to be able to enforce the many translation-validation cycles through the stepwise transformation process. Any one among the marketers, business analyst, project managers, and project doers failing to abide by the trust but verify doctrine could detriment the conversion quality and could result in misconstruing project objectives and plans to misalign deliverables with the market appeals. In summary, the process to translate requirements from market intelligence to a project plan is a knotty one, and wise project directors must secure their empowerments before managing this trust but verify credo conscientiously to eliminate any loss in translation.