D

D is for… Dunning Kruger*

Leave a comment

This one is an official, scientific observation. But it’s so good, it merits a mention here.

The premise is pretty straight-forward. But, we’re going to paraphrase here, so check the Wikipedia definition if you want the science bit.

Intelligent people are clever enough to understand they are fallible and may sometimes get it wrong; they can doubt themselves and their judgement on occasion, but often in a disproportionate or misplaced fashion.

However, those who may lack the necessary knowledge or intelligence related to the position they hold often have a disproportionate amount of self-confidence; they have little or no self-doubt in their decisions or actions and in fact have mistaken confidence in their own abilities.

In summary; Idiots think they are brilliant because they are not clever enough to understand what Good Guys can spot in an instant.

* All credit to David Dunning and Justin Kruger of Cornell University for their observations and definition of the effect.

Q

Q is for… Quantification

Leave a comment

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!

K

K is for… Keep pushing

Leave a comment

Managing a software delivery project, as you may have already found from reading this guide, leaves no scope for complacency. You need to keep you wits about you at all times.

There will be times where everything seems to be going right; your team are on target, the customer is onboard, the budget is on the nail. In some ways this is the time you should be extra-vigilant.

Projects generally don’t coast down the highway of delivery, they need to be driven.

So, in the times when things aren’t going wrong for you and you’re spending a lot of time fixing problems, make sure the team don’t lift the foot from the pedal too much. That’s not to say you can’t ease off a little, especially if you’ve been buring the midnight oil for a period, the guys need to have a chance to draw breath. But make sure it doesn’t ease off too far or you’ll find it hard to get things going again.

Keep a look-out for people coming in late and leaving early, keep an eye on the productivity levels, keep an ear open for the chat on the shop-floor. If it’s beginning to look like things are getting a bit too relaxed, it’s probably time to kick it up a notch or two, but do it subtly.

Maybe suggest the guys get ahead of the game to give scope for coping better with problems that may arise later. Perhaps get them to look at clearing the decks of some of those little tasks that got put to the side when things were busy. Even a bug-blitz to get the stats looking better. All of these things are relatively painless and deliver that little it of extra value to the pot for your project as a whole.

U

U is for… Upscope

Leave a comment

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

S is for… Slow Play

Leave a comment

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.

W

W is for… Wing it

Leave a comment

This is the bit that really gets the adrenaline flowing. When you have to think on your feet and wing-it in the face of adversity.

You can plan all you want and dry-run all you want. When push comes to shove and you have to stand up in front of your boss, or the customer, or the board and demo, or explain, or show something; be it the fruits of your team’s labour, your product or your project’s finances, all eyes will be on you or your nominated demo-monkey as you peddle your wares to the assembled throng. Presenting can be a terrifying time for the best of people but with practice, it can be mastered.

However it’s when it all goes wrong and believe us, with technical solutions, it will, that’s when you will properly earn your stripes as a manager. Now, it may or may not be you that’s presenting, but your reputation and that of your team will likely be affected by the outcome of the presentation/demo. So you’d better be ready to jump in and save the day at zero notice.

The key is preparation, think it through. Like in sports, run the play in your head, think of what could happen, assume it does happen, what would you do? What else could happen, what would you do then?

It may mean you need a backup presentation to run if the demo fails, or another demo, or a back story. Have your presentation on a CD or pen-drive in case your laptop packs in. Maybe you take an extra projector of your own, or make sure you have a flip-chart available in the event of a bulb failure. Or even something as simple as having your own whiteboard pens in your bag. Think it through.

When you have to jump in and rescue the event, you’ll be glad you did.

L

L is for… Lab Rat

Leave a comment

The Lab Rat is the team member that scurries around from location to location looking for morsels of cheese. Sorry, information. You’ll find them hanging out at the desks of their pals, next to the coffee machine, or out at the smoking area, even when they don’t smoke.

They’re not really that keen in doing any work, they are more interested in finding out who’s been doing what, with whom and when. They’ll be looking to spend their days keeping themselves busy chasing down tasty morsels of gossip instead of getting your project delivered.

Obviously, on the surfact this really isn’t a great thing for you, as you care passionately about getting your project delivered. But all is not lost if you happen to have a Lab Rat on your team, you just need to know how to manage them.

First of all you need to manage their workload to a level that you are getting an acceptable amount of work out of them; after all you’re paying for them and if they’re not delivering, you’ll not be having any of that.

They’re your eyes and ears on the street.

Then you need to take advantage of their personal network. Use them to keep you appraised of what’s happening on other projects, with other managers and keep yourself ahead of the competition when it comes to soon-to-be-available resources, potential budget-cuts, political in-fighting, etc. All the things that you may be able to use to your advantage on delivering your project.

Y

Y is for… (Are we there) Yet

Leave a comment

Everyone knows what it’s like when you take a five-year-old for a journey in the car.

After about five minutes of the drive, they will quietly ask, “Are we there yet?”. At this point, you’re fresh and your patience is intact and, in a rational manner, you will be delighted to calmly explain to your little darling that there is still a long way to go.

After an hour, and the same question being repeated about a hundred or so times more, your sanity will be stretched to breaking point and it will be all you can do to stop yourself slamming on the anchors, getting out and running to the hills screaming.

Projects can get you like that too.

Particularly when things are going wrong, for example when the test environment is down,  the demo won’t work or the deadline is looming.

This is the point when, as a manager, you need to resist the urge to ask, “Is it fixed yet?” every five minutes. Think of the five-year-old in the previous example, compare yourself to that, and remind yourself that asking your techie that question will absolutely not make it work any quicker. In fact it’s likely to slow the proceedings down.

So, if you don’t have anything to contribute to the proceedings, get yourself out the way. Even if it means you are relegated to tea-boy/girl or pizza delivery-boy, it’s a thousand times better than annoying them and perhaps delaying the solution.

Your time would be better spent keeping everyone else away from your techie too. So do that instead. Other people asking your techie when it will be ready will be significantly worse impact than you placating them, and acting as conduit to the upper echelons of management.

Before you get to the point of leaving your techie alone, make sure they know to let you know as soon as you can help, or they solve the problem.

Z

Z is for… Zebra

Leave a comment

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.

J

J is for… Jenga

Leave a comment

Projects can be precarious things.

It’s a delicate balance of resources, requirements and time. If you keep it all under control, things can go swimmingly, but the slightest knock can bring it all crashing down around your ears. A bit like a game of Jenga™.

As Project Manager, it’s your job to oversee this particular game. You need to ensure everyone knows, and plays by, the rules. In order to do that, make sure you have all the ‘pieces’ you need; cash, people, kit, requirements, etc. and make sure you have a nice flat surface to ‘play’ on.

The latter may be more challenging as we don’t always have the luxury of a level playing field or stable platform even before starting a new project. That’s where you come in, to bring your skills and knowledge to the party, to level it as best you can.

You may need to get extra budget or people to perform a clean up before you start, put caveats around some of your deliverables, or even pull out your scoping sword. In any case, this is the time to do it, before the game starts.

So, in simple terms, build your project on a solid foundation and don’t let anyone pull anything out from under your nose, or add something in that tips the balance.

The Real Art of Project Management and Software Delivery