Skip to main content

Author: Mark Broadbent

A Surefire Way of Delivering What You Set Out to Deliver In Your Next Project Plan

Written by Mark Broadbent on . Posted in Articles. 4 Comments on A Surefire Way of Delivering What You Set Out to Deliver In Your Next Project Plan

No amount of detailed planning will guarantee success.

Yes – you read that correctly.

Many project managers tend to think – “I’ve planned the project, worked out when we need to have things done, now just monitor the work and it will all happen.”

No it won’t.

In fact, the only thing you can really guarantee about a plan is that it won’t go to plan.

Related Article: Look Out for “Best Efforts” Projects

I can just hear it now… “Mark – why start with this seemingly contrary aspect of project planning as a way of ensuring I deliver what we set out to deliver?” Simple – it’s to show that you should not spend an undue amount of time getting every little detail right when planning.

In fact, the more detail you attempt to put into a plan, the more likely your project will start to miss targets, start to get behind and generally cause you a lot of angst. So the idea is to find the happy median between too little and too much detail. But how?

What you need is clarity of what it is you want to deliver from the start.

Planning involves the deliberate intent to think about what needs to be done, when, by whom and what dependencies are required before we are part way through – while it is all on paper and much easier to change as we work it out some more.

We must be careful about being too sequential in our thinking when planning. We need to think holistically as we work out to successfully deliver our new project. That is, work from a high level down.

Too many PM’s try to start planning at the perceived start of the project and then attempt to think of everything that needs to be done in sequence.

Don’t do this.

Your projects will suddenly take you months (or even years) longer than expected, you will get bogged down in detail and will likely miss something that needs to be done. And most importantly – never seem to get started. (And likely have a plan that will be off track before you barely get into it).

Work from a broad overall picture then tease out the detail.

Anyone who has done any painting knows this – try painting a portrait from the top of the canvas to the bottom every little detail as you go – and see how good the painting is in the end! (It can be done – but you need to be an outstanding technician, very experienced and very familiar with your subject.)

By working with a broader overall context first and refining things as you plan, you have a far greater advantage over the sequence driven planner – you can stop at whatever level of granularity is appropriate for now – and be confident you have not left out anything even if you are not sure about the detail yet.

To do this, start with the end in mind. In our project world, this means starting with a clear definition of what we want at the end.

The PRINCE2 methodology has a nice way of doing this – with a “Project Product Description” – a brief description of the overall “product” or set of products that you are going to deliver. (PRINCE2 uses the term “Product” instead of “Deliverables” – I will use the terms interchangeably – but understand they mean the same thing – something you can point at in the end).

In reality, this overall vision can be in the form of a concept model of any type – document, drawings, computer presentation/mockups, physical models. The clearer, the better. As long as the key people involved in your project agree what it is.

Next – agree on the definition of “done”. That is, when is the product considered complete?

So

Step 1 – Have a clear definition of what it is your project will deliver in the end.

Step 2 – Define “done” for each deliverable.

This is the starting point to having a plan that is focused on what the project owner wants while at the same time stopping us from over thinking everything in a sequential manner when we do our planning.

If you are in the software development world and you are using agile software planning – the principle still applies. You start with story “epics” that denote the essential pieces of functionality that make up your new overall product.

Planning for a Product-Driven Project

One of the best ways to achieve the happy medium in terms of detail in your plan is to start with this end-project vision and break it down into the various components or “sub-products” that must be delivered to get us there.

You can (if you want) draw up a dependency diagram of the components of your products; however, a simple indented list does just as well.

Don’t be tempted to get into activities and estimates of time and resource allocations just yet. That comes later. Just the thinking that goes into what we need to deliver overall as interim deliverables towards that overall end product is what is important.

Here are a couple of examples of the type of thing I’m talking about as a simple indented list:

  • Big Expensive Software Product
    • Functional Requirements Document
    • Tender Request Document
    • Budget Plan
    • Business Case
    • Evaluation Criteria
    • Evaluation Team
    • Legal Team
  • New Warehouse
    • Plans
    • Council Submission
    • Budget Plan
    • Road Access Plan
    • etc

