Cherwell IT Service Management Blog
Resources, Best Practices, and Solutions for ITSM Pros

ITSM Project Success – Define & Document

Posted by

Cherwell Software welcomes guest blogger Barclay Rae. He is an independent management consultant, specialising in IT Service Management.

My last blog for Cherwell talked about the need for buyers to look for suitable partners and for vendors to be bold in terms of assessing risk and really engaging with clients. This piece looks at how both parties should start to engage with a project once the procurement decision is made and the vendor and product are selected.

Of course this is just the beginning of the project, but sometimes this can be forgotten after the perhaps difficult selection process.  The point is, it can be too easy for either or both parties to relax into a state of ‘right, that’s done’ and to expect more from the other party than is actually contracted for.

For me, the fundamental issue is how to engage and get structure and agreement around the logistics, roles, responsibilities, timelines, deliverables, communications approaches, tasks and owners. Very often, the success or failure of a project rests on the first day or days and how the project is defined, documented and understood.

Two things stand out that don’t often get done and invariably mean the difference between success and failure:

1. Set clear and measurable project targets and outcomes. Too often on the buyer side, this gets ignored or is too focussed on technical functionality and what that will deliver. What use is a grand software purchase if it doesn’t achieve the required business outcome?

The best way to do this is to break down expectations into small short term achievements that can help build momentum and buy-in and show successes in specific areas – e.g. Reducing incident resolution time, increasing number of problems raised. At the same time, this can be seen to be working towards a measurable longer-term goal – e.g. Reducing the number of incidents, etc.

In terms of goal-setting, it is clearly the responsibility of the buying (customer) organisation to set its own targets and to have good controls in place to measure the value of its investment. However, vendors should also contribute by providing suggestions on how to turn operational activity into business success.  If they can’t do this, they may not be the best choice of partner.

2. Risk assess the project (by both parties).  This doesn’t need to be an overly formal process.  The main point is to ensure each party takes a realistic view as to the level of risk and the impact of this on the real success of the project. Then, do something about it at an early stage to mitigate and avoid problems.

For example, what level of maturity does each organisation possess in terms of people, skills, resources? From a vendor’s viewpoint, does the client have political issues that might get in the way?  Do they understand the real impact of what’s required to implement this type of tool?  Do they have the right people and availability to make this work?

Does the vendor need to then adjust its resourcing and level of attentiveness, reporting, etc., to make sure things get off to a good start and get done on time? Is the vendor also familiar with this type of organisation and sector?  Does it appreciate the culture and potential barriers to getting things done?

The client/buyers needs to also be sure it has fully assessed its and the vendor’s capability and experience.  A ‘gap analysis’ will identify if further resources or levels of management, control and early reporting is required.

These first few meetings and days in a project often shape success or failure. They serve as an ‘early warning’ and realistic assessment of the ’emotional IQ’ of the project.

Spend a little time looking at the people and their capabilities. This will save a lot of time and hassle later on.