Re-planning: Path to Success or Mark of Failure?

Project Gantt Chart
Project Gantt Chart

When did you last revise your project plan? Did it make you feel you had failed, or did you feel it was an essential step on the path to success?

I would argue that re-planning is a necessary part of projects.

Re-planning: Just part of project life

I have met people who felt that “re-planning” or revising a project plan was an admission of defeat. They feel they should have anticipated everything in advance and built it into the original plan. I think they are being unnecessarily hard on themselves.

Unless you have complete foreknowledge about everything in and around your project, then some degree of re-planning is inevitable.

Re-planning to suit your project

To oversimplify things a little, there are two kinds of project, “Waterfall” and “Agile”.

  • With Waterfall, you can really only plan one phase at a time in any detail. That means that one of the concluding outputs from each phase is the detailed plan for the next phase. This means that you have to revisit the plan with each new phase. It’s an essential part of the method.
  • With Agile, you plan each iteration or sprint as it comes up. Again, this means planning again and again. The plans may be smaller, because the steps are smaller but they are still there.

In both cases the smaller plans fit within a larger, coarser grained project plan.

How up to date is your plan?

One of the advantages of re-planning or revising your plan is that it allows you to take what you have learned from your project into account. It means that the projections in you plan are more likely to be accurate and therefore you can take action to try to achieve them. Having an out of date plan which contains unachievable completion dates is demotivating. Bring your plan up to date and then manage to the up-to-date plan!

Check-Point: Are you where you want to be?

Project Check-Point
Project Check-Point

Check-Points are a way of telling if your project doing well or badly and whether you are where you want to be.

People can become some wrapped up in what they are doing that they forget what is going on around them. Check-Points are and opportunity to review where you are.

If you were heading in the wrong direction, you would want someone to tell you?

Check-Points: One solution to this problem

One approach I use to address this situation is to have periodic “Check-Points”. A Check-Point is a quick review which is not directly linked to the project schedule. Regular reviews are best. You can have them at any frequency to suit your own needs.

Choosing the frequency of Check-Points is a matter of personal preference. Too frequently and you are wasting effort. Not frequently enough and you may “travel in the wrong direction” for longer than you need to. In my business I combine the Check-Points with the quarterly reports I produce for my investors, collaborators and colleagues.

The Check-Point should confirm that the objectives of the project are still valid. After all, who wants to have an on-budget, on-schedule project for superseded technology! It should assess where the project is relative to its objectives and it should assess the rate of progress and identify any issues. All of this should be done as quickly and with as little expenditure of effort as possible.

Plan your Check-Points carefully

Running a Check-Point should not be onerous. At its simplest it involves the Project Manager and a few other people and can be performed without disrupting the project team.

  • Confirm with the Project Sponsor (the Business) that the objectives of the project are still valid. After all, conditions in the outside world may have changed.
  • How much progress the project has made?
  • How much of the scheduled time has passed and how much remains?
  • How much of the budget has been spent and how much remains?
  • What is the rate of progress?
  • Are there any issues which are inhibiting progress?

If you are using one Agile project management, then you probably want the check-point to coincide with the end of a sprint.

Schedule a Check-Point

Why not schedule a Check-Point for your current project. Aim to answer the following questions:

  • Is the project still valid for the business?
  • Where are you? (And where do you want to be?)
  • Are you moving in the right direction?
  • Are you moving at the speed you want?

Bright Idea: Opportunity or Distraction?

Bright Idea!
Bright Idea!

Are you creative? Do you employ creative people? I like dealing with creative people, but we all know people who are always seduced by the next shiny thing they see. What do you do when someone comes up with a “bright idea”, a new way of doing things part way through a project? Do you adopt it or not?

This is one of those situations where you are damned if you do, and damned if you don’t.

What are the issues:

I expect that we want to achieve our objective and we want to do this efficiently.

  • We want to continue to make progress.
  • The “bright idea” may cause an improvement or it may not.
  • Implementing the idea will inevitably cause some disruption.
  • Even assessing the idea will cost some effort.

So, what should we do? – Change Management

The answer to our dilemma is to have some version of “Change Management”. We need to capture the “bright idea” and then assess whether it will actually help us and then, if appropriate, introduce it in a controlled way. We should also have some kind of back-out plan, so that if the proposed change doesn’t have the beneficial effect we hope for, then we can revert to doing things the old way.

