Reward: Make it worthwhile and memorable!

Reward Package
Give them a reward

When you have done the “close-down” and “lessons learned” things I suggested last month there are a few more activities which I think are really worth considering at the end of a project:

  • Punctuation – Make sure people realise that this is The End.
  • Say “Thank you” – You might be surprised how much people appreciate it.
  • Give small gifts or mementos for people to remember the project by.

These things can be done by management roles, but they can be done informally within a team as well.

What to give as a reward? A little more detail.

Sometimes projects just “peter out”. The last person to leave switches off the lights. I think it is better to have a final social occasion – a project meal or something similar.

Saying “Thank you” costs nothing more than a little effort. People appreciate it and if you work with the same people again they will remember that you appreciated what they did.

Small gifts can be a nice gesture. I have been given some strange things over the years, ranging from the technical (a couple of planes of core memory, and a disk platter), through the practical (some coasters and a set of cuff-links) to the rather strange (a curry cook-book!). All of these things bring back pleasant memories about the projects in question.

Why bother with a reward?

As well as being pleasant, these things serve practical purpose.

  • Bringing the project to an emotional close is a good thing. It is time to finish what are doing and move on to the next activity.
  • You may find yourself working with the same people in the future. This can happen years later, and you may be in quite different roles. Parting company on good terms means that it will be easier to start the new relationship with a good feeling.
  • I think it is good for your reputation to be thought of as being appreciative. This does not mean that you have to be soft. There is no contradiction between being a “hard task-master” and saying “thank you” in various ways.

Think of these activities as being a small speculative investment in the future.

Two words of caution:

  • Do not be seen to be doing these things in a manipulative way. People do not like that and it is generally counter-productive.
  • Do not say you are going to do something (like hold an “end of project meal”) and then not do it. That is demotivating.

Enjoy a break before starting again refreshed!

Success: Congratulations! You’ve arrived.

Successful Project
Successful Project

What do you do when the project is finished? I mean, apart from the party and the sigh of relief? You’ve delivered your project. Maybe you consider it a success, maybe you’re not sure. It doesn’t matter, it’s over now. Celebrate your success!

Part of good project management is learning from your experiences. Now is the perfect time to do lots of little things. Most of them do not take a great deal of effort, but some of them can do you a great deal of good in the future.

Who are we doing this for? Who do we tell that this has been a success?

There can be several groups or individuals here:

  • The Customer
  • Your employer
  • Your colleagues
  • Yourself!

There is an old English saying (in Yorkshire dialect) which goes:

If ever tha does owt for nowt, make sure tha does it for tha’sen!

(If ever you do anything for nothing, make sure you do it for yourself!)

What should you do we do? (to get the most from our success)

We want to get as much benefit as we can out of the experience we have gained.

Ensure that you respect the “intellectual property rights” and confidentiality of others, but make sure you get something out of the experience.

Here are my suggestions for things to do in the wind-down period of the project or immediately after it finishes. Make sure you have something tangible to take away.

  • Update your CV to include the project you have just completed.
  • If you keep a notebook (you should), then review the sections relating to the project.
  • Update your contacts book. Make sure you connect on LinkedIn or similar with the people you want to remain in contact with.
  • Write a short report (maybe just 1 or 2 pages) to yourself, describing what happened – the good, the bad and the ugly!
  • Create a short presentation describing the project and the key learning points. Maybe produce two versions: the “selling version” and the “warts and all” version. Don’t mix them up!

How do you get started?

This is a surprisingly easy thing to do. All you need is the motivation.

There is often a period at the (or shortly after) the end of a project when you will have spare time and may not be sure what to do. I have given you a short list of small activities, all of which will be beneficial.

Use the list at the completion of your next project!

Review: How was it for you?

Review - How was it for you?
Review – How was it for you?

What is your opinion of someone who keeps on making the same mistake? I expect it is probably not very high. Making mistakes is inevitable, but we should learn from them. Having a “review” is one way we can do this.

Having a review means taking the time to look at what we did and how we did it. We can learn from what we did, and do better the next time.

Review: When, How, What?

Hold your review when something is complete and when it is still fresh in people’s minds.

I prefer “light weight”, “low ceremony” activities. Doing our review that way means we can do it quickly and cheaply.  The simplest way is to ask the people involved – “How was it for you?”

Keep it simple. Make the product of your review a few things you plan to improve the next time, and then put those changes into effect.

The idea of reviewing what you have done fits naturally into the iterative structure of Agile projects, but it can also be applied with Waterfall.

Use reviews to improve your productivity:

A review is intended to help us to: “Do it better next time!” The effort which goes into the review must be repaid by the improvements it causes.

  • Remember to include the different groups involved. If we are talking about a specification or requirements document, include: Business Users, Developers and Testers. The objective is not to find “what went wrong?” but to find a way to “do it better!”
  • Keep it simple. Make the product of your review a few things you plan to improve the next time. Make sure your review has some visible effect. People like to feel they have influenced how things are working. On the other hand, people do not like to be ignored. It is demotivating.

Some of the suggestions from different parties may be contradictory. For example: Some people may want more detail and others want to spend less time producing documentation. This is a challenge to your imagination, creativity and skill at negotiation.

What is the next step?

Adding reviews like this to your process is something you can do in a stealthy way. Start by identifying a work-product which is coming up for completion.

  • Who would you involve in your review?
  • When and how are you going to get hold of them?
  • What specific questions will you ask them?
  • How long will you allow yourself to manage the review so you can incorporate its findings into the next suitable activity?

Good luck! Have fun and tell me how you get on with your reviews.

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?