I hear from our clients quite often that after they’ve purchased our software that they want to get something deployed for the “quick win”. When I explain the ideal approach to implementing business and IT service management solutions such as Tivoli Business Service Manager (TBSM) (Netcool/RAD), their response is often “that sounds great, but we’re too busy and need to focus on the quick wins”.
What’s a “quick win” for someone interested in business service management? How do we measure the value of a “quick win”? How do we keep the “win” after the “quick”? Are they merely tactical efforts that are scrapped when the strategic solution can be implemented? Are the returns from a “quick win” worth the effort of doing something a more difficult, time consuming or strategic way?
The approach to the “quick win” makese sense especially when there are obvious pain points with certain key business services within a company. The problems that I see in nearly all of our client’s environments is that we ultimately have to go through the same steps of the methodology to get the “quick win” as we do if we were to take the time to do it right in the first place.
Business service management takes quite a lot of planning up front and requires a solid foundation in the basics of network and systems management. There are many approaches that could help get that “quick win” but I find that most IT organizations don’t have a solid foundation to build something quickly. The last thing anyone should want to do is deal with the “garbage in garbage out” scenario with a solution that’s expensive and potentially very visible within the company.
Any other thoughts or ideas on “quick wins” and business service management?
Comments on this entry are closed.
“Do it fast or do it right?” We face these type of questions in many ways in our lives. Our developers come back to me with similar sentiments when impatience gets better of me and I push for something to get done quickly.
I think the desire to have “quick wins” is the result of folks losing faith in IT (and the vendors). Too many projects have failed, too many promises have been broken, hence people are no longer willing to wait for long periods without getting some reassurance that they are on the right track. It is simple risk mitigation. The larger the project is the higher the risk for failure both for the organization and for the people pushing for the project. Customers are looking for ways to mitigate the risk in number of ways, and one approach is to attempt to break large project into smaller pieces and start with the smallest pieces that would have the biggest impact.
The tension between quick wins and strategic long term view approach is quite well known in development projects. I think the quick win philosophy is analogous to “agile development”, which promotes iterative development in 2 weeks chunks among other things.
We may need a similar philosophy in implementation of BSM solutions. I believe releasing the tension between long term and quick wins is the key to be successful in this market. History is not on the side of “long view” approach. Many large scale, ambitious management projects have failed spectacularly.
Opportunistic approach has won against strategic approach in most cases. If BSM is positioned as a grand scale project that will “change the face of IT as we know it”, then it is destined to fail. We must find a way to introduce it incrementally, and that’s easier to be said then done …
A “quick win” can be a confidence-booster for both your team and the rest of the business. If your department can do some work on small jobs which actually produce a benefit outside of the support systems “Grand Plan”, then other parts of the business will have confidence that you are capable of coming through with the long-term plan. The resigned shrug and mutterings about “strategic solution” doesn’t actually address the requirement sitting in front of you right now.
Business requirements come in so quickly that changes to current systems need to be made long before the year-long megaproject is completed. Having seen three OSS directors come and go in as many years, each with a new strategy, the only effort which was worth a penny at the end was the “quick win” work.
The trick is to balance the sawing and banging in the shed with actual releases.
Thanks for commenting Ben. You’re spot on! I think there are key ties to this line of thinking with the efforts around agile development practice.
It’d be an interesting study to understand the successes/failures and value provided of quick win/agile like projects versus strategic/waterfall-sdlc like projects.
There’s nothing wrong with working towards a grand plan, but “getting things done” must be at the forefront of everyone’s minds. If we don’t do this, we’re likely to loose interest, funding, etc. from our sponsors. (which I see a lot of these days)
Quick wins is nothing more than getting results faster through a well thought plan. The process to achieve quick wins need a step by step implementation of which each step can be evaluated to determine the levels of achievement before another level is attempted.
I also agree with Ben’s comments. It’s not about doing something fast and incorrect, it’s about realising that a small change can make a big difference. It could be in the form of changing when a decision is made in the process chain or adding some extra fields to a system that will enable better analysis and tracking of a process. It’s about analysing the big picture but understand what can be done during the implementation of the grand plan.
Agile philosophy (YAGNI: You Aint Gonna Need IT) has always been somewhat bent focusing on problem at hand and letting the speculative problems take a back seat. This works just fine at grassroot level. But *caution* needs to be practiced.
We can look at all the big companies which are falling flat. I am sure they will tell you that they focused on short term gains or “Quick Win” and they ended up paying the price.
Thr is no such thing as a silver bullet. IMHO, decisions need to be balanced and should consider both aspects of the problem i.e. Quick resolution (tactical): Big Picture (strategic).
I strongly feel strategic solution doesnt need to be years worth of work to accomplish.
Anything which does not deliver atleast a reviewable deliverable in 6 -12 weeks and a working iteration in 18-24 weeks really needs some retroscpection.