Remember everything in the hierarchy is something you can point at later. Products (or deliverables) are things you can see and touch. We normally use nouns to describe them.

By the way, I’m not trying to advocate PRINCE2 in particular (although it has a lot of advantages for the more formal project environment) – however, this is one very nice aspect of that methodology that is useful for many projects. 

Often people say – “but, my project is a doing thing, like – move the office to a new location, purchase a new software package, migrate the data center”.

Yes – these are actions. But these are actually the outcomes we want to achieve – “I want to move my data centre into the cloud” – is an outcome or objective of the project owner.

Certainly finding the appropriate thing / noun from this as your first instruction can require you to flip your thinking – but work with it. It’ll be worth it. The deliverable, in the end, are still things – “outsourced data centre”, “software x”, “new office”.

So start with a clear definition of what it is you want to deliver IN THE END and work holistically – use a “broad brush” approach sketching the overall picture and then work out the lower level components – all things you can see and touch. Have a definition of “done” for each.

Work on detail for the first things you need to do for now.

Such a simple process. It will deliver the results you want.

Happy projects.

Mark

Look out for “Best Efforts” Projects

Written by Mark Broadbent on . Posted in Articles. 7 Comments on Look out for “Best Efforts” Projects

Today I am going to talk about something that will likely occur in every project manager’s career, usually without realizing it. These are projects that I like to call “best efforts” projects.

Best efforts projects most often come from 3 different sources:

  1. The boss’s pet project;
  2. A project that was failing; and
  3. “Abandon the plan” mode projects.

They hit you unaware. They quietly creep up on you while you are busy.

Related Article: Why Projects Fail: A Root Cause

Let’s discuss the sources.

The Boss’s Pet Project or The One that is Failing

These types of best efforts projects often started as a request from a senior person: “Mark, you’re the guy who seems to always get things done – can you take on this project for me? It has failed so far, and I really need someone I can rely on to get it going.”

You usually are a little chuffed that you have been asked. You think to yourself – “Yes, I know I could get this done. It’ll be close to impossible to achieve in the three months left, but you know, I’ve done things like that before. I can do it. Besides, this is obviously an important project – everyone knows it because it’s the boss’s highest priority. I will be able to get lots of help. I probably don’t have the budget available to throw resources at it to get it done, but hey I’ve been asked to do it at the last minute. I know everyone will rally behind me, remove the blockers, make budget available – we can get close to that target! The boss won’t mind if we are a bit later than that target because they know that it’s almost impossible.”

Wrong, wrong, wrong.

It’s not uncommon for these projects to be “death march” projects. It has failed a number of times. Perhaps the concept is flawed, team members are not capable of doing the work, the work is too innovative, or to deliver the boss’s vision is just plain impossible.

Instead of taking stock and proceeding carefully you optimistically revise the plan, then ask for help and input from everyone; but no one really wants to help. They don’t care that the boss has asked for it: “It’s impossible to get it done in that time,” Or “The idea is simply not capable of being done.”

The main thing here is that with best effort intention we think “No matter, the boss will understand if it’s a bit late; the boss knew it was tricky – so they will cut me a bit of slack.”

But it does not work out that way.

The boss complains that the project is running late almost from the get go. You try and show that your people are working on it, putting in extra hours, trying to get it done using heroic effort. But still the boss is not happy – in fact, it seems no one is happy.

The boss still wants the project done in the original time and scope. They are frustrated, the team is frustrated, and mostly the PM will be seen to have failed. Why? Because the boss made the assumption that when you rescued the project you could still get it to come in on time, and/or budget and with the same quality and scope.

The problem with these projects is that you assumed that “best effort” would be well received because of the circumstances. This is not project management; it is wishful thinking.

“Abandon The Plan” Projects

