Risk-driven IT Implementation
Alastair Blakey
Implementing an IT solution has its own special set of risks, that need careful management, and, historically, IT implementation projects have demonstrably paid less than ideal attention to these risks. Government IT projects are so apparent as cases of inadequate risk management as to barely merit mentioning. In the private sector, the statistics for failed IT projects also present an overwhelming case.
Identifying a Need
An IT implementation proceeds from the identification of a business need requiring an IT solution, followed by developing a clear idea of what that IT solution will do, and by extension, what it will not do.
A useful exercise is to weigh the risks to the business, comparing those arising if the project goes forward, and of the possible outcomes, versus those if it does not, including some hypothetical factors and outcomes. In the extreme, these are variations on “wasting a lot of time and capital for nothing”, versus “losing business, to more effective competitors”. This assessment should be agreed amongst all stakeholders, and documented.
At this early point, a senior manager, “the Champion”, with purchasing authority, who has “signed up” to the business risk analysis, must be clearly identified to have acceptance responsibility for the project, allocating some days effort per month, and a suitably experienced individual, “the Implementation Owner”, must be found, to be responsibility for delivery of the project, as their primary/sole responsibility.
The Implementation Owner must be able to bridge the knowledge areas of the business, so they can understand the business case, and communicate with business personnel, and must have in depth IT understanding, so they can manage the implementation, and communicate with IT personnel. For small scale development, the Implementation Owner may work at a very hands on level; for large projects, they may be a senior manager, delegating main aspects of the project to sub-contract organisations, etc.
It makes sense to sub-contract the Implementation Owner rôle; implementation projects, by nature, are transient, not permanent, so the business does not want the long term commitment of a permanent employee.
Representative “Stakeholders” from effected departments will also need to be involved, on an ad-hoc basis involving some hours per week, particularly initially.
The Scope Document
The team described above will work together, driven by the Implementation Owner, to produce a scope document for the project, proceeding from the business analysis, detailing the functions of the required system, how it fits in to existing systems and processes, with measures of acceptable cost, timescale, and reliability. As with any kind of project, this inception phase is the most risky. If the scope document is incorrect, then the implementation effort will be a complete waste of time, since the delivered system will not meet the business need. Risk management techniques such as Joint Application Development (JAD), prototyping and modelling, and weighted matrix functionality evaluation should be applied.
If the Champion, or other stakeholders, are not committed, e.g. repeatedly cannot attend scoping meetings, or provide feedback, etc., the Champion needs to take a decision on whether the project really is so important to the business, and perhaps cancel, before wasting further investment. This decision should make reference to the business risk identification document; perhaps workload requires that the case be passed higher up.
This risk, of lack of organisational commitment, cannot be overstated. It is almost certainly the single main cause of project failure, demonstrated in innumerable cases, and is the driving reason for UK governments creating a new methodology every five years or so, each of which can be summarised with the statement “Commitment by organisation staff is essential”.
The Technical Solution
Having developed a clear scoping document, the next step is the well known “buy or build” decision. In today’s technology sector, this is no longer so clear cut, with a continuous range of combinations of hybrid options, ranging from pure “buy in of best of breed”, to building by internal staff, who may be contract or permanent, supported by overseas outsource contractors, some on time and materials, some on fixed price, with some components being bought in outright, some leased, and some tailored, by suppliers or partner companies.
This range of combinations brings its own management risk; very approximately, the more options involved in the complete solution, the greater the risk that one or other will fail in some fashion. Each option will also bring its own risk profile, for example, the risk of failure by a market leading supplier, delivering their standard product, that is already in use in a thousand other sites, compares very favourably with the risk of failure of a Russian anarcho-collective software house you’ve never heard of before.
Simple failure is also not that clear cut. In the extreme, a proposed element may simply not be workable, or be wholly unreliable, but it is more probable that cost overruns, or time overruns, will arise, or critical staff will become unavailable, or that two components will not immediately work together, or that unknown issues with the target environment will emerge.
The Implementation Owner should identify available options that can contribute to a complete technical solution, to identify what functionality each can bring, measuring fitness against the scope document, and assessing risk for each sub-component. From the available options, they should create several possible technical solutions, architecture combinations that come as near as possible to meeting the full required functionality of the scope document, and assessing the risks and fitness for each, guided by the business risk analysis, and produce a set of choices, ordered by preference.
The Implementation Owner and Champion should then work together to identify a preferred solution, or a shortlist of candidate preferred solutions, and identify further detail that needs resolving for each. The Implementation Owner must find out these details, and gain measures of assurance from the suppliers for each component, and should also work up a well thought architecture for the solution(s).
How to play these risks will depend on the risk preferences of the business; some may prefer to run two or more parallel projects for a time, until the main risks have been eliminated, others may choose early to pick one preferred combination. This is a decision for the Champion to take.
Project Planning and Management
With one main technical solution identified, the Implementation Owner can formulate a project plan, the sequence of events that need to occur to produce a complete implementation of the IT system to meet the business need. This plan must be constructed with the aim of eliminating, or reducing, identified major risks at an early stage, i.e. at as low a cost in time and investment as possible.
These risks can be broken down into Supplier Risk, including reliability, communication, quality, time/cost overrun likelihood, source code escrow, and contracts, and Technology Risk, including functionality, interoperability, timescale, reliability. (This is not a comprehensive list; it is impractical to explore further detail in this limited article.)
Suppliers should be vetted, taking feedback from reference organisations they can provide, and others, and views on their organisational stability. Payment schedules should reflect this; the less demonstrably reliable a supplier, the more effort must be invested in validating each of their delivered phases, before any phased payment is made.
A similar pattern holds for technologies; the less well you know it, the less you should trust it, and the more scrupulously you should vet it before, and as, you use it. This applies to individual technology components: vet that they function as described, and to interoperation between components: clearly, the individual parts of the system must work together. Both must also function correctly in the target environment, i.e. where the boundaries of the system meet other systems/processes, and interoperate.
In producing the plan, a useful approach to mitigate Implementation risk is the “T-Technique”. Any solution can be identified as having “ends”, for example, the “front end”, and the “back end”, etc. In the T-Technique, an initial activity is to implement some minimum functionality from end to end, to verify that all components, and all interactions, (the “depth” of the system) are functional. This forms the upright of the “T”. After that verification, the functionality of one layer can be elaborated, “widened”, to verify the “breadth” of the system, i.e. the cross-bar of the “T”.
To address Functionality risk, current accepted development methodologies all propose “phased delivery”, whereby the plan is structured to regularly deliver incremental additional functionality, at least for testing in a close representation of the target environment, preferably followed by direct installation and use by end-users. Through this, stakeholders gain early indications of how well the solution meets their needs, and can supply early critical feedback.
Almost inevitably, the plan will involve multiple, simultaneous threads of effort, ordered by dependency. For each thread, the Implementation Owner must identify steps and dependencies, and break each step down into phases, with Specific, Measurable, Ambitious, Realistic, Timescaled” (SMART) milestones for each, at weekly, fortnightly, and monthly intervals. The plan must be discussed and agreed with the Champion.
As the project progresses, the Implementation Owner measures progress and issues on each activity, against the weekly milestones, and through qualitative discussions, to enable them to determine if slippage is occurring, or new unknowns are emerging, and to track status of current/emerging/receding risks, their likelihood, and impact if they arise. With these weekly measures, they can respond in quick order, as appropriate, working with the Champion, and with stakeholders.
Installation
As every phased delivery is installed, an installation and roll-back plan will be required. This should cover preparation before installation, such as validated backup of current system state, the steps for installation, tests at each stage, and most importantly, the steps to roll-back the installation if something goes wrong, to restore the target environment to be in exactly the same state as before installation commenced. As elsewhere, this planning should be done by the Implementation Owner, in close coordination with the Champion and individual stakeholders.
Taken together, this process addresses the highest level risks in Implementing an IT solution; naturally, there are more detailed activities, an entire corpus of Project Management and IT development methodology, research, and theory, which again re-enforces the value of outsourcing the Implementation Owner rôle, and the supporting IT functions.
Alastair Blakey is currently Senior Consultant, and Principal, for Verdhandi.co.uk Ltd, offering services for IT projects in the Financial Markets Sector.
His background includes development and research work at the European Space Agency, consultancy and management in Project Methodologies and Risk, Object Oriented technologies and methods, and Human Computer Interfaces, at ESA, Reuters, major financial institutions and software houses, including projects in securities and derivative financial markets, and mentoring/training in all aspects, from mechanics of instruments to development methods. He holds an MBA from Kingston, and is an associate member of the Global Association of Risk Professionals.
