Project Delivery Room

Project overview One floor plan, six departments, a calm move The place for project leads, contributors and receiving teams to find what the Harbor Street office move is meant to achieve and who is responsible for what. Northstar Services is a fictional company, and this room follows its sample project: consolidating about 420 people from two buildings into one over three phases. What the project is, and is not Read these four cards first, then follow a link for the detail. Intended outcome All six departments work from the Harbor Street building by Week 15, with desks, network access and meeting rooms ready on each move day. In scope Space planning, desk and equipment moves, network and telephony setup, move-day logistics and a two-week settling-in period. Floors 2 to 4 only Staff and shared equipment Out of scope Lease exit at the old buildings, redesign of team working practices and any change to team reporting lines. What done means The receiving Operations team accepts the floors, with every open item owned by a named role. Section Divider Delivery context Who coordinates, and how changes reach them Responsibilities by role Ask the role first. Names are kept in the project's own contact list, not on this page. Project Lead Owns the plan, the decision record and the weekly check-in. Takes any changed assumption and decides who needs to hear about it. Runs the Thursday 30-minute delivery check-in Updates this room within two working days of a decision Workstream owners The Workplace Facilities Manager owns space and furniture. The IT Service Owner owns network, devices and meeting-room equipment. Each owner keeps task status in the project work tracker Each owner names a backup for move weeks Department Move Coordinators One per department. They collect desk and equipment needs from their team and are the contact on move day. Send space needs to the Project Lead by Week 3 Report a changed headcount as soon as it is known Sample project snapshot Illustrative Northstar figures, entered by hand from the Facilities planning sheet as of 14 March. This is not live status. People moving (headcount in the plan) 420 Departments across 3 phases 6 Planned duration, kickoff to handover 17 weeks Floors in the Harbor Street building 3 Milestones The delivery sequence at a glance This is the sample plan for the Harbor Street move. Weeks count from kickoff (Week 1). Each milestone lists its prerequisite, so you can see what a slip would hold up. The table shows the agreed sequence, not today's task status. Daily progress lives in the project's work tracker, where each workstream owner updates their own tasks. Sample milestone schedule Illustrative target weeks. Read left to right: what, when, what it waits for, who answers for it. Milestone Target Waits for Accountable role Floor plan approved Week 4 Space needs from all six departments Workplace Facilities Manager Equipment and network ordered Week 6 Approved floor plan IT Service Owner Network equipment delivered Week 7 Week 6 equipment order Phase 1 move: Finance, HR Week 9 Floor 2 network tested Department Move Coordinators Phase 2 move: Sales, Support Week 12 Phase 1 issues closed Project Lead Phase 3 move: Product, Operations Week 15 Phase 2 issues closed Handover accepted Week 17 Phase 3 open items reviewed Receiving Operations Lead If a prerequisite changes Example: the supplier moves network equipment delivery from Week 7 to Week 8. Name the change Write one sentence: what moved, from when to when, and why. For example: 'The supplier moved switch delivery from Week 7 to Week 8.' Find what waits for it Check the Waits for column. Here Phase 1 depends on a tested Floor 2 network, so Week 9 is at risk. Tell the Project Lead the same day Send the sentence and the affected milestone before the next Thursday check-in, not at it. Update the tracker, then the plan The owner updates the task in the work tracker. The Project Lead updates this page if a target week changes. Follow a dependency Decisions Why the sequence is phased Risks and dependencies What could move a date Handover What Week 17 needs to include Decisions Settled decisions and open questions A decision is a choice the Project Lead has recorded with an owner and a reason. Until then it is an open question , and work should not depend on it. The entries below are worked examples from the sample Northstar move. They illustrate the record's shape and are not connected to a decision log. Worked example: move in three phases A complete decision record, from question to review trigger. Decided: phased moves by department Decision owner: Project Lead, with the Business Operations sponsor. Six departments move in three phases instead of one weekend. Finance and HR first, because their needs are the most predictable Customer-facing Sales and Support in the middle, with cover from the old building for two days Product and Operations last, after settling-in issues are fixed What was traded off, and when we look again Phasing costs about two extra weeks and two sites to support. It cuts the risk of every team losing a day at once. Review trigger: Phase 1 leaves more than 10 open issues after one week Review trigger: the supplier delivery date moves past Week 7 Who is told: every Department Move Coordinator, within two working days Sample decision register Illustrative entries. 'Review if' names the event that reopens a decision. Decision Why Affects Review if Phased move by department Limits the disruption to any one team All three move milestones More than 10 Phase 1 issues remain open after one week Neighbourhood seating, no assigned desks on Floor 4 Product and Operations use desks on alternate days Floor plan, equipment order Average attendance passes 70% of headcount Open question: shared quiet room on Floor 3 Support asked for one; Facilities has not confirmed space Floor plan Not decided; the Project Lead sets a date See what a decision changes Milestones Which dates a decision moves Risks and dependencies Uncertainties behind open questions Handover Decisions the receiving team inherits Risks and dependencies A risk might happen. A dependency must happen first. A risk is something uncertain that could hurt delivery, so the team watches it and plans a response. A dependency is a piece of work another team has to finish before yours can start. Handle each with a named role and a next review point. The examples are authored for the sample Northstar move and are not pulled from a risk system. One of each, side by side Risk: late room-layout confirmation Departments might not confirm meeting-room needs by Week 3, which would delay the floor plan. Consequence: Week 4 plan approval slips Response: the Project Lead sends a reminder at Week 2 Role: Department Move Coordinators Dependency: facilities approval of the floor plan IT cannot order switches and desk phones until Facilities approves where desks and rooms go. Consequence: Week 6 order cannot be placed Needed by: end of Week 4 Role: Workplace Facilities Manager Which is it? Ask: is this certain to be needed, and does another team own it? If yes, it is a dependency. If it might occur, it is a risk. If both apply, record the dependency and add the risk that it slips. Sample register Illustrative entries, with no status shown. Current status sits in the project's work tracker. Item If it slips Next review Role Dependency: floor plan approved Equipment order waits Thursday check-in, Week 3 Workplace Facilities Manager Dependency: Floor 2 network tested Phase 1 move cannot start Week 8 check-in IT Service Owner Risk: late room-layout confirmation Plan approval slips a week Week 2 reminder Project Lead Risk: supplier delivery after Week 7 Phase 1 date reconsidered Week 6 check-in When something changes Describe the change in a sentence What is different, since when, and what you expect to happen next. Name the affected milestone Use the Waits for column on the Milestones page to find it. Tell the coordinating role Message the Project Lead, and the workstream owner if the item sits in their area. Record it in the project system The owner updates the work tracker. A recorded decision may then need revisiting on the Decisions page. Related context Milestones See which dates the item touches Decisions Check whether a choice needs revisiting Handover Where the project stops and Operations begins Project participants prepare and coordinate the transfer. After the receiving Operations Lead accepts the floors, that role owns day-to-day support through the organization's normal operating process. The reference below is illustrative for the sample Northstar move. Your own acceptance steps come from your operating procedures, not from this page. What a clear handover covers What was delivered Summarise the outcome against scope so the receiving team knows what they are being handed. Floors 2 to 4 ready for 420 people Equipment and network installed by department Decisions that shape daily use, such as shared desks on Floor 4 What is still open, and who holds it Each open item has an impact in plain words, an interim owner role and a point where the receiving team takes it over. List open items by effect on daily work, not by task number Name an interim owner role, never 'the project' Link to the tracker for task detail Who supports it afterwards Explain where employees go for help once the project team disbands, and which role answers questions about the project's decisions. Day-to-day issues: the Operations support route Questions about why: this Decisions page Changes to the building: Workplace Facilities Manager Worked example: one open item A sample entry from the Phase 3 review at Week 16. Open item Effect on work Interim owner Follow-up Two Floor 3 meeting rooms lack booking panels Rooms can only be used walk-up until panels are fitted IT Service Owner Receiving Operations Lead reviews at the Week 18 check-in If an open item changes an earlier choice Decisions Check the reason behind a choice Risks and dependencies See what was still uncertain