The next kind of project that ends up as best efforts projects are those that start out with a plan, but as things start getting behind or things start getting tricky, the plan is forgotten while everyone hunkers down to get the “real work” done.
Sadly, this is probably the most common sort of project!

You start a plan with good intentions. Things don’t go to plan. Things get desperate as delivery time looms. PM’s think “let’s just get on with the work, put in lots of hours, (heroic effort), then everyone will understand we have done our best. The boss will understand we are all working so hard – staying all night to get the deliverables done.”

Wrong, wrong, wrong.

They won’t understand. This is not project management; it is project heroics based on wishful thinking.

If you find yourself needing to always put in heroic effort to complete project deliverables or interim deliverables, then there is something wrong with your planning.

You might think it is the nature of a highly innovative project, the skill level of your team, the team’s inability to deliver to the plan or the acceptance level of the change that are contributing to the variations to the plan. In the end, though, especially after delivering the first couple of deliverables of your project, you should be examining what it is that is creating the need for the heroic effort and re-planning the next iteration or stage to compensate.

Have an agreed and deliberate intentioned alternative plan.

No matter what happened, most projects that fall into these buckets are still expected to be delivered or at least partly delivered close to the original time, scope and budget unless you have an agreed and deliberate intentioned alternative plan.
Never assume that people will rally around and the boss will “forgive” changes to targets.

Whenever you are asked to come in and help, think to yourself that this is a problem child and needs careful consideration BEFORE committing to anything. Gauge the level of acceptance of change. Ask the question “What’s the most important thing – the target date, the budget, or the scope?”

By asking this up front you are inspiring confidence immediately, and knowing the answer will enable you to re-plan accordingly.

So what steps could you take?

The best approach to this is an alternative plan – or as the popular PRINCE2 project methodology would call it – an Exception Plan.

To develop an alternate plan consider reducing scope, breaking deliverables into smaller achievable chunks, or employ an agile delivery model but mostly consider a plan to deliver a little a lot.

It is amazing how such a simple philosophy can fix so many potential problems!

By delivering a little a lot you can achieve a sense of accomplishment from the team’s perspective, and a sense of delivery from the boss’s and the customer’s perspective. Also, you will be able to see issues emerge early, and therefore be in a position to consider changes in direction without too much sunk cost and wasted effort.

Get “skin in the game” from the team.

Many projects got into abandoned-plan mode when the team was not consulted in the development of the original plan. They have no ownership of the plan hence will undertake “best efforts” to get work completed – whatever that means to them – simply because it was not their plan.Make sure as a PM you work to get realistic estimates from the people who will actually do the work – that way there is a level of ownership and “skin in the game”.

Agile (Scrum) planning has a really useful process called “planning poker” as a fun way to involve the whole team in effort estimation that can be adapted for any style of project. Check out planning poker from Mountain Goat Software’s site here or Planning Poker.com to learn a bit more.

Develop a realistic plan to complete the work – but develop it as a variation to the original plan so everyone can see how things will change. Make no assumptions about the budget, resources, or time left – work out what is really needed to get the job done. Do not depend on “heroic effort” or “best efforts”.

Once the plan is reworked, work out the new cost, the new time, the resource requirements and options for different mixes of scope, cost, resources, and time. Remember to plan to deliver a little a lot.

Present this to the boss with a recommendation – only after the team have all agreed it’s workable. The boss might want some further compromises, but be clear, be intentioned – show how the changes will impact the project. Give yourself time to think – don’t commit to something without the team’s input.

If this was a troubled project, the real trick is in seeing it for what it is when you are asked to take it on. Don’t just think of being a hero. Be a realist and you are more likely to be thanked. You will be thanked for telling the truth up front. If the project is cancelled after telling the truth, you will be respected for it.

Best efforts projects are not obvious. You can simply roll into them without realizing it. Look out for abandoned plan mode.

