Requirements Gathering: What Could Possibly Go Wrong?
•Als PPTX, PDF herunterladen•
1 gefällt mir•3,908 views
Slides form my talk to the Irish Computer Society/Business Analysts Association on 25th March 204.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Requirements Gathering: What Could Possibly Go Wrong?
Ähnlich wie Requirements Gathering: What Could Possibly Go Wrong? (20)
Mehr von Eugene O'Loughlin
Mehr von Eugene O'Loughlin (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Requirements Gathering: What Could Possibly Go Wrong?
- 1. Requirements Gathering: What Could Possibly Go Wrong? Dr Eugene O’Loughlin
- 2. Agenda • Perception • Planning • Common problems facing BA • Project failures • Poor requirements • Methodology • Overcome problems • Lessons learned
- 3. Oops!
- 4. What does your Business Card say about you? Perfect Results Every Time! I’m Imperfect! Business Analyst
- 5. Perception
- 6. What do you see in this picture?
- 7. Business Analysts are Organized People? • Organized • Methodical • Planned
- 8. Dive in and get started
- 9. Fail to Plan, Plan to Fail
- 10. • The best or “alpha” project managers spend more time on every PM process group than their counterparts except for execution, as follows: • Initiating: 2% vs. 1% • Planning: 21% vs. 11% • Executing: 69% vs. 82% • Controlling: 5% vs. 4% • Closing: 3% vs. 2%1* What the top 2% know that everyone else does not Andy Crowe, Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not, Velociteach Press (2006). 10 8 key areas were identified where alpha project managers shine: 1. Attitude and belief 2. Communication 3. Alignment with the organization 4. Approach and organization 5. Priority management skills 6. Issue Management 7. Relationships and conflict 8. Leadership
- 11. Competencies Paul, Yeates & Cadle (2010) p17
- 12. Six Common Problems Faced By A Business Analyst 1. Resistance in sharing information 2. Irregular attendance 3. Accountability for decisions 4. Resolving user conflicts 5. Real needs vs. perceived needs 6. Changing needs Source: BA Times
- 13. The Top Challenges Facing Business Analysts Source: Business Improvement Architects
- 15. Federal Bureau of Investigation
- 16. US Census Bureau – Field Data Collection Automation (FDCA)
- 17. Swedish Navy
- 18. Why Projects Fail – Poor Requirements • Most business requirements approaches fail on two dimensions 1. Lack of a true process orientation 2. Lack of understanding of the neuroscience involved in requirements definition Being asked what you want out of a system is like being asked what you want out of life! Where do you start? What are the parameters?
- 19. Impact of Poor Requirements If business analysts provide subpar requirements, it causes a wide range of negative consequences not only for the current project but for the business as a whole.
- 20. Methodologies
- 21. Business Analysis Body of Knowledge …BABOK Guide…should not be construed as a methodology for the performance of business analysis. (BABOK p6)
- 22. BABOK = Panacea?
- 23. BABOK – works “most of the time” Source: BABOK p1
- 24. Some Strategies (Austin, Runk, & Waters 2009)
- 25. Some Strategies (Austin, Runk, & Waters 2009) Source: http://delphi.com/pdf/techpapers/2009-01-0529.pdf
- 26. Flaws
- 27. Five common errors in requirements analysis 1. Customers don't (really) know what they want 2. Requirements change during the course of the project 3. Customers have unreasonable timelines 4. Communication gaps exist between customers, engineers and project managers 5. The development team doesn't understand the politics of the customer's organization Source: http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them
- 28. SAME O' SAME O'.… • Every project is different, but… • Same people • Same Team Lead • Same Project Manager • Same agendas • Same customs • Same needs Negotiate – Polite – Change
- 29. Lessons Learned • What works in Manufacturing will not work in Finance • One-to-one interviews “brilliant”, especially if you want to know a process • Workshops only work if you bring in people from all departments • Use Visio for step-by-step walkthroughs • Use templates • Read legislation • Get on with the Project Manager • Know the issues, risks, and dependencies
- 30. Learning from our mistakes • “The hardest mistakes to learn from are those that lack consequence.” Jasper Sole • “No one is exempt from the rule that learning occurs through recognition of error.” Alexander Lowen
- 31. QQI Certificate in Business Analysis • More information at: • www.businessanalyst.ie • www.ncirl.ie
- 32. My Book Business Systems Analysis Analysis Tools Problem Identification Improvement Priorities Identification Decision Making Process Identification Resource Planning Process Improvement Controlling and Improving Processes Performance Measurement Benchmarking Performance Importance/ Performance Requirements Elicitation Analysis www.theliffeypress.com
Hinweis der Redaktion
- http://usingmyvoice.blogspot.ie/2006/05/pitfalls-of-perception.htmlWe are conditioned by our experiences to anticipate when presented with new stimuli. The author shows the following example to demonstrate this point. Take a look at the following illustration:The triangles contain 3 little homilies that are very familiar to most people who see them. So how many of you realized right away that each triangle repeats the "article" in the saying (the/the, an/an/, the/the)? I sure didn't see that. I saw what my prior experiences caused me to expect.
- The picture is of a woman, but do you see a young woman or an old woman? Most people will immediately form an impression of one or the other. Whichever woman you see, how long did it take you to see the other woman? Still working on it? The young woman has a smaller face and is looking away from us. The older woman has a larger face and is turned a bit more in our direction. It can take quite a while to make the shift from one image to the other even after you can see both of them. We assimilate the details into our previous impression, such as interpreting the older woman's mouth as the younger woman's necklace. Interesting, isn't it?
- http://www.b2ttraining.com/2014/01/27/get-out-of-the-elicitation-rutThey call a meeting, pull a bunch of people together into a room, and start asking questions. Then they wonder why they’re so frustrated by the lack of progress that they make. I get all the war stories about arguments, conflicting agendas, and participants who get side-trackedand hijack the meeting.I think they’re stuck in a rut. They’ve gotten in the habit of viewing meetings as the primary (or only) technique for requirements elicitation, and they don’t stop to think about their options. They also don’t think about their participants in enough detail. In other words – they don’t plan their elicitation, they just dive in and try to get
- Usually in an SDLC cycle, the requirements elicitation phase is right at the beginning. As oft repeated, this is a very crucial phase that will make or break the project. This is the only time in the entire SDLC when the business users spend considerable time with the business analysts. Since these are focused sessions or workshops, it is imperative that the business analyst is able to make the most of the business users’ time and knowledge. It is important to remember that there will be no phase in future that provides the BAs with this luxury! However, it is not without its own problem areas.In this article, I will highlight the most common problems and provide some pointers as to how we can work around them. These may not be foolproof solutions but they will work in most situations. I leave it to the reader to decide.1. Resistance in sharing information: In some cases, information will not be forthcoming. These users will regularly attend your workshop but it will take a mammoth effort to make them talk. At the other end of the spectrum, there are users who make your life difficult by bombarding you with loads of documents. In such a scenario, even to find the answer to a simple question, you may have to read hundreds of pages!How to get around this problem:The very fact that the users are not sharing relevant information should raise red flags. We need to understand the users’ reasons for doing so:Are they resistant to change and are so used to a certain way of working that they do not want to change?Is it a complicated case of ego issues and office politics that causes them to not want to share information?They really don’t know why a certain process is being done in a particular manner and they have been blindly following it for ages.The first two issues get addressed gradually once the BA is able to gain the users’ confidence and trust. In my experience, this usually happens after a couple of sessions. Once the ice is broken, information flows more easily.The last issue is a bit tricky as users hate to admit that they never thought of the ‘why’ and they just concentrated on the ‘how’. The BA has to word his or her questions very skillfully here. After playing detective, it is often very clear that users don’t have the information that is the BA needs. Once this is known, the BA will have to identify the proper source for this information by talking to the facilitator.2. Irregular attendance:This happens when key users attend one session and then skip a few in a row. Suddenly, they appear and start changing the course by asking/changing things that were frozen during their absence. Or worse still, they want you to start from where they left.A set of users keeps on rotating, and a user who is present today may be gone tomorrow. There is inconsistency in attending the workshop.How to get around this problem:The first problem usually happens when the changes have been proposed by IT and not driven by a business need. Since there is no buy-in from the business users, they are not interested in attending the workshops. However, as the project is be driven from the top, they attend the sessions intermittently to get the ‘attendance’ and ‘participation’ tick mark. They also pose hurdles in the form of the next problem as they send their team members in turns.As a business analyst, apart from escalation to the project manager and the project sponsor, there is nothing much that can be done. The BA can highlight that the requirements captured during the workshops may have to be re-validated as there is no continuity of the users.3. Accountability for decisions:There may be instances in which the current business process needs to be changed or modified to make it more efficient. The users may all be in consensus but none will volunteer to approve it. Or, there could be situations where the elicitation process may reach a dead end if certain decisions are not taken.How to get around this problem:The very fact that the users are in consensus is itself a big win. Here, the only issue is of accountability. If the issue under discussion can be moved into a parking lot and can be considered later, then the next function can be picked up. If this is not possible then along with the project manager, the BA can prepare a business case and present it to the user community. The business case document should have enough details for the decision-maker to come to a decision. It should clearly elaborate on the issue on which the decision is sought and the preferred outcome to resolve that issue.4. Resolving user conflicts:This could take two forms:a. Conflict between the business analyst and the users: This usually happens when the business analyst tries to propose a new or a modified approach to the current process that is being followed.How to get around this problem:To address the first problem, the BA will have to first understand the resistance from the users. Has he/she missed or not taken something into consideration? Or, is it again a situation where the users wish to continue doing what they have been doing? The BA will first have to get clear answers for these and potentially other questions. After all this is done, if the BA still feels that the recommendation needs to get a user buy-in, then the approach followed will be similar to the one that we saw in the earlier problem area, i.e., preparing a tight business case without any loopholes and presenting it to the users.b. Conflict between users: If users who perform similar tasks across different organizational functions come together, there is bound to be conflict as each one feels that their approach is best.How to get around this problem:This could be an ego issue as each function would like to outshine the other. This is an area where the BA’s facilitation and analytical skills are put to test. The BA should be able to dissect all the views that have been put forth and try to facilitate a healthy discussion in which all the parties are listened to. It is not necessary to accept every suggestion but it is important that each user feels that he or she has been given a fair chance to present his or her case. In most situations, this approach works. If it doesn’t, the only option left is escalation to the relevant people.5. Real needs vs. perceived needs:Sometimes it becomes difficult for business users to distinguish between a real need and a perceived need. A perceived need is always a little tricky as it may be a workaround/temporary solution for the problem and not the problem itself!How to get around this problem:Real needs are the obvious ones and can be easily identified. These are usually the issues or the major process changes that the business requires. In the eyes of the business user, a perceived need is very much a real need. The trick here is to dig deeper and probe to discover the real issue. For example, a user might ask for the functionality to update data. This can definitely be a risky requirement as it may lead to data tampering. However, the real need may be that the source data is received in an Excel file and the user probably has to do some sort of data formatting (e.g., date to be in mmddyyyy instead of ddmmyyyy) and hence the request. This can be easily achieved by asking the source to provide the data in the requisite format. Thus, it is very important for the business analyst to dig deeper and identify the true problem area.6. Changing needs:Time and again, we have faced this, and there is always a dilemma as to whether a BA should accommodate or ignore the change.How to get around this problem:This is a perpetual problem and I am sure that there is hardly anyone in the business analyst world who has not faced this! There is no hard and fast rule to accept or reject the changes. The best way is to first understand the reason for the change. If it is regulatory then the change will most likely have to be included but at the cost of a delay in the project delivery. If it is not regulatory then a dialogue is required with the customer to understand the priority, whether it can be included in the current phase or if it could be delivered in the next phase. The best method is to do the MoSCoW analysis. This will definitely provide the business analyst the information that he or she seeks.
- The research also showed the following major issues increasing in importance over prior years that are facing organizations when identifying and managing business requirements:Project changes are poorly managedProject does not address all stakeholder needsPoor project management skillsTest strategy not well definedProject not linked to organizational goals
- Firms with a standard PM methodology for managing their projects (78% of the firms surveyed) had fewer than half as many project failures as those that did not have one The top five actions most often taken in a project recovery intervention are: » Improving communication, stakeholder management (62%). » Redefining the project—reducing the scope, re-justifying the project financially (60%). » Adding and/or removing resources (58%). » Resolving problematic technical issues (49%). » Replacing the project manager or bringing in a consultant to manage recovery (36%).
- Most business requirements approaches fail on two dimensions.The first dimension is a lack of a true process orientation. When you're building a system you may need to know the features and functions required. But the business does not work through features and functions, but through processes. Business requirements need to be defined in business process terms — how the organization wants to do business, compete and make money in the future.This needs to include the process and information flows (so you can see where the system can cost-effectively automate the process) as well as the organizational change requirements (so you can prepare the organization to adopt and use the new system) and the desired business outcomes (the business end states to be achieved).So your requirements generation process needs to deliver the systems and organizational change requirements in process terms and the business measures of success (in measurable end states terms). Most requirements processes fail on at least two of these dimensions. (While there is a lot of focus on processes these days, most is misfocused. Approaches focus on, for example, getting the symbols of the flow maps right or the data for Six Sigma outputs. Process requirements need to focus on the value of each and every step in the process, the information needs of these steps and the resultant business changes required to make this new way of working happen.)The second dimension missing in requirements definition is an understanding of the neuroscience involved in requirements definition.Being asked "What do you want from a system?" also only taps into people's conscious brain (often called "top of mind"). This is only one-sixth of the brain and even less of people's total knowledge. All real knowledge is in their non-conscious.As one Chairperson said to me, "Being asked what you want out of a system is like being asked what you want out of life! Where do you start? What are the parameters?"If you rely on people's conscious "requirements" you'll fail. You need to tap into people's non-conscious to define their real requirements. People are conscious of the immediate problems and issues with their processes and so will seek to have these resolved. However, few are conscious of the strategic intent and rationale of their processes — what they are really trying to achieve and the reason (or lack of reason) for each step in the process. This knowledge is held in their non-conscious and has to be tapped into to identify what they really want the process to do, and why.Tapping into their non-conscious requires their intimate involvement in the requirements definition process — documenting the existing and new processes down to the operational problem level. It requires running workshops where people write down their thoughts before any brainstorming so as to tap into their inner knowledge before their thoughts are channeled by the loudest workshop participants.
- Poor requirementsThe quality of requirements can have a lot of impact on the outcome of the project. One high profile project that was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87000 employees but was shut down after several years of development.The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.Here is the poster with the visual summary:
- Don’t start without Customer Requirements!
- Lessons Learned in How to Generate a Complete, Correct and Usable Set of Requirements the First Time and Every TimeThomas E. Austin and Lori H. RunkThermal Systems Division, DelphiJames P. WatersPowertrain Division, DelphiABSTRACTFrom a quarter to one half of all projects that fail to meettheir imperatives of cost, performance / quality orschedule are in some way associated with missing,poorly written or misunderstood requirements (1). Thisresults in re-design, re-test and continual frustration toboth the originator and the user of these requirements.Thus, a process for generating complete, consistent,unambiguous and verifiable requirements is essential totoday’s automotive development process which focuseson “fast to market” and “doing it right the first time.”Lessons learned from evaluating the customer, internaland supplier requirements specifications show that thefollowing requirement deficiencies regularly occur –• Hidden• Incomplete or unclear• Incorrect• Ambiguous• Missing• Unknown• Secret (competitive sensitive)• Unknown Correlations.This paper will review the purpose of requirements,characteristics of good requirements, and will provideexamples of what did go wrong in two automotiveprojects, what deficiencies / problems occurred, and howdifficult it was to find and define some requirements.RAR - Requirements Analysis Report.
- http://www.techrepublic.com/article/five-common-errors-in-requirements-analysis-and-how-to-avoid-them
- BA has agenda too!