Category Archives: Z

Z is for… Zebra

An older, wiser man than us once said, “If you hear the sound of hooves, you should shout ‘Horse’, not ‘Zebra'”.

It’s a perfect example of suggesting you should perhaps jump to the obvious conclusion first.

This also applies to the times you’re trying to solve a problem, particularly a technical problem. Start off by accepting that the obvious solution might just be the answer you’re looking for and pursue that option first.

The thing is, you’re running a technical project and you’ll have a pile of techies in your team. Now, when you have a pile of techies in one place, they like to do techie things, they like to talk about techie things. Their natural instinct will drive them to come up with the complicated answer because it’s more interesting than the easy one.

For the true low-level techie, upgrading the development platform to the next version of Java is much more fun than changing ten lines of code. Each may have the desired effect but there’s loads more to play with with the former option. Unfortunately the former will bring many, many more problems.

So, one of the problems you will undoubtedly have is preventing your techies wandering off down the more complicated solution path because it happens to be a path that interests them.

When you see it happening, shout “Horse!” at the top of your voice and see what kind of reaction you get. Nine times out of ten, you’ll probably be right and you’ll have saved some time and effort by not pursuing some esoteric techie solution.

Z is for… Zero-cost

In the world of software delivery, nothing is for nothing.

This is a key principle you absolutely need to get embedded into all of your team at an early stage in the project. It’s well worth taking the time to make sure, as it will potentially payback big-time in the long term.

The assumption is that you start off knowing what you need to do. If you don’t, then you have bigger problems to sort out; so best you do that first.

Still here? Good, you must know what you’re delivering. Now, anything to be done in your project should be assessed against what you need to do. If you do actually need to do it, fine, get it done. If you don’t need to do it, ask yourself why are you doing it?

There are many good reasons to do things you don’t actually need to. But with each of them comes a cost to your project, either in time, manpower, resources, or a combination of things. The cost of doing stuff certainly isn’t zero.

It’s up to you to assess that cost and weigh it up against the benefit of doing it. Then you work out what you can get back for it.

The cost side will generally be straightforward; do the sums.
The benefit side can sometimes be a bit more tangential; Maybe it will make things easier for your project later, maybe it will make things easier for someone else, maybe it will expand the scope of your project, in a beneficial way.

Once you’ve worked that out, you can then work out what you can get in return. Maybe you can get some extra budget, from another project, or someone will owe you a favour, or maybe you stack up some brownie points, or improve your credibility, all of which is worth something.

Z is for… Zealot

Like the Evangelist, the Zealot can see no wrong in the particular cause they are thumping the tub for. No matter how obvious it may be to the people surrounding them, they will continue on their unending task of imparting their amazing breadth of knowledge on the subject to all and any that will listen.

While it’s great to have people that are really motivated on your project, the Zealot will actually detract from the forward momentum of the project by insisting on ‘sticking to the method’ or ‘doing it by the book’. Often resulting in heading off down blind alleys and wasting valuable time for little or no benefit.

Now, as you will see from other areas of the A-Z, we are firm believers in pragmatism. Unfortunately for the Zealot, the pragmatist can see through all his fluff and techniques and will spot when they start heading off down the blinkered highway to fail-to-deliver-land.

The assumption of course is that you can’t just get rid of them of your own free will, likely because they’ve been imposed on you or your project. If they cannot be instilled with an element of sensibility, there is nothing for it but to either get them off your project, or get them sidelined to the extent they can do no damage.

Fear not, there are a couple of ways forward: marginalisation or vapourisation.