Rollout Hub

Rollout Home

Start here for the reason the intake process is changing and the two most useful next steps: review the plan or practice a request.

• A simpler way to start project work
  For Northstar Services employees who request, review, or prioritize project work. Northstar Services is a fictional sample organization. This hub explains its example intake rollout and helps you prepare for the new process.
• What is changing
  Project requests begin with one intake route that captures the problem, expected impact, and preferred timing before review. The goal is to give reviewers consistent context—not to promise that every request will be approved or scheduled.
• Plan is not completion
  A planned milestone describes intended work; completion needs an actual update from the responsible rollout team. What it tells you What is scheduled or intended What the responsible team has confirmed Example Team practice is planned after the intake form is prepared A rollout update confirms team practice took place How to read it A plan, not proof of completion Use the actual published completion update
• Go to the answer you need
  Choose a page by your next task. Milestones Read the example sequence and what each stage means. Role changes Compare requester, reviewer, and team lead responsibilities. Training Walk through a sample request and practical checks. Frequently asked questions Find answers about writing, reviewing, and updating requests. Go-live support Prepare a clear process question or feedback note.

Timeline and Milestones

• The planned sequence
  This is a published sample plan for the Northstar Services intake rollout, not live completion tracking. No calendar dates are asserted here. A planned activity should be treated as complete only when the responsible rollout team publishes an actual update.
• Rollout milestones
  Prepare the intake route Finalize the example form fields for request summary, problem, expected impact, and preferred timing. Planned stage 1 Brief teams Explain where requests start and how reviewers ask for missing context. Planned stage 2 Practice sample requests Use a realistic scenario to check that requesters and reviewers understand the handoff. Planned stage 3 Begin using the new process Use the approved intake route for new project requests when the rollout team announces it is in use. Planned stage 4 Review early feedback Collect recurring questions and identify improvements to instructions or the intake experience. Planned stage 5
• What a milestone means to employees
  A schedule describes intended work. Look for a separate update before treating work as complete. Milestone Employee-facing outcome Completion evidence Prepare intake route The request fields and route are explained. A rollout update confirms the route is ready. Brief teams Employees know where to start and what context to include. The responsible team confirms the briefing occurred. Practice requests Requesters and reviewers can work through an example. A published update records that practice was completed. Begin new process Employees are told when to use the approved route. The rollout team announces that the process is active. Review feedback Common questions and improvement themes are summarized. A published review or follow-up update is available.
• How to check progress
  If you need to know whether a stage has happened, look for an actual update from the rollout team rather than inferring completion from its position in this planned sequence. Go-live Support and Feedback If you cannot find an update or have a process question, use this guidance.

Role Changes

• One starting point, different responsibilities
  In the Northstar Services example, all new project requests begin through one intake route. Requesters describe the need, reviewers check the information and clarify gaps, and team leads consider priority and capacity.
• Worked role matrix
  Example responsibilities for a request to improve shared reporting. Role What they do What to check Next handoff Requester Submits the reporting problem, who is affected, expected benefit, and preferred timing. The request explains the need without assuming a solution is already approved. Reviewer checks the request and asks for clarification if needed. Reviewer Checks that the request has enough context for a consistent review. Problem, impact, timing, and any missing details are understandable. Returns a focused clarification question or passes a clear request onward. Team lead Considers the request alongside team priorities and available capacity. The impact and timing are clear enough to support prioritization. Communicates the next decision or follow-up through the approved process.
• Sample handoff: shared reporting improvement
  A request moves from description to review without treating submission as approval. Requester describes the need A team reports that a recurring weekly summary takes time to assemble and explains which decisions the summary supports. Reviewer checks context The reviewer checks that the affected audience, current problem, expected benefit, and preferred timing are clear; they ask a specific question if a key detail is missing. Team lead considers priority The team lead reviews the clarified request alongside other work and communicates the next step. Submission alone does not mean the work is approved or scheduled.
• Questions by role
  Practical next actions for common handoff situations. What if my request is incomplete? Add the missing context requested by the reviewer, such as who is affected or what outcome would help. Keep the original problem clear. What if I am unsure who should review it? Submit through the approved intake route and describe the area affected. Do not guess an individual reviewer; use the process's designated routing guidance. Does a clear request mean the work is approved? No. Clear information supports review. A prioritization or approval decision is a separate step.

