However it did get me thinking why it was such a successful
project. It all went to plan and the final production upgrade was
uneventful. It comes down to the basics
of good Application Management. I have read many application management articles,
some are too high level and many can be overly complex, so based on my experience and the theme of
“simple is good” here are the basics:
Strategy & Processes
Have a vision for your application, have plans to get it
there. Measure those plans and change them if they are not working. After the
upgrade to the newest version last year I had a vision of the Wiki usage
increasing, more spaces, more content, more views and more users. The
application Wiki statistics have proven this.
Process, the how, what and why – in detail. During the our
big upgrade we realised that a lot of processes we needed existed in email
folders or did not exist. Discussing, proposing, socialising and finalising
processes around support, upgrade paths, plugins, macros, etc. meant we can
move from project to operational mode without losing momentum and knowledge.
Treat DEV and TEST like PRODUCTION
One of the issues we faced with our three year catch-up
upgrade project last year was the mess that the Development and Test
environments were in. Development was a partial failed install of an old version
and was dead, Test was running, but was a failed install of yet of another
version and no one could log on and Production was stable, running and out of
date and was been used like development and test. Plus there were issues with disk
space, missing files, missing images, permissions, firewalls, ports, backups, user
numbers, licensing, plugin versions, performance all of which needed to be
fixed.
After considerable effort to align all three environments it
was made very clear to those whom access these environments they are not a play
pen for bored Developers or Operations staff. All changes on all environments
need my approval. I regularly check them and cycle through changes. If anything
is broken I want to know why and I want to know whom. A discussion ensures followed by corrective
action.
We now have an ecosystem which is easy to cycle your upgrades and changes
through.
Use Experts
The corporate Wiki is not our core business, we are not
interested in customising the application or developing any form of
intellectual property or specialist knowledge. We are happy to outsource.
So when we commenced planning last year we sought the help
of experts in this particular field. Especially as previous efforts had failed
through lack of internal resource availability and expertise. Our external
partners are experts, they are also fast,
efficient, effective and thorough.
Partners not Vendors
This is a deliberate choice of words. I want to work with
another company that sees our working relationship as long term and beneficial
to all involved. They go beyond the boundaries of our agreement to assist and
we do likewise. This is a benefit to both of use. It still amazes me how many
companies treat their clients as an invoice recipient and if you are lucky - a biannual coffee visit.
Learn from Your Lessons Learnt
This sounds obvious, but how often is it done. There can
often be a “Groundhog Day” affect with
IT Projects. Understand how and why previous projects did not work and plan
differently. In our case, we used an external expert, listened to their advice
and respected their expertise. This made a huge difference in the quality of
technical work done. One of the weak points in our previous project was
communication, during the planning of the most recent upgrade we developed a
communications strategy, a communications log and followed the communications
plan. The outcome was a much better informed and happier user community. The lessons from our last upgrade will go
into the next upgrade, this is to
prevent the good points for being forgotten as much as to remediate the bad points.
Understand Your User Community
You don’t want to release “New Coke” thinking it’s the next
big thing. Find your experts and
champions and get them on-board, work with them and get close to them. Listen
and learn from their experiences. They will offer good advice and make great
user acceptance testing Testers. They
will championing your application to others and spread the word.
Benefits
Define and measure. If you don’t have a good reason to do
something, then don’t do it. This comes back to your strategy. If you are doing
something and planning to get a benefit and do not, go back and think again,
you are doing it wrong.
Closing
All the above can take some hard work and some good planning
(let’s not confuse simple with easy). Many
of the above areas overlap, lessons learnt with communication, expertise and change
control on all your environments. Above all – have a plan. Be realistic,
define, measure and realise your benefits. It gets easier when the elements
fall into place.
