by John Parker | Mar 7, 2014 | Business Analysis, Collaboration, Uncategorized |
In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance. Standish Group Research shows that the top five reasons for failed or challenged projects are: Lack of user involvement Lack of transparency Poor or incomplete requirements Changing requirements Lack of business alignment Now, examine these problems carefully; all of them are related to poor business analysis. Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK. Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements. Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and...
by Enfocus Solutions | Mar 3, 2014 | Business Analysis, Uncategorized |
I’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them. Let me know if this sounds familiar… You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it. You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right? Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document. Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in. In today’s projects, where the dynamics of the solution is constantly shifting,...
by John Parker | Feb 27, 2014 | Business Analysis, Uncategorized |
Business analysis is at a dangerously low level of maturity for most organizations. According to Standish Group Research, the top five reasons for failed or challenged projects are: 1. Lack of user involvement 2. Lack of transparency 3. Poor or incomplete requirements 4. Changing requirements 5. Lack of business alignment Look at all these problems carefully; all of these are related to poor business analysis. Looking at this and other research, poor business analysis is the number one cause of failed and challenged projects. A vast majority of business analysts only write solution requirements and do not perform other activities as specified in IIBA’s Business Analysis Body of Knowledge. Many are not involved in activities such as Enterprise Analysis and Solution Assessment and Validation. Many only write solution requirements and have not idea about the importance of other requirement types defined in BABOK. A mature business analysis function will perform the following types of activities: Focus on achievement of business outcomes and enablement of business change. Perform analysis and evaluation, not simply taking notes. Work with Business SMEs to analyze the problem and root cause. Work with Business SMEs to redesign business process to decrease cycle time, reduce errors, and reduce waste. Serve as the knowledge manager for the solution by providing advice, facilitating discussions and decisions, and promoting collaboration between business and technical stakeholders. Responsible for defining and managing solution scope. Work with stakeholders to simplify solutions and eliminate non-value added features and functions. Write high quality requirements that are concise, clear, complete, testable, and valuable. Assess and validate the development and deployment of the solution to ensure...
