Tuesday, April 24, 2007

Challenges When Assessing a Portfolio of Business Change Programmes


In a world of boundless resources, there would be no need for decision makers to assess the merits of individual projects – all could be indulged with equal resources and without fear of consequence. In the real world however, resources are finite and organisations must ration their resources, investing first in the most deserving projects. The process of prioritising project investment is sometimes referred to as Capital Rationing.


The definition of insanity is doing the same thing over and over and expecting different results - Benjamin Franklin

To adequately perform this task, decision makers need a rich information base to illuminate the costs, values & risks of competing projects. An assessment is made to find the projects which offer the greatest return when matched to the organisation’s key business objectives.


Perfect Information


No decision about the future is made with perfect information. Decisions are made based on information which is subject to sampling, of insufficient coverage, is not current or contains errors. This is the true position that most companies face when making information decisions. Consultants (including the author) provide an Information Quality Healthcheck service which assesses the strategic value of information available to senior executives relative to their business objectives. For example, organisations tend to have good information about how projects have proceeded to date but relatively poor information about what they will do in the future. This comes at two levels:



  1. project efficiency - is the project on schedule?

  2. project effectiveness - is the project still true to the objectives of business unit it serves?


There are a raft of project control methods to assist with the first but few tools to assist with the second. My Healthcheck service will point out where the organisation is information-rich and where it is information-poor, relating to it's strategic business objectives, where projects and business objectives are tracking and where they are diverging. This can be extremely illuminating (and important) and allow projects which are efficient to be killed because they no longer serve the business. Traditional project management takes an efficiency based view of the workstack that may not be most intelligent assessment method.


If a large project is scheduled to take two years to complete, that is a long, long time in a customer centric business. Look at how quickly User Generated Content took to gain mass market status and radically change the outlook of consumer facing brands. What are the chances that your two-year old CRM project remains as tightly relevant to the needs and aspiration of the market as it did when the project was commissioned. In many small, yet significant ways, poject develops can track away from where the market is going. These changes need to be picked up and fed back into the project workstack to ensure it remains true to the current needs of the enterprise.


Copyright 2007 Robert A Innes

Saturday, April 21, 2007

Scoping Projects for Risk to Inform Selection of Project Management Methods


It's common these days to hear of "agile" developments for IT projects - agile meaning, quick set-up, quick to get to the coding stage and an iterative approach to specification, development & testing. Organisations however, often still rely on more formal methods "Bid Design Up Front" commonly referred to as Waterfall methods, where one stage commences only once the previous stage finishes, so coding and design never overlap. How do organisations decide which method to use and is there scope to support both approches in the one organisation?


Apparently, if you stand on top of the Great Wall of China, you can see the moon - Boothby Graffoe

Formal methodologies usually require some form of feasibility study to senior management with a go/no go option on the development based on Return on Investment and do-ability. There is an option, however, to look at the project and quickly scope out the risk & value profile at a high level and inform the decision on methodologies, and if this points towards agile methods, restricting the effort required for feasibility and saving the organisation time and resources


How to Scope for Risk and Value up front


To be "Agile" in this step requires the Scoping exercise to be shift yet valuable and this requires its own methodology - Navigator - which is designed for Risk and Value management of individual projects, programmes and indeed an entire portfolio of development efforts. At a simple level Navigator allows a consultant to make an informed decision on the route the project should take. This is based on easily accessible information (which is expanded in greater detail as programmes progress) and presented in a simple and easy to digest format. Perfect for indication agile or formal.


There are about ten risk "markers" and about ten value "markers" but for this article I will examine the threee of the most common. Firstly, on the risk side we have: 1. the number of stakeholders, 2. assumed complexity of the mission, and 3. expected duration. For instance, imagine a project such as the replacement of premises based IVR systems in two call centres with one hosted IVR system serving both centres. Using only the three risk markers above, likely this project has one stakeholder - the head of customer service delivery, likely has low to medium complexity (the new system can be tested and tested without removing the old ones) and the duration is likely to be relatively short - three to six months. This data would lean the project towards agile methods. On the other hand, imagine a project to upgrade call centre applications to provide better integration with the rest of the busines. Immediately, this brings in other stakeholders - finance, branch networks, marketing, etc. It's also likely to be highly complex as interfaces between systems and division are often where trouble lies in project management and the duration is likely to be medium to long. This data would lean the project towards formal methods with a high degree of planning and consultation prior to development.


Without delving into the mathematics behind the risk assessments, one can see there is a relationship between, say an increasing number of stakeholders and an increasing risk of a project missing some of its objectives, due to the way conflicts are resolved in organisations.


The above examples are fairly obvious for the purpose of illustration but what Navigator does is allow value and risk, which are intangible elements to be deconstructed and given tangible £ values. The elements in a project can then be aggregated and compared, on an equal footing with all projects in the portfolio regardless of the asset class they serve.


Having risk and value assessments over an entire portfolio allows senior IT staff to accurately manage risk and be assured in delivering the value. They can also easily decide which projects to fast track through agile methods and which to manage through traditional methods.


Note: Navigator is a decision support methodology for enterprises to use to align business technology decision with business goals and to keep this relationship in lock-step as the business evironment changes and the portfolio evolves. Navigator is the property of the author.


Copyright 2007 Robert A Innes