Airspace Q2 2019 – Know what is required
In the second of a series of articles for Airspace on best practice in procurement, Kelly Ann Hicks, Chair of the CANSO Acquisition Excellence Workgroup, explains the importance of understanding and documenting all requirements in a project.
As outlined in the first article in this series, A Best Value Approach, purchasing and supply chain functions need to work together with the aviation industry to deliver better value to their organisations.
Purchasing and the supply chain must also work closely with their internal stakeholders to develop requirements that reflect that value in order for industry to deliver what is required.
Ever expanding or changing requirements on a project greatly impacts cost and schedule and can ultimately lead to the failure of a project.
Requirement ‘creep’ reflects an inconsistent or undisciplined approach to requirement development. Putting in place a flexible and scalable requirements management plan is how organisations become successful in delivering projects on time and within budget.
Who to involve
The first step in developing a requirements plan is to determine who are the project stakeholders. Teams must look to the whole organisation when defining stakeholders to include individual experts and representatives of each functional domain.
For example, if you are only working with the engineering team and not the ultimate users of the product then the chances are your requirements will not be comprehensive. This jeopardises the success of the project. A well-thought-out plan will include securing the buy in of users, developers, maintainers and project sponsors at various levels of the organisation.
If a project deployment involves many stakeholders, then the supply chain or the lead function should also consider implementing a stakeholder management plan which involves identifying and classifying stakeholders in terms of influence and interest in the project and then monitoring their engagement. The better your governance of multiple stakeholders, the better your requirement plan will be.
A successful project will include the requirement development process at the outset of the process. The earlier a team starts gathering and developing its requirements, the less impact potential changes or issues will have. If the project is well on its way, and requirements are still being defined then changes or issues to those requirements will most likely adversely affect project cost and schedule.
When to start
Once the stakeholders have been identified, it is necessary to gather all the requirements. However, it is important that the lead organisation and involved stakeholders understand the project’s objective and mission prior to inundating the project team with a list full of requirements.
For example, is your new enterprise resource planning system mission to improve the client experience or to drive efficiencies within the organisation? If the answer is both, then your requirements will need to reflect this duality and be aligned separately with each of these objectives especially when one objective (efficiency) can impact another objective (client experience).
There are various ways to gather information from your stakeholders, such as surveys, one-to-one meetings, or brainstorming sessions. The technique chosen should take stakeholders and organisational culture into account. An engineering group may be more receptive to a brainstorming session than a formal survey. A finance department may welcome an in-depth spreadsheet analysis of the requirements.
The task is far from done once you have gathered all the requirements. Many project teams make the mistake of including all requirements into a project’s specifications – all things for all people. This can lead to unclear objectives and a multitude of conflicting project paths. Budget considerations must also be taken into account at this stage.
The team in charge of requirements must now analyse, refine and organise the requirements received into a clear project path that is aligned with the project’s mission and objectives. This process is sometimes referred to as requirements definition. This phase of the process, if done well, should also reveal requirements that were missed during the gathering initiative. Sometimes, these requirements can be as or more important than requirements that were obvious from the start.
Thoroughly aligned requirements with objectives can assist in revealing what you do not know at the outset.
Your plan should consider and include training requirements, human factors and steps involved in managing resulting change.
Formal requests for information
At every step of gathering, analysing and defining, the requirements team should be documenting the rationale behind why a requirement has made the list. If a requirement justification cannot be easily explained, then there might be a requirement that should not be there.
Sufficient and clear documentation will enable the project team to clearly track deliverables back to the requirements. This will save a lot of effort in the long run by permitting the project team to focus on the deliverables.
Many organisations use a formal request for information process (RFI) to gather and hone requirements. Expert advice from potential suppliers can be invaluable to the process. RFIs also facilitate a more formal review of existing solutions that may fulfill a project’s requirements. However, if a requirements team does not start with, or spend enough time gathering input from stakeholders, then the most thorough RFI process will never produce the results that the project delivery team is seeking.
Once you are confident that you have defined requirements, traceable to deliverables, the project – and the procurement process – is ready to proceed. It is important at this stage to circle back to the stakeholders and verify that everybody has got it right. A requirements document will change and evolve throughout the course of the process, so it is important to ensure that nothing was lost.
Stakeholders’ final review and buy-in will also ensure shared accountability for the project.
In summary, an effective requirement plan should include a defined mission, a clear understanding of the current situation and the associated costs in filling gaps. Comprehensive budget forecasting exercises at the outset and understanding how requirements changes can impact cost and schedule are essential.
Requirements planning takes time and commitment but will ultimately result in a more cohesive, disciplined approach, favourably impacting project delivery, cost and schedule.
The next article in this series will examine how to select suppliers that meet your exact needs.
