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 Jenny Boronyak | Mar 5, 2014 | Agile, Project Management, Uncategorized |
In our previous blog on Dual-Track Agile, John Parker described the benefits of this emerging concept. Dual-track agile is an approach to agile development in which project teams are constantly working on the discovery and delivery of solutions that will deliver business value and obtain user adoption. By following the principles of dual-track agile, project managers and their teams can eliminate a lot of frustration and costs in agile development. Below are the key guidelines to implementing dual-track agile in your projects. 1. Put together a proficient discovery team with expert capabilities who are able to blend entrepreneurial skills and research gathered from the market. Your team needs to have the following skills so they can thoroughly and effectively understand the problem, recommend the best solution, and align the project with business needs: User Experience/User-Centered Design Business Analysis Pricing and Financial Analysis Customer Discovery Impact/Gap Analysis Focus on Collaboration Experimentation Attitude 2. Have the discovery team working one or more months ahead of the development team. The discovery team should be constantly populating the backlog with validated ideas and user stories. 3. With the help of the discovery team, create an understanding of your customers’ core problem before gathering ideas/features. Do not start putting together a solution until you have a complete understanding of the problem. Use Root Cause Analysis techniques like Fishbone Diagrams or The Five Whys to dig deep into the source of the problem and set the context for the project. 4. Develop a shared vision by hosting a vision planning workshop. Invite the product owner, business stakeholders, technical subject matter experts (SMEs), user-centered designers, 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...
by Jenny Boronyak | Feb 24, 2014 | Project Management, Uncategorized |
Even though it’s a methodology designed for product management teams, Lean Startup provides a lot of good concepts and principles for project managers looking to make sure their projects are successful. And while the word “startup” is in the name, its core tenets can actually be applied to any organization, whether a startup or a Fortune 500 company. “The goal of a startup is to figure out the right thing to build—the thing customers want and will pay for—as quickly as possible. In other words, the Lean Startup is a new way of looking at the development of innovative new products that emphasize fast iteration and customer insight, a huge vision, and great ambition, all at the same time.” – The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries If we take this quote from author and Lean Startup pioneer Eric Ries and replace the phrases “a startup” and “Lean Startup” with the phrase “an organization,” the statement would still be true. Any organization wants to figure out the right thing to build as quickly as possible, not just startups. With agile development being the latest craze, we all want to emphasize fast iteration, and experience has taught us all that customer insight is at the core of success. Many of the lessons and principles in Lean Startup are indeed tailored to the needs of entrepreneurs and new endeavors; however, many of them also apply to project management initiatives in any company. 50% of features and functions are rarely or never used, while 30% get used sometimes or infrequently, according to...
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...
