Tag Archives: Techniques

Q is for… Quantification

We all have to do it at some point or other and it’s never easy. There is no magic formula, there is no way to find a truly accurate answer. All you can ever do is guess and suffer the consequences.

But there are a few things you can do to make that guess a little bit closer to the mark and there are only a few things you need to find out.

  • What is the latest time the customer will allow you deliver?
  • What is the minimum amount you can get away with?
  • How much budget does the customer have?

Try and work these things out and build your estimate around them. Sure, build some sort of model to justify your numbers, maybe use something scientific looking like standard deviation and use fancy terminology like ‘risk budget’ and ‘contingency’ with percentages and things.

Ok, so you still want to try? Right then, on your own head be it, but here is some additional help in case you are still feeling misguided.

What does your gut feel tell you? Come on, your experience must tell you something? Is it 10 man days, 100, 1000? How long would it take you to do it, back when you were king/queen of code? Think of a number, you’ll probably be more right than you think.

Remember that when you are estimating for a project, you are unlikely to be able to pick-up and drop individuals as you go along the cycle of the project. Once you have them onboard, you will either have to keep them to the end, or risk losing them forever to another project, so best budget that way too.

Then to confirm this, use another method of quantification to check your figures. Maybe the obvious but often forgotten ‘bums on seats’ estimate. Count the number of people you have available to do the work, multiply that by your gut feel duration and that gives you a guide to your total number of man days.

If your two methods give numbers that are hugely different, maybe you need to think about it a bit more. However, if they are in the same ballpark, then you may just have a number you can use. In that case, you just need to tart your working up into something you can present to the people you have to get the money from, put on your best smile and go for it!

U is for… Upscope

As an aternative to the Scoping Sword, there is another technique that can be used to protentially bring benefit to you as a Project Manager or your project, it’s called Upscoping.

Upscoping is a method whereby you actually expand the scope of your project to take in additional deliverables, functions, teams or even other projects.

While this may on the surface of it sound like a bad thing, it can often be made to work in your favour, not least by giving you negotiating room.

You can perhaps use it to get an increase in your budget and/or timescales to take account of your new responsibilities and scope.

You can also take advantage of some potential economies of scale, where you may already be delivering something similar, or on similar technologies. And sometimes you can use it as a means to get some key resources onto your project.

Finally, you may have the opportunity to take responsibility for things, external to your scope, that may already be giving you problems. Particularly useful with third party suppliers that may be impacting your project. If you can make yourself responsible for them, you can manage them directly and thus exert more control over your destiny.

However, with this technique you need to be a little careful. Always remember the wise words of the old shopkeeper, “With Mogwai comes much responsibility.”

If you make a land-grab, make sure you can deliver it.

S is for… Slow Play

One of the more advanced techniques covered in the A-Z, Slow Play is all about avoiding doing something you really don’t want to do. The term originates from the land of Poker, but can be applied to software delivery too.

The technique centres around giving the impression you are doing a particular thing but taking so long to do it, you reach the point where there is no point in doing it any more.

Of course, the A-Z would never condone this kind of thing, but feels the need to alert the reader to the existence of this technique in the interests of science and, more importantly, to allow them to spot it when it is being used on them.

To do it right, you do need to put in some work in on the task in question, just enough work in fact, but taking your time so you run out of time to do it while demonstrating you tried.

Obviously you don’t want to get caught out doing this or you could end up looking a bit silly.

F is for… Forms

Here’s a game. You’ll like this. Listen carefully.

In any organisation there are essentially two groups of people. People who know stuff. People who don’t really know all that much.

In many, many cases the people who don’t know stuff try to find stuff out by getting the people who know stuff to fill in forms or spreadsheets. It makes them feel useful. It makes it look like they are doing work. But in the end, they still don’t know much stuff and they’ve just wasted a lot of time.

“Fill this form in so I can approve…” – does that mean they understand?

So, here’s the game. When you are in work, just walking round the office, or in a meeting maybe, decide which of the two groups people are in. You’ll be surprised by how many people fall into the “gaining information via the medium of forms” gang.

And if you spend all your day getting people to fill in forms then… better not finish that.

M is for… MBWA

Management By Walking About (MBWA) is a much underrated mechanism to keep an eye on what is going on in your project.

As things have evolved technically over the years is becomes all too easy to orchestrate, or attempt to orchestrate, your project form the comfort of your adjustable office-chair. Using eMail, Instant Messaging, Text Messaging, etc. to deliver your guidance and expert opinion.

However, while you may like to think you are some kind of techno-mastermind of all you survey, the chances are you’re missing out on a lot of the crucial information you really should have a firm grasp on.

If you’re only reading the written word, and worse, only spouting it too, you are missing a huge percentage of the other parts that make up that thing we call human communication.

Without getting the real ‘word on the street’, complete with intonation, attitude and accompanying body-language, you’ve only got part of the picture.

Have you ever said to yourself, “I didn’t realise it was that bad” or, “They should have said there was a problem”, then maybe you need a bit more ‘face time’ with your team, customers or co-workers.

So, If you want to keep on top of what’s going on, get off your arse and walk about!

V is for… Vapourisation

Sometimes you are stuck with people on your project that you could, quite frankly, do without. They may just not be up to the job, or there may be something else they bring to the party that detracts from the team’s ability to deliver.

This can happen for a number of different reasons; Perhaps you inherited them when you took over the project. Perhaps they have been foisted on you as a result of a management decision. Perhaps they were sold to you as a guru, or the best person for the job.

The assumption here is that you cannot simply remove them from the project, because you would have by now and you wouldn’t have a problem. So you need another way out. One option is to minimise the effect of these people, but sometimes Vapourisation is the only way.

One thing to bear in mind is that whining about your resources is never a good thing. People will think you’re just making early excuses for your future lack of delivery, or label you as a whiney project manager. But, more importantly, always remember that it’s your team that will deliver the project, under your excellent guidance of course, so it’s probably best not to alienate them. So removal by stealth is the key.

One approach is to give them responsibility for the delivery of something, ideally not too critical, and let them prove their obsession with their chosen speciality subject gets in the way of delivering, effectively letting them fall on their over zealous sword. Now, you’ve proved they’re no good, they should be ripe for removal…

M is for… Marginalisation

Sometimes you get people on your project that are a danger to themselves, let alone anyone else or your project. On occasion, they are actually OK in terms of their knowledge of the subject matter, but you wouldn’t trust them to deliver newspapers.

If this is the case, you may wish to assing them an ‘advisory’ or ‘consulting’ role without any real delivery responsibility. They could maybe coach some of the more junior people in your team in their area of expertise. If you sell it correctly, there’s a good chance they will be happy in the respect you have in their knowledge.

That way you get the benefit of their knowledge without the associated failure to deliver; just make sure you give them some boundaries and keep a close eye on them.

B is for… Blamestorming

This term will likely be familiar to anyone that’s been on an IT project, it describes the point of sudden realisation that there is a problem on the project and a scapegoat is required.

Really it shouldn’t work that way, people should undoubtedly be focussing on solving the problem and delivering the project, but these days it seems that there always has to be a post-mortem and a, consequently, a culprit found.

The meeting may take a number of different forms, or have a number of different titles, like “Process Improvement Workshop”, or “Post Implementation Review”, but in essence it will turn out to be a drains up blame-fest. You can usually gauge how much of a kicking is going to be dealt out by the seniority of the attendees. There may be even a series of blamestorming meetings to get the story straight before the upper management get told the story.

As you attend more of these meetings, you will witness people who have never moved quickly in their lives suddenly acquire the speed and adaptiveness of gazelles being pursued by a cheetah and reknowned trouble-makers will become strangely slippery, as if lubricated with some kind of advanced silicone compound.

Best go prepared to these kind of meetings, because the black spot will need to be finding a home, and you’d be advised to make sure it doesn’t unfairly land on your lapel. Of course, if you are a Good Guy and have followed the advice in this guide, you will already be well equipped and have nothing to fear.

At the meetings, watch out for the phrases, “This isn’t intended to be a witch-hunt”, and, “We’re not looking for a scape-goat here”.
It is, and they are.

X is for… Xpectation Setting

OK, so it doesn’t actually start with an ‘X’, but there aren’t many words that do, so this is pretty much the best you’re going to get.

This one can’t be stressed enough. If you are managing a project, delivering software, whatever, it means you have customers, or stakeholders, or perhaps both. These are the people that will build or break your reputation in equal measures and with astonishing speed. So, best have them on your side eh?

Build a rapport with them ensure they are aware that you have their interests at heart, because you do of course!

When things are going well, be sure to make sure they are aware of how good a job you are doing, but in a subtle way of course. Equally when things are going wrong, it’s a good idea to be open an honest with them up-front and early. That way the kicking you are likely to receive as a result of it will be minimised, perhaps to none at all.

Of course, if you are a good guy, you will have thought through all the permutations and options and presented the best solution for the benefit of the project. So, beforehand, work out what’s wrong and how you’re going to put it right then present your plan for saving the world to your customer(s). Do it well and you will maybe even come out smelling of roses.

S is for… Scoping-Sword

Because of the single most important rule of delivering software projects – the Scoping Sword is not only a key weapon in your armoury, you must be skilled in how to use it effectively.

Picture the scenario; you start off with a nicely planned and resourced project and everything is just swell, the sun is shining and pretty flowers are blooming all around your feet. Cue the day you deliver the first cut of the new software to the customer. This is the point when you experience the phenomena known as goalpost-shifting. The customer will come back with all sorts of statements, like, “but I thought it would do X”, or, “surely you knew I needed Y”, or even, “everyone in this business knows it has to be able to do Z”. It is important to recognise it immediately and act swiftly to regain control and limit the potential damage.

First of all you need to weed out the genuine defects – of course you are going to fix them. Then you need to assess the features the customer forgot to tell you about first time round, the requirements that your code-monkeys misinterpreted and delivered wrongly and the stuff you were planning to deliver in a later phase anyway.

Once you have all of this information, you need to look at your options. If the project deadline is not moving, the customer is not stumping up any extra cash, and your management won’t sanction any extra zero-cost resource – what’s left to do?

Correct! – pick up your big Scoping-Sword and hack a chunk of features out of the project! Now don’t panic, if you’re good enough, this can all be done in a controlled and tactful manner. The customer can be shown that the additional work he needs can’t be delivered in the remaining time without something else suffering. ‘Better to remove something and deliver it in release 2.0, rather than deliver it badly in 1.0’ is always a good line. You can then re-group, re-cost and charge for it in Phase 2.

Ensure you cover any changes with the appropriate Change Control paperwork and sign-off, to ensure you suffer no repercussions later when it turns out the person that was waiting for the feature wasn’t informed when it suffered at the hands of the de-scoping exercise of week 24.