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...
by John Parker | Feb 21, 2014 | Agile, Business Analysis, Project Management, Uncategorized |
The questions below came from our latest webinar on KPIs for Agile Project Managers and Business Analysts. What are some leading BA KPIs? Stakeholder satisfaction by Feature (Satisfaction) Stakeholder activity by Feature (Engagement) Cycle time from ideation to Feature approval Business value per Feature (Value) Test coverage for Feature (Quality) Number of defects per Feature (Quality) Feature Completeness (Inspection or Peer Review) Is it common practice to have stakeholders sign off on KPIs prior to development? Yes, however, stakeholders should also be actively involved in their development. Getting stakeholder approval is key for all KPIs. What is a good way to minimize the time to get signoff on requirements WITHOUT getting poor/missing/misunderstood requirements? Optimally, requirements should be reviewed as they are being created. To do this requires an automated requirements tool such as Enfocus Requirements Suite™. Here are some specific recommendations: Break down the solution scope into separate independent components (Features). Validate each Feature and eliminate Features that provide little or no value. Define solution requirements only for validated features. Assign a BA and a Sponsor to each Feature Allow stakeholders to review and comment on each requirement as they are being developed using an automated tool such as Enfocus Requirements Suite.™ Obtain review and signoff on a Feature by Feature basis using stakeholders that are involved in that feature. This procedure can prevent a lot of noise. Measure the cycle time from Ideation to validation and validation to acceptance. Where can I get the benchmark for any metric? There are many benchmarking services, including: APQC The Hackett Group InfoTech Enfocus Requirements Suite™ (RequirementCoach™) Process Intelligence What tool was...
by John Parker | Feb 6, 2014 | Business Analysis, Uncategorized |
Many project risk managers view risk management as the identification and mitigation of potential events that could affect the likelihood of a project’s success. This view is flawed, as the greatest risk to a project success is not some event that might occur, but rather simply having poor processes and practices for collaboration, project management, discovery, development, or delivery. At the beginning of an initiative, there are many risks associated with getting the requirements right, obtaining active user involvement and adoption, and enabling business change to achieve successful business outcomes. However, most risk management practices are focused internally on project resources, project activities, and project deliverables. Risk management practices must change from the current process of focusing internally within the project to an external focus on the business and the users. There are two aspects to software risk: Context and Process. Both of these areas are explained below. Context Risk Understanding the context for risk is critically important. In understanding risk, it is important to gain an understanding of both the organizational and strategic context. Gaining this understanding requires a thorough review of the environment in which an organization exists and operates. It is important to take into account your organization’s specific objectives and capabilities, as well as external factors, such as the changing legal environment and shifting social standards. Establishing context provides the framework for the risk management process. Context risks can be defined in three broad categories: Project, Business Change, and User Adoption, which are explored in the following paragraphs. Project Project context is where risk management has traditionally concentrated. It is generally focused on the work...
by John Parker | Jan 29, 2014 | Business Analysis, Uncategorized |
The Standish Group 2013 CHAOS Manifesto Report titled “Think Big Act Small” presents two core concepts to achieve more successful projects. The first key is to break a project down into small independent components that can be managed and delivered separately. The second key is eliminating features that provide little or no business value. Let’s examine both of these. Breaking a Project Down It is important not to confuse breaking down projects as simply defining milestones, phases, critical paths, and activities. These are simply components of a single large project. It literally means breaking a project down into a series of independent smaller projects. Each smaller project is defined, developed, and delivered independently producing a valuable result. The Standish Group says “A large project has virtually no chance of coming in on time, on budget, and within scope, which is The Standish Group definition of a successful project.” The Standish Group reports that large projects are 10 times more likely to fail, meaning the project will be canceled or will not be used because it outlived its useful life prior to implementation. In contrast, small projects have more than a 70% chance of success. Breaking down a large project into a series of smaller projects does not require migrating to agile, although use of the agile methodology can help in this regard. Breaking one large project into five or ten smaller projects and delivering each one independently can greatly improve the likelihood of overall success. Breaking down a project is not always easy, but can be done. The writers of this CHAOS Manifesto Report state flatly that they have come...
