The Past, Present, and Future of Business Analysis
•Télécharger en tant que PPTX, PDF•
2 j'aime•2,539 vues
Business analysis is growing beyond its roots in software requirements engineering and process performance measurement to become a true profession focused on organizational change. To be successful, business analysts will find themselves focusing less on technology and detailed specifications and more on business value, strategy, and delivering results. The demand for business analysts with these skills is only going to increase in the years to come. Business analysts must learn to look beyond project scope to understand why the business needs to change, and to help the business realize the benefits of change. If companies are going to survive and thrive in an increasingly competitive and globalized world, they will need business analysts to move beyond facilitation and requirements management and embrace architecture and design. The future for the business analysis profession is very, very bright - as long as we are willing to grasp it.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à The Past, Present, and Future of Business Analysis
Similaire à The Past, Present, and Future of Business Analysis (20)
Dernier
Dernier (20)
The Past, Present, and Future of Business Analysis
- 1. The Past, Present, and Future of Business Analysis Title Slide Include a tagline for your presentation here BBC 2013 1
- 2. Once upon a time... Image ©2009 Doug Kerr, Licensed Under CC-BY-SA How I Became A BA 2
- 3. Nobody Understood What We Did PM? Rules? Testing? Coding? UX? Process? Requirements? Training? Data? Coffee? © 2012 CollegeDegrees360. Licensed under CC-BY-SA. 3
- 4. Projects Paid A High Price Flawed business analysis work became a key point of failure for projects and drove much higher delivery costs “Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure— bigger than bad technology, missed deadlines or change management fiascoes.” Source: CIO Magazine, 11/15/2005 4
- 5. Are we: ORDER-TAKERS? GOFERS? ASSISTANT PROJECT MANAGERS? DOCUMENTERS? Or would we rise to the challenge? 5
- 6. Business Analysis Had to Change New tools and techniques, methodologies, and organizations began to define and improve how business analysts worked. ‣ Methodologies began to address requirements development in earnest ‣ Specialized techniques emerged taking us past “the system shall” ‣ IIBA formed in 2003 to help move profession forward 6
- 7. Business Analysis Became A Profession We developed a shared understanding of the role so that we could define how to deliver better project outcomes. 7
- 8. Bridging the gap between… Business and IT 8 © 2011 Jonas Ginter. Licensed under CC-BY-NC-ND. 8
- 9. But that didn’t fix the problem According to PMI, less than ⅔ of projects meet their business goals and that number has been falling since 2008. Standish Group CHAOS Report 60 50 40 Succeeded 30 Challenged Failed 20 10 0 1994 1996 1998 2000 2002 2004 2006 2009 Source: The Standish Group Project Resolution History, PMI Pulse of the Profession 9
- 10. Business Value Isn’t Inside Projects We can only do so much to improve business value by focusing on managing requirements within a project. Traditional BA Space Pre-Project Project Post-Project Rationale Delivery Benefits Enterprise Analysis Requirements Analysis Solution Assessment & Validation 10
- 11. Are we: LIAISONS? FACILITATORS? TRANSLATORS? REQUIREMENTS MANAGERS? Or will we rise to the challenge? 11
- 12. Business Analysis Has to Change Our focus has to shift again…from tactical support of project delivery to a strategic understanding of business value. ‣ Requirements management focuses us on predictable delivery of scope ‣ We have to focus on delivery of business value ‣ We consistently neglect understanding of the reasons for change and evaluating the benefits 12
- 13. Move From Software to Systems Successful change requires that we look at things from a business perspective—software requirements are only a part. People Software Organizational System Rules & Data Process 13
- 14. Bridging the gap between… Projects and Operations 14 © 2010 Doug88888. Licensed under CC-BY-NC-SA. 14
- 15. We still have the alignment problem… We must strike a balance between analysis and intuition, and take a share of responsibility for business outcomes. Analytical Thinking Architecture and Design Goal: To Produce Reliable, Predictable, Repeata ble Outcomes Reliability Intuitive Thinking Goal: To produce outcomes that meet the desired objectives Validity Source: Roger L. Martin, The Design of Business 15
- 16. Embrace Architecture and Design Architecture Architecture and design ensure that we deliver value to our stakeholders by defining solutions that meet their needs Focused on Strategy, Structure and Purpose Focused on Execution and Implementation Provides a vision for Design, keeps it flexible Keeps Architecture grounded and relevant Design 16
- 17. Can we become: VISIONARIES? INNOVATORS? STRATEGISTS? LEADERS? Are we up to the challenge? 17
- 18. Business Analysis Can Change Again We need to create a feedback loop in the business between its strategies and the results delivered by change. Whole Context Envision Estimate Potential Value Organizat ional Syst em Observe Measure Actual Value Part Component 18
- 19. Each Level Builds On The One Before Master the key skills required at each level to earn the trust needed to move to the next. Strategist Facilitator Contributor 19
- 20. Bridging the gap between… Strategy and Execution 20 20
- 21. Businesses Need Us To Take This Leap The average lifespan of an S&P 500 company has dropped from 67 years in the 1920s to 15 today. ‣ Companies must focus on innovation and reinvention to survive ‣ Process and rules systems intensify competition ‣ Better execution of old models isn’t enough 21
- 22. The Path Forward Is Up To Us “Innovation distinguishes between a leader and a follower.” Steve Jobs ‣ Business Analysis is a selfimproving profession ‣ This gives us exciting new challenges and opportunities ‣ This gives our employers a better future, greater odds of success Source: Wikipedia 22
- 23. “If you don’t like change, you’re going to like irrelevance even less.” Gen. Eric Shinseki 23 23
- 24. C o m m u n i t y. I I B A . o r g | I I B A . o r g | i n f o @ I I B A . o r g Kevin Brennan, CBAP®, PMP® Chief Business Analyst, IIBA @bakevin kevin.brennan@IIBA.org 24 © I n t e r n a t i o n a l I n s t i t u t e o f B u s i n e s s A n a l y s i s
Notes de l'éditeur
- On most project teams, the BA filled a poorly defined role. Requirements were not a first-class citizen of the project world—they were assumed to be known or could be easily gathered. As a result, the BA filled a gap, helping to do whatever the project team needed at a given time. Methodologies were frequently undefined, ad hoc waterfall approaches.
- RUP and others began to move development towards iterative approaches with reductions to project risk.PM community starts to grasp the importance of requirements: PMBOK 3e adds processes for collecting and approving them
- We began by focusing on improving communications between business users and developers, by trying to speak both languages. We expressed business needs in language IT people can understand and vice versa.
- Use POSP to introduce this section…project that did the wrong thingAgile methods question the usefulness and value of projects—agile methods have greater success by shifting to closer to a continuous improvement paradigm. Many objections are circular—they come from people who can’t imagine working outside the project paradigm and complain about things that don’t work in that paradigm. For instance, if I have hired team, and they are building useful stuff, question is are they producing value at acceptable pace not when will they reach some arbitrary definition of “done”?Agile methods also initially questioned the need for BAs but most businesses still need us.
- PMBOK like many other methods fail to address where requirements come from, and treat them like they emerge fully formed. They talk about change control but you have to decide to change before you can control it.We focus on requirements analysis at the expense of the others: IIBA has evidence of this from competency assessments and certification exams. BAs report all three KAs are equally important but do far more RA.
- Organizations pay a even higher, but invisible, cost for failure in this domain. We can’t measure the cost of projects not done, of changes not made, of investments in the wrong thing.
- Consider all of the things that go into a viable organizational system. We need to incorporate disciplines like change management into the BA space.
- We solve this problem by ensuring that we keep one foot in the project world, serving the team delivering the change, and one foot in the business world, understanding their concerns and what value means to them. We have to investigate potential change and how value is delivered. We need to consider when the organization delivers value as well.
- “If a system is to succeed, it must satisfy a useful purpose at an affordable cost for an acceptable period of time.” (Mark Meier)We cannot take ownership of value for our stakeholders, they must always decide what is valuable. But we can and should take ownership of creating things which are valuable to them.Analytical thinking supports the project paradigm…produce a defined result in a certain period of time. Intuition focuses on the right result, on taking leaps that let you push beyond what is possible…like CPSO, run-time linking of subprocesses to allow a process to change in flight.Cost of failure to align strategy and execution is potentially the greatest cost of all.
- Stakeholders own value but we must help them find it. These occur at all levels of an organization. A project involves architecture and design; so does business strategy.Architecture allows us to view the system as a whole and plan for change. Not all requirements change at a uniform pace and many are consistent in the long term. We need to understand where we should pay more for flexibility and where we can accept rigidity.Design implies choice on the part of the designer. We also must ask what problem we are solving…reframing the problem often allows new solutions to emerge.
- All these things interact. Exploration of the problem space is just as important as exploration of possible solutions and the value they bring. We do not seek the perfect solution but rather the one that does what our client needs well enough to satisfy them. Without looking at the whole we risk local optimization. Without architecture and modeling we fail to truly understand the implications of the solution or how to ensure it’s not fragile or brittle. Without evaluation we have no idea if we have delivered real business value—we just throw stuff out there and hope it was the right thing to do. Methodologies frequently favor or or two of these and undervalue the others.
- Mastery of each level is necessary to be effective in the one above it. If you cannot help a team you will not be trusted to get the requirements right. If you can’t get the requirements right you won’t be trusted to help figure out what they truly should be. Contributor: Learn the skills needed to contribute to a change team, the challenges of making changes, and the importance of requirements.Facilitator: Help project teams deliver better outcomes and results, control change, learn how to get requirements right, define needs correctly, create useful models.Strategist: Link needs to results, envision what could be, create new ideas and approaches.
- This is truly where we need to be…taking our knowledge and skills in the architecture and design space to build a linkage between the strategy of an organization and the changes it makes.
- Stress, having your back against the wall, forces creative solutions but to get to them you must be willing to let go those parts of the past that no longer fit. Disruption works as a business tactic because the victims of disruption are trapped in their old ways of doing business until it’s too late. They can’t sacrifice a profitable business when a competitor makes inroads or upends their business model. Kodak failed, Blackberry is failing, Microsoft is trying to reinvent itself. When the old business is unsustainable we must look for new approaches. Research published in HBR shows that rapid deployment of new processes and rules through IT is a major factor in driving increased competition in industries. It’s not that IT provides a competitive advantage, it’s that IT drives competition.
- Analysis won’t help your company cope with new technologies and business models. It’s important and we have to keep doing it but we must blend it with intuition, focus not just on requirements but also on architecture and design.If you succeed you have unlimited opportunities, a chance to shape the future.