Richard Byford’s speaker’s notes from Project Challenge 2002 conference, Birmingham, England, 2nd May 2002.
Just enough process
The conventional wisdom about project assurance usually focuses on the processes, procedures and tools used. These include the use of planning and scheduling tools, requirements, configuration, resource and change management – and procedures to guarantee safety, accountability and minimise risk.
As you might expect there was a strong correlation between project under-performance and a lack of formal project management methods. Very few projects performed well without the basic tools of project management. When you are dealing with complex projects, a structured approach to project management and the associated tools, processes and methods is essential. Without these things in place, your projects will be at risk.
But sometimes, these same elements can have the opposite effect.
A good set of processes, tools and procedures can be very re-assuring. Comforting even. They can give the illusion that a project can be managed mechanistically when in fact it is far from the case. When the project is going well, it is easy to believe that it is because you have put so much effort into getting the mechanism of management right.
The problem comes when the project starts to go wrong. Because the previous period of success was wrongly attributed to the action of the control systems – and the control systems gave a warm and comforting feeling – the team start working the processes harder. Harder – not smarter. This can lead to disproportionate management overhead and a reaction against the control being exerted.
But the real danger is that it diverts management energy away from the real business of managing – actually creating change.
Use processes, tools and procedures to manage – not for comfort.
Nurturing Projects
Senior management can change the way a project performs, just by changing their minds.
The way an organisation views a project can have a dramatic effect on its success. Much of this attitude will come from senior management – less by what they say, than by the way the organisation is run. No amount of words, pep talks and newsletters will overcome the message broadcast by contradicting company policies and actions.
On one extreme, an organisation might regard a project as something valuable, to be nurtured. Like a baby. Growing inside, being fed by the organisation as it progresses. Looking forward to the day of delivery. Talk about it as something wonderful that’s happening. A subject of conversation. Supported. A joy. An extension of the organisation itself. Part of ‘us’. To be cherished.
The other extreme is the organisation that treats a project like an abscess or boil. Something rather unpleasant on the outside – external to the organisation that should not be discussed. Unpleasant. Embarrassing. Painful. Something to be covered up and forgotten if possible. Something they would rather go away.
Those responsible for running the organisation need to send out the right message about how the project fits in with the overall strategy of the company. Is it something to be nurtured, or an abscess?
If projects are well founded and aligned to the host organisation’s strategy, it should be very easy to create a corporate environment where a project is treated like a new addition to the family.
Adopt a ‘project-as-embryo’ mindset.
Selling the Project Experience
The Butlins experience, Thompsons experience, The Hoseasons experience. The marketing managers of each of these companies need to know exactly what their customers’ experience when they book one of their holidays. The accommodation, the flights or travel. How good are the rooms? What’s the food like? How easy is it to book? Even to the extent of things outside of their control: What are the locals like? How accessible are the airports or stations? All this work for a week or two of a person’s year and maybe a thousand pounds. If it’s not quite right, it’s not the end of the world – they will have another holiday next year.
Contrast this with the other forty-six or so weeks of the year that a person is working on a project. You are asking them for half their waking hours, a chunk of their life, months or even years. Their reputation, a slot on their CV. Their need for achievement and learning. A career move. Their pride and self esteem. And how much effort is put into thinking about what the experience of being on the project will be like for them? Usually, it’s down to salary.
Companies accustomed to delivering projects successfully were more likely to have considered the ‘Project Experience’ from the point of view of the team members.
Consider the Project Experience from a team members’ point of view.
The Right Sort of Team
We often hear people saying that they need better teamwork on a project. Very often, this is followed by some sort of a ‘Team-building’ exercise.
Good teamwork on a project is clearly important. Regardless of how good the individuals are in a team, if they can’t work together for a common goal, the performance of the project is likely to be jeopardised. Despite the obvious need for teamwork, the type of team you build for each phase of a project can make a vast difference in how much benefit it delivers.
A strong team is not necessarily good. We encountered a number of examples where great effort was taken to build a team, only to find that the team had aligned itself around goals other than those of the project.
If you really want to see spectacular teamwork, try this secret formula: First, find the lowest common denominator in the group of people you want to meld into a team. The basic drivers are always the best – greed, fear, power are the easy ones. A common enemy is always useful. Start some rituals and customs that only the group know about. Consider some sort of uniform or dress code. Put them through a stressful situation together and make sure they have a chance to celebrate together afterwards. Before long you will have a strong team and you will be able to say you have good teamwork on your project.
So what happens when they start to associate stress with the customer or users. Could the customer become ‘the common enemy’? How easy will it be to integrate new members? What happens when the project starts to come to an end? Will the team be happy to be disbanded or will they wish that they could stay together longer? How will that affect your schedule?
Design the team before you build it.
Making experience count
A common response to project under-performance is to bring in some more ‘good people’. This is often an expensive option, but people with the right sort of experience and good management skills can greatly enhance the incumbent team and give it the ‘lift’ it needs to deliver success.
We found many examples where this strategy had been used with good results. But we also found a significant number where the same strategy had created the opposite result. We set about discovering the dynamic that decided the outcome.
‘Personality conflict’ was often cited when these new people failed to have the desired effect. Others quite rightly noted the possibility that Belbin’s Apollo Syndrome was the cause. But this could not explain away the dysfunction created by the interaction of people with such diverse backgrounds.
We looked at how some of these people were applying their experience.
There is a well-known model that describes how people go through the learning process. They start by not knowing what they don’t know (unconsciously incompetent), through knowing what they don’t know (consciously competent) to the point where they have learned what they need to know (consciously competent). In project management terms, at this stage they are following rules – either external or intrinsic. Managing by the rulebook.
The last stage of learning is when you have learned things so well that you become unconscious of your competence. Some refer to this as Mastery. You are managing beyond the rulebook using both instinct and intuition.
Being able to ‘managing beyond the rulebook’ is a desirable attribute for any project team member. In simple situations, where the team trusts a member to make quick decisions – shooting from the hip – the skill is invaluable. But what happens in a complex situation or where decisions need to be made collaboratively?
What we suspect happens is that experienced people will tend to see similarities between a situation and similar episodes in their past. They will recognise certain patterns and choose to ignore factors present in the situation that they do not recognise or which do not seem to be important. Others will do the same but see different patterns that are familiar to them and attach different levels of importance to peripheral factors. Hence, differently experienced managers will interpret a situation very differently and wonder how others can possibly come to different conclusions to themselves. Conflict ensues, power is exerted and the familiar phrase ‘I told you so’ is made ready to fly.
Experienced people will work well together if sufficient attention is paid to understanding how their personal experience maps to each specific problem. Kevin Potts and myself have worked on ways of ‘reverse engineering’ experience using common frameworks, shared language and mental models.
Encourage your ‘Masters’ to manage their experience.