Managing Client Expectations
Posted by Brad Egeland
Somehow clients always seem to expect more than we are prepared to deliver. This expectation gap is more the result of a failure to communicate than it is of anything else, and this lack of communication starts at the beginning of a project and extends all the way to the end. This definitely does not have to be the case. It is the project manager’s job to utilize effective and efficient communication to sort out customers needs and to appropriately set customer expectations and team expectations early in the project to ensure the end goals are correct and attainable. If the end goals are blurry or not specified, then they will never be attainable.
Sorting Wants versus Needs
The root cause of many problems that come up in the course of a project originate in a disconnect between what the client says they want and what they really need. The disconnect may come about because the client is swept up in a euphoria over the technology and is so enamored with what they see for potential technologies and solutions that they have convinced themselves they have to have it without any further thought of exactly what it is they really need.
The disconnect can also come about because the client does not really know what they need. It is the job of the project manager and team to ask the right questions and extract the needs out from behind the wants. If there is any reason to believe that what the client says they want is different from what they need, the project manager has the responsibility of sifting and sorting this out ASAP. It would be a mistake to proceed without having the assurance that wants and needs are in alignment. You don’t want to start the project not knowing that the solution is in fact what will satisfy the client. The project Statement of Work, or SOW, developed early in the discussion phases of the project will begin to lay this foundation for the project team but may not fully sort out the customer needs from wants.
Problems with listening and communication
If I had to pick one area where most projects run into trouble, I would pick the very beginning. For some reason, people have a difficult time understanding what they are saying to one another. How often do you find yourself thinking about what you are going to say while the other party is talking? If you are going to be a successful project manager, you must stop and listen. Proactive thinking and planning is great – but not at the expense of hearing what the customer is expressing early in the project planning process. An essential skill that project managers need to cultivate is good listening skills.
Handling Interpersonal Relationships on the Project Team
Posted by Brad Egeland
Friction exists in almost any interaction between human beings. There may be misunderstandings, conflicts, personality clashes, or petty jealousies. Project managers must be prepared to deal with all of these. In fact, if you dislike having to deal with the behavioral problems that arise on project teams, you should ask yourself whether you really want to manage projects at all. It’s a given that this will be part of the project manager’s responsibilities, just as it really is with any management role. Like it or not, the behavioral problems come with the job, and failure to deal with them may sink a project.
Many personality clashes are the result of a lack of good interpersonal skills. People have never been taught how to sit down and work out differences with others, so when the inevitable conflict happens, it just blows up. The best way to minimize the impact of such problems is to provide training for all team members (including yourself) in interpersonal skills. This area has been sorely neglected in many organizations because there seems to be no bottom-line impact. It is hard to prove that there will be a $10 return on a $1 training investment.
Because of their inability to quantify the benefits, companies don’t do the training. Yet if they have capital resources that don’t work well, they will spend whatever is necessary to correct the problem. Interestingly, a company’s human resources are the only ones that are renewable almost indefinitely, but companies fail to take steps to keep them functioning effectively. As a project manager, you owe it to yourself to manage this aspect of the job.
Understanding Project Team Roles and Responsibilities
Posted by Brad Egeland
Once the team’s goals and mission have been established, the project team members’ roles must be clearly defined. What is expected of each individual, and by when? One common problem is that team leaders think they communicate information on goals and roles clearly to team members, yet team members remain fuzzy on these critical areas. Communication, communication, communication. Have I stressed this before?
The problem is that we fail to solicit feedback from team members to be really sure that they understand their roles and responsibilities. To compound the problem further, team members themselves are sometimes reluctant to admit that they don’t understand. This reluctance appears to be a result of our tendency in school to put people down for asking “stupid” questions. So, as adults, rather than admit that they don’t understand, people interpret what they have been told and try to do the best job that they can with what they think they know.
Project managers must establish a climate of open communication with the team, a climate in which no one feels too intimidated to speak up. The best way to do this is to comment on the problem: “I know some of you may feel reluctant to speak up and say you don’t understand, but we can’t operate that way. Please feel free to be candid. If you don’t understand, say so.” Team members must be clear on the fact that if they don’t agree with something or don’t understand an assignment or task, it is critical that they speak up. It is your only hope for success. You’re lucky to have the time to do the job once. It’s not likely that you’ll have the time – or budget – to do it over again without severe impact to the project and customer satisfaction.
How stable is your stakeholder base?
Posted by Elizabeth
What would happen if someone new came on board tomorrow? Not necessarily a project team member, but a new executive?
It’s not that unusual. Stakeholders at executive level change frequently. From time to time the board will move responsibilities for certain initiatives around between themselves. You might find that your project is now the responsibility of the marketing director instead of the sales director. Or that something previously sponsored by finance is now sitting with the VP of Product Development.
Executive stakeholders can also change due to redundancy or through the post holder finding a new career opportunity. On a long project, you should expect a certain degree of change. And the more senior the stakeholder, the less notice you will get about the change. Read more »
Documenting the Project at Closeout Time
Posted by Brad Egeland
Documentation always seems to be the most difficult part of the project to complete. There is little glamour and no major kudos in doing documentation. That does not diminish its importance, however. There are at least five reasons why the project manager and team need to do documentation on the project:
Reference for future changes in deliverables. Even though the project work is complete, there may be further changes that warrant follow-up projects. By using the deliverables, the customer may identify improvement opportunities, features to be added, and functions to be modified. The documentation of the project just completed is the foundation for the follow-up projects.
Historical record for estimating duration and cost on future projects, activities, and tasks. Completed projects are a great source of information for future projects, but only if data and other documentation from them is archived so that it can be retrieved and used. Estimated and actual duration and cost for each activity on completed projects are particularly valuable for estimating these variables on future projects.
Training resource for new project managers. History is a great teacher, and nowhere is that more significant than on completed projects. Such items as how the WBS architecture was determined, how change requests were analyzed and decisions reached, problem identification, analysis and resolution situations, and a variety of other experiences are invaluable lessons for the newly appointed project manager.
Input for further training and development of the project team. As a reference, project documentation can help the project team deal with situations that arise in the current project. How a similar problem or change request was handled in the past is an excellent example.
