Mike Knapp | Doing the Job Right vs Doing the Job Right Now

Doing the Job Right vs Doing the Job Right Now

Doing the Job Right vs Doing the Job Right Now

Posted by Mike Knapp in IT Management 05 Apr 2010

A couple weeks ago I finished on a renovation project at the Ki Society with my step father, John.  John is a recently-retired trades-person.  It’s interesting to listen to him talk about the difference in trades-work between the professionals today, and those from a generation ago.

John strongly believes in quality.  He does things right.  He uses the right tools and processes to ensure everything is done to a high level of workmanship and that things are built to last.  There’s a deep level of pride and importance attached to that which is impossible to discount.

Something has changed with the current generation – the focus is on doing the job right now instead of doing it right. There’s less pride in workmanship, and it shows in so many ways.
This directly translates in IT. The many pressures of the business, including keeping costs down and high workloads and a “just get it done” attitude have a lot to do with this. Sadly, this one of the reasons why many IT teams are stuck in fire-fighting mode all the time.  Instead of getting projects or tasks done right, they focus on getting them done right now, leaving them with fragile systems that never quite work right, and aren’t scalable or sustainable.

When working on a task, ask yourself the following questions:

  • If this solution was going to be in place for at least three years, how would I build it?
  • What should I do so someone else can maintain this solution?
  • Do I need a quick fix, or do I have time to get this done right?

Built to Last

It’s very rare that you build a system (or complete a project) that will only be in place for a few days or even a few months (see The Quick Fix).  Generally speaking, it’s surprising how long the systems we build stay in place, especially if we build them to last.

Built to last means taking the potential life of a system into account when designing it.  If a system is going to be in place for a year, three years (not an unusual life span), it’s important to think about what needs to be in place so you can simply turn it on and forget about it.

If you had to do a five minute task each day to maintain (or operate) a system for 3 years, you’re looking at an additional 60+ hours of pure working time (without factoring in errors, problems, lost productivity, task shifting overhead or other items which could easily double that number). That’s over $1200 assuming a $40K/year resource.

How much time could be saved by investing at the beginning in automation, or a better management interface, or more robust error handling? Building a system to last means thinking about these things in the first place and designing them into the solution.

Systems that are built to last are better designed, often more flexible, easier to extend and better able to handle the long term needs of the company.

Maintained by Someone Else

I have a saying almost everyone who has worked with me has heard – make the system so simple a monkey can use it.

There are two parts to this: designing the system, management and maintenance of it to be simple, so anyone with the right skill set can do it easily, and documenting the system (and it’s processes) to the appropriate level.  That way others can maintain it and troubleshoot problems, reducing risk to the company and making it more sustainable.

I don’t want to count the number of times I’ve found systems that aren’t designed with this in mind and become an Achilles Heel for the company, and the system administrators involved.  It doesn’t matter if there’s only one technical person in the company.  Eventually you will move on and someone else will need to take over, or the company will grow and you’ll become the manager, or one of a dozen other scenarios.

Don’t forget, if you are key to the maintenance and management of a system, you are bound to that system and your ability to do more interesting and potentially innovative (and value-creating) work is reduced.

The Quick Fix

How often have you been in the following scenario:

System XYZ is broken and you need a solution now.  The boss is breathing down your neck about the downtime.  Apply duct tape, smack with BFW (Big Friggin’ Wrench) and make it work.

If you’re in IT, the answer is probably a very high number of times.  The duct-tape immediate fix is not the problem. The expectation is clear: get the system back up now.  Downtime is money. The problem is that in most shops the duct tape solution ends up becoming the permanent fix. In the long term (sometimes in the short term), this creates brittle systems which are very hard to maintain and more prone to failure

The right answer is two phase – for every immediate fix (duct tape), there has to be a proper fix put into place.  This long term solution should always go through the full SDLC / Project life cycle and be fully documented.  By doing so, IT becomes the hero two-fold, having gotten the system back up and provided a permanent, designed solution to the problem.

Doing the Job Right
Next time you have a project to do, be it a quick fix or a major system implementation, take the time to work through these simple thought processes.  In the end, you’ll build better systems, which will be more stable and require less of your time, giving you more time to surf the web … I mean, giving you more time to deliver actual value to the company instead of constantly being in fire-fighting mode.

Post a comment