The question is, “how do we do that?”

My suggested way of handling this situation:

First of all, you an agreed “Change Management” (in this case “suggestion management”) process. I  prefer it to be as light-weight as possible. This should:

  • Capture the idea, so that it is not lost, even if it is rejected or not implemented immediately.
  • Encourage people, so they know their ideas are being considered.

Ideas should be assessed quickly, but without disrupting productive activity.

Here are some questions which will help you decide whether to adopt a suggestion and when to adopt it:

  • Can we continue to work doing things the current way? If so, perhaps we should defer assessing the change.
  • widespread is the effect of the change? Changes with widespread effects need to be considered more carefully.
  • Is there an obvious way of “backing out” the change?
  • Do the benefits offered by the bright idea justify the effort and risk to implement it?

Agile project management offers opportunities to incorporate change management and adopt bright ideas in a controlled way.

Scope: Are you trying to do too much?

Project Scope diagram
Set the Scope of your project

I don’t mean to be negative, but have you ever asked yourself why projects fail? I’m sure you can come up with a great long list. Today I’d like to address just one – trying to do too much, also known as having the wrong scope.

You must have come across projects which you feel would have succeeded if only they had set their sights a little lower – and stuck with that. I’m not just talking about “Scope Creep” where the project grows during its course, but I’m including the projects where the scope was too big from the beginning.

Realism versus Optimism

Optimism is a good thing. If we don’t believe we are going to succeed, we are unlikely to start a project. If we don’t believe we can succeed, we are not going to try and we almost guarantee failure.

On the other hand, if we commit to a project which will require all the resources we have, and then something else comes up, then again we are not going to succeed.

The scope of a project needs to be realistic. It needs to recognise that the objectives of the project need to be compatible with the constraints and the environment in which it operates. A project which has to deal with outside events is likely to be less productive.

One of the keys to effective project management is for the sponsors, management and workers to agree what they want to achieve – and then stick to the plan!

Getting Scope right in the first place

Agreeing the scope of a project is one of those areas where technical skills and so-called “soft skills” are required. You may find what you are doing being influenced by politics and things outside your control.

There are tools you can use to help you to get and to document agreement. Aim to get the different parties to agree what is “in scope” and what is “out of scope”.

The Agile project management methods emphasise prioritisation and create opportunities to adjust the scope of each iteration. There is less need to get it absolutely right first time.

Tools for getting scope right

I recommend holding workshops where the different stakeholders can agree what the project scope. Within these workshops, I use a technique to help the participants agree and document the project scope. The technique is simple and I have created a short course so you can learn. Go and have a look now.

Prioritisation: Are you doing the right things?

Priorities over diary page
Prioritisation means knowing what you are going to do.

I know you’re terribly busy, but take a moment to ask “am I doing the right things?” If someone shouted

“Stop what you are doing!”

right now, would you look back at what you had created and be satisfied, or would you wish you had put the effort into something different?

Get your priorities right

Sooner or later every project comes to an end. Projects can end for many reasons:

  • All the work has been completed
  • We’ve run out of time, or
  • We’ve run out of money (budget)
  • Someone in charge says “I’ve changed my mind. Stop!”

Knowing what the priorities are as an individual and as a project at each stage is extremely powerful. It means that you know where to put your effort, you know what to do next, when you finish a task, or a task become “blocked” and it means that you know what you are _not_ going to do (at least for the  time being).

Prioritisation: How should you decide your priorities?

You can do it on the basis of maximising benefit or minimising risk or cost or any other criteria you decide. Those in authority (which might or might not include you) should discuss the priorities (that includes having a good argument about them) for phase of the project you are working on, agree what the priorities are and then stick to that plan.

One of the strengths of the various “Agile” project management methods is the emphasis they put on agreeing the objectives or priorities of a time-box, iteration or sprint. Personally, I like to use MoSCoW for this, where:

  • M= Must have. There should only be one or two “Must haves” for each time-box.
  • S= Should have. There can be several “Should haves”
  • C=Could have. There can be several “Could haves”, and finally
  • W=Won’t have (this time around).

This approach concentrates on the “Must Haves” and only starts on the “Should Haves” when they have been completed. If you get it right, you run out of time or budget ideally somewhere in the Could haves (if you do well) or in the Should haves (if you make less progress than you hope).

Make sure that when someone calls “stop!” you (and everyone else) thinks they have received good value for your efforts.