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

The Elusive Quest for Business Value

Ask someone about business value and you will most likely get a blank stare or many different answers. Is business value the same thing as Shareholder Value or Customer Value? OK—if all else fails, let’s go to Wikipedia; it is always a trusted source right? Here is the definition of Value in Wikipedia: In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Wow, I don’t think this helps much. Let’s look at another source. IIBA’s new BABOK (Version 3) that will be published this year is heavily focused on value.  IIBA recently conducted a webinar on Value and posted it on YouTube. According to the IIBA and the new BABOK, value is defined as “The importance of something to a Stakeholder in a Context.”  I am not sure that I agree with IIBA’s definition of value but I definitely agree with the IIBA when they say “Value is not understood.” At first look, this definition is nebulous, but it has components that are very important. There are three key words here that we have to focus on: Importance, Stakeholder, and Context. Importance – Importance allows us to compare one option to another and make decisions in terms of what delivers the most value....

Two Keys for Project Success

The Standish Group 2013 CHAOS Manifesto Report titled “Think Big Act Small” presents two core concepts to achieve more successful projects. The first key is to break a project down into small independent components that can be managed and delivered separately.  The second key is eliminating features that provide little or no business value.  Let’s examine both of these. Breaking a Project Down It is important not to confuse breaking down projects as simply defining milestones, phases, critical paths, and activities. These are simply components of a single large project. It literally means breaking a project down into a series of independent smaller projects. Each smaller project is defined, developed, and delivered independently producing a valuable result. The Standish Group says “A large project has virtually no chance of coming in on time, on budget, and within scope, which is The Standish Group definition of a successful project.”  The Standish Group reports that large projects are 10 times more likely to fail, meaning the project will be canceled or will not be used because it outlived its useful life prior to implementation. In contrast, small projects have more than a 70% chance of success. Breaking down a large project into a series of smaller projects does not require migrating to agile, although use of the agile methodology can help in this regard. Breaking one large project into five or ten smaller projects and delivering each one independently can greatly improve the likelihood of overall success. Breaking down a project is not always easy, but can be done. The writers of this CHAOS Manifesto Report state flatly that they have come...