Despite decades of project management advice being dispensed, books being written and tools and methodologies being championed, project failure rates are still mind blowing.
McKinsey, in conjunction with the BT Centre for Major Programme Management at the University of Oxford, published figures comparing 5,400 large IT projects. They found that 45 per cent ran over budget, collectively delivering a whopping $66 billion overspend, and seven per cent ran over time. In addition, these projects delivered 56 per cent less value than expected.
In the face of figures like these is it any wonder that the industry continues to obsess over the reasons for project failure? They are many and varied, and if you choose your research carefully, you can find them served up in any order you prefer. A simple Google search for ‘why do projects fail’ returns 1.6m results in less than half a second but, perhaps more positively, a search for ‘making projects more successful’ reveals almost 400 times that number with 634m hits.
So what’s the problem?
The McKinsey research showed that as well as content, skills and execution issues, the majority of the projects cited ‘focus issues’ as the cause of their failure, in particular, unclear objectives and a lack of business focus.
Projects are often started with a vague idea of the objective. If you ask the project sponsor and the project team what they’re trying to achieve they will generally talk about the solution rather than the problem they’re trying to solve.
How do we change that?
This is where you might want to depart from traditional project management and consider adding a business analyst (BA) to the team. Business analysis has evolved as a profession over the last few decades. You might already be enlightened and have them embedded in your projects, in which case the rest of this article can help you understand better the role they’re playing for you. Otherwise, if I can convince you of the value of adding one, then my work here is done.
Ideally, BAs are involved before the project is set up, helping to define the problem that the project is to address and ensuring that the focus and objectives are well-formed. Once the project is underway, the BAs will make sure that the stakeholders, the business and the customer needs are translated in to clearly defined and documented requirements.
The trade off for this is a smoother running project, outcomes that are more closely aligned with stakeholder needs, a happier project team and much less likelihood of additional delays and costs later down the line.
Which tools and techniques?
Requirements elicitations can be handled in a number of ways. These could include one to one interviews, group workshops, questionnaires and good old fashioned job shadowing.
The output for requirements can also be varied. Using the appropriate visuals and documents for your business and your project is critical. There might be a formal business requirements document (BRD) that lists all the requirements, but be prepared for this to be long and perhaps a little dry (see box).
Who owns the requirements?
Once the requirements are gathered in whatever form suits best, the entire group of stakeholders should meet to agree them and provide sign off. It’s vital that the stakeholders ‘own’ the requirements.
Often this full group review will take place only once smaller subsets and individuals have reviewed, prioritised and sharpened the requirements - possibly in several cycles. This iteration and honing makes the full review much quicker.
Your BA might use the MoSCoW principle to help with this, identifying ‘Must have’, ‘Should have’, ‘Could have’ and ‘Want to have but won’t have this time’ requirements. Categorising like this will helps prioritise requirements and keeps a sharp focus on the scope.
A good BA will plan their one to one meetings, the small subsets and the full requirements review to encourage active participation and to keep the momentum going. They want the process to be energetic and they’ll encourage criticism and open debate to make sure that all perspectives are considered. They’ll ensure that the stakeholders understand and feel their ownership of the requirements before the BRD is signed off.
Attitude or skill?
But that’s not the only display of soft skills. A great BA will use a wide variety of skills to engage and include all the team members throughout this process. The importance of this cannot be underestimated and is often something that easily identifies a BA in the making.
Requirements elicitation is just the beginning of the BAs involvement in any project. Amongst many other things you will find them: managing stakeholders throughout the project; ensuring that the requirements are fully understood by the development team; translating and acting as a go-between for the business and IT; supporting the preparation and execution of user acceptance testing; helping to train users in the final solution; defining and measuring business benefit.
So what next?
With over 70,000 certified BCS BAs and established BA practices within many large organisations, the profession is well and truly established and making significant improvements in the running of projects.
The BCS International Diploma and Advanced International Diploma can help you or your team members grow your knowledge and expertise. Our modular programme offers a flexible, career-long education, with specialist learning you can tailor to your specific business needs.
You’ll find more information at: bcs.org/businessanalysis
