itSMFI 2017 Forum Focus - June Forum Focus ITSMFI | Page 8

desk and incident management process wants and demands
more comprehensive closure notes. That’s so much easier if,
as is often the case, you are restoring through a fix that’s been
applied many times. The documentation already exists.
Building and designing systems using tools that can self-log will
help. Using customers’/ support teams’ own blog experience
to supplement official documentation is priceless because of
its ability to address context immediately. I’m not suggesting
throwing away the “official” documentation, but how many of
us have got by on a trip without a guide book and just referred
to Trip Advisor? These actions allow one to focus on working
services over comprehensive documentation.
weekly “top 10 issues” meetings that operations often had
in the 1980’s and 90’s? For example, I recall the daily
operational “Morning Prayers” meeting that we used to
hold at the Co-Operative Group in the 1990’s.
It was
designed to refocus operational efforts for the day, balanc-
ing all the support and development work we had and
providing full visibility of where we were at. It worked…
period.
I wholeheartedly believe that in 2017, with a
Kanban board and a little more customer input, the same
meeting would be held up as beacon of “agility”.
Customer collaboration over contract
negotiation
1
Let’s get this straight…no one is saying that we don't need
contracts and we can solve all our ills at the coffee machine or
water cooler. I believe that focusing solely on the contract
leads us to a fool’s paradise where we think everyone agrees
to what is being done. We have a signed contract, we’re good
to go, right? The reality is ‘Rumsfeldesque’, we do not know
what we do not know. An iterative approach can be the best
solution to this problem. This means contracts need to be
flexible and have the proper change control built in to
accommodate an agile process. The difficulty arises in the
effort that's required to convince the customer of the benefits
of say a more "flexible" support contract when they are
seeking the lower risk fixed-price contract. Does this mean we
cannot do Agile? Of course not. One of our large customers
are trying to increase agility with smaller, low maintenance,
fixed-price contracts to support processes with more than a
modicum of success already.
Responding to change over following a
plan
Some
organisations
have
super
elaborate
operations,
operating models and plans with detailed documentation that
have failed.
They make the plans so complex and over
engineered that they're difficult to modify when changes
occur. Becoming more agile could replace complex plans with
release schedules, issue logs and backlogs that can
accommodate change. H