Recently I wrote something entitled ‘EVERYONE IN YOUR ORGANISATION SHOULD LEARN PROJECT MANAGEMENT – HERE’S WHY’.

I’d go even further than that. Project management is a life skill that everyone – Project Managers, everybody else, kids – should have.

I’m not talking about methodologies like Prince2 or something like Agile. Instead it’s something far simpler.

Project Management can be boiled down to two very simple ideas.

The first is that anything can be a project – from something as small as say, a 1-hour meeting all the way up to some vast undertaking.

The second is that whether a project is tiny, vast or anything in between, all projects all exhibit the same behaviour.

Or to put that another way, there are things which are common to all successful projects and things which are common to all failed projects – irrespective of size or number of people or anything else.

By harnessing the positive things and trying to reduce the effect of the negative things, we can have many more successful projects.

So, what are these things?

Well, they’re encapsulated in The Ten Steps. Once you know these, you have everything you need to run any project successfully.

What’s the best way to learn The Ten Steps?

Depends on who you are:

WHO?	HOW?
Project Managers	The Project Management Masterclass: 2-day face-to-face workshop, orThe same, but online over Zoom, Teams or equivalent, orThe same, but online and self-training
All other staff	Online and self-training as for Project Managers
Kids	How to Put a Man on the Moon if You’re a Kid

Well, quite simply because we all do projects.

Even if they’re small, even if we think of them as one-person projects, project management ensures that these projects got done as quickly and as cost-effectively as possible.

But this project management can’t be the heavy-duty stuff of the big methodologies.

This project management has to be easy to learn, simple to carry out and there must be benefits in using it.

This project management exists today. You’ll find it here https://lnkd.in/diEh2j9.

Your colleagues can learn this project management in one day of their time and for as little as € 246 per person.

If you want to try it out – free of charge – on behalf of your organisation, just email info@fastprojects.org. 

Teach your staff project management and you will see:

o  Productivity climb.
o  Wasted time, effort, resources and money go down.
o  Predictability of estimates, deadlines and commitments increase.
o  Occurrence of nasty surprise drop.
o  ‘Firefighting’ and working continuous long hours decrease.

Footnote:

Kids in school should learn this project management. We’re surprised when ‘adult’ projects go spectacularly off the rails – but if we don’t teach the skills in the first place, what can we expect?

Imagine we expected people to become scientists, engineers or accountants but didn’t teach them arithmetic or mathematics!

So it’s for the kids in school that I wrote How to Put a Man on the Moon if You’re a Kid a few years back. You’ll find a free download here https://lnkd.in/dHkcya6V.

In 1995, Martin Cobb, then CIO for the Treasury Board of Canada Secretariat, asked a question which has since become known as Cobb’s Paradox. He said: ‘We know why projects fail; we know how to prevent their failure – so why do they still fail?’

‘We know why projects fail’

Well … we sort-of do.

Sometimes – but really not often enough – when projects go wrong, we do some kind of post mortem on them. Or there are recriminations. Or if a project is big and high profile and ugly enough, there is a stink in the media about it.

And we might identify things like lack of stakeholder engagement or unclear objectives or bad estimation or inadequate budget or lack of resources and so on.

If you want it in a nutshell though, projects fail because they require us to do something we can’t actually do.

They require us to predict the future (and make it come true).

If we think about it from this point of view, maybe the question we should really be asking should not be, ‘why do some projects fail’ but rather, ‘how is it that any projects actually succeed?’

If we think about it from this point of view, there is not a great deal of difference between a project plan and a lottery ticket other than the odds. We’d like to feel that the odds on our project plan are better than those for a lottery ticket, but certainly I’ve seen projects where the smart money would have to be on the lottery ticket!

There is, however, also a fundamental difference between the plan and the lottery ticket. In the lottery we can’t influence the odds – they’re fixed. But in a plan, we can. In a plan, we can stack the odds in our favour.

And the way we do that … drum roll, please … is by planning.

‘We know how to prevent their failure’

Ho-hum.

Well maybe some of us do.

Without meaning to blow my own trumpet, I do.

And this is not because I’m smarter than anybody else, but just because I’ve thought about the problem.

And when you do that, when you start to ask yourself why do some projects succeed and others fail, you very quickly start to see a pattern.

There are certain things that are common to all successful projects and there are certain things that are common to failed projects.

‘So why do they still fail?’ 

