Leading the Project Team and Resolving Conflict

Leading a project team means getting people who may not report to you to work well together toward the project's goal. Most project managers have little formal authority: the developers, engineers or analysts belong to other departments. So you lead with clarity, fairness, good habits and the trust you build, not with rank. In this lesson you'll follow a project manager running an ERP rollout at a manufacturer in Michigan, through a rough start, an overloaded analyst and a heated disagreement about data migration.

1. Read the team's stage
2. Agree on how to work
3. Balance the workload
4. Resolve conflict
5. Protect focus

The team

Dana Whitfield is the PM for a new ERP system (the software that runs orders, inventory and accounting) at a 300-employee furniture manufacturer in Grand Rapids, Michigan. Her team has nine people: two from IT, two from finance, a warehouse supervisor, a production planner, a data analyst and two consultants from the software vendor. None of them report to her, and all of them still have their day jobs.

Step 1: know the stages of team development

Psychologist Bruce Tuckman's model describes how most teams evolve. The stages aren't always neat, and a team can slide back (a new member often triggers a mini-forming), but the model tells you what kind of help the team needs right now:

1. FormingPolite and unsurePeople are friendly but cautious, and unclear about roles. You: give direction, explain the goal, define roles, set up the basics.
2. StormingFriction surfacesDisagreements about approach, priorities and turf. Normal and even useful. You: bring conflict into the open and resolve it fairly.
3. NormingAgreements settleThe team finds its rhythm and working agreements stick. You: coach, reinforce good habits, step back from details.
4. PerformingHigh outputThe team solves its own problems. You: remove obstacles, shield the team from distractions, delegate.
5. AdjourningWrapping upThe project ends and people move on. You: recognize contributions, capture lessons, help people transition.

Dana's team hit storming in week 3: finance wanted to customize the ERP to match its current reports, while IT and the vendor pushed to adopt the software's standard processes. That fight wasn't a sign of a bad team. It was the first real conversation about scope.

Step 2: write a team charter

A team charter (different from the project charter) records how the team will work together. Dana wrote it with the team in a 45-minute session, which matters more than the document itself: people follow agreements they helped make.

Step 3: balance the workload

The fastest way to lose a good team member is to overload them quietly. In week 6, the data analyst, Priya, was assigned three tasks at once:

Allocation = assigned hours ÷ available hours = (24 + 16 + 12) ÷ 40 = 52 ÷ 40 = 130%

And that's before her day job. Dana had three options, in order of preference:

1. Use float: test scripts weren't on the critical path, so they moved to week 7 (resource leveling within float costs nothing).
2. Reassign: one of the vendor consultants took part of the report mapping.
3. Negotiate with her manager: temporarily shift some of Priya's day-job work to a colleague.

Step 4: resolve conflict with the right approach

Conflict on projects is usually about priorities, schedules, resources, technical choices or, less often, personalities. There are five common approaches (PMI's names first, with the everyday equivalent):

Dana's data migration conflict

Mark (IT) wanted to migrate 10 years of order history into the new ERP. Luis (finance) wanted only open orders and two years of history, to go live faster. Instead of picking a winner, Dana used problem-solving: she asked each of them why. Mark's real need was that customer service could look up old orders. Luis's real need was hitting the January 1 go-live for the new fiscal year. The solution covered both: migrate two years into the ERP and keep the older history in a read-only archive that customer service can search. Neither got their original position; both got what they actually needed.

Step 5: protect the team's focus

Meetings are the most expensive thing nobody budgets for. Dana's weekly status meeting had nine people for one hour. At an average loaded rate of $70 an hour:

Before: 9 people × 1 hour × $70 = $630 a week × 50 weeks = $31,500 a year
After:  6 people × 0.5 hour × $70 = $210 a week × 50 weeks = $10,500 a year
Savings: $21,000 a year, and 3.5 hours a week back for the team

She cut it to 30 minutes with only the workstream leads, moved routine status into the project board, and sent written notes to everyone else. Here's how her team's habits changed over the next two months:

Remote and hybrid team members

• Default to written: decisions and status in the shared board, so nobody depends on hallway talk.
• Equal presence: if one person is remote, run the meeting as if everyone were.
• Mind time zones: rotate inconvenient meeting times instead of always penalizing the same people.
• Recognize in public: remote contributions are easy to miss; call them out in team channels and in front of the sponsor.

Common leadership mistakes

(a) 9 × 0.5 h × $65 = $292.50 a day × 5 = $1,462.50 a week
(b) 15 minutes: 9 × 0.25 × $65 × 5 = $731.25 a week
    Savings: ($1,462.50 − $731.25) × 48 = $35,100 a year

Summary

• Teams move through forming, storming, norming, performing and adjourning; adapt your leadership to the stage.
• A team charter written with the team sets working agreements for communication, meetings, decisions and conflict.
• Allocation = assigned hours ÷ available hours; fix anything above 100% by leveling within float, reassigning or negotiating.
• Choose the conflict approach for the situation: collaborate when it matters, direct for safety or emergencies.
• Meetings have a real cost; shorten them, shrink them and move routine status into writing.

Next lesson: Project Closure and Lessons Learned. You'll close a project properly: acceptance, contracts, final report, lessons learned and handover.