Lucy Ireland, Deputy CEO at BCS Learning & Development, looks at how focusing on the problem rather than rushing to solutions can ameliorate project underachievement, and shows how a business analyst can help.
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.
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.
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.
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).
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.
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.
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
I've been working in IT for over 40 years & this sounds like old-fashioned systems analysis. I had not realised that this common sense role had ceased to be used. I, certainly, continue to advocate and use role(s) like this in my projects & programmes. I have to wonder what education younger IT professionals have had if this role needs to be explained & championed.
I believe that multi-disciplined team adhering to the appropriate methodology are essential to a successful project outcome. In reality, organisational stakeholders' business objectives are often vague, contradictory and incomplete. A systematic methodology assists to reconcile stakeholders' business objectives before requirements for a system are produced. Additionally, the matching of requirement statements to business objectives ensures completeness and identifies project scope creep.
If unclear about the purpose and goal, why start a project? Surely that is a recipe for disaster. Success of IT project is measured not by the product it delivers but by extend to which it meet its goals, provide value for money and transform how people work and interact.
How many of us will set out on a journey without a clear purpose. So why start a project without clarifying why it was necessary? Barry Midgley, is right, that is just common sense.
In my project class, I insist candidates start their project by first stating clearly why they think their project work was necessary, instead of what system they wish to build. They must write to explain and evaluate the problem they are trying to solve before starting their project. This simple approach seems to work well each time.