While it's interesting that team members have different interests and hobbies, this isn't likely to affect anything you're doing on the project. Nor is the fact that their salaries might come out of different cost centers. You probably will never know this fact, nor care. However, the fact that people bring diverse skill sets to the team has a very dramatic effect on the way the team is shaped and works. You have to manage to the team's makeup. Also, if some members are geographically separated from the rest, this presents challenges that you'll have to manage.
People, not equipment or code, are the most important thing your project team has going for itself. Clearly, this individual came to the team with some sort of issue. It's important that you work with him, not because he©s mission-critical to the project, but because he has issues that you might be able to help him with so he can enjoy his time working on the project just like everyone else. It's important that he knows his importance to the team and the project as well.
This team member has demonstrated that she©s able to handle the level of work you've given her and can produce quality output. Now she's begun to slack off. The problem could be that she©s been working too much overtime or that she's lost energy for the project. It's up to you to figure out what's bothering her, then see if you can fix it and get her back on track. You should never bring up that others are asking about her (even if they are). You also shouldn't resort to ordering someone to do something. Telling her to increase her productivity is going to result in exactly the opposite effect. She's able to do the work, an assistant isn't required—getting at the heart of the issue is what's needed.
When giving a team member performance feedback, it's important that there's some "face time" with you or a designated team lead. Impersonal methods such as an intranet site, e-mail, or a conference call, while communicating the information, don't tell the whole story.
A quality turnover also includes making sure the add-ons the deliverables may require are in place (and have been well thought out). Dor example, it' s important to have good end-user documentation in place so users know how to operate the system. Also, you should have your training methodology in place and operational at deployment time. Your help-desk and support staff should be trained and in place.
Some project elements may not lend themselves to testing at the central site (servers put in place at remote sites, for example). But the building and testing criteria you use should be universal so you' re assured of level quality throughout the project. Even though the telecommuting developers may have tested their code, it would be good to make a second pass and evaluate their incoming code before putting it with other complete modules.
It' s not altogether important that you get all of your gear from one vendor. While this has support implications for the servers, it won 't matter much relative to the installations you' re doing. On the other hand, settling on a given manufacturer and making sure all the gear is from that manufacturer may go a long way toward making sure the installations are uniform and of good quality. Dor example, you may have an item in your burn doc that requires that the BIOS for each computer be upgraded to the latest version before the NOS is installed. If you ' re working with different server manufacturers, then you have to worry about each manufacturer' s implementation of BIOS updates. A standardized burn doc is mandatory—one standard burn doc for each type of server you' re burning.
It' s important, especially with a large team, to set up standards by which you ll communicate and work. These may include such elements as using a project intranet site, standard performance reviews, and uniform hardware burn documents. The holidays are usually regulated by the company' s calendar and, truthfully, may not affect the work your team members are doing, especially if they' re under a deadline crunch. Ditto for overtime standards.
Situations like this are difficult because you can' t simply take at face value what another team member is telling you. You 've got to find out for yourself, then make a decision about how to handle it. You should never tell a team member that someone else said something about them. The advice and counsel should come from your observation of the situation.
Asking team members to work overtime on a project that ' s behind schedule is a big deal. It impacts lots of lives besides the team members ' own (families, second jobs, etc.). It ' s important that you show your support by being there with them as much as possible, by showing sensitivity to individual team members needs, and by motivating and rewarding team members.
Calling the activity "cliquish" or accusing folks of being involved in cliques won' t make them stop doing so. What you have to do is to try to get the team to work together in a collective effort. You could use phrases such as, "We need to think not only about our team partners, but also about all others on the team," to get team members to realize in a roundabout way what you ' re driving at. But you shouldn' t point fingers. And you should always reinforce the project ' s goals— the reason the team exists in the first place.
You 've already taken into account the ethnic culture and education of your team members by simply being aware of their knowledge, skills, and abilities and knowing them as people. The bonuses you collect from a successful project shouldn' t affect your leadership style. But the corporate culture—how the company looks at successful teams and what' s expected of team members—might have a large affect on how you do your job.
A project manager is a manager, a leader. As such, the project manager is expected to perform in a way that s what you' d expect from a leadership role. PMs should be able to adapt their leadership style to a situation or person in order to best manage the situation. A PM should be someone who can influence and motivate others in order to accomplish the requirements of the project. A PM should be relationship oriented, able to build good relationships, and accepted as a leader both personally and positionally.
Negotiation is the key word in this question, but it s a matter of negotiating with stakeholders and sponsors which tasks can be adjusted so as to produce an improved project outcome.
Teams that are moving apart or pulling from different directions are asking for leadership from you. You can begin by putting together teambuilding exercises. These can be anywhere from very simple things like helping a team member brainstorm regarding a problem he ' s having, to full classroom-style sessions or "extracurricular" activities. You should also reiterate the project goals and in every way possible try to motivate team members. P
Balancing team members' needs with the elements of the project can be difficult. You want to meet people' s needs, but
you also have a project to get out the door. You should assess what kind of impact the need will have on the tasks associated with this person, and decide how the project's scope, budget, quality, and schedule are affected. Then make a decision accordingly.
Petermining the constraint that stakeholders think is driving the project will help you determine the kinds of trade-offs or alternatives you can propose to lessen the affect of the proposed scope change.
You might have to talk to the janitors if a trash can isn't being emptied out each night, but you'll likely not negotiate some aspect of the project with them. Unless your project is very high-level, or your company very small, it's doubtful that your CEO will get involved in your project. Everyone else here is a potential contributor to deciding how your project gets done.
System testing involves the thorough testing of the entire system before users are allowed to test it in the user acceptance testing phase.
By standardizing on the way you do a common thing (such as server burns), you create an environment in which everyone involved knows what to expect. Likewise, keeping certain processes (such as code development) in a centralized locale creates a simplified process.
Was this article helpful?