That's not what I wanted, An Acando master class in business analysis.
•Download as PPTX, PDF•
1 like•404 views
In this master class we look out how to undertake effective business analysis from inception through to implementation to ensure successful project delivery.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to That's not what I wanted, An Acando master class in business analysis.
Similar to That's not what I wanted, An Acando master class in business analysis. (20)
More from Edward Gould
More from Edward Gould (9)
Recently uploaded
Recently uploaded (20)
That's not what I wanted, An Acando master class in business analysis.
- 1. THAT’S NOT WHAT I WANTED! An Acando master class in business analysis
- 2. TIM READER Lead Business Analyst www.acando.co.uk Tel: +44 (0) 1928 796 800
- 3. Acando is a company of Programme Managers, Project Managers and Business Analysts focused on raising the bar for project success. We engage differently to create the conditions for success so that projects achieve both benefits and the best possible delivery. Our customers tell us that our consultants achieve this better than 99% of the time (and our engagement model guarantees this).
- 4. In this master class we look out how to undertake effective business analysis from inception through to implementation to ensure successful project delivery.
- 6. How often do we find that a project does not deliver as expected, or if it does, it's only as a result of increased cost and time?
- 9. Root of Project Failure • Majority of errors are introduced during requirements analysis • Very few errors are introduced during development • Less than 12% of project time is allocated to the requirements phase – bulk of time allocated to development and testing • Lack of alignment with business objectives and strategy • Poor Management of requirements
- 10. Percentage of errors found at acceptance testing – James Martin
- 11. Relative Cost of Correction at Each Stage – Barry Boehm
- 12. So, what is the Solution?
- 13. 1 Image courtesy of Bing. Free to Share & Use Licence
- 14. 1
- 15. Projects cannot live by Project Management alone
- 16. Less than 12% of project time is allocated to the requirements phase. The bulk of time is allocated to development and testing
- 17. Are you undertaking sufficient analysis to ensure that the project being proposed is the right thing to do?
- 18. Do your Business Analysts have the necessary skills and attributes to deliver what is required?
- 19. Does your organisation, And its stakeholders, understand the value of business analysis?
- 22. Thank you for listening… Any Questions ?
Editor's Notes
- Hello my name is Tim Reader and I’m a BA for Acando. Welcome to this session on Business Analysis. CLICK
- Obviously, this isn’t me! Mike couldn’t be here today, so I’m here instead to tell you why Business Analysis is critical to Project success. What makes me qualified to deliver this in his stead? Business Analyst for 12 years across a variety of companies and industries, ranging from Finance & Banking to Loyalty & Retail. Employ a variety of methodologies, tailored to the Project & client need. CLICK
- Who are we? Acando is a consultancy that thinks differently. Our ultimate aim is the successful delivery of Projects across any industry, utilising our experienced consultants to deliver what clients need, not what they think they want.
- In this master class we look out how to undertake effective business analysis from inception through to implementation to ensure successful project delivery
- As much as this session is about getting requirements analysis right, it is really about more effective use of Business Analysts and the role they can play throughout the life of a project to ensure that what is delivered is what was wanted and more importantly needed. From my own experience I often find that BA’s are under-valued and the requirements, even design phases of projects are given a disproportionately small amount of the overall project time and budget. So I would like to talk to you today about why I think greater investment in requirements analysis and the involvement of BA’s throughout the life of a project can increase your chances of success. CLICK
- An unfortunate aspect of our profession is the continuing association with failure and despite all the analysis and research, the development of methodologies, techniques and tools, lectures, debates and so on, successful project delivery does not seem to be getting any easier. Defining what makes a successful project is a tough subject in itself and open to all sorts of interpretation, although, fortunately for me, that’s not what I’ve been asked to talk about today. However, one aspect or measure of success that I hope we can all agree on is has the project delivered what is required or more importantly what is actually needed to support the organisation’s objectives and associated benefits? The title of this session is “That’s Not What I Wanted”, which is unfortunately a not uncommon response from project customers and stakeholders to what’s just been demonstrated or worse, delivered to them. So how many of you have been involved with or know of projects that have got part way through or even to the end and the customers have suddenly stated (usually in the middle of a demonstration) that what’s been delivered or being developed isn’t what they wanted or doesn’t work in the way they expected? Quick show of hands please. (Fingers crossed for some honesty and a majority show of hands) Sadly I’m rather pleased that it’s so many of you, otherwise it means that it’s just me that’s experienced this and I should leave now and rethink my career. Even when projects do deliver what is wanted, it is frequently only as the result of increased cost and/or time. So why is this so often the case? CLICK
- Research and experience show us that in the majority of cases, this can be traced back to the requirements that the subject of their disappointment has been based on. This infers then that the requirements engineering element of the project is at fault in some way, including one or more of: Failure to identify requirements Poorly defined requirements Poor management of requirements Lack of ownership Of course part of the issue is getting acceptance that what is wanted, and what is actually needed, are very often different things. CLICK
- Given that poor requirements analysis or management is at the heart of the problem, are we really investing enough time and resource into getting it right? Not wishing to bore you with quotes and results from past research, but I think the following help to illustrate these issues but… CLICK
- Over the last 30 years or so there has been much analysis and soul searching to try to determine why so many project fail.
- Research undertaken in the 1980’s found that nearly 60% errors found during acceptance testing could be traced to mistakes made during requirements analysis, with relatively few errors down to poor coding. Although this graph is from the 1980’s, it still holds true today. So if most errors ok during requirements analysis, and if we are able to identify them at that stage, then the cost of correcting them should be relatively low, right? CLICK
- Whereas if the errors persist through the later stages of the project and into live operation, then cost of correction is exponentially higher. CLICK
- So, what's the solution? CLICK
- First of all; There is no magic solution or shiny new method or set of tools to pitch, we’re not here to sell you anything, and I’m not going to pull a rabbit out of a hat and give you an all-in-one solution, it doesn’t exist. At it’s core, it comes down to a combination of tools and techniques readily available to us, the trick is to ensure that we are using the right approach and the right tools for the companies we work for, or the organisations we are working with, not because that's the way it's always been done, but because it is right for the Project. But perhaps more important than that is to ensure that Business Analysis and particularly requirements engineering is core to the initiation, development and implementation of the project. CLICK
- Given that the output from Business Analysis supports so many elements of a project; from cost justification through supplier selection, design, development support, testing and implementation, the role of BA should not be underestimated. A BA is often defined as the bridge between the business and the project/IT or the ambassador for the project. In terms of stakeholder management, BA’s often have a much better relationship, at least at the start of the project, than other project roles, which usually stems from a feeling of trust that the BA is there to help them and not blind them with technical (project and IT) jargon. One of a BA’s most useful, and yet unrecognised attributes is the fact that we are generalists, not specialists. We develop skills and toolsets that can be applied across any industry and any project, meaning that we are not constrained by established opinions, and can view Projects objectively. As one of my colleagues put it, we get to ask the stupid questions, because no one else wants to. CLICK
- CLICK
- As BA’s we often join a project to undertake a variety of key tasks, including developing RFP’s, requirements analysis, process mapping and developing functional specifications, the usual things that BA’s are expected to do. However, this is more often than not the first time any form of business analysis, particularly in relation to requirements analysis, has been undertaken on the project. Which of course means that the project has been estimated and approved without any real analysis to support the business case and the associated costs and timescale to deliver the project and its promised solution. So to get back to the answer, in order to increase your chances of delivering more successful projects, you should first of all consider the following: CLICK
- If your project is being established to address problems with existing processes and/or systems, a high level process mapping exercise with key stakeholders will help to confirm exactly where the issues lie and options for addressing them, which could simply be a change in process without the need for costly system development. High level requirements analysis will help support the case for any investment, help with producing more accurate estimates and support all the processes that follow – detailed requirements analysis, procurement and tendering exercises etc, Undertaking a short piece of analysis before committing to the project could not only save considerable time and money, but also avoid the creation of another project that fails or at least fails to meet expectations. Being strong enough to challenge the requirements from the start and throughout – the world does change and on some long term projects requirements and design decisions taken over a year ago may no longer be valid CLICK
- The role of BA is not always as obvious as it would appear – one man’s BA is another man’s System Analyst or Data Analyst. So it’s important that you have the right skill set for the project or at least the phase of the project. For me Business Analyst is someone who focuses on the business issues and needs, looking for the right solution rather than focusing on the constraints and issues. Stakeholder engagement is key, and ensuring that they understand and empathise with business issues whilst being willing to challenge their requirements in a consistent unbiased way creates a relationship of trust, aligning your aims and clearly setting the expectations. CLICK
- Convincing stakeholders to invest the time and money to undertake this work is difficult. How do you quantify an unknown benefit before you've seen the results? Ensuring that Business Analysis in itself is valued and recognised as key part of any project requires an understanding of the impact that a BA can have on a project. Up front engagement on requirements analysis and business process mapping supports the development of the project, from business case to delivery, and ensures that the project is run for the right reasons, and delivering what the client needs, not wants. CLICK
- Regardless of the project approach, identifying, defining and verifying requirements are an essential element of ensuring that a project delivers the processes, tools, functionality etc that are needed to ensure objectives are met. Possibly not what the users wanted – the old of analogy of the gold plated Rolls Royce vs the more practical delivery van, which will do everything that is needed, only a lot more efficiently and for a lot less money. CLICK