Luca Collina|How to Use Requirements Questionnaire During Project Recovery Assessment
top of page

How to Use Requirements Questionnaire During Project Recovery Assessment



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

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

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!

Recent Posts
No tags yet.
bottom of page