Projects from a Service Management Perspective
In this second instalment on project management we continue to move through the stages of an IT project starting with the build phase. Read the first instalment here.
Build
While the build is being undertaken ensure that project management and solution architect perform solution awareness sessions with the service desk, all support teams and relevant 3rd parties. They should walk everyone involved through the solution and give them the ability to ask questions. They may well have comments that had not been considered because something was not documented sufficiently in the first place. This could change the build, but it is better to do so now rather than at delivery. (Of course the design would be updated).
Test
Testing is not only about the users signing off on a solution, but is also about the support teams ensuring that they can restore services within agreed timeframes (these have been defined, right?) and can build / rebuild hardware from the build documentation.
Documentation
Prior to submission of any changes, arrange for a walkthrough of operational documentation, so that the support teams have everything they need to support the service. No change should be approved without this, as how can a service go live if the support teams are not able to support it? Ensure that the service catalogue is updated by the relevant people, that service levels or operational levels are negotiated, agreed upon and documented, and that capacity management, security requirements and IT service continuity is taken care of and included in the documentation. Do you have all configuration management aspects considered and documented? Hardware and software support contracts are in place? This all needs recording.
Training
Have all support personnel been trained in the new or amended service? Do the service desk know how the users will interact with the service, and use it? Do the infrastructure and application teams know what the implications are of downtime or delayed response to calls? Do the users know about the change? Do they all understand what will change and how to handle that? Has any or all organisational change been considered, planned and implemented fully?
Change Management
As a project team, ensure that the change manager is aware of your change(s) as early in the project lifecycle as possible. Most change managers want to help you get your changes through first time and successfully, so work with them. Do not imagine that a forgotten change can be rushed through as an emergency because the project team forgot to raise the ‘paperwork’. That won’t wash and will generally end up with you looking foolish. And believe me, that is better than making a change manager look foolish in front of senior managers! You do not make friends that way.
This is one of the most important aspects of project management and needs to be treated as such. All of your ducks need to be lined up nicely prior to this point.
Warranty
The project team should be available to support the new or amended service for a pre-defined period of time post implementation so that teething issues that may not have been picked up in testing can be rectified quickly. It also goes a long way towards goodwill with support teams when the project team don’t just walk out of the building straight after implementation. That shows the confidence they have in their delivery and solution.
Post Implementation Review
Ok, so you’ve gone live. Well done. After an appropriate period of time, a review should be undertaken with all parties to understand what worked, what didn’t and what could be improved upon for next time. All teams should be able to input to this – without emotion – and to receive feedback. This is part of our improvement process.
Now all of these project management steps may seem overkill to some organisations, and possibly light to others, but to me, somebody who has worked in most areas of IT in my time, these are the essential elements to making any significant change to the production environment successful. You can get away with doing less, and if you are lucky, you will have no issues. However, experience has taught me that most teams eventually realise that the above are essential to take an idea successfully through to delivery.
