UPI Study › Courses › Project Management › Free lessons › Lesson 11.1 Free with a free account
Defining Goals and Objectives for Project Teams
Project Management · Chapter 11: Team Dynamics and Conflict ResolutionSection 11.1 · lesson 67 of 73video coming soon
← Post-Project Customer Evaluations and Implementation ReviewsNext lesson: Cross-Organizational Collaboration and Partnerships →
In this lesson
Turn broad goals into SMART team objectives and keep them alive.
- Distinguish a goal from an objective and test objectives with SMART criteria
- Trace team objectives upward to project objectives and downward to work
- Explain goal-setting theory, its conditions and its limits
- Describe a team charter, ground rules and decision rules, and track objectives openly
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (2,155 words). Read along, or search it.
Opening Question
Three Meanings of Stable on One Team
Dana has just taken over a five-person release team. On the office whiteboard are its aims: make the app more stable, ship soon, keep it fast. She asks three teammates what stable means, and gets three different answers. So here's the question: on any given Friday, how would this team know whether it's winning? Dana is a project manager at Meridian Clinic Network, a made-up clinic chain, and her team is releasing its new online booking app. The app must reach the app store in twelve weeks. The store's review time is outside her control, and testing time is short.
Key Distinction
Goals Give Direction, Objectives Are Checkable
Before rewriting anything, Dana separates two words that teams often blur: goal and objective. A goal is a broad statement of direction, with no specific amount or date. For example: become a team the clinics can rely on. It points somewhere worth going, but nobody could say on a given Friday whether it had been reached. An objective is a specific, measurable result that the team commits to reach by a stated time. For example: deliver every weekly status report to the sponsor by noon on Friday, for the next twelve weeks. A stranger could check that. A goal gives direction, and a reason to care. An objective makes that direction checkable. A team with only goals can't tell whether it's succeeding. A team with only objectives may hit every number, and still miss the point. The project's own objectives are already set, in the project charter and the scope statement. The team doesn't rewrite them. It turns its share into team objectives.
SMART Test
Rewriting a Vague Testing Objective
The most widely taught test for an objective is SMART: five properties, one letter each. Specific: it states exactly what is to be achieved, by whom, and for what. Measurable: a number, or an observable condition, settles whether it was met. Achievable: the people responsible have the skill, time, and resources to reach it. Relevant: it feeds something the project or sponsor actually needs. And time-bound: it names a date, or a period. Rosa leads testing. Her group of three has been told: do better at testing the new booking screens. Better might mean more tests, earlier tests, or fewer missed faults. No result could show it was met, and there's no date. Dana and Rosa rewrite it. By May fifteenth, the three-person test group runs all forty agreed acceptance tests on the booking screens, at least weekly. And every failed test is logged, then retested within two working days of its fix. Now it names who, what, and how often. The counts come straight from the test log, and the date is fixed. It's achievable if one full run takes well under a week for three people, and relevant because bookings must complete without help. The extra words are decisions the weak version left unmade. Making them now costs a short conversation. Leaving them costs an argument later.
Applying SMART
Turning Stable and Soon Into Targets
Dana runs the same test on her team's three aims. For stable, the crash log already records the share of sessions that end in a crash. Right now, it's four percent. The team agrees on two percent or lower, measured on the final test build, by release freeze. Halving it is demanding, but the main causes are known. Ship soon becomes a freeze date, set back from submission by the length of the store's review. Keeping it fast is harder. Nobody has agreed how speed would be measured, and Dana won't write a measure the team can't read from a record. So fast stays a goal, watched by eye rather than tracked. It's a trade-off she accepts openly. Notice what achievable means here. It rules out the impossible, not the demanding: a hard target, plus a step that can plausibly reach it.
Alignment
Tracing Objectives Up and Down
Good objectives can still pull in different directions. Alignment means every objective contributes to a specific objective one level up. And every piece of individual work contributes to a team objective. You check it by tracing. Upward: pick any task, and ask why it exists. The answer should name a team objective, and then a project objective. A task with no upward path is either wasted effort, or a sign that a project objective was never written. Downward: pick a project objective, and ask what work delivers it. If no team objective answers, nobody is responsible for it. Every box also needs an owner and a measure. An objective without an owner is a wish, and one without a measure can't be checked. Omar, the operations director, sponsors the app. He owns the project objective: ninety percent of test bookings complete without help. But alignment doesn't prove the team objectives are enough. Omar has to ask: if every team measure were met, would the project measure be true?
Quick Check
Forty Days of Work in Ten
Quick check, with a new case. By May first, a two-person data team will clean and load five million records. Their own estimate says the work needs forty working days, and ten working days remain. Which SMART test does this objective fail? Pause, and decide. Achievable. The people responsible don't have the time: forty days of work won't fit into ten. It is measurable, since loaded records can be counted, and it's time-bound, with a May first date. A date alone doesn't make a target reachable.
Goal-Setting Theory
Why Specific, Challenging Goals Help
Over coffee, Jun, the lead developer, asks why Dana pushed for such a hard target. Wouldn't do your best be kinder? Her answer comes from goal-setting theory, developed by Edwin Locke and Gary Latham over decades of research. Its central claim: specific, challenging goals tend to produce better performance than vague goals, like do your best, or easy ones. A specific goal tells people what to attend to. A challenging one calls for more effort, and keeps people going until it's reached. A vague goal supplies neither, because almost any result can be called good enough. The claim comes with conditions. First, commitment: a hard goal nobody has accepted does little. Second, feedback: people need to see how they're doing against the goal. Third, task complexity: on complex tasks, success depends on finding good methods, not just on effort. Fourth, ability and confidence: the goal must be within reach, and people must believe it is. Fifth, support: time, tools, and information. So challenging and achievable don't conflict. Achievable means possible with real effort, not already assured.
Theory Limits
Learning Goals, Crowding Out and Corner-Cutting
The theory is widely supported, but the research also finds limits, and they belong right next to the claim. On a new or complex task, a demanding number can pull attention away from learning. There, a learning goal helps more: master the method first. Second, goals can crowd out whatever isn't measured, like quality that no number captures, or helping colleagues. Third, demanding goals, especially with rewards attached, can encourage corner-cutting: shortcuts that raise the number, but damage what it doesn't show. So set few objectives, pair each outcome measure with a quality check, and discuss every goal with the people who'll carry it out.
Team Charter
Six Parts of a Team Charter
Commitment, feedback, and support are things a team can arrange for itself. That's the job of a team charter. A team charter is a short written agreement, made by the members themselves, stating why the team exists and how it will work together. It isn't the project charter. That one authorizes the project, and comes from the sponsor. The team charter works inside it, and never overrides it. It has six parts. Purpose: one or two sentences on what the team is for. Objectives: its SMART objectives, traced upward. Membership: who's on the team, what each person contributes, how much of their time is committed, and who leads. Working hours: when people are reachable, and across which time zones. Communication: which channel carries which kind of message. And escalation: the route for an issue the team can't settle. What triggers it, who receives it, and what the team does while it waits. An escalation route isn't an admission of failure. Without one, problems tend to sit. The test of a charter: could someone who joined last week say what the team is trying to do, and what to do when something goes wrong?
Ground Rules
Observable Standards for Everyday Behavior
Beside the charter sit ground rules: agreed standards of everyday behavior, written down so expectations are shared, not guessed. Good ones can be observed. Respect each other is a hope. Nobody is interrupted until they finish is something you can see. Four areas cover most needs. Meeting behavior: an agenda the day before, and a closing list of actions, each with an owner and a date. Response times: the longest a member waits before answering, often set separately for urgent and routine requests. Respectful disagreement: critique the idea, not the person. Give a reason, offer an alternative, and once it's decided, support it in public. And absences: how to give notice, who covers urgent work, and how the person catches up afterward.
Decision Rules
Consensus, Majority, Delegated or Leader Decides
Last, the team agrees how it will decide. A decision rule says who has the authority, and how the choice is reached. Agree it beforehand. Otherwise the argument about how to decide gets tangled up with the argument about what to decide. Consensus: talk until everyone can support the decision, or at least live with it. It suits choices that are hard to reverse. Its cost is time. Majority: the option backed by more than half wins. It suits moderate, reversible choices among equals. Its cost: a minority carries out what it opposed. Delegated: the team hands the call to the member with the knowledge, and agrees in advance to accept it. Its cost is weaker ownership. Leader decides: for urgent or confidential matters, or a deadlock. Its cost is weaker buy-in, and a leader who may decide blind. A senior engineer wants consensus on everything. Dana explains there isn't time, and the team settles on a mix. Consensus on what done means for a feature. Technical choices delegated to the engineer closest to them. Majority for scheduling. And the go or no-go goes to Dana. The cost is real: some members will sometimes be overruled. Dana writes the objectives and rules into a one-page charter, and sets a Friday check-in.
Tracking Progress
Visible Measures and Open Adjustments
An objective that's written and then forgotten has the same effect as no objective. Tracking keeps it alive, in three light parts. First, a simple, visible measure, taken from a record the team already keeps, like tests passed, and shown where everyone can see it. Rosa's group aims to pass forty acceptance tests in ten weeks. At the end of week six, twenty-six pass. Twenty-six divided by forty is sixty-five percent done. And the clock? Six weeks of ten is sixty percent. So they're five points ahead of the clock. That says roughly on track, not that the remaining tests are as easy as the ones passed. Second, a regular check-in: short, scheduled, and built on the visible measures, so problems are seen while they're small. Third, adjust openly when conditions change. Rosa learns that eight of the fourteen remaining tests need a screen the designers will deliver late. So they split the objective. The six runnable tests keep the original date, and the other eight get a new one, with the reason recorded. Adjusting because the world changed is good management. Quietly lowering a target because you're behind is not. The written reason separates the two. If the change touches a project objective, it goes through the project's change control. It's no longer a team decision. Visible progress is also feedback, a condition the theory names. But a measure directs attention to what it counts, so watch what it leaves out.
Quick Check
Members Skipping Meetings Without Notice
Quick check. Another team at Meridian meets weekly. Over several weeks, members skip meetings without telling anyone. Later, the others discover that decisions made without them have to be redone. Which ground rule was missing? Pause, and decide. A rule on absences. It says how to give notice, who covers, how an absent member hears what was decided, and whether a decision can wait for them. A response-time rule sets how fast messages get answers, and an agenda shapes the meeting itself. Neither says what happens when someone can't attend.
Case Resolved
A Shared Board Anyone Can Read
Back to Dana's release team, and the question from the start: how would they know, on a Friday, whether they're winning? Now the crash rate sits on a shared board, next to tests passed and days to freeze. Anyone, even a stranger, can read it. Speed is still a goal, watched by eye, and the charter says so honestly. And when a decision comes up, the team already knows who makes it.
Key Takeaways
From Goals to Tracked Objectives
To recap: a goal gives direction, and an objective gives a result a stranger could check. Write objectives to the SMART test, and trace each one up to the project, and down to the work. Put commitment, feedback, and support in place with a team charter, ground rules, and an agreed decision rule. And keep objectives alive with visible measures, regular check-ins, and openly recorded adjustments.
About Project Management at UPI Study
Project Management (Business 230) is a self-paced online course of 73 video lessons in 12 chapters, from starting and defining a project to planning, budgets, scheduling tools, proposals, contracts, execution, monitoring, closure, teams and certification. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Business courses Every course with PRO →
Why take it here
Why students take Project Management with UPI Study
Where the credit goes
Universities that work with NCCRS
Project Management carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Defining Goals and Objectives for Project Teams
What is the difference between a goal and an objective for a project team?
What does SMART stand for when writing objectives?
What is goal-setting theory by Locke and Latham?
What is the difference between a team charter and a project charter?
About the Project Management course
How many college credits is Project Management?
How much does Project Management cost and what is included?
Which universities accept UPI Study credits?
How long does Project Management take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Project Management.
73 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →