Requirements gathering is in my opinion they most important part of any project. If this phase is mis-managed in any way then the impact on proceeding phases can be catastrophic. The reason for this is that the requirements of any deliverable dictate what will be designed, built, tested and deployed down the line. Many organizations will have at their disposal Business Analysts whose primary role is to ascertain information form key business stakeholders and document requirements. These requirements need to be agreed and signed off by the key stakeholders and then managed to delivery by the Project Manager. Depending on the scale of the deliverable at hand the Project Manager may need to have a very detailed low-level grasp of the requirements or a more high-level working knowledge. Either way the Project Manager needs to understand the requirements and understand what is to be delivered and manage accordingly. If a Business Analyst is not available to aid in the requirements gathering phase, then the Project Manager will need to take full ownership of this phase. Please see below for more information.

• Requirements phase of any project is arguably the most important – reason being get requirements wrong and delays are inevitable in subsequent phases.

• The Business Analyst should gather the requirements for project deliverables aided by primarily the stakeholders who are subject matter expert’s and also supported by the PM.

• Requirements can be gathered in excel, word, PowerPoint, whatever works for the Business Analysts.

• Systems like Visio, Miro, JIRA, Confluence helps with creation of process flow diagram & the management of user stories.

• Depending on the methodology used the terminology can be different, in Waterfall it’s requirements, in Agile its features & user stories.

• It doesn’t matter what they are called, what matters is they are captured accurately and signed off by business owners.

• Refinement sessions and / or further analysis sessions may be needed to tweak requirements so that they are fit for development teams to accept and begin the build phase.

• In systems development it is common for Business Analysts to document the current “as is” processes and ideal state “to be” processes.

• In some developments it may be the case that the “as is” processes are staying the same with better more automated systems introduced to potentially stream line them.

• The idea should be that business processes improve, become streamlined and the quality at least stays the same but ideally improves, at least reaching its optimal level.

• It would be naive to think requirements gathering works the same in each organisation – and because of this on occasion PMs May be asked to double job or at least aid the business analysis In producing the requirements.

• Even if as is traditionally accepted and Business Analysts produce the requirements PMs should have adequate requirements gathering skills to review the requirements produced for accuracy.

• A PM should manage the requirements gathered by making sure they are signed off by business owners.

• PMs should track the requirements by classifying them by in scope / out of scope.

• Then any change requests whether free of charge/ or charged can be classified and managed separately.

• It is wise to add all requirements to a traceability matrix and track them through the development phase until fully built and tested.

• End users should perform testing on all requirements and sign off once they are happy they meet their needs.

• Numerous requirements workshops may need to be organised during the requirements phase of the project – resources attending should be Business Analysts, system engineers, Project Managers & subjects matter experts and / or system end users.

• Project Managers attend requirements workshops more to listen and take notes and give guidance where necessary – they are also there to make sure that if scope has been agreed in signed off contracts, it is adhered to.

• Workshops can be onsite in offices or online, it all depends on the project being delivered.

• Requirements should be dictated, driven and controlled by the customer.

• The vendor should listen and carefully review customer requirements.

• The vendor can demo their systems but in theory this should happen in pre contract (discovery) sessions.

• During requirements if a demo is needed or requested by the customer then this is fine.

• Some vendors will try to dictate and control requirements by facilitating and providing endless, indirectly and directly trying to force customers to accept their systems without any bespoke work or tailoring if the system being entertained.

• This is more likely to happen when internal systems are being implemented by a headquarters to a local office – keeping costs in line & maintaining standardised systems can be reasons for this

• External vendors should adhere to signed contracts and a collaborative approval to requirements gathering should be facilitated & executed.

• Customers should make sure all their requirements are included in requirements documentation and that any bespoke system work is clearly outlined. If there is an agreed extra cost or if it’s free of charge if outside contract then this needs to be noted to.

• Any disagreements in requirements whether it’s interpretation of requirements or whether there is a disagreement on whether a requirement is included in the signed contract or not should be handled by an agreed dispute resolution process. This process should be in the contract.

• If requirements are managed professionally and carefully then subsequent phases will run smoothly without problems.

• If requirements have been missed or documented incorrectly then delays & lags to subsequent phases is inevitable with increased costs.

• Agile development can facilitate requirements known as features be developed in certain sets during certain sprints. There may be numerous sprints during each development.

• Agile development can support an iterative approach whereby requirements maybe tweaked numerous times to support the desired delivery output.

• Agile is better for smaller system deliveries but has now become more common in larger deliveries too.

• The PM depending on methodology used needs to manage requirements so that scope is delivered, whether it’s waterfall, agile or a hybrid mix.