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:
- Requirements review
- Using an indirect requirements validation approach
Let’s see how the indirect requirements validation can be very effective.
Prerequisites:
- 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

Scope Management Plan Template
(For Software Projects)
Most software project managers don’t know what goes into a Scope Management Plan. So, they simply don’t write it out. Unfortunately, this often leads to problems.
Get my template and use it as a starting point. In addition, you get access to all related scope management resources I have.
This template will eliminate the guesswork for you. With minor adjustments, you’ll be proud to present your scope management plan to the team and stakeholders.
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)
Priorities
We decided to take the priorities already assigned and integrate them with our standards.
Processes References
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
Test Your Knowledge in Scope Management
Take a quick quiz on project scope management. In the end, you’ll get a review of correct answers and explanations. Additionally, you’ll find resources that will help you cover the knowledge gaps. As a result, you’ll become a more efficient project manager.
(opens in a new tab)
Which techniques can we use to create questions?
How:
- Question (which regroups two different requirements)
“How would you manage/improve/change a supplier invoice related to import transaction?”
Why:
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?”
What:
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.
Who:
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
Pros
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
Cons:
- 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!
Get My Scope Management Plan Template
Most project managers don’t have formal education. That’s why you have to google all the bits and pieces of project management.
I know how frustrating it is to search answer for each step of a project.
That’s why I recommend you get this Scope Management Plan template. It will provide you with access to all my Scope management materials:

Scope Management Plan Template
(For Software Projects)
Most software project managers don’t know what goes into a Scope Management Plan. So, they simply don’t write it out. Unfortunately, this often leads to problems.
Get my template and use it as a starting point. In addition, you get access to all related scope management resources I have.
This template will eliminate the guesswork for you. With minor adjustments, you’ll be proud to present your scope management plan to the team and stakeholders.

Luca Collina (BA, BSC & PM PRINCE 2 Certified) is an independent transformational consultant and PM (change management and ERP). If you are looking for a way to balance your tasks between project & change management send me a message directly to me at info@lucacollina.co.uk
Leave a Reply