Achieving the Benefits in the Business Case

The vast majority of IT projects seldom deliver the anticipated returns specified in the business case. Look at the same of the quotes from the sources below. “78% of Information Systems projects failed to realize even 50% of the originally identified benefits.” Source: Management Today “Only 40% of CFOs find that their IT investments are producing the returns they expected.” Source: Gartner, How to Optimize IT Investment Decisions “30-40% of systems to support business change deliver no benefit whatsoever.” Source: OGC, Successful Delivery Toolkit The reasons why benefits are seldom achieved are many.  Below is a list of some of the common reasons. The business problem was poorly defined giving rise to a flawed business case. The business case was poorly developed and established an incorrect or unrealistic expectation. Requirements for the solution were inaccurate, incomplete or were poorly defined. Delivery of the solution was poorly executed. The technical solution was fundamentally flawed. The delivered solution was not effectively adopted by the business. The business changed significantly between inception and project completion. Let’s look at what can be done to achieve more benefits. Prepare a realistic and accurate business case.  The business case should not just be used to secure funding, but should also be used a management tool to measure success. Section 1 – Problem Statement Section 2 – Vision Section 3 – Alternatives Section 4 – Recommended Strategy Section 5 – Benefits Section 6 – Assumptions Section 7 – Financial Analysis Section 8 – Risk and Mitigation Strategies Change the key measure for determining project success to whether the business benefits as proposed in the initial business case were achieved....

Transition Requirements

BABOK V2 describes Transition Requirements as “capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined.” In simpler terms, transition requirements are what needs to be done to transition to the solution. Below is a list of various types of transition requirements. Data Conversion and Migration Data conversions Temporary interfaces User Access and Security Rights Security privileges User access User Acceptance Testing Test case development Test facility Production Turnover and Transition User support and help desk Operations Application support User Preparation and Transition Skill enhancements Training delivery One-on-one support Super user programs Customer and Supplier Preparation and Transition Communications and notifications Data interchange Pilot Testing Model office Pilot test Organizational Changes Temporary staffing for backfill New hires Transfers Outplacements Infrastructure Transition Servers Storage Network Personal computing devices Changes to Policies, Procedures and Forms Policies Procedures Workflow Forms Business Continuity BC contracts DR Testing No matter how good the code, with out attention to transition requirements, stakeholder won’t be satisfied with the result. [cta...

Investment in Business Analysis Pays Off Big

Demand for good business analysis skills is high, and for good reason. An investment made in improving business analysis capabilities can have huge payback. Simply stated, organizations that have not developed strong business analysis capability are at a competitive disadvantage. Enterprises with strong business analysis capabilities have achieved many benefits, including: Implemented solutions that meet business needs Increased the ability of the business to adapt quickly to changes Reduced risk, complexity, redundancy Aligned business and IT Enabled re-use and faster time-to-market Presented one face to the business (customer) Increased business value Conversely, studies routinely conclude that poor business analysis is the root cause of many project failures, resulting in, among other things: Incomplete requirements capture and definition Poor strategic alignment leading to an inaccurate business case Solution design that does not deliver requested features and functions Applications that are not what the business needs The International Institute of Business Analysts (IIBA) describes business analysis as “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.”   IIBA describes business analysis as a discipline, rather than as the responsibilities of a person with the job title of business analyst. According to IIBA, business analysis may be performed by people with various job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others. In this article, I may refer to a business analyst but I am actually referring to the discipline of business analysis. Anyone...

Principle #10 – Implement Requirements-Based Project Management Practices

This is the tenth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. For all significant project failures, requirements were wholly or partly missing. Whenever a project team jumps directly into implementation (in the mistaken belief it saves time and effort because members “know” what is need) it invariably leads to a delayed or cancelled result. “Build-first-ask-questions-later” projects significantly overrun their budgets and deliver less than optimum systems. Project and program managers, team leaders, and business analysts can use requirements to  deliver value on enterprise projects. Specifically Requirements can be used as input to manage each phase of the development lifecycle. This concept is best exemplified in the book by James and Suzanne Robertson entitled Requirements-Led Project Management. Requirements can be used for: Used as input to project planning and decision-making Determine whether to invest in a project Deliver more appropriate products with a quick cycle time Measure and estimate the development effort Drive user acceptance and system testing Manage stakeholder involvement and expectations Establish priorities Communicate across business and technological boundaries Enfocus Requirements Suite™ is designed and fully embraces the 12 principles discussed in this article. Enfocus Requirement Suite™ enables solution teams and stakeholders to work together to deliver successful enterprise...

Principle #9 – Prioritize Requirements for Delivering Business Value

This is the ninth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. Maintaining focus on project priorities can be extremely challenging within the culture of large enterprises. According to one industry study, 53% of project prioritization is driven by internal politics. In this climate, adapting more open and transparent project prioritization activities can be extremely difficult. There are powerful people who like the way things are and may have “pet projects” that are near and dear. But that doesn’t mean we shouldn’t try and prioritize by value – it just means bringing change may be harder than we think. One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, it is essential to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements. Thus, collaboration and effective communication are key. A project manager has to balance project scope against the constraints of schedule, budget, staff resources, and quality. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and...