Despite taking on a difficult project where you expect best efforts and heroic efforts will suffice, that will not be enough. Return to fundamentals such as scope, time, quality and deliverables. Work out a way to deliver a little a lot – it will demonstrate achievement and relieve pressure. Develop an intentioned alternative plan based on input from the team.

You can be the hero without working yourself and your team into the ground. Keep your radar out looking for heroic effort and team members working best efforts and disregarding plans. It may be symptomatic of a struggling project. Catch it before it causes pain for everyone involved.

Happy projects.

Mark

Why Social Software Makes Sense for Project Management

Written by Mark Broadbent on . Posted in Articles. 4 Comments on Why Social Software Makes Sense for Project Management

A project is a human endeavour – a temporary society of people with a common interest and a desire to achieve something.

Project management as a discipline attempts to put some repeatable practices around achieving these things. It is forethought about forethought.

The problem is that we project people often get caught up in the process and the artifacts of those processes that we forget to keep our eye on the end-game – the delivery of something for our organizations.

A lot of project management software (certainly in the past) has tried to put some way of supporting a particular process and then sharing the process artifacts with the team in the belief that if we all just see the process artifacts, the project will work. But the big issue is that this way of working still does not guarantee the right result.

Why?

The problem is that I believe our tools often fail in understanding 3 simple principles of human endeavour, especially as they relate to projects:

  1. There is an almost infinite way to achieve something;
  2. Nothing in human endeavour can be totally predictable;
  3. Most often, the big issues that confront most projects are people-related.

To date, we have tried to reign in all of this messy human stuff by following a process – effectively trying to deny the indeterminate nature of most human endeavours – particularly in the creation of something new.

Ironically, it is this indetermination that is our strength.

Through variation and changing influences we humans produce breakthrough results, especially when we need to be creative to overcome issues.

I cannot recall any time when a truly breakthrough change, an “ah-ha” moment, a new product, a creative solution to that seemingly impossible problem, came from having only a disciplined processes. (I’m happy to be proven wrong). There are plenty of examples of competent results being achieved using “the process”, but the new, inventive, brilliant?

I believe that it is simply counter-intuitive to try and achieve a different result using the same process as we did before. It’s certainly hard to achieve something we did last time when the influencing factors change and they nearly always change as time progresses or the environment or people change. It seems that we believe that if we just keep one thing constant – the process – that we will overcome these other variables. The changing environment, changing people and changing influences adds to the indeterminate nature of human endeavours – especially in an ever increasingly complex world.

We humans are essentially adaptive creatures – we take our changing circumstances and influences into account, learn from them (hopefully), and as a consequence, change the way we do things to get the result. However; our processes are often designed to try and ignore this very fundamental nature.

If we work together, draw on each other’s unique perspectives and knowledge we handle indetermination better. The collective mind becomes greater than individual perspectives.

In the process, we move away from thinking of work as a set of transactions or an assembly line of activity that just has to be completed to the process, to thinking and working interactively. When we do this, we achieve something else, something better.
A high level of interaction between team members within a project provides a context for sharing thoughts, ideas, status, issues, events, etc.

This is the secret of social-based software as a tool for projects. Social based software allows for the indetermination of each unique project as a piece of human endeavour to meet the challenges thrown at it by using natural human interaction. This results in a way to achieve our result exploiting the three principles, instead of fighting them.

This process develops a collective consciousness and a shared result with high buy-in. It allows us to handle the unpredictable. It allows us to achieve something in a way that is humanistic, using a variety of approaches.

It does not mean that we have to abandon the good things that our old disciplines provide. It adds a dimension – the dimension that supports the indeterminate nature and the humanness of project endeavours.

Social software in projects is not a panacea to failed projects – but at least it provides an opportunity for success in a way that our favourite project management methods may not – something that supports the indeterminate human aspects of real life projects – people.

And you know – it could just make “work” fun. Because essentially we like to interact, be part of something bigger than ourselves and to be inventive.

Social based software provides us with this opportunity.