Skip to content

Capstone 2 - Planning the Work

Google Project Management Certificate · Course 6: Applying Project Management in the Real World


With the project charter signed off, the Sauce and Spoon tablet pilot crosses from initiation into planning, and the artifact at the centre of that phase is the project plan. The charter said what the project is and who cares about it; the plan says what has to be done, in what order, by whom, and how long each piece will take. Peta, the chain’s first in-house project manager, now has to turn two restaurant locations’ worth of intent into a list of tasks precise enough to schedule.

The course treats this as the single most portfolio-worthy document of the capstone, because it demonstrates the skill employers actually probe for: breaking a large, vague project into a set of small achievable tasks with credible durations. Week 2 builds that document in one pass, in the order a real planner would work. Find the tasks from documents, then from research, then from people. Order them and mark the milestones. Estimate them. Rate how much you trust each estimate. Then go and negotiate the estimates you do not like.

A project plan documents the scope, tasks, milestones, budget and overall activities of a project, and at its centre sits the schedule, the guide for making time estimates, determining milestones and monitoring progress. One of the project manager’s main jobs is simply stated: identify every task, estimate how long each takes, and track each one.


The phase reading lists what a plan can contain. Not every project needs all twelve, but the list is the checklist for what the document is supposed to carry.

Project nameDescription of the projectProject owners (RACI)Project statusTasks and milestonesTimelines and scheduleBudgetCommunication planResources and referencesQuality and evaluation planRisk mitigation planStatement of work

Documenting and organising these components buys visibility and accountability: team members and senior stakeholders will reference and add to the plan throughout the project, it streamlines team tasks and communication, and it becomes the raw material for planning the next project.

Before any of it, the reading suggests a short introduction or coffee chat with everyone on the immediate team, using four questions:

  • Have you worked on a project like this before, what did you do, and do you expect to do that here?
  • Are you expecting to do tasks on this project or only give input and review information? Will you delegate or do the work yourself?
  • What are you hoping to gain from this project: strengths to demonstrate, new skills, a step on your career path?
  • How can I, as project manager, best support you?

A few personal questions belong here too. Strong personal relationships are treated as an asset to the project, not a distraction from it.


Finding tasks by analysing existing documentation

Section titled “Finding tasks by analysing existing documentation”

The first source is the charter itself. Review the goals and deliverables, list every item that has tasks or milestones attached to it, and then, for each deliverable, ask one question: what steps do we need to take to achieve this? The steps become the tasks.

Sauce and Spoon deliverableMilestone it impliesTasks it hides
Promote the new tablet menus with table signs and email blastsThe deliverable being complete, meaning sign-offs on final marketing materials and confirmed blast datesWrite multiple drafts of each marketing piece, generate the email list, programme the emails to send on the right dates
Implement a post-dining survey to assess customer satisfactionSurvey live and collecting responsesAssign someone to develop the survey, decide how it will be delivered, create a process for carrying it out

Because so much workplace communication happens over email, ask stakeholders and colleagues to forward the threads where project details were discussed. Emails yield tasks directly, and they also reveal who to go back to with follow-up questions.

The richer source is an older project plan for a similar initiative. If you are launching a product, ask a colleague who has launched one before; if your project has a construction component, ask about an unrelated project that also involved construction. What a previous plan gives you:

Inspiration for your own task listPossible task durationsNames of subject matter expertsSuppliers who may be useful again

Two questions run in the background the whole time:

  • Is there a large task being worked on by many people that could be broken into smaller tasks assigned to individuals?
  • Are there signals that prior tasks must be completed first? A deliverable such as install tablets implies selecting a tablet vendor as a prior task.

The week supplies a real previous plan: the Reservation System Implementation for Sauce and Spoon, managed by Carmen back in 2018. It is a twelve-week Gantt spreadsheet with WBS numbering, and its columns are WBS number, task title, task owner, start date, due date, duration in days and percent complete, banded into four phases.

