The Basics of Good Application Management

 

  Recently I completed the corporate Wiki upgrade, bang on time and at one-third of the planned budget.  When I presented the closure report I was asked by our Accountant  why I was so under budget. I  replied “I am a really really really good Project Manager. [Happy Face]”, followed by a humorous exchange.  I had a similar result   one month ago with the JIRA upgrade, on time and only half the budget.

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.