Brunel University's Business Class: Motivating and rewarding

Developing a rewards-based culture is a challenge most businesses grapple with. Brunel's Professor Robert Macredie and Dr Mark Lycett shed light on some of the options...

Motivation is a tough nut to crack. We all have our own, distinct criteria that motivate us to get out of bed in the morning and go to work. Well-motivated people work more productively, while those with little or no motivation are, at best, likely to be less productive or, at worst, obstructive. The job of the employer is to find out what an individual’s motivation is and cater to it in order to keep them interested and working to the best of their ability.

In any job this is important but in IT the effects of de-motivated staff are especially noticeable not just because many IT projects are staffed by contractors but also because there’s so much at stake: how IT systems are set up and maintained will affect a business’ efficiency.

In previous articles, we’ve tried to come up with suggestions on how to improve IT development: ‘be agile’ we’ve asked, ‘think out of the box’ and ‘try to understand the context in which the software will be used’. ‘Listen to the business department and work with them for the greater good of the company as a whole’ we’ve urged: ‘think holistically and leave a legacy for others with advice, best practice descriptions and details of lessons learnt’.

These kinds of suggestions must come from the top down - IT directors have to push for this. However, for developers to bear these in mind, there must be a ‘pull’ factor as well. This is where motivation comes into the equation. IT directors should ask themselves whether programmers are given the incentives to think differently?

The majority of developers work on a project basis, with heavy cost and time constraints. This means that there’s a tendency to stick to what they know – to what can be done easily. The sooner the job gets done, the quicker they can move onto the next one. While this is entirely understandable, it is equally easy to see that this doesn’t necessarily always lead to the best possible outcome: not only does quality run the risk of being sacrificed for time but the short-term goal of speed is often at odds with the longer term goals of personal skills development, ensuring the team learns from lessons and ensuring the system supports business objectives.

It’s clear that this ‘business value’ needs to be embedded into the development process but the question is: how can this be done, especially when many involved are contractors with no particular affiliation to the business?

This is when the concept of ‘benefits management’ – of offering incentives to developers for thinking and acting differently – might be considered. Just as we would consider offering builders extra cash if they finish the road/house more quickly, it’s worth considering whether and how developers could be rewarded for excellence in system design and implementation.

If a reward scheme is initiated careful consideration should go into what kinds of activity are rewarded – and what constitutes excellence. It negates the objective of the scheme if speed alone gains points! The reward culture needs to focus on criteria such as quality of software, ease of implementation and improvements to the original brief. Establishing this environment of continual improvement – or kaizen, as the Japanese call it - is about giving developers real incentives to think differently so that small but regular improvements are made to the development process.

The other way to establish this kind of environment is to attach different measurables for success throughout the development process. This is not likely to be easy. A recent survey carried out by our research colleagues at Brunel's Department of Information Systems shows mixed results when respondents were asked how to classify success. When asked to provide the primary measure of development progress, only 26 per cent of respondents judged success on working software. Fifty-four per cent confirmed that they measured on attainment of project milestones and deliverables, with 20 per cent happy to complete the software development stages.

These figures are confusing: surely a fifth of IT departments can’t consider that simply ticking boxes of the software development process is a suitable measure of success? And with only a quarter wanting software that actually worked, we can only hope that working software is included within the measurement criteria for the 54 per cent who judge progress on achievement of project milestones.

What the survey does show is that the process of establishing a reward-based culture for innovation is likely to be a hard one, initially raising more questions that it answers. However, if we’re to solve the problem of how to motivate developers to move beyond the norm, then it’s one that we’ll have to address. Move over Mr Motivator…

Professor Robert Macredie and Dr Mark Lycett are leaders of ‘Fluid Business’, a groundbreaking research project within the Department of Information Systems and Computing at Brunel University. They can be contacted by emailing FluidBusinessTeam@fusepr.com. Or email us with your opinions at editorial@silicon.com.