Practical Project Management – Tips and Techniques – Part 2

February 21, 2006

The shift from team member to team leader is a difficult step. The right approach can turn project management into a “win-win” situation for you, your team and the client.

Even people with years of experience managing people and projects refer to project management as a “no-win” situation: Either the project team resents you for driving them too hard, or the client or end-user is dissatisfied because the project is late, too expensive and/or does not meet the requirements. Fortunately, there are ways to overcome this dilemma.

The first article in this two-part series on project management provided some tips and techniques about the more “concrete” areas of project management–scope, timelines and deliverables. These are the areas of project management that we tend to be good at as engineers. This article will discuss the areas of project management that require softer skills and we are often accused of having trouble with–communications and managing people.

Communicate, communicate, communicate
Documentation of meetings, agreements, progress reports, issues and achievements is vital. Write everything down, date it and distribute it widely. In other words: Publish or perish. One of Murphy’s laws is that “what is not written was not said.” The longer the project, the truer this is, because people will change roles and forget what was said earlier. Don’t be caught without a paper trail.

Similarly, it is vital to communicate the status of the project regularly through meetings and reports. I copy everyone even slightly involved on the status of the project at least once every two weeks. Since it is clearly labelled as a status report at the top, they can choose whether to ignore or read it. A status report should start with the issues that need action, and not be more than two pages.

Avoid wasting people’s time
One of the problems in communicating the status of the project is the confusion between status meetings and problem resolution meetings. While working on other people’s projects, you may have been invited to a status meeting only to find yourself trapped in an hour long discussion of a technical or user requirement issue on which you have no interest or expertise.
A status meeting is just that–to communicate the status and issues. Other issues should be resolved separately. It’s best to hold half-hour status meetings, but ask people to block one full hour in their calendars. After the first half-hour, people can leave who are not required to focus on the second half–issue management and resolution.

The frequency of status meetings depends on how fast the project is changing. If the status is changing slowly, meetings every two weeks are acceptable. If things are changing more quickly, weekly meetings become necessary. Often during testing or the final days of development, I have a 15 minute ‘stand-up’ meeting (no chairs allowed, time limit strictly enforced) to review status and assign staff to eliminate roadblocks. This type of meeting only works over a short period of time, and if the status is changing rapidly and the deadline for delivery is looming.

Be clear
Although whole books have been written on the correct style of communications, it all boils down to making sure the people you communicate with understand what you are saying and that you understand them. If your client is not a technical professional, don’t confuse him or her with jargon, acronyms and techno-speak. Use examples and metaphors to illustrate your point. Use acronyms sparingly and spell them out before using them in every memo. Learn your client’s jargon and use it. Run the spell and grammar check functions of your word processing software before you send documents out.

Remember: Change costs
The final communications issue is dealing with the cost of changes. Every project of any significance will require changes in scope at some point. The most important thing a project manager can communicate on this issue is that every change costs. Whether you are using internal resources or consultants for your project, every change will have a cost associated with it. Having changes in scope along the way is not a bad thing, as long as the people requesting them understand the impact and are willing to live with the consequences.

Delegation: The key to survival
One of the most difficult lessons I had to learn was that you cannot manage a project and be an individual contributor at the same time. On the first software development project where I had a leadership role, I kept one of the most complex software components for myself. Guess which part was late? I spent so much time reviewing work, making sure that every one else was on time and meeting the specifications, that I did not have any time to actually design or code my component.

My own rule of thumb is that each person on your team will require between 10 per cent and 20 per cent of your time in management overhead. So, if you have a team of five people, you will not have time to do any “real” work yourself. If your team is larger than 10 people, you will need other project leaders to help you.

There are three stages of delegation. When you are first responsible for other people’s work, you hold onto every important task and delegate nothing of consequence. When you realize that this does not work, you enter the second stage, the “long bomb,” where you delegate everything and never check on progress until the work is overdue. In the final, mature stage, you both delegate and monitor activities.

Track progress
Tracking your team’s action items is vitally important. Keep meeting minutes that are focused on the decisions reached, and the action items received by each person. Distribute them to everyone who attended the meeting and to whom a task was delegated. I recently sat in on a meeting for a project where action items were assigned to people who were not there, minutes were not taken, and no one told the people who were absent of their new tasks! No wonder the project was late and over budget–no one knew that they had something to do until after the deadline had passed.

Provide feedback to the team quickly on the quality of work. If you care enough to review the work, the team will care enough to do good work. If the work is substandard, let them know what the standard is. Set the bar early. Review work promptly, as soon as it is ready for you to see. Do not wait until it is ready for the client to see. The longer you wait, the harder and more costly it will be to go back and redo the work. You should also review work at every stage.

Celebrate success
Particularly when managing a long project, it’s important to celebrate success along the way. Milestones, deadlines met or a particularly hard bug found are good reasons to buy the team lunch or to get together after work. Celebrate the completion of the project too. Try to invite not just the team, but anyone who worked even briefly with you to reach the goals.

Make sure that the team knows why they are together. I always try to get the best team available, and I let them know it. Any time I am starting a project, I interview every potential team member that I don’t already know to ensure that they are appropriate for the job. You are balancing what the team can learn versus the experience needed, the drive to get it done versus the ability to work in a team, and many other factors. Regardless, the team is together either because they are the best team the organization can assemble for the job, or you have faith that they can become the best team for the job.

Include yourself as a member of the team. Let them know that you have faith that “our team” can accomplish the task set before “us.” Pride and confidence are contagious. So is their absence.

Heap praise on team members publicly. When necessary, criticize them privately. Take the heat from project sponsors or clients yourself. You will be surprised how well your team responds to courtesy.

Communication: You can’t have too much
If I could sum up my advice to project managers in one word, it would be “communicate,” or perhaps, “over-communicate.” Project management is primarily a communications task. Understand what your team is doing, and ensure that it meets the needs of the organization. Understand the needs of the client, and ensure that your team is meeting those requirements.

Project management does not need to be a no-win situation. If you follow these suggestions and add some common sense, you stand a good chance of being successful–or at least surviving. You may even find that you enjoy it.

Steps to managing your team effectively