In the Project recovery life cycle, there is a crucial phase: Requirements for a recovery
phase, where we assess and validate the original requirements vs solution proposed.
I have broken down the two other sub-phases to help in understanding where we can
allocate the indirect requirements validation approach and what are the outputs of managing phases 10 and 11.
It is clear that, depending on the size and scope of the project, we need to find the most time effective solution to complete these tasks.
When is an indirect requirement validation necessary?
When I was called to assess the requirements in a project recovery, my team had to extract them from the related requirements documentation and to create a log with 850 requirements, split into different project areas (configuration, customizations, integrations, reporting).
Due to the high number of items, and the critical situation of stakeholders’ engagement, it was clear we had to find the most time-efficient solution and at the same time being able to have the most independent evaluation criteria.
We have managed the point 10.1, which has been handled with the combination of different techniques:
Using an indirect requirements validation approach
Let’s see how the indirect requirements validation can be very effective.
Functional requirements documentation and technical documentation are available
Resources such as Business analysts and technical guys are available to build your team
There is a large number of requirements
How does a Requirements log structure look like?
Our starting point for this technique was to create a requirements’ log as in the picture below.
Let’s have a look at the relevant fields (in grey information from previous requirements gathering; In light blue: assessment and consultancy criteria).
We decided to take the priorities already assigned and integrate them with our standards.
We then attributed to each requirement, the process and sub-processes, considering previous highlights already made by the consultancy company, if any (in my experience it’s fundamental to evaluate the sub-processes assignments)
Gap/fit: see table below
Impact on business processes, on original scope – see table below
Current requirements status in the project (issues)- see table below
Group for questionnaire
You may regroup more than one requirement in one question on the questionnaire/survey, or you can leave each one as a single question. This is a discretional activity: choose the most suitable group based on any possible type of questions, type of priority and sub-process.
How can we choose the requirements to be transformed into questions?
Please bear in mind that this activity remains a discretional one anyway, using an independent approach.
We need to exclude those which:
have a low or medium-low impact on the project status
have a low impact on the business processes-original scope
Which techniques can we use to create questions?
Question (which regroups two different requirements)
“How would you manage/improve/change a supplier invoice related to import transaction?”
it’s another powerful question type. It can give you an indirect positive or negative confirmation of the requirements which have been identified in the scope, and it can also help you to understand the root cause of the requirements
Question example, which regroups two requirements from different processes:
“Why is a re-working process necessary to plan and keep under control stock materials consumption?”
I have used to regroup different requirements to ask:
“What do you expect from an integrated approval workflow for Purchasing order proposal? Please describe the main outputs expected from this functionality” Or “Please select from the list below (ticking off the available boxes with predefined features elements)
Where and when:
These are usually used to understand if the requirements related to process checks, workflow approval, tools gates are clear and confirmed, or something have been missed in the first place.
Questions with who, normally help to identify resources and workflows roles involved in the process, and to verify other stakeholders related to cross-functional processes.
How can I manage the outcomes of the questionnaire?
Once received the questionnaire, complete the requirements log in the section with the findings in the section answers received. We need now to highlight the gaps between original requirements and answers validating them.
I would like to propose the following criteria and the relative actions to take:
What have the results been for my project so far?
We have segmented the 850 original requirements in:
124 – low to medium-low impact on processes and project status, no further investigation
456 – regrouped in 210 questions in total with an average for business process owners of 35 questions each
270 – specific requirements’ review in workshops
From the original 456 requirements, we could then:
Confirm 245 requirements
Remove 98 requirements
Investigate further 113 requirements
Total requirements to be further investigated in meetings and workshops: 383 (45% of the existing requirements),
New requirements: 89.
Wrapping all together
The main outputs of these targeted questions are:
Validated critical selected requirements,
Discovered unexpressed requirements to be used in 11.1-New requirements mapping
Workshops and meetings about requirements verification by exception
You can use the gaps between the original requirements and the new findings
to keep the conversation with stakeholders on track
To save time organizing workshops, group and 1-2-1 meetings
To refine the requirements analysis and the evaluation impact of both the requirements confirmed and the others with a changed status
Not as accurate as the requirements gathering activity, it may require additional investigation
Risk of not matching answers with the original requirements at 100%
Using assumptions rather than specific requests specification
Hope that you can try it with success!