Project Management Software
Specialists in Project Infrastructure
I mentioned there was a difference between a project team and a departmental role. Here area a few of those differences:
A project environment is usually:
The Usual Problems
It is not hard to see the sorts of problems that are likely to arise.
Setting up the Team
The starting point for a project team member should be no different to the starting point for a new employee. Most organisations have some sort of induction program for new employees even if it is only sitting with the person they are replacing for a few days.
A project should be no different. How the person is integrated into the team will have a significant impact on how they see themselves in relation to the team. If they are put in a corner and asked to design a database, they will not feel committed to the team. If they are introduced to all the team, given a full briefing on the project, work with a number of people to understand the purpose of the project, they will be more committed. Not only that, they will have a better context to design their database. They will be more likely to ask questions. In short, they will do a better job.
Roles and Responsibilities
Defining roles and responsibilities is critical where people are in a new environment. Basically you take all the work and divide it up amongst various people. It solves two problems:
Once defined, they need to be discussed with the team, and adjusted if necessary. Preparing a document and emailing it to team members does not provide understanding. It needs to be talked through. As the project progresses, they should be re-visited to ensure they are still current.
What is the outcome you are trying to achieve with this project? How will the organisation be different when the work is successfully completed? Just because you understand it, does not mean the team does. Get the sponsor to talk to the team about why the project is being undertaken and how it will change the organisation.
One project I was involved in was in the hundreds of millions of dollars. I asked the sponsor to brief the major participants in the project about the outcome. He was reluctant and finally I badgered him into spending an hour with the team. These were his words.
“I had been through all this at our annual planning exercise so I saw it as being a waste of time. All I wanted to do was get through it as quickly as possible and get on a plane out of there.
About 15 minutes into the presentation I noticed a lot of talking going on and thought they were loosing interest. I though, “Great! I can make it even shorter.”
Then I started to hear comments like “That’s what he meant when he was talking about …..” and “Now I see what he has been trying to do”
Frankly I was amazed. Why had they not seen where I was trying to take the organisation? It was in the corporate plan.”
Eventually the discussion went 3 hours. He cancelled his flight and stayed overnight continuing in the morning in a more broad ranging discussion on the views of his executive team. He told me afterwards it was the most important meeting he had attending in two years. For the first time his Executive Team had a chance to see his vision, and they had a chance to add their views. They all said the annual planning exercise was primarily “fill in the template” and argue for your departmental budget. During this workshop they talked themselves into the same direction.
That taught me a lot about having an interactive session with the team to discuss the outcome. In fact I tend to do it regularly to ensure we are all still pointed in the same direction. In the heat of a project, it is easy to loose direction.
My tendency is to throw out the corporate rulebook for working conditions. It is inevitable that people will be asked to go the extra yard. There needs to be a balance in how the organisation rewards them. For this reason, I suggest that there is flexibility in working hours.
Some people like to start early and finish late. Others are the opposite. As long as it does not adversely impact the project, I encourage them to work their own hours. If working from home makes sense, let people do it.
On one project, there was a period when people were working weekends. As they were not being paid for it, and were not given time in lieu, some people were working 7 days straight and often more. I introduced a planning day. I would nominate particular people to do some planning – from home for a day.
I never actually asked for any deliverables. When someone tried to find them, I would say they were on a planning day. For months we got away with it. People were given an unofficial day off and it not only gave them some time to catch up with the rest of their lives. It was a secret that helped bond the team. Often being part of a secret brings people together.
Being appreciated helps maintain your enthusiasm. Get the sponsor to go out of his or her way to congratulate people. Something as simple as tickets to a movie for the family, or a taxi voucher to get home late at night makes people feel valued.
The pressure and stress of a project does not stop when you walk out the corporate door. It spills over at home – particularly if you are not there much of the time. Telling your partner how important your work is, is another way of saying “Spending time at work is more important than spending time with you.” Do something for the family be it a “planning day”, picking up the bill for a visit to a restaurant, or even a letter from the Sponsor thanking the partner for their patience during the project.
Problems are bound to arise that are unable to be resolved within the team. They might require a level of authority beyond that mandated to the team. It may be that the solution causes two solutions to be put forward that are equally supported.
The situation should be foreseen and a plan put in place to address the problem.
It is sort of like a disaster recovery plan. A DR plan is created because, in the heat of the moment, nobody wants to decide all the things that need to be done. It is better to have a plan or process to follow rather than have to both invent and implement a plan. So with escalation. Developing a plan for escalation means there is a clear expectation set that if something cannot be resolved, we will react in this manner.
An escalation process has two clear benefits:
I once ran a project where one junior business member was an excellent documenter. She was not recruited for that skill, but she was good at it, and what’s more, loved doing it. We re-wrote the roles and responsibilities to ensure she was responsible for all documentation.
We could have said that she was responsible for contributing to the requirements and not used her documentation skills, but it was far more productive to let her do what she liked to do. Others hated documentation. They could now get on with doing extra work in providing requirements to cover her role.
The lesson is to look for skills people have, and exploit those skills. Just because they have a particular role, does not mean it cannot change to utilise their strengths. On the other side of the coin, it might change to avoid their weaknesses.
You need to seek out the strengths in people. On another occasion I was running a big data cleansing project for an insurance company. I had about 50 temps working for me. Many were back packers traveling in Australia and looking for a few months work. One girl came to me and suggested that part of the process could be speeded up if they had a spreadsheet to do some complex calculations. She started to explain the concept in terms that indicated she knew what she was talking about.
I stopped her and asked her what her background was. She told me she had just graduated from Oxford with honours in Computer Science. When I asked her how long to develop the spreadsheet she told me 2 to 3 days to develop, test and deploy. I gave her a laptop and sent her away for a few days. When she returned, she became our trainer, and the spreadsheet saved us months of work. We even gave her a raise. Not bad for a back packer.
I have always liked the concept of starting the week with a team meeting that everyone must attend. Usually I start with an overview of progress then go around the table getting everyone to discuss what they have planned for the week. It achieves a number of things:
I always try to keep it light. A bit of chat about the weekend and personal issues makes it seem like we are a group of individuals rather than robotic zombies. It is also useful to buy some coffees or snacks.
One thing I do avoid is to get everyone in early to have the meeting. If 8:30 is the normal start time in the organisation, that is when the meeting starts. If you call everyone in at 7:30 it sets the scene as being yet another overhead. Yet another task above and beyond the call of duty. The whole mood of the meeting is one of stress and formality rather than one they look forward to.
Another must do is to have an agenda, and minutes. If you create action items, make sure they are documented in the minutes. Make sure there is an agenda item to review action items so people don’t forget about it. Also make sure the agenda goes out Friday morning so that people have time to complete the action items they forgot about. Similarly the minutes need to go out on Monday afternoon.
They are bound to happen. Hopefully the steps above will avoid many of the conflicts. When they do happen, there are a number of ways to resolve them. Here are a few techniques:
This topic is endless. In fact there may be a part 2 in the near future. There is no single way for a project manager to manage people. Trying to learn the right way is a waste of time. What you need is a collection of techniques and tricks to use, and the wisdom to know which one to use when. The project manager with only one solution will soon hit the wall.
Each solution needs to be evaluated within the corporate environment and within the context of the project. If there is one overriding thing to remember it is this. You are dealing with people, not machines. People are unpredictable, influenced by things completely outside your control, and come with their own agenda. You need to be patient with them and get to know why they are as they are. Only then can you hope to guide them to achieve the goals of the project.