Project Initiationresearch, stakeholder alignment, staff interviews, charter, kickoff
→
Sourcingresearch options, quotes and costs, test systems, choose one, vendor schedule
→
Planningcontracts and statements of work, launch message, marketing calendar, launch day plan
→
Trainingseating chart upload, train GMs, train staff, test run, support plan, launch day
The phase skeleton of the 2018 reservation system plan transfers almost intact to a tablet rollout.

Rows worth lifting: generate quotes and review costs, create contracts and statements of work for vendors, train general managers on the new software before training staff, run a test of the system, create a troubleshooting and support plan, create a launch day plan covering staffing and troubleshooting, and launch day itself. The zero-duration rows are also informative: a kickoff meeting, a launch message to stakeholders and launch day are single-point events, which is exactly the shape of a milestone.

Activity: start the project plan from existing documentation

Section titled “Activity: start the project plan from existing documentation”

The activity asks you to read the charter, the historical plan and the supporting materials and to put a first list of tasks into the provided template. The template has five sheets. Tasks and Timeline is the schedule: Task, Notes, Start Date, Due Date, Duration, Task Owner, Status, followed by a day-by-day grid of twelve weeks banded into four phases. Task Brainstorm is the working sheet: Task, Notes, Estimated Duration (Days), Optimistic, Most Likely, Pessimistic, Confidence Rating (H/M/L), Known Dates. Additional Resources holds Title, Link, Date Added, Notes. The last two sheets, Quality and Evaluation and Survey Questions, stay empty until week 3.

Representative rows from the plan I submitted, with the provenance recorded in the Notes column:

TaskWhere it came from
Generate quotes and review costs with the tablet vendorHistorical plan, sourcing phase
Select the tablet vendor package with menu add-on and coupon featuresCharter, supports the upsell and product-mix goal
Create contracts and statements of work for the tablet vendor and electricianHistorical plan, planning phase
Install tablets in the bar area at the Downtown and North locationsCharter, the pilot deliverable
Create a launch-day plan covering staffing, troubleshooting and escalation pathsHistorical plan, training and launch phase

Breaking work into parts is a judgement call: some tasks need subtasks and some do not. Managing a cross-country move, you do not break unload the boxes from the car down into which box goes first, but you probably do break the movers’ work into detailed steps. Four guidelines help while the judgement is still developing.

One or two sentences
  • Keep every task description to one or two sentences
  • If it needs more, the task is complex and should be split, or it needs clarifying
Look at dependencies
  • What has to be finished or handed over before this work can start?
  • Dependencies tell you how far down to break a task
Define by time
  • A task expected to take a long time probably hides subtasks
  • Timed tasks let you schedule other work around them and suggest where milestones belong
Identify the done factors
  • Begin with the end in mind: what does done mean for this task?
  • Work backwards to catch missed steps and set checkpoints along the way

The dependency example is an awards ceremony where one task is to set up the stage:

Get an AV contractor estimate
→
Procure the equipment
→
Construct the backdrop
→
Set up the stage
What looked like one task is a chain of four, and the chain is what makes it schedulable.

Run the breakdown with the people who will do the work. Discuss each broad goal or major task as a group, because someone who has done a similar project may know that one of your tasks is really three. The phase reading adds the practical sizing rule: meet as a single group if the team is under five people, and on larger teams create subgroups to talk through the project and source ideas about tasks and deadlines. Two questions to put to them: are there tasks that can be broken down further, and are there tasks with no single clear owner?

The reading also asks you to flag blockers and dependencies explicitly in the plan, check their progress often, keep the team informed when one of them moves another task’s start date, and warn people when their own delay will block a colleague. That last habit creates peer accountability rather than manager-driven chasing.


