Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

Perfecting business requirements for successful projects

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

Projects tend to be complex and have inherent risks and uncertainties so we use established procedures and templates to manage them. However, using a standard template is not necessarily a recipe for the perfect (or even good) business requirements. Just as blindly following a set of procedures and templates won't make your project successful. We all know there is much more to professional project management than that.

But what will contribute to a successful project is making sure the business requirements are right, detailed, thorough, complete and leave nothing to chance. Don't shy away from difficult conversations – at the requirements stage what's needed is candour because only by all parties involved being open and honest can you hope to achieve a detailed set of requirements that will deliver a successful project outcome with or without using a standard template. 

So when you are faced yet again with your organisation's standard template take a good long look at it and see if it can be improved – if you have been running projects for any length of time you should know where things have gone wrong before and where improvements could be made. The business requirements are the foundation of every project so make sure yours is solidly built.

Depending on the complexity of a particular project the business requirements will clearly be more or less detailed but most should contain the following core sections so that your final deliverable delivers on-time and on-budget but, most importantly, meets the needs of the client.

The business problem 
Projects are instigated because of an existing problem that needs solving or the lack of something so make sure this is clearly defined. The problem definition will be used time and again throughout the project when decisions need to be made about changes and when checking the project is on track to deliver.

The current situation
Only by understanding how something currently works and why it fails to meet current needs can a project hope to successfully deliver real change and improvement. 

The goal
What do the stakeholders wish to achieve with this project - what is the overall objective? Without this being clearly established resources will be wasted doing tasks that do not contribute to the goal.

Project scope 
It is essential to clearly define what is within the scope of the project right from the outset to avoid any uncertainty once the work is in progress. Failing to define scope will lead to scope creep, and scope creep will lead to project failure. The project scope will both set realistic expectations and help the project manager to manage stakeholder expectations throughout the course of the project.

If there are any limitations or constraints: legal, technical or budgetary, these should also be explained in the scope definition.

Success criteria 
This should be a pre-agreed and pre-approved list of items that indicate the project has been completed successfully. It goes without saying, but I will say it anyway, that these criteria must be objective not subjective i.e. they are measurable and not based solely on opinions.

Risks
The nature of projects, embarking on creating something new, means that risks are inherent in projects. However, it is essential to identify the potential risks early on so that plans can be put in place for risk mitigation. Risks cannot be eliminated entirely and neither can all risks necessarily be identified but neither can potential risks be ignored. 
 
Assumptions 
It is difficult to obtain a list of assumptions because many stakeholders may not be consciously aware of the assumptions they are making. Nevertheless, by talking to key individuals a list can be drawn up that can help clarify project scope and expectations.

The new/improved situation
A project could involve straightforward improvements to an existing situation (such as adding a lane to a congested section of motorway) or a radical new solution (such as the proposed 'double decker highway' on the busiest stretch of the M25). But whether it is a simple or complex solution it does need to be clearly stated in order to highlight potential problems and issues as early as possible.

Quality criteria
As with success criteria by defining at the outset the quality of the final deliverable and how that can be measured this will help ensure that quality targets are met and, of course, the key objectives are met.


This is a project management fundamentals blog written and sponsored by Parallel Project Training

4 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Nicole Reilly
    Nicole Reilly 01 July 2016, 06:29 PM

    Only yesterday I was involved in a conversation about document-driven project management, and how this is bad for governance.Good to see this thought process also being applied to business requirements. 

  2. Paul Naybour
    Paul Naybour 01 July 2016, 06:43 PM

    Nicole I couldn't agree more. Having said that I think a simple PM framework can be very helpful in developing team work. With no clarity over roles, basic processes then we don't get team work. I think the key thing to remember is that the processes are there to serve the project delivery and not the other way around. I have seen good frameworks make big differences to delivery in some organisations.

  3. Philip Macey
    Philip Macey 01 July 2016, 10:16 AM

    Paul a most useful summary - re-posted on LinkedIn.  I concur with your comments on current situation - the As Is.  It is here where the causes are located and where the business analysts/systems engineers should concentrate their efforts.  Too often a project delivers a solution to the wrong problem which would have been obvious if more time had been spent understanding the current situation.

  4. Paul Naybour
    Paul Naybour 01 July 2016, 06:44 PM

    PhilipThanks for leaving a comment. Yes quite often I see people setting off designing the solution without asking any questions about what the problem is first. it must be something built into our human behavior.Paul