Quite simply, they fail because we’re either not aware of this pattern, or – for whatever reason – we choose to ignore it.

 All of the preceding then, brings me to: 

Ten Steps to a Successful Project

*  This is a methodology with a small ‘m’. It doesn’t compete with the big methodologies. If you use PRINCE2, for example, or Agile, or anything else, you still need this.

*  In ETP and Fast Projects, we’ve been teaching / using it now for more than 30 years.

*  It’s been taught to around 10,000 people.

*  I’m not stupid enough to think that they’ve all used it but lots of them have.

*  No one’s every phoned me up and said, ‘I did it and it didn’t work’.

*  Lots of people have told me it enabled them to get their projects done – on time, sometimes early, on budget, sometimes under, delighting their stakeholders.

*  So it has some pretty serious credentials.

If you think about it in its simplest terms, when any project is executed – something tiny like making dinner, all the way up to something massive, like Brexit – the project happens because a sequence of jobs is carried out.

To be even more precise, each day of the project, each one of a group of people do one or more things, until eventually (hopefully!) the project is over.

Figuring out this sequence of jobs [i.e. who does what on what day] in advance is known as planning. Figuring it out as you go along is called firefighting. Figuring it out after the fact is often known as a project post-mortem – but more often as a cockup. (See earlier reference to Brexit.)

When you come to carry out your project – any project – there are three possible ways you can build this sequence of jobs [who does what on what day]:

A.   You can have no plan and just let the project unfold – see what happens. Now, apart from the ‘we don’t have time to plan it, just go do it’ merchants, of which, unfortunately, there are still far too many about – no sane person would deliberately do this. But I would bet my house (and I would win the bet) that in your organisation today there are people doing precisely this. They’re doing it not because they’re stupid or incompetent but because they’re overloaded; they’re too busy – with the result that essential planning on a project gets overlooked completely or only done partially or not done at all.

B.   The second way to build the sequence of jobs is to do it in real time – to make it up as you go along. This is known as firefighting.

C.    The third way is to build the sequence of jobs at the beginning.

There is also the very real issue of what level of detail the sequence of jobs should go to. But clearly, the only level of detail that ultimately matters is the day [i.e. who does what on what day] level of detail.

In reality, most people don’t just do one, but rather, a combination of A, B and C above. Here are some typical examples:

1.    A ‘high level plan’ is built [C – sort-of] and then the day-to-day decisions on who will do what on what day are decided … well, day-to-day [B].

2.    ‘We use Agile’. A ‘high level plan’ is built [C – maybe] and then the day-to-day decisions on who will do what on what day are decided day-to-day [B]. 

3.    ‘We have constantly changing priorities’. No plan is built [A]; the project is just started and then the day-to-day decisions on who will do what on what day are decided day-to-day [B].

These, and any similar approaches guarantee that the project will take longer rather than shorter: Precious days will be wasted, the project will go down dead ends that will have to be retraced, scarce resources will be frittered away as problems – many of which could have been anticipated in advance, if we had planned at the day level of detail – are discovered for the first time.

If you build a plan at the day level of detail, it is like you have identified one possible way the project could be done. You have made all the decisions about who is going to do what on what day – decisions you would have to make some day anyway.

But in terms of A/B/C above, you have made these decisions in a (relatively calm) C setting – critically – before you’ve made any commitments to any stakeholders. This is as opposed to the A and B settings where these commitments have been made long ago and the setting is anything but calm.

So, to build a plan at the day level of detail, we need two things:

1.    We need to be able to estimate accurately.

2.    We need to have a way of representing the plan we come up with.

Happily, both these things already exist:

1.    I’ve been teaching people how to estimate accurately for nearly thirty years.

2.    There is something known as a ‘strip board’ – something that has been knocking around in the movie-making industry, pretty much since its origins.

Need to shorten a critical project of yours? Give us a shout fergus@fastprojects.org.

17192_How_to_assess_a_project_in_five_minutes_SD

Earlier this year, the Harvard Business Review published an article called The 4 Types of Project Manager. The article described how different types of growth opportunities require different types of project managers to run them. It’s a good article.

It’s been my experience that there are indeed four types of project manager – though in a different way from that described in the HBR. The four types are:

• The Techie
• The Pioneer
• The Magician
• The Soothsayer.

The Techie

We need techies. There would be no projects without them – both the ones who conceive a grand vision and the ones who work to deliver that vision.

In many organisations – though this is changing – it can happen that there is only so far a techie can go in terms of increased salary and promotion. To get round this problem, techies are often promoted to manager – and therein, potentially, lies a problem.

Often too though, it has to be said, the techie who conceived the grand vision wants to be the one who delivers it i.e. the project manager. Therein too, lies a problem.

I’m not saying the great techies can’t become great project managers, but to be honest, I haven’t seen it very often myself. The things that excite a techie are not the things that excite a project manager. I’m a project manager. Show me a beautifully estimated Gantt Chart and it will bring a tear of happiness to my eye. Show it to most techies and they regard it as ‘admin’.

The Techie (i.e. a techie who has become a project manager) often has no interest in the ‘things’ of project management – tasks, people, dates, effort and so forth. Techies bring everything back to technical matters. Try to talk to them about project management ‘things’ and their eyes quickly glaze over and you can tell they’ve stopped listening.

(Gently and tactfully) offer to educate them in these matters and they’ll say yes – but it’s a ‘yes’ that’s actually a very definite ‘no’. Technical matters are where the Techie is comfortable; they will almost never step outside their comfort zone.

Often the Techie has no little or no interest in work-life balance – at least, while the project is going on. The Techie reckons that almost all problems on the project have a technical solution and those that haven’t are ‘HR issues’.

Techies generally tend to look for complicated solutions and the notion that there might be a simple, common sense solution is abhorrent to most Techies.

If you’re persuasive enough or failing that, lucky, you may be able to get a Techie to produce a plan for you. The Gantt Chart they give you will almost certainly be a timeline (i.e. without estimates of effort) – probably produced in something like Basecamp or whatever the latest hot thing is.

A Techie project manager may or may not deliver a project. If they do, it will usually be after much blood, sweat and tears that probably could have been avoided if some basic planning had been done.

Techies – gotta love ‘em! There’d be no projects without them.

Most likely to say: ‘We don’t have time to plan it – just go do it!’

Least likely to say: ‘Just give me a few more minutes – I want to get this status report looking absolutely right.’

 

The Pioneer

The Pioneer is most often found in companies that were once startups but that have now been on the road for a few years. Generally, in such companies, the Techies (techies who have become project managers) rule the roost.

The Pioneer arrives on the scene convinced that there’s a better way to deliver projects.

The Pioneer has often attended some kind of project management course or read a project management book and has had a Pauline conversion to the whole idea of good planning.

It’s tough being a Pioneer. I say this having been one.

The Pioneer has to carry out a constant fight against the ‘We don’t have time to plan it, just go do it’ brigade.

The first time a Pioneer tries to sell a realistic plan to bosses or stakeholders or customers, they [the Pioneer] will face a barrage of criticism. Phrases like ‘That’s not the culture here’ or ‘Is this plan based on a 5-day week?’ or ‘If you don’t do it, I’ll find somebody who will’ or much worse, will be traded freely.

This may well continue over the life of that first project.

But there’s good news for Pioneers. The first project you work on will be the hardest. It get’s easier after that and over time – if you stick to your guns – you may be able to leave your pioneering days behind and become a Soothsayer (below).

Pioneers will pretty much always deliver their projects – that’s if they don’t quit first!

Most likely to say: ‘I won’t be able to tell you until I’ve done a plan.’

Least likely to say: ‘Sure.’

 

The Magician

Magicians do exactly as the name suggests – they do magic tricks; they take seemingly impossible projects and make them happen. When a boss says, ‘If you don’t do it, I’ll find somebody who will,’ the somebody they are referring to is a Magician.

If a company has Magicians, it should love them. It should give them bonuses, stock options, profit-sharing, promotions, extra grades, flowers on their birthday, presents at Christmas – because Magicians do an extraordinary thing.

Imagine you went to a job interview and the interviewer asked, ‘What do you do?’

‘I do impossible missions,’ you reply.

The interviewer’s gonna say, ‘Sign the contract. How much do we have to pay you to come and do that for us?’

But there is a problem with being a Magician – and it’s a very serious problem.

As soon as you do your first magic trick, as soon as you pull that first rabbit from the hat, you’ve now created a problem for yourself. Now, a rabbit from the hat is suddenly the standard that bosses / stakeholders / customers expect.

This means that the next time you go on stage – the next time you have to do a magic trick – a rabbit from the hat won’t impress anybody; you’ll have to do a bigger animal.

The result of this is that you now suddenly find yourself on an escalator that only goes up and every time you do a more spectacular magic trick, that becomes the new standard that everybody expects.