Managing projects in private banking means understanding how clients open accounts, how back office operations run and how trade confirmations get verified. Managing a restaurant pilot means understanding things like guest averages and table turn times. Building that knowledge also pays forward: the next project in the same industry needs fewer questions and less research.

  1. Search for news coverage of similar projects at other companies. Terms such as menu tablet news or restaurant tablet news. While reading, note surprising outcomes after launch and unanticipated roadblocks, then decide which tasks to add so you repeat the successes or dodge the obstacles.

  2. Search for research on related topics. Terms such as restaurant tablet research or digital menu ordering, narrowed with tags like best practices or key takeaways.

  3. Research similar projects in other industries. Tablet installation in retail stores or coffee shops differs in detail but is a legitimate source of ideas when the industry itself is new to you.

  4. Go back to the task list you already have and research the specifics of executing that work. If choosing the tablet model is on the list, searching will surface the subtasks that decision needs.

The activity asks for genuine online research recorded on the Additional Resources sheet (Title, Link, Date Added, Notes), with any tasks it uncovers added to the brainstorm. Research is the only route to tasks a newcomer to restaurants would never think of, and it produced these on my plan:

Task found by researchWhy research surfaced it
Add payment-portal security messaging to the tablet checkout screenCoverage of other chains shows customers trust a checkout more when the security is visible
Create an end-of-service procedure for securing tablets, with a lockup checklist and device tracking enabled on each unitRestaurant tablet best-practice guides treat device loss as a standing risk

My two sources were an industry guide to restaurant tablet ordering covering hardware setup, staff training, security and rollout practice, and a trade magazine article on tabletop tablets at other chains that flagged payment security, staff-training pitfalls and device management.


Documents and research will not tell you everything. Discussions with the people doing the work uncover missing tasks and clarify subtasks, because your team, outside vendors and executives have expertise and job experience that give them a deeper picture of what the work involves. Four kinds of conversation, in widening circles:

Group brainstormthe team
Brainstorm with the people likely to do the tasksfor example, the challenges waitstaff and guests might have with the tablets, which surfaces tasks nobody had listed
One-on-onetask owners
Talk to each person about the tasks they will owna vendor who trains restaurant employees on how to prepare for training, a graphic designer on new marketing materials
Internal expertsoff the project
Consult colleagues elsewhere in the organisationpeople not involved in your project who know a given process can still fill in gaps
Stakeholderslast, and selectively
Go to stakeholders for what is still missingchoose those with high or medium interest or influence, subject matter experts, and those directly affected, using the stakeholder analysis

Senior stakeholders are busy, so preparation is the price of their time: gather everything you can beforehand, write down the specific outstanding questions, and in the meeting present your research and current task list and explain exactly how they can help you move forward. Seeing what you have already done is what lets them spot the gap. Expect these conversations to carry far more detail than your plan needs, and keep notes on the surplus anyway, because it tends to matter later.

What the week’s conversations actually produced

Section titled “What the week’s conversations actually produced”
ConversationWhat it added to the plan
Email thread with Seydou on tablet logisticsThe tables have to be physically wired, so an electrician is a real task; Seydou will bring one in through the tablet vendor once the extent of installation at each location is known
Same thread, real-time menu updatesPulling a sold-out dish instantly is a standard feature on current models, done from the software’s admin back end on the office computer, but staff have to be trained to do it
Same thread, brandingCustom branding, design and upload are separate vendor offerings bundled with some Terrific Tablets packages; choosing one means Seydou works with marketing so the tablet interface matches the printed menus
Call with Deanna on menu and couponsThe designer cannot start mock-ups without the featured menu items and coupon values; Carter wants to revamp the menu first and would only start late next week, and his menu work runs from a few days to a few weeks
Call with Seydou on software installationSyncing the tablet software with the POS is a few hours of adding code and rebooting, but only on FlatPlate version 3.0 or higher; nobody knows which version the locations run, and updating means contacting FlatPlate directly

Activity: add task details from conversations

Section titled “Activity: add task details from conversations”

This activity is a second pass over the brainstorm sheet, adding the tasks and Notes that only the conversations reveal. The visible result is that vague deliverables sprout prerequisites:

