by John Parker | Mar 24, 2014 | Business Analysis, Uncategorized |
In the most recent VersionOne State of Agile Survey released in 2014, Business Analysts are considered the least knowledgeable about Agile. Please see the diagram below. Working with many Business Analysts, I am not surprised by this statistic, but it does concern me. In the Scrum world, there is no official role for a Business Analyst. We don’t write the functional requirements the way we did in the past and a Business Analyst is not required or needed to write or draft user stories. Business Analysis skills are very much needed, however the traditional BAs that simply write functional requirements will either need to re-skill or retire. Recently Forrester research shows that more than 90% of organizations are actively pursuing Agile. If Business Analysts do not learn and embrace Agile now, and they plan on continuing writing functional requirements in the ways they have in the past, then they should start planning a new career as their positions will soon be eliminated in a future downsizing effort. If the BAs in your organization have not made the transformation to Agile, please call us at Enfocus Solutions; we can help. We can provide you with the education, knowledge, and tools to transform you business analysis function to the Agile world. Please attend the Webinar tomorrow to find out more. [cta...
by John Parker | Mar 14, 2014 | Business Analysis, Project Management, Uncategorized |
Normally, trends and projections come out in December or January. These are a little late, but at least they still make the first quarter in 2014. Here are my predictions of key trends that we will see affect business analysis and project management in 2014. 1. Agile Continues to Grow – Agile adoption will continue to grow. This will mean many changes in terms of how requirements are developed and managed. Requirement “shall” statements will be replaced with user stories. The three C’s model of users stories: Card, Confirmation, and Conversations will continue to grow. PMs and BAs will continue to redefine their roles in the agile world of self-managing teams and product backlogs. 2. Managing Data not Documents – As agile adoption continues, the need for large paper based requirement documents will go away. Requirements will be managed as data in a backlog, not as long paper-based business requirement documents (BRDs) or Functional Requirement Specifications (FRS). 3. Dual-Track Agile Takes Off – Agile will be difficult and a cultural challenge for many organizations where there are multiple teams and resources are not collocated. “User story hell” will become a reality for many organizations as teams continue to spend more and more time grooming the backlog. Many organizations will adopt dual-track agile or some variant to better manage discovery activities. This will enable lower costs as requirements will be validated using less expensive methods than code. 4. More Emphasis on Business Change – The BABOK Version 3 will be released sometime in 2014. There are big changes coming to the role of business analysis. The focus will be much...
by Enfocus Solutions | Mar 12, 2014 | Business Analysis, Product Development, Uncategorized |
I was recently reading an article about a company featured in Fast Company magazine, who has become very successful with a very simple business model: give customers only what they want. You might be thinking: “well, that’s what every company does.” But, the 2013 Chaos Manifesto published by The Standish Group presents a very different story. They report that only 20% of any given product’s features are used often, 50% are hardly ever used, and the remaining 30% are used infrequently. Yikes. That literally means that about 70% of the functionality most companies are spending their money to discover and deliver to the market are not really even being used—and by extension, one can assume, needed. As a consumer I know I can relate to that—I’m pretty sure my phone does much more than I ever use, know how to use, or care to use. You can probably relate. But this company I was reading about in Fast Company, they didn’t really seem to have that issue because either a) they did not build anything not explicitly asked for by the market, or b) they quickly tossed any products that were not being used and moved onto research what else to develop. Now maybe that in and of itself is not that interesting, but what I did find interesting was they approach they used to do it. And how easily they seemed to have done it—as well as how cheaply. Some organizations spend thousands of dollars a year on market-sensing activities trying to figure out what the right product and features are to build—focus groups, surveys, market research service...
by John Parker | Mar 10, 2014 | Project Management, Uncategorized |
According to the Standish Group, over 60% of projects fail or are challenged. Gartner Group 2011 research shows the same story; only it paints a slightly worse picture. Based on these statistics, program/portfolio managers and PMOs need to have skills for rescuing troubled projects. Determining if You Have a Troubled Project It is important to determine if you have a troubled project before any significant intervention is taken. It is best to do this using predefined criterion that are administered at the PMO or portfolio level. The following criteria provide some examples: Project Planning The project does not have an agreed upon vision and clear set of objectives. Impacts that the project will have on the business architecture have not been identified and defined. A thorough stakeholder analysis has not been performed. Discovery The solution scope has not been clearly defined as a set of features that can be delivered independently. Customers and users are not adequately engaged in project discovery activities. Delivery Delivery team satisfaction is low. Agile team commitments have not been met. Velocity is decreasing. Project Performance The project is trending 20% or more over its estimated budget. The project is trending 20% or more over its estimated deadline. Benefits Realization The client is extremely dissatisfied with the performance of the project team. Benefits as defined in the business case are not being achieved. Project Recovery Process Turning around a troubled project is never easy, but there are approaches that can be used that provide a good chance for success. It is important to note that success may not mean delivering the project within the original time and budget constraints. Rather the focus must now be on salvaging the project to ensure that the project addresses the business need and achieves the expected business outcomes. If...
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...
