Risk Management: Business Analysis is a Huge Risk for Organizations

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...

Q&A on KPIs for Agile Project Managers and Business Analysts

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...

Measuring Project Success Using Business KPIs

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...

Software Risk Management

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...

Delivering Value through Application Portfolio Rationalization

By proactively identifying and eliminating or remedying poorly performing application assets, Application Portfolio Rationalization helps companies to: Reduce costs, Target efforts to the areas of highest return, and Maximize the business value of their application portfolios. Globalization and changing business requirements impose significant challenges on technology leaders who are under constant pressure to both innovate and reduce costs. These demands to do more with less have been exacerbated by business leaders hearing about prospective savings from use of the Cloud without understanding the impact of transition. Many organizations are electing to combine their initiatives for application rationalization and migration to the cloud. IT leaders are forced to accelerate the rollout of new systems and technologies to support the business without compromising the performance of existing applications. They must address key issues, such as balancing cost, complexity, and capacity, and also deliver business value by applying continuous improvement methodologies. Application portfolio rationalization helps organizations turn these challenges into benefits in terms of reduced costs and more value delivered to the business. Application portfolio rationalization is an important and continuous exercise for evaluating and controlling IT costs. Application portfolio rationalization involves focusing on the application portfolio looking for redundant applications, one-off technologies, applications with few users, and applications with a high cost/user ratio. With a complete understanding of the current environment, the next step is to consider what should be done to move from current to the ideal. Gartner Group research confirms that a focused application rationalization effort will typically result in substantial cost savings while improving support for the lines of business. These savings are too large to ignore. Additional...