Task added or refinedTrigger
Schedule an electrician to wire the tables for tablet power at both pilot locationsThe logistics email thread
Connect the marketing team with the tablet vendor for custom branding and menu-interface designThe logistics email thread, branding is a separate offering
Confirm the POS software version at both locations and update FlatPlate if neededThe software installation call
Finalise menu items and coupon values with Carter, then upload the contentThe menu and coupons call

Ordering the tasks and identifying milestones

Section titled “Ordering the tasks and identifying milestones”

Finalise the list first: scan for any remaining large task that could still be split, and add the pieces. Then arrange the tasks in the order they have to be done, which is what lets you assign start and end dates.

  1. Consider the basic order of operations: what is the natural sequence of this work?

  2. Find the dependencies and prerequisites. You cannot train staff on the tablets before the tablets are installed and tested.

  3. Ask each task owner what has to happen before they can start. Searching online with a phrase such as prerequisites for launching new hardware works as a cross-check.

  4. Rearrange the spreadsheet rows to match. Researching tablet models has to precede signing a contract with the supplier, because you would not sign before reviewing the options.

TaskMilestone
What it isAn activity to be completed in a set periodAn important point in the schedule that indicates progress
Who holds itAssigned to a team member by role and skillBelongs to the project, not to a person
DurationHas a duration and a start and end dateA point, usually shown with zero duration
RelationshipMany tasks feed one milestoneUsually signifies a deliverable or a phase being complete

Three ways the video suggests to spot one: points where you and the team can evaluate the work completed so far (often the same as the deliverables you already listed, such as the first internal test run of the tablets’ ordering capability); tasks your stakeholders take a particular interest in, found by re-reading your notes for what they were eager to hear about (selecting the tablet supplier, because it drives the budget); and tasks that carry high risk or signal the completion of a phase or major task.

Success metrics can be testedA certain type of work is completedA certain type of resource is no longer being usedStakeholders want updatesA large percentage of the budget is being spentThere is cause for celebration

Celebration is not decoration here: the reading pairs it with the point that acknowledging a long task’s completion is a way to mark success, learn from the process and keep the project moving.

The activity asks you to reorder the rows and insert milestone rows. The course exemplar numbers four milestones and groups the tasks beneath each:

MilestoneTasks grouped under it
1.0 Tablets receivedGenerate quotes and review costs, create contracts and statements of work, order tablets
2.0 Training completeManager training planning, manager training, GM meeting with staff for buy-in, waitstaff training planning, waitstaff training
3.0 Tablet installation completeBook an electrician, install tablets in the bar area at each location, sync the tablet software with the POS
4.0 Launch Day completeLaunch day plan, upload branding, load menus, payment security messaging, securing procedure, post-dining survey, test run planning, test run, launch day

My own plan used phases rather than numbered milestones, closing each with a milestone row: vendor selected and contracts signed; tablets installed, integrated with the POS and host software and metrics wired up; all pilot-location staff trained and signed off; and pilot go-live at the start of Q2.


Effort estimate versus total duration estimate

Section titled “Effort estimate versus total duration estimate”

This is the distinction the course most wants clarified before any numbers are written down.

Effort estimateTotal duration estimate
CountsOnly the actual working time to complete the taskThe effort plus everything around it: approvals, prep work, testing and so on
Checkout page example8 hours to mock up and implement the designMore than 8 hours, because launching it needs testing, feedback and approvals
Risk if confusedThe schedule silently loses all the waiting timeNone, this is the number the schedule needs

Sauce and Spoon runs straight into it. Uploading the menu content is a few hours of effort, but its duration is hostage to Carter’s menu revamp. Syncing the tablets with the POS is a few hours of effort, and a possible few days of duration if FlatPlate has to be updated first.

Getting an accurate estimate out of an expert

Section titled “Getting an accurate estimate out of an expert”
  1. Check their understanding of the task. Ask them to explain every detailed step involved. You will not put those steps in the plan; the point is to make them think the work through before they give you a number.

  2. Ask for estimates of the sub-steps, note them, add them up, and compare the total with the expert’s own estimate of the whole task. A gap between the two is the conversation.

  3. Question their assumptions. What equipment and supplies do they assume they will have? How many people, and how skilled and experienced? Are there steps or other tasks they assume will already be done? Then ask how likely it is that some of those assumptions will not hold, and what that would do to the estimate.

  4. Compare against a similar past project. How was it similar, how was it different, how long did it take, and does thinking about it change their estimate at all?

The software installation call is step three in miniature. Seydou’s cheerful few hours rested on an unexamined assumption about the POS version; one question about it turned a few hours into a possible several-day dependency. The project update meeting shows the same move on the electrician: two business days of wiring, sixteen hours, is the effort, but the restaurants cannot close for a full day, so the duration becomes two half-days at each location.

The activity works down the Task Brainstorm sheet filling in the Estimated Duration (Days) column from the meeting transcripts and email threads, with the reasoning in Notes. The numbers the week’s materials hand over:

TaskWhat the sources give
Order and receive tabletsShipping projected at 7 to 10 days
Integrate the tablet software with the POS3 to 4 hours, plus 3 to 4 days if the POS has to be upgraded first
Wire both locationsTwo business days of work, scheduled as two half-days at each location
Menu and coupon mock-ups, then uploadAiming for one week but possibly two for the mock-ups, then 3 to 4 hours to upload
Training1 hour pre-training meeting per location, 2 hours for Seydou to train the managers, then 2 hours per staff training plus an hour either side for prep and debrief, each part on a different day, with about a week of preparation

EstimateAssumptionStaff training example
OptimisticBest case: issues will not occur and the task finishes within the estimateThe vendor is well qualified, has all the materials and arrives on time, all staff attend and finish in the scheduled slot, all the equipment works. 4 hours, being 2 hours of training and an hour each for setup and review, on the original date
Most likelySome issues occur; how long it usually takes under normal circumstancesThe vendor is qualified but is missing materials or is new and needs preparation time, a couple of staff cannot attend so extra training is scheduled, minor equipment glitches force a reschedule. 6 hours, two or three days later than planned
PessimisticWorst case: issues will definitely occurThe original vendor quits and a replacement has to be hired, staff no-show or leave just before the session, the equipment arrives late or does not work. Training time is still around 6 hours, but the date slips by up to a week (the reading records this case as 6 days)

Record the conditions behind each of the three, not just the numbers. When someone quotes you a figure, the context they are estimating from matters more than the figure: an optimist’s two days that becomes a week wrecks your schedule, and a pessimist’s one month for a week’s work leaves slack that could have gone to other tasks or an earlier launch. Always planning for the worst case looks prudent and is actually wasteful. Compare the best and worst cases against the most likely one, then build a buffer that covers the likely risks while keeping the project moving efficiently.

  • If the team has never done the task, or the dependencies are unknown, put the final estimate nearer the pessimistic figure.
  • If the team knows the task and you can confirm the optimistic conditions hold, move it nearer the optimistic figure.
  • If the spread between optimistic and pessimistic is small, a few hours or a day or two, simply use the most likely figure.

The video stops before the arithmetic and hands it to the reading, which gives two. In both, E is the final estimate, o the optimistic, m the most likely and p the pessimistic.

Triangular distribution
  • E = (o + m + p) / 3
  • All three weigh the same, so the most likely case has no more pull on the answer than the extremes
  • Reading example: o = 4, m = 8, p = 16 hours, so E = 28 / 3 = 9.3 hours
Beta (PERT) distribution
  • E = (o + 4m + p) / 6, a weighted average
  • The most likely estimate gets a multiplier of four and the divisor rises to six, because the most likely case really is more likely
  • Same numbers: E = (4 + 32 + 16) / 6 = 52 / 6 = 8.7 hours
Weighting the middle drags the answer away from the long pessimistic tail. The reading notes that beta (PERT) has proved more accurate in most cases and is used for cost estimates as well as time.

Worked on a real row from the course exemplar, generate quotes and review costs, where o = 8 days, m = 14 days and p = 16 days:

  • Triangular: E = (8 + 14 + 16) / 3 = 38 / 3 = 12.7 days.
  • Beta (PERT): E = (8 + 56 + 16) / 6 = 80 / 6 = 13.3 days.
  • The exemplar records 14 days, the most likely figure, which is a defensible call because the spread is narrow and the pessimistic case is only two days away.

The same arithmetic on a wide spread shows why the weighting matters. My plan’s menu and coupon task has o = 3, m = 7, p = 21 days because of Carter’s unpredictable revamp: triangular gives 31 / 3 = 10.3 days, while beta (PERT) gives (3 + 28 + 21) / 6 = 52 / 6 = 8.7 days. The wilder the worst case, the more the unweighted formula lets it distort the plan.


Sharing these ratings with stakeholders tells them how likely it is that a task really will finish in the time estimated. Internally they act as a filter: a low rating, together with notes on the risks or issues behind it, marks the estimates worth asking the team about and the tasks worth tracking closely. And if confidence is low across a large percentage of your estimates, that is the signal to communicate uncertainty about the whole timeline to stakeholders rather than presenting a schedule you do not believe.

From the three pointsevidence
Having worked the best and worst cases through is itself grounds for a high ratingbecause it shows a thorough understanding of the task
By polling the teampercentage
Ask everyone how confident they are in their own tasks and average it90 percent reads as high, 60 percent as medium
By categoryexperience
Never done this before, done it once, done it a handful of times, done it many timesnever or once maps to a low rating for that estimate

The week’s team meeting runs the category method live. Fifteen minutes go on assessing which tasks, or similar tasks, the team has done before, and the whiteboard comes out as three columns:

Never attemptedintegrating tablet software with the POS, training waitstaff on a new software system, updating the menu regularly through software
→
Attempted at least oncewiring through tables, done before for light fixtures in the booths but never for the tables themselves
→
Attempted regularlystaff training in general, though never on a directive like this one
Left-hand column tasks are where the low confidence ratings belong. The team still recorded a high level of confidence in the plan’s estimates overall.

The meeting closes with next steps that read as a to-do list for the following week: follow up with Carter on the menu, follow up with Gilly and Alex about scheduling the staff meetings, check the POS status, work out how many tablets each location needs, book the electrician for specific dates, set training dates and update staff calendars, and start drafting a training plan.

The activity fills the Confidence Rating (H/M/L) column next to the three-point columns already on the brainstorm sheet. The course exemplar’s pattern is consistent with the whiteboard:

TaskOptimistic, most likely, pessimistic (days)Rating
Create contracts and statements of work3, 5, 7H, past contracts give boilerplate
Manager training, a one-day event1, 1, 2H
Order and receive tablets8, 10, 12M, shipping updated to about 10 days
Sync the tablet software with the POS4, 7, 9L, the POS may need upgrading first
Load menus into the tablets4, 7, 9L, waiting on Carter
Create the launch day plan10, 20, 23L
Test run planning7, 10, 15L

The three low-rated rows are precisely the never-attempted work plus the tasks whose duration depends on somebody else’s decision, which is the pattern to look for in any plan.


Negotiating scope with a stakeholder and negotiating an estimate with a task expert are different exercises. With the expert you are not trying to persuade them towards an outcome; you are trying to arrive at an objectively accurate estimate together. People over- and under-estimate without meaning to, usually out of optimism, or a wish to give you the answer they think you want, or an over-cautious padding in case something goes wrong.

Say no without saying no
  • Avoid that will not work, that is not going to happen, there is no way: they put people on the defensive and end the conversation
  • Ask instead how would you like me to proceed, how can we solve this, what can I do to help
  • The aim is to get the other person working out an alternative with you
Focus on interests, not positions
  • The goal is not to win; identify their needs, wants and motivations around the task
  • An expert who cares about quality may be missing that a missed deadline makes the quality moot
  • Ask which areas of quality they could compromise on to shorten the estimate while keeping the work acceptable
Present mutually beneficial options
  • Use open-ended questions to find a solution that meets both goals
  • Perhaps the expert is missing information, or there is a resource you could commit to supplying that lowers the estimate
Insist on objective criteria
  • Neutral information: market value, research findings, previously documented experience, laws and regulations
  • Agree in advance which criteria you will both consult, then use them to set the estimate
  • For the expert who estimates on instinct, ask up front for the data that supports the instinct

Raising a delay without damaging the relationship

Section titled “Raising a delay without damaging the relationship”

Asking how long something will take, or why something is late, is the conversation most likely to land badly. People can hear it as mistrust, as doubt about their competence, or as a claim that you know their job better than they do, and without empathy the questions read as micromanaging, which itself signals a lack of confidence in the people you oversee.

  • Listen with curiosity. Open with a question rather than an assumption or a suggestion. Ask how long this task took them on a previous project instead of proposing a timeframe.
  • Repeat back what you heard, in your own words. It prompts them to confirm or correct their intent, and it can show them the issue from another angle.
  • Connect with their experience. Say plainly that estimating is hard for everyone, yourself included, and share a time you struggled with an estimate or got one wrong.
  • Recognise your own judgements. Notice when you are privately doubting someone’s work, then look for the more compassionate reading, because people read body language, expression and tone even when nothing is said.
  • Recognise buffering. Ask up front whether the number includes a buffer for holidays, sickness, childcare or emergencies, and make clear you want the honest answer even if it is not the one you hoped for. It is both an act of empathy and the shortest route to an accurate estimate.
  • Avoid distractions. Phone on silent and out of sight, laptop closed. Undivided attention is the message.

Torie, an Education Program Manager at Google working on the Applied Digital Skills digital literacy curriculum, adds the field version. Project management means dealing with many work and communication styles at once, so understanding how different people prefer to be communicated with is what lets your goals and impact land. On a five-person program team she kept hitting missed deadlines; talking to the team member concerned revealed personal circumstances behind them, and the answer was to shift resources and pull in help from teammates rather than to press harder. Her advice for negotiating estimates is to ask a lot of questions at the very beginning, seek out past projects similar to yours, look also at projects that differ but have comparable timelines, and gather as much data as you can early.

Activity: prepare for the negotiation conversations

Section titled “Activity: prepare for the negotiation conversations”

The final activity of the week is preparation rather than spreadsheet work: review the supporting materials, record notes on the tasks with low confidence ratings or estimates longer than hoped, and name the technique you would use in each case. The live cases the week hands over:

SituationTechnique that fits
Carter wants to revamp the menu before sending tablet content, which puts the upload at riskFocus on interests, not positions. His interest is his new menu launching with the rollout; Deanna notes he is usually agreeable once he knows the timeline, and offers to step in
The electrician is confident about two business days, but the restaurants cannot closePresent mutually beneficial options, splitting the work into two half-days at each location
Seydou quotes a few hours for the POS syncInsist on objective criteria: confirm the actual FlatPlate version before the estimate goes into the plan

The finished document is a single spreadsheet in which every task carries its provenance in the Notes column, its three-point estimates, a final duration and a confidence letter, grouped into phases that each end in a milestone row, with the research sources logged on their own sheet. It is the artifact that demonstrates the skill the whole capstone is about: taking a large project and breaking it into a set of achievable, smaller tasks that a team can actually be scheduled against. Next comes preparing to execute, starting with quality.



Next: Quality and evaluation → - quality standards, evaluation questions, surveys and the retrospective.