How do you motivate people on projects?

Its amazing what a small group of motivated people can achieve when given the chance.

It is also amazing how many project managers launch into planning and running their projects without thinking about how to motivate the people delivering the project and then struggle against the tide to try and deliver the work they planned.

I believe motivating the team to want to deliver a good quality outcome that is suited to the needs of the customer is half the battle to delivering successful projects.  If you have a well motivated team they will solve surprisingly complex problems and if you have an unmotivated team they will stumble on the most trifling of problems.

But how do you motivate the team and how do you keep them motivated?  I used to think you needed charisma and a regular supply on snacks and beverages, but I have started to think it is less about either of those things and more about understanding what really motivates (and demotivates) people.

My favourite theory of motivation is “Expectancy Theory” because it is simple to both understand and apply … and it seems to work for me more often than not.

Expectancy theory says that people will be motivated to do something if they think it will be worth doing it. And it goes on to say that they believe (“expect”) it will be worth doing if:

1. They have the ability to do it.
2. Doing it will make a difference.
3. They will be rewarded for making a difference.

It really seems to be that simple on a lot of my projects.

If people don’t believe they can do something then they will not expend much effort to do so. Which means that:

• If people don’t know what is expected of them they will often focus on doing the things they know the most about doing rather than stopping to see what really needs to be done;
• If people don’t already have the skills to do something they generally won’t try; and
• If people do know what needs to be done and feel like there is something they can do to contribute then they will generally dive in to help.

If people think that their effort will have no impact then they will not be motivated to act. And worse, if they are not motivated to act then they will become generally unmotivated.

Similarly, if people only see part of the impact of their actions then they will be motivated to act more responsibly based on what they do see.  So if they don’t see the impact of hard-coding on the users then they will start to do more hard-coding of their work to get things across the line more often.

But if people do see the real impact of what they are doing then they will generally be motivated to do the right things and will also feel more motivated in general.

Finally, if people get rewarded for the wrong things then they will do more of the wrong things. Hence if we measure testers on bugs found they may focus on raising bulk numbers of trivial errors rather than spending time looking for patterns of failure and sharing these with the developers.

But being rewarded does not necessarily mean “extrinsic” or external rewards like money or promotion. If also includes a feeling of pride in seeing a job well done, a thankyou or even the joy of feeling like you have solved a difficult problem.

So, the simple version of motivating people on projects is really to:

• Generate clarity around what needs to be done, as well as align work to people’s skills, and show them you will provide support where they need help;
• Show people the impact of what they are doing; and
• Make sure that where people have a positive impact, they get rewarded even if its just with a thankyou or more respect from their peers.

This is a simplistic model but I always find it useful.  What do you think – simple and effective or simplistic and naive?