A look back at New Year's resolutions for 2006
Shannon T. Kalvar
Published: 20 Dec 2006 12:30 GMT
A year ago, I wrote a list of 10 New Year's resolutions for IT managers. The resolutions covered principles of time management, psychological tricks for keeping ahead of problems, and recommendations for avoiding the pitfalls associated with modern IT. My colleagues and I tried to put these concepts into practice during the past year. How well did they stand up to reality? Let's find out.
#1: End where you mean to begin
#2: Begin as you mean to continue
Resolutions 1 and 2 help set up the day's activities. Unfortunately, in practice, we found it hard to keep to the discipline. A lot of days don't end very well in IT; we commonly work through problems until we finally get to go home. We also found it difficult to begin as we meant to continue without some kind of prior preparation.
One manager suggested we overcome these problems by inverting the usual Franklin-Covey practice of starting every day with planning and solitude as a practical method to apply these. He tried to end each day with a 10-minute break to organise his thoughts and lay out the next day's tasks. He also set up his first task, usually a phone call or status meeting, before leaving for the day.
He noticed when doing this that he rarely used the task lists he prepared. The act of organising, though, helped him to keep both priorities and urgency in focus.
#3: Act to solve problems rather than reacting to them
#4: Stop making pigs fly
#5: Remember that the customer is mostly right
Resolutions 3, 4 and 5 got us into a lot of trouble over the last year. There's something about not panicking in times of stress that makes people think we don't take the problems seriously. In fact, sometimes it leads to comments such as: "You have no detectable sense of urgency." The idea that the managers giving orders are only mostly right, rather than always speaking "The Truth" also doesn't go down well.
One manager reported troubles stopping his "pig-flying" ways. The sacred animals of upper management (cows, elephants and the like) continue to draw resources away from fighting off operational rot. Trying to get the pigs to fly didn't work out any better.
Another manager found that not having a reputation for immediately reacting to the obvious issue got in him into hot water with his reactionary peers. Trying to solve problems so that the issues go away, it turns out, is not popular in some organisations. In the long run, it removes activity from the environment, leading to a need for less staff and fewer opportunities for heroics.
#6: Heed your inner geek
#7: Best practices aren't always the best
#8: Know what you want at a meeting
Resolutions 6, 7, and 8 suggest asserting our own experience to better manage our environments. That is, after all, what our bosses hired us to do.
Unfortunately, a cooling economic environment and rapidly expanding audit controls have put a bit of a snag in the idea of individual initiative. The current climate strongly supports a much more conservative approach, focusing on smoothing things over rather than doing it right.
One friend of mine, an IT manager himself, suggested that the idea of the manager as decision maker rather than executor had fallen by the wayside. With the renewed advent of business process re-engineering and the soaring costs of software, IT's role as anything other than an influencer are probably numbered.
#9: Remember the basic English you were taught at school
#10: Trust QA (quality assurance), listen to QA, QA is...
Resolutions 9 and 10 focused on practical planning and preparation activities intended to reduce project costs. Being clear on what we want to do and how we want to go about doing it does, over time, reduce administrative burdens, free up support resources, and allow for a much more methodical approach to problem resolution.
No one argued with the idea. However, we found that many people simply did not have the ability to put it into practice. Pesky things such as planning and serious business analysis took away from IT's ability to immediately respond to business wants. Planning and analysis also added considerably to the cycle times our organisation wanted from its IT team, leading to accusations of "paralysis by analysis".
As with many things, implementing these recommendations comes down to finding a balance between planning and execution. In this case, the balance depends entirely on the cycle time expected between either development releases or infrastructure additions. If we want to run two-week cycle times (more common than we would like to admit in infrastructure), there isn't really a whole lot of time for co-ordinated planning or regression testing. If we want to run quarterly releases, we have more time to spend getting all our ducks in a row.
So, the questions become: given what happened, were we able to get any value from the resolutions? Did they help or hinder us during the year?
The resolutions ended up being a mixed bag. Most came from sound principles but suffered though the long and rocky journey from principle to execution. The current industry environment argues for a more complacent approach, at least until the whole environment starts to fall down around everyone's ears.
Did you find this article useful?
24 out of 53 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
