Category Archives: S

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.

S is for… Surely

“Surely” is a word that should not be in the vocabulary of the vigilant Project Manager. Uttering phrases like, “Surely the customer knew we would…” or, “Surely the software is able to…” or even, “Surely they don’t expect…”, means you have made assumptions.

When you make assumptions you are leaving yourself open to all sorts of problems down the line that will, of course, materialise at the worst possible time.

Assumptions are a bad thing and are best left to the amateurs. Since you’re a good PM you will be keen to be across everything in your project and you will have thought throught the ‘What-if’ scenarios, giving you time to put any mitigation plans into action.

So, do your homework, make sure you know what is going on and don’t get caught with your pants down. But surely you knew that…

S is for… Slush Fund

So, you’ve just been told about your shiny new project, and everything is all exciting and ready for you to stamp your authority on it and tell everyone how it’s going to be done. It’s great when it happens like that, isn’t it? I’m sure you’ve got loads of time to deliver too…

Well, you’d better get your finger out and start pulling a budget together. You’ll be wanting to get all your requirements and estimates sorted out, and your team, and your kit, and your licenses, and desks, and… What are you waiting for? You’d better hurry up, the clock is ticking you know.

Assuming all of that has gone swimmingly and your project is well underway. What happens when something unexpected comes up, like a change in the design means you need a new batch of licenses, or a misunderstanding of a requirement means one of your estimates is woefully light, one of the team takes a lot longer to complete their tasks?

Maybe you have an understanding boss, or a customer with deep pockets and an understanding nature. If so, then you can stop reading this one now and have another sip of ambrosia, provided your at-the-desk masseuse is finished.

If you’re still here, then this is when the Slush Fund comes into play. When your budget was compiled, was there contingency included in estimates for tasks that are now complete, are there any things that are no longer required, are there things that could be descoped from the project or deferred to a separately funded phase? Gather all those little pockets of cash together and see if that can be released to make up for your omission/issue. If so, you’ve probably avoided a bullet, for now.

Note: Some people may surreptitiously include extra dosh in some tasks or over-egg their estimates to include some slush when the budget is originally compiled. Of course, while the A-Z would never condone such a practice, it recognises it is a reality.

S is for… Sponge

The sponge is another example of a PM out of his depth trying to add value to his project.

His project team will be telling this PM there are problems on the project, they will be sending him progress reports coloured in heavily in red felt-tip pen, they will be telling him things like, “We’re going to be late”, or, “We’re easily going to spend double the budget”, or, “We need help!”

The sponge will happily absorb this bad news and report to his management that everything is fine, brilliant in fact. So much so, the Sponge will be looking for more green felt-tip pens in the stationery cupboard. He will blissfully continue in this fashion until the point where he can hide it no more. He thinks he’s keeping the management happy by telling them what they want to hear and will get gold stars and plaudits in return.

Similarly, any criticism and/or bad news, coming from further up the hierarchy, towards his project team will be soaked up by the Sponge and kept from the poor souls on the team. His management will be telling him, “The business are concerned with the lack of progress”, or, “The budget seems a bit tight, do we have enought to complete?”, or, “Are you sure you’ll deliver what we promised on time.” By acting as a Sponge, he thinks he’s protecting his team from the bad press.

At the end of the day, it will all explode in his face. Carnage will ensue, with the finger of blame being pointed at everyone and everything.

S is for… Scoob

The working assuption here is that the reader has a Scoob** either generally or specifically. To deliver projects successfully, you need the people that have the Scoobs to help you.

If you’re on a project and there’s noone else with a Scoob, you’re in trouble.
If your management don’t have a Scoob, you’re in big trouble.
If there’s noone else you can turn to in the organisation that has a Scoob, better man the lifeboats.

Unfortunately you can’t go the the shops and buy a ‘Big Box of Scoobs’ to get you out of trouble, but you can do the PM Survival equivalent; find yourself some Good Guys and get them onto the project pdq.

** For the uninitiated, Scoob is short for Scooby Doo which, in turn, is rhyming slang for ‘clue’.

S is for… Silver Bullet

You will often hear people say that “there is no Silver Bullet“. And this is generally true. Such miracles tend not to happen. What you can say, though, is that there are many situations that would be significantly improved by Silver and Bullets.

It is hard to see how getting rid of useless people and paying a little more for good people can’t help. Not necessarily a palatable option but quote it to people seeking miracles. It might shut them up.

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.

S is for… Schedule Chicken

People, especially customers, forget the real definition of an estimate. Its an estimate. Not a guarantee. But because they forget this they are generally unhappy if a delivery is going to be ‘late’. And with lateness comes blame. And, good guys don’t get blamed. Its the arses fault.

Good guys get out of this blame problem by getting good at the ancient art of Schedule Chicken. In every delivery, there is almost always a set of dependant deliverables. To win the game all you have to do is bet that one of the other deliverables will deliver late and, crucially, declare they are going to be late before you have to. Therefore, you gain the extra time their slippage offers.

So, the easiest way to for you to get some slip in your project is to let someone else do it for you and, presumably, take the blame.

Schedule Chicken should be played with caution and definitely not by an arse. Watching an arse attempt to do it is however, very funny. This is particularly good when an arse is playing schedule chicken against you and you know you are going to deliver on time. Supply misinformation that suggests to him, off the record, that you might be a bit late. He’ll rub his hands together in glee hoping that you have given him a way out of his own slippage. This joy will be short lived as he finally declares that he is unable to deliver one day before the project is due and is ripped a new one.

S is for… Scrum Half

Sometimes you might think that dealing with problems is hard. But you’d
be wrong. All you have to do is break it down into the three main
choices and work from there. Think of a Scrum Half in Rugby Union. He
receives the ball from the scrum and can do 1 of three things:

1. Deal with it himself
Tuck the ball under his arm and go for it. You always have that
choice. Deal with it yourself. Often easier but you have to consider
the possibility of a Hospital Pass.

2. Pass it on
The Scrum Half oftens chooses to release the ball to his Stand-Off.
This is often the simplest and quickest choice. Pass the problem on to
someone else. This is particularly useful if the problem you receive is
a bomb and you can get rid of it before it goes off in your hands.

3. Punt It
Take the ball and kick it as far down the field as you can. This may
only delay the problem coming back to you but it might buy you some
valuable breathing space.

Take the problem, look at these three options and take it from there.
But remember, you may only have a split second to choose before 20
stone of sweaty descends on you and crushes you.