Developing Your Team

Acquiring a Team Is Not the Same as Building One

Putting the right people on a project does not automatically produce a team. It produces a group of individuals who happen to share a project and a deadline. The difference between that group and a functioning team is not time. It is deliberate effort. Development is what turns individuals into a unit, and it should start before major delivery pressure arrives. It does not end there. Development must continue whenever the team changes, conflict surfaces, or the work exposes gaps in how people are operating together. Most project managers do the acquisition work and assume the development will take care of itself. It does not, and the cost of that assumption usually appears when the pressure is highest and there is no time left to address it.

The Team Charter — Built, Not Handed

A project charter authorizes the project and defines its mandate. It is handed to the team. A team charter explains how the team will operate together, and it must be built by the team. That distinction is not procedural. A document people helped create is one they feel responsible for. A document handed down from above is one they feel comfortable ignoring when the pressure is on. The team charter's value comes entirely from the ownership it generates, which means a charter distributed for signatures without real team revision has already failed at its primary purpose. A PM may draft a starting point, but the team must revise it in substance before it owns it.

The sections of a team charter follow a consistent pattern: a mission statement, roles and responsibilities, working agreements, decision-making and escalation rights, quality expectations, and change control protocols. Each section does a different job, and the weakest version of each one is the version written at the level of generality that could apply to any project.

Mission — Not the Scope Statement

The most common mistake in the mission section is copying language from the project scope or business case. Those are project objectives. The team mission answers a different question: why does this specific team exist, and what is the team's operational role while it executes the work? The RtR project team charter captures this distinction clearly. Where the project objective is about growing commercial revenue through a better location, the team mission is about coordination and execution: protecting business continuity, managing project risks, coordinating internal and external resources, and preparing the new location for operational readiness. Same project, entirely different framing. The mission describes what the team does, not what the project is for. A team that has articulated its own answer to that question has something to return to when things get tense, when conflict flares, when someone is tempted to take a shortcut.

Working Agreements That Hold Under Pressure

Working agreements turn expectations into visible, referenceable rules, and visible rules matter precisely when expectations break down. The most common failure in this section is writing at the level of vague intention. "Team members will communicate openly." That sentence helps no one. A useful working agreement is specific enough to reference in a real conversation when something has gone wrong. In the RtR charter, working agreements read like this: every action item carries one owner and one due date, with a status reported at every core team meeting. Blocked work gets raised before the next meeting, not at it. No informal commitments are made to vendors, contractors, or clients that touch scope, cost, or schedule. Each of those can be tested. "Will communicate openly" cannot.

Decision Rights and the Escalation Threshold

The section teams most often skip is the one they most regret skipping: decision-making and escalation. Who decides what, and at what point does a decision go upward? Most project managers assume this is obvious from the org chart or the role descriptions. It is not. A coordinator may believe they can approve a field change. The PM may believe the same change requires her review. Without a written escalation threshold, both are acting in good faith and creating chaos. In the RtR charter, the threshold is explicit: routine coordination stays with the PM, and anything affecting approved scope, schedule, budget, or vendor commitments escalates to her. That line is specific enough that when a question arises mid-project, the answer is in the document rather than in a conversation that nobody remembers clearly.

Quality and Change Control

The quality section of a team charter should name specific acceptance conditions for what this project delivers, not restate a commitment to general quality standards. In the RtR charter, quality does not mean "deliverables will meet standards." It means utilities are confirmed, internet and phone systems are tested, computers are configured, signage is installed, customer-facing areas are accessible, vehicle access is cleared, and vendor work is complete. Those are the conditions that define done for a business relocation. The change control language pairs with it: work does not proceed on out-of-scope requests without documented approval. Informal requests from vendors, staff, or stakeholders are captured and assessed before anyone acts on them. That discipline matters most when the pressure to improvise is highest, particularly when a vendor is on-site asking for a decision, or when a stakeholder makes a commitment the team is now expected to honor.

The RtR Charter in Practice

The sections described above are easier to understand when you see what specific language looks like in practice. The following is a condensed version of the RtR project team charter. Each entry is concrete enough to reference in a real conversation when something goes wrong.

The Test of Specificity

A strong team charter has one quality that shows up in every section: it cannot be copy-pasted onto a different project without rewriting it. The mission references this team's operational role on this project. The roles call out specific people and specific lanes. The quality section lists acceptance conditions for this deliverable, not a standard that could apply to anything. If you can substitute a different project name at the top and have every section still make sense, you have written a template. The charter earns its place in execution when it is specific enough that the team can open it during a difficult conversation and find a fair reference point, not a paragraph that means whatever each party needs it to mean.

Your Most Powerful Resource

Equipment follows specifications. Materials behave predictably. Software does what it is programmed to do. Your team is the only resource with the capacity to surprise you, to find a better approach than the one the plan described, to solve a problem that was not anticipated, to carry the project through conditions the schedule did not account for. That potential is real. But it only becomes available when the team feels clear about what they are doing, connected to each other, and supported by a PM who invested in building the conditions for it. Developing your team is not a soft activity alongside the real work. It is the real work, and everything else in execution depends on it.

What's Next

The next chapter, Motivation, Team Formation, and Managing Performance, goes deeper into what actually drives people to do their best work, how teams move through the predictable stages of formation, and what the PM does when individual performance falls short of what the project needs.

Reflect

• In your current or most recent project, how was the team charter created? Did the team build it together, or did someone fill it in and distribute it for acknowledgment?
• Look at your working agreements, if you have them. Are they specific enough to use in a real conversation when something goes wrong, or are they stated at the level of good intention?
• Where in your project is the escalation threshold defined? Would every team member give the same answer if asked what kinds of decisions require PM involvement?
• Think of a team member who is technically capable but not fully engaged with the team's working agreements. What is actually driving that disengagement, and what would it take to close that gap the way the PM in the scenario did?