Training and Resources

• Practice the new intake workflow
  Use this fictional shared-reporting scenario to practice describing a need before proposing a solution.
• Worked example: improve a weekly report
  A useful request gives reviewers enough context to understand the problem and consider next steps. Describe the current problem A team spends time combining updates from several sources to prepare its weekly summary. Explain who and what are affected The summary is used by the team's leads to review recurring work; manual collation makes it harder to compare the same information each week. State the intended outcome The requester wants a more consistent way to bring the information together, while leaving the implementation approach open for review. Add preferred timing and submit The requester notes when the improvement would be most useful and submits it through the approved intake route for review.
• Two checks that make the handoff clearer
  Use these short checks before submission and during review. Requester check Make the need understandable without relying on a proposed solution. Name the current problem and who experiences it. Describe the expected benefit in practical terms. Include preferred timing and relevant non-sensitive context. Reviewer check Check for enough context to route or clarify the request. Confirm the problem and affected audience are clear. Ask a focused question when an important detail is missing. Keep review distinct from any later prioritization decision.
• Practice materials on this page
  Use the worked scenario and checks above, then compare the role responsibilities. Intake walkthrough Use the worked example and requester check on this page to practice describing a need. Practice Shared reporting scenario Follow the four-step fictional scenario above, from problem description to submission for review. Requester and reviewer checks Compare the requester and reviewer responsibilities before sending a request or asking for clarification. See role responsibilities

Frequently Asked Questions

• Consistent context helps requests get reviewed
  The example intake route gathers a clear description of the problem, its impact, and preferred timing before review. A complete request supports a better-informed review; it does not guarantee approval or a particular schedule.
• Common questions
  Answers for requesters and people following a request. What belongs in a project request? Describe the problem, who or what is affected, the expected benefit, and preferred timing. Include relevant non-sensitive context that helps someone understand the need. What should I do if a reviewer asks for more information? Answer the specific question and update the request with the missing context, so the review can continue from one clear record. Can I suggest a solution? You can describe an idea, but make the underlying problem and desired outcome clear too. That gives reviewers room to consider appropriate options. What if the priority changes after submission? Use the approved process to update the request with what changed and why. Do not assume an earlier timing preference still represents the current need. Does submitting a request put it on the schedule? No. Submission starts review. Any decision or schedule is a separate communication through the approved process.
• Make the request specific
  Fictional before-and-after example for the shared reporting scenario. Request description Our team manually combines several updates for the weekly summary; a more consistent way to bring them together would help leads compare recurring work. Make reporting better. Why it helps Names the current problem, affected audience, and intended outcome without locking in a solution. Does not explain what is wrong, who is affected, or what improvement is needed.
• Still have a process question?
  Prepare the step you were taking, what you expected, and what happened. Go-live Support and Feedback Practical guidance on asking for help or sharing a workflow observation.

Go-live Support and Feedback

• Make a support question easy to understand
  When asking about the intake process, say which step you were on, what you expected to happen, and what happened instead. Include only non-sensitive context needed to understand the issue; do not post passwords, personal identifiers, or confidential request details in a general feedback message.
• Prepare before you ask
  A short, factual description helps the appropriate support route understand your question. Identify the step Name the intake stage or field where you had difficulty. Describe expected and actual results State what you thought would happen and what happened instead, without including sensitive information. Check the process answer Review the FAQ for answers about request context, clarification, and changed priorities. Use the approved support route Follow the support channel published by your organization. If the route is not shown in your local rollout materials, ask your manager or rollout coordinator which approved channel to use.
• Choose the right next action
  Situation What to include Next action Process question The step you were taking and what was unclear. Check the FAQ; if unresolved, use the approved support route. Incomplete request The request detail the reviewer needs and any relevant context. Update the request through the approved intake process. Workflow feedback What happened, the impact on your work, and a practical suggestion if you have one. Share it through the configured rollout feedback channel. Access or routing difficulty The affected step and what you can safely describe. Use the organization’s approved support route; avoid sending credentials or sensitive data.
• Keep feedback actionable
  A useful observation is specific: “I could not tell whether preferred timing meant a requested date or a general planning window.” This describes the point of confusion and gives the rollout team something concrete to review. Frequently Asked Questions For common process answers, return to the FAQ.