While all of this is going on, you and your team are now probably working insane hours with all the attendant problems that come with that – health, relationship, quality of life – not to mention that fact that working long hours for sustained periods of time quickly becomes unproductive. (To be clear what this means – you would be better off working your team forty or so hours a week and sending them home to have a life.)

There’s a saying that ‘All political lives … end in failure.’ This is almost always true of Magicians as well. Sooner or later our Magician take on something that is actually impossible and the project ends in tears at bedtime.

Usually then, the Magician leaves that organization and goes to some place new. Will they have learnt from this bitter experience? Probably not? Most Magicians revert to type and start doing low-grade tricks again – pulling small furry animals from hats! But all they do is get on the escalator another time.

A Magician may or may not deliver a project. If they do, it will usually be after epic amounts of blood, sweat and tears that could certainly have been avoided if some basic planning and subsequent negotiation with the powers-that-be had been done.

Most likely to say: ‘Sure.’

Least likely to say: ‘No.’

 

The Soothsayer

The definition of a soothsayer is ‘a person able to foresee the future. This IS what Soothsayer project managers do – they predict the future and then make it come true.

Soothsayers build proper plans. Using these plans, they then tell bosses / stakeholders / customers what’s possible and what isn’t. They do this in a calm, unemotional way using the facts in the plan as evidence.

Soothsayers know that they know more about the project than anybody else. Thus, if a boss / stakeholder / customer says that the Soothsayer is wrong or hasn’t thought of something or has the wrong end of the stick, the Soothsayer will politely correct them and show them the error of their ways.

When bosses / stakeholders / customers engage in delusional behaviour – for example, saying non-fact based things to the project manager like ‘You’ve got to find a way’ or ‘You’ve got to work smarter, not harder’ or ‘If you don’t do it, I’ll find somebody who will’, the Soothsayer politely but firmly brings them back to reality, to the world of numbers and facts.

As somebody once described it – and in some ways, I have yet to find a better description – ‘[Soothsayers] take no crap from the management.’

Soothsayers are good people because they stop bosses / stakeholders / customers from doing harm to themselves.

Soothsayers don’t ‘say no’ or ‘push back’. In a very real sense they don’t bring problems, they bring solutions.

A Soothsayer will always deliver a project. And then another. And another and another. What Soothsayers do is sustainable. They build a track record of success, while having a life outside work – which is as it should be.

Most likely to say: ‘Here’s why that won’t work but here’s what you could do.’

Least likely to say: ‘Sure.’

 

 

—o0o—

 

If you found this useful, please share it with anyone else you know who’s trying to get projects done successfully.  

 

Okay, so hopefully we’ve established https://fastprojects.org/2017/08/23/we-dont-have-time-to-plan-it-just-go-do-it/ that planning is a good idea and that the alternative – ‘we don’t have time to plan it – just go do it’ is, to put it mildly, rather dumb.

But how can we estimate accurately when estimation is – basically – predicting the future and something that no mortal person can do? There are three things that can help us. These are:

o Detail in the plan
o Learning from previous projects
o Using Assumptions.

We have a paper called How To Estimate Anything Accurately. If you’d like a copy just email us at info@fastprojects.org and we’ll send it to you.

Don’t know if you’ve ever heard somebody – typically, a boss or a manager – say ‘we don’t have time to plan it – just go do it’. And maybe you’ve wondered if this is good advice / a good strategy / good management practice. After all, they’re probably more senior to you, more highly paid, more experienced, more knowledgeable.

Well, here’s what cooking dinner would be like using the same ‘we don’t have time to plan it, just go do it’ approach.
Imagine this. It’s about six o’clock in the evening and you suddenly realise you’re hungry. You decide to cook dinner.

Here’s what you do next:
1. You light the gas ring.
2. You look in the fridge to see if there’s something to cook.
3. You find there’s nothing you like there, so you decide to head down to the supermarket. Hopefully, you turn off the gas ring before you go.
4. You return with some eggs. You’re going to make an omelette.
5. You light the gas ring again.
6. Where’s the frying pan? Uh oh, it’s in the dishwasher and the dishwasher is part way through its cycle. Okay, let’s wait until the cycle is over. Turn off the gas again. Go watch TV.
7. Finally the dishwasher cycle is over and you starting cooking your omelette. But then you think, ‘It’d be really nice to have some fried potatoes with the omelette.’ But oh hell, you should have done the potatoes first because they take longer than the omelette.
8. You finish the omelette and put it in the oven to keep warm. You start on the potatoes. You’re going to have a can of mushy peas with them and happily, you have both enough potatoes and the mushy peas.
9. But mid way through frying the potatoes, you change your mind. Wouldn’t asparagus be really nice instead of mushy peas? Back down the store again.
10. And so on …

Good advice / a good strategy / good management practice? What do you think?

If you want to shorten a project there is one place where – more than any other – this can be achieved.

This is right at the beginning, as soon as the idea for the project is born.

You don’t have to take my word for this.

In their book, Developing Products in Half the Time , the authors Smith and Reinertsen refer to the beginning of the project as ‘the fuzzy front end’. They say this: ‘Time is an irreplaceable resource. When a month of potential development time is squandered, it can never be recovered … each month of delay has a quantifiable cost of delay. Our goal as developers is to find opportunities to buy cycle time for less than this cost. These opportunities, large and small, appear throughout the development process. There is, however, one place that we could call the ‘bargain basement’ of cycle time reduction opportunities. It is the place that we consistently find the least expensive opportunities to achieve large improvements in time to market. We call this stage of development the Fuzzy Front End of the development program. It is the fuzzy zone between when the opportunity is known and when we mount a serious effort on the development project.’

If the ‘fuzzy front end’ is where ‘opportunities to achieve large improvements in time to market’ are greatest, then learning to scope and plan a project in a day is the best way of maxing out those opportunities.

If you don’t scope and plan the project in a day, what’s the alternative? It goes something like this:
1. Somebody identifies some kind of need or requirement or problem that needs to be solved.
2. Based on this somebody does some ferreting around and then writes a proposal / business case / specification.
3. This is reviewed by the stakeholders (those people affected by the project) and the reviews are fed back to the author of the document.
4. There are updates to the document, plus perhaps flurries of e-mail exchanges, phone calls, requests for information and meetings to resolve various issues.
5. Items 3 and 4 get looped around a number of times until finally …
6. There is agreement on what we are going to do.
7. Then somebody is charged with building a plan.
8. That somebody does some ferreting around and then writes a plan.
9. That plan is reviewed by some or all of the stakeholders and the reviews are fed back to the author.
10. There are updates to the plan, perhaps more e-mails, phone calls, requests for information and meetings – particularly if there is a gap between what the stakeholders want and what the project team say is possible.
11. Items 9 and 10 get looped around a number of times until finally …
12. There is agreement on the plan.

This process can take weeks … months … years, in some cases.

As an alternative to all of this carry on, you can scope and plan the project in a day.

You would have thought that if you told most bosses or CEOs that there was something they could do which would:

• Save precious time which could then be used for other things
• Reduce costs
• Reduce waste
• Save money
• Increase revenues
• Increase profits
• Improve cash flow
• Enable them to steal a march on, or gain a competitive advantage over their competitors
• Deliver business benefits quicker
• Reduce the risks of projects running over time or budget
• Increase staff morale
• Give greater employee job satisfaction,

they would jump at it.

If, in addition, you told them that this would require no extra resources – material or people, then you’d have thought the only question would be, ‘ How soon can I have it?’

Bizarrely, this is not the case.

Shortening projects / shortening time to market is something that does indeed tick all of the boxes above. Nor does it require extra resources – merely a change to the way the current resources are used.

Why then, is everybody not trying to do it?

It seems to me that there are a variety of reasons:

• People don’t actually believe it’s possible – most bosses and project stakeholders think they’re lucky if projects come in on time and within budget.
• Nobody figures out what getting the project done early would mean financially.
• Many projects aren’t planned and estimated properly – if they’re not planned and estimated properly they can’t possibly be done quicker.
• Getting projects done quickly is not in the ‘official’ project management literature, the Project Management Institute’s PMBOK [Project Management Body Of Knowledge].
• The emotional investment people have in the way things are done at the moment – ‘What’s wrong with the way we do things at the moment?’ syndrome.
• All of the people involved in the project are afraid that if they do the project fast they’ll miss something important.
• Especially in high-tech organizations, very smart people can often regard very simple ideas as being of no value.
• Again in high tech organizations, very smart people often can’t believe that simple ideas would work where complex ones have failed.

It’s a pity – because for those bosses and project stakeholders who are going to be first to embrace this disruptive idea, there will be a crock of gold at the end of the rainbow.