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...
by John Parker | Feb 14, 2014 | Business Analysis, Project Management, Uncategorized |
Delivering a project “on-time and on-budget” is no longer an adequate measure of project success. In today’s environment, the key question should be: “Did the project deliver value to the business?” For example, a project could be delivered on time and on budget, but does not guarantee: Benefits outlined in business case were achieved User adoption Expected ROI was achieved A satisfied customer The solution addresses the customer need Sales were in line with forecasts There will be market demand for the product As a project manager, you may think that delivering business results isn’t your concern and that it is the customer’s problem to solve. However in today’s environment, project managers are expected to partner with the customer, understand the business drivers, and ensure that the project delivers the business results that were specified in the business case. That is how many organizations are beginning to view project success. Delivering business value can be a tall order. Delivering business value requires gaining an understanding of the business drivers: the problem or opportunity that precipitated the project and defining a clear set of business objectives to address the problem. Measuring business value is best done through defining Key Performance Indicators (KPIs) and measuring actual performance using the KPIs. Key Performance Indicators are quantifiable measurements that are agreed to by stakeholders to reflect the critical success factors of an organization. KPIs are: Established by the customer at the beginning of the project and listed in order of priority. Directly related to and supported by business goals and objectives. The basis for critical decision-making throughout the project. The basis for acceptance...
by Jenny Boronyak | Feb 11, 2014 | Business Analysis, Uncategorized |
User stories provide agile practitioners with great success because they help focus on the value being delivered to users. As Mike Cohn writes in his book, User Stories Applied: For Agile Software Development: “Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog must describe some item of value to a user or to the product owner.” And that’s why a key component to agile software development is effectively managing the user story backlog. Typically in an agile operation, an initial set of user stories is defined as part of the discovery process, and additional user stories are continuously added by the team as needed during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals—which is why they can be so successful at helping you determine what is valuable to your uers. Good user stories are much more than just statements. A good user story consists of three elements, commonly referred to as the three C’s: 1. Card The user story should be able to fit on a 3”x5” note card, efficiently capturing the most important information. While this “C” sometimes refers to an actual note card, we mean it to refer to the optimal size of a user story. As Jeffries writes, the card should not contain all information about the requirement, but rather just enough to be used in planning to identify the requirement and remind the project team of the story. Each user story should follow the standardized format of:...
