IT Service Management - afterthought

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Thu Oct 15, 2009 3:28 pm

Hi,

Just want to probe the community for some suggestion regarding the following. Our company is in the middle (close to deployment actually) of a very large software development project for a business critical application for a client. Just a couple of days ago somebody in some ever important management meeting brought up service management into the conversation and recommended I get involved to put some controls in place (didn’t say which… up to me to figure out). The environment is software developers, people who love to code, to live to code and who know nothing else but code. So my thought was to approach it from two angles –

a) I don’t want to tell these guys how to develop software, neither am I equipped to do, but some transition planning and release controls can be implemented in their dark pre-prod world… In particular controls around changes to pre-prod environment which is critical for testing. A mini change management process perhaps.

b) support for the application after it has gone live – typical SR, incident, change management

I am assuming I won’t have a large budget to work with because this was never thought of during the project planning, hence everything needs to be a “light” version.

My question I guess is whether anybody had a similar situation to deal with and what useful lessons learned can you share in terms of approach you’ve taken and hurdles (probably pretty obvious) you had to overcome.

Thanks in advance,

Michael


User avatar
swansong
ITIL Expert
ITIL Expert
Posts: 109
Joined: Tue Nov 13, 2007 7:00 pm

Fri Oct 16, 2009 2:54 am

It's good to hear from someone who shares the same pain as me.

How many times have I seen big developments gain an unstoppable momentum, and then at the 11th hour someone asks "How are we going to support this thing?..."

The message I gave the decision makes at my organisation was simple.
- You have just spent £x million on a new devlopment.
- At the point of go live you have not delivered any of the projected benefits, but you have incurred a huge cost.
- You will only get the benefits after the system has been running for Y years.
- The objective of this development was to deliver benefits to the organisation.
- SO WHY DO YOU FOCUS ON THE BLOODY PROJECT AND NOT ON THE DELIVERY OF THE BENEFITS? (Ok - I might not actually shout at them...)
- I then talk about how we could do this next time - Start planning for the delivery of the benefits at the start of the project and not at the end, develop some requirements etc etc etc, and everyone nods and agrees.
- 12 months later when the next development begins all is forgotten, and we start again.

So in short, I have no advice to resolve this, other than to say i share your pain.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Fri Oct 16, 2009 3:37 am

Timo

IFYP. I am in the same situation

My recommendation

1 - enforce software development lifecycle and source code management on the coders
2 - establish release management
3 - establish change management

The path to production is

development -> testing -> QA -> Production

I could spout on for hours
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Oct 16, 2009 3:53 am

Timo,

as swansong says, oh how familiar.

First, I think you have to make up your mind about whether you are going to build service management or also build development management. I wouldn't touch the dev environment. Instead I would specify acceptance criteria for live service and let the project that is supposed to be managing the quality of its products do just that. If they cannot assure the quality then you are into that bridge falling down scenario, I posted yesterday.

That keeps you free of the flak from product shortfalls and lets you concentrate where it matters - service delivery.

Second, there is no "light version". The degree of control you need is not a veneer it is what is required to ensure that the service delivers reliably, consistently, cost effectively etc. to meet the business requirements. This includes not adversely impacting on other services.

I would (but then I'm biased) apply ISO20000 as the yardstick for managing the service. This gives you something tangible to aim for and something independent of your opinion to wave under the noses of management. And it meets the needs of service.

Now I know you can't wait a year to get this in place (well, you can, but the business can't) and so I suggest that you establish the objective and draw up a plan that will get some basic building blocks up and running in an achievable time. but it has to be something on the road, not a palliative that can later be a cul de sac ("And when they all, All go home, Down the cobblestones, You will double back, To a cul de sac, You know, you know you will")

All costs go to the project which will now be over-budget because it did not plan for implementation and service delivery. Your achievable timescale may also mean an overrun. that is down to the PPP of the project also. One tactic is to show them it will take a year and then offer them a viable subset in eight weeks or whatever. that way you are being "positive" rather than "obstructive".

When you are told this is unacceptable (and you will be, that's for sure) and you are accused of sabotaging a good project, present them with the risk analysis and let senior management decide on acceptable risk levels.

Of course this is all cloud cuckoo land because they will accept the risk and then blame service management every time there is a hiccough because it's in the job to run things perfectly so that the risks never become reality; and you can obviously do it because you understand the risks.

Still, you've got to ask, was the project intended to produce some nice neat code or was it intended to create a valuable service?
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Fri Oct 16, 2009 10:47 am

Thanks guys... great responses. I knew I wasn't alone in my pains. My biggest challenge is that even management doesn't really believe in SM, and if they somewhat do, it is still something they would rather avoid as inconvenient and "in the way" type of thing. So hard to change minds.

One thing Diarmid has mentioned that also will greatly influence how I go about it is the CYOA - I know there will be finger pointing and that's why I completely agree with the approach that risk analysis has to be done and let management decide what's more important. Being thrown into it in the end of the project and not being part of "the developers club" I will be the easiest person to blame should something go wrong. Outsourcing decisions to management will help somewhat. Then again, no guarantees those will be good decisions :)

Anyway... thanks again for your input. Felt good to vent :?
User avatar
Anticlue
Itiler
Itiler
Posts: 10
Joined: Mon Sep 28, 2009 8:00 pm
Location: Jacksonville, FL, USA
Contact:

Sat Oct 17, 2009 11:15 am

Hi,


Just a couple of suggestion to help justify the need. It sounds like your corporation is missing a sense of the benefits of software as a service, instead of just developing and walking away.

I'd start with the service design listing out the services needed to offer support of this solution to the client. Have the costs detailed, however also include the expected benefits. Within this model include the difference service management components of service transition (Change and Release Management) and service operation (incident, problem, and event management).

Hope this helps,
Elyse
Collaboration is the key to success!
User avatar
YorkshirePudding
Itiler
Itiler
Posts: 15
Joined: Sun Oct 25, 2009 8:00 pm
Location: Sheffield, UK
Contact:

Mon Oct 26, 2009 7:28 am

Hi,

I couldn't agree more with the replies posted on this subject. Having been on the sharp-end of Implementation projects I understand your frustrations all too clearly.
The need to integrate Project Management & Service Management best practice in a Service Introduction Process is barely touched upon in the "ITIL & Prince Bibles".
Great Frameworks in their own rights but much greater when actively combined and integrated together.
It is the issues and challenges you Guys have been discussing here that drove myself and some colleagues to develop a practical software solution. This is not a sales plug - just trying to promote the need for our industry to wake up to the enormous missed opportunities by not integrating the frameworks in a timely, cost-effective & cost-reducing manner.
Take a look at SMART-SIP.COM. There is lots of further information on this subject there. You can download 5 FREE Whitepapers that will help you build the case for your organisation to evaluate the facts, and to open their eyes to the real costs of not having this integration in place.
I hope this helps

Terry.
Post Reply