<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
<channel>
<title>Missions blog</title>
<link>https://missionnops.com/blog</link>
<atom:link href="https://missionnops.com/blog/rss.xml" rel="self" type="application/rss+xml"/>
<description>Practical guides on planning client projects, running a team and tracking time, from the team behind Missions.</description>
<language>en</language>
<lastBuildDate>Fri, 13 Nov 2026 15:48:37 GMT</lastBuildDate>
<item>
<title>How to plan a client website project from kickoff to launch</title>
<link>https://missionnops.com/blog/client-project-planning-website-kickoff-to-launch</link>
<guid isPermaLink="false">01a1d2ea-1f1e-7f4c-b5a0-d57ef5267f50</guid>
<pubDate>Fri, 13 Nov 2026 03:27:41 GMT</pubDate>
<dc:creator>Dhruti</dc:creator>
<category>Project management</category>
<description>A practical week-by-week plan for client website projects: scope, sitemap, design, build, content, QA, launch and a clean handover.</description>
<content:encoded><![CDATA[<p>Most client websites do not run late because the build is hard. They run late because nobody agreed what &quot;done&quot; meant, content arrived a fortnight after it was needed, and feedback came from five people in three channels. Good <strong>client project planning</strong> fixes that before the first wireframe exists: a clear scope, a phase plan with dates, one owner per piece of work and a single place where the client can see progress.</p>
<p>This guide walks through a practical, week-by-week plan for an agency building a client website, from kickoff to handover. Stretch or squeeze the weeks to fit the size of the site, but keep the order and the gates between phases.</p>
<h2 id="why-client-website-projects-slip">Why client website projects slip</h2>
<p>Before the plan, it helps to name the usual culprits, because each phase below is designed to head one of them off.</p>
<ul><li><strong>Fuzzy scope.</strong> &quot;A new website&quot; means different things to the client, the designer and the developer. Without a written scope, every extra page feels reasonable.</li><li><strong>Late content.</strong> Copy, photos and product details are the client's job, and they are almost always the last thing to arrive. Build waits, launch slips.</li><li><strong>Feedback sprawl.</strong> Comments by email, chat and phone, with no record of what was agreed.</li><li><strong>No single owner.</strong> &quot;The team&quot; is responsible, so nobody is. Tasks drift between people and quietly stall.</li><li><strong>A soft finish.</strong> Launch happens, but logins, training and hand-off notes trail on for weeks.</li></ul>
<p>A plan that names owners, dates and sign-offs for each phase removes most of this friction.</p>
<h2 id="a-week-by-week-client-website-plan">A week-by-week client website plan</h2>
<p>Here is a typical eight-week shape for a small-to-medium marketing site. Treat the weeks as a starting point, not a promise.</p>
<figure class="btl"><figcaption class="btl-t">Kickoff to launch in eight weeks</figcaption><ol><li><span class="btl-k">Week 1: Kickoff</span><div class="btl-b">Meet the client, confirm goals, audience, decision-makers and how feedback will be given.</div></li><li><span class="btl-k">Week 1: Scope</span><div class="btl-b">Write down pages, features, integrations and what is out of scope. Get it signed off.</div></li><li><span class="btl-k">Week 2: Sitemap</span><div class="btl-b">Agree the page structure and navigation, and list the content each page needs.</div></li><li><span class="btl-k">Weeks 2-3: Design</span><div class="btl-b">Wireframes for key templates, then visual design. One consolidated round of feedback per stage.</div></li><li><span class="btl-k">Weeks 4-6: Build</span><div class="btl-b">Develop templates, set up the CMS, connect forms and integrations.</div></li><li><span class="btl-k">Weeks 3-6: Content</span><div class="btl-b">The client writes or approves copy and supplies images while the build runs in parallel.</div></li><li><span class="btl-k">Week 7: QA</span><div class="btl-b">Test on real devices and browsers, check forms, speed, accessibility and redirects.</div></li><li><span class="btl-k">Week 8: Launch</span><div class="btl-b">Go live, check analytics and search settings, watch for errors.</div></li><li><span class="btl-k">Week 8: Handover</span><div class="btl-b">Hand over logins, a short training session and notes on how to keep the site healthy.</div></li></ol></figure>
<h3 id="week-1-kickoff-and-scope">Week 1: kickoff and scope</h3>
<p>The kickoff call sets the tone for the whole project. Agree the business goals, who the site is for, who signs off and how feedback will reach you. Then turn that conversation into a written scope: the pages, the features (forms, booking, shop, blog), any integrations, and a short list of what is <em>not</em> included. A signed scope is the best defence against creep, and it gives you something neutral to point to when new requests appear.</p>
<h3 id="week-2-sitemap-and-content-plan">Week 2: sitemap and content plan</h3>
<p>The sitemap is where scope becomes concrete. List every page, how it sits in the navigation and what content it needs. This is also the moment to send the client a content checklist with dates attached, because content is the dependency most likely to hold up launch. If you are unsure how visitors expect pages to be grouped, a quick card sort with a few real users is cheap and revealing.</p>
<h3 id="weeks-2-3-design">Weeks 2-3: design</h3>
<p>Start with wireframes for the templates that matter most (home, a service page, a contact page), then move to visual design. Ask the client to gather everyone's comments into one round per stage. Two clean rounds beat six scattered ones.</p>
<h3 id="weeks-4-6-build-and-content-in-parallel">Weeks 4-6: build and content in parallel</h3>
<p>Development runs while the client finishes copy and images. Keep a running list of which pages have final content and which are still waiting, so nobody is surprised in week seven.</p>
<h3 id="week-7-qa">Week 7: QA</h3>
<p>Test like a visitor, not like the person who built it. Check every form, every link and every template on phones, tablets and desktops. Review headings, alt text and colour contrast against the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/" target="_blank" rel="noopener">Web Content Accessibility Guidelines</a>, and confirm redirects from any old URLs.</p>
<h3 id="week-8-launch-and-handover">Week 8: launch and handover</h3>
<p>Launch on a quiet weekday morning, not a Friday afternoon. Check analytics, search settings and forms in the live environment. Then close the project properly: hand over logins, run a short training session and leave written notes on updates and backups.</p>
<aside class="bcallout tip" role="note"><p class="bct">Put a gate between phases</p><p>Do not open the next phase until the current one is signed off. Design starts after the sitemap is agreed; build starts after designs are approved. A gate turns &quot;can we just change…&quot; into a conscious decision with a cost, rather than a quiet slip.</p></aside>
<h2 id="turn-the-plan-into-owners-and-dates">Turn the plan into owners and dates</h2>
<p>A timeline on a slide is not a plan until every piece of work has a name and a date on it. The simplest rule that works: <strong>every task has one owner and one due date.</strong> Two owners means no owner. No due date means &quot;someday&quot;.</p>
<p>Break each phase into tasks small enough to finish in a few days. &quot;Design&quot; is a phase; &quot;Homepage wireframe&quot;, &quot;Service page visual design&quot; and &quot;Design feedback round 1&quot; are tasks someone can own. For each task, write down what done looks like as a short checklist, so the person doing the work and the person reviewing it agree on the finish line.</p>
<div class="btable" role="region" aria-label="Table" tabindex="0"><table><thead><tr><th>Phase</th><th>Example tasks</th><th>Typical owner</th></tr></thead><tbody><tr><td>Scope</td><td>Write scope document, client sign-off</td><td>Project manager</td></tr><tr><td>Sitemap</td><td>Draft sitemap, content checklist sent</td><td>Strategist or PM</td></tr><tr><td>Design</td><td>Wireframes, visual design, feedback rounds</td><td>Designer</td></tr><tr><td>Build</td><td>Templates, CMS set-up, forms</td><td>Developer</td></tr><tr><td>Content</td><td>Copy per page, images, final approval</td><td>Client contact</td></tr><tr><td>QA</td><td>Device tests, form tests, accessibility check</td><td>Developer and PM</td></tr><tr><td>Launch</td><td>Go-live checklist, handover session</td><td>Project manager</td></tr></tbody></table></div>
<p>Notice the client appears as an owner. If content is late, it should be visible to everyone that it is the client's task that is overdue, not the developer's.</p>
<h2 id="how-missions-keeps-a-client-website-on-track">How Missions keeps a client website on track</h2>
<p><a href="/features">Missions</a> is built for exactly this kind of work. Here is how the plan above maps onto it.</p>
<p><strong>One project per client site.</strong> Create a project for each client website so its work, files and conversations stay together. You can group projects under the client they belong to, which keeps things tidy when you run several sites for the same company.</p>
<p><strong>Missions with one owner and a due date.</strong> Each task is a mission. Give it an owner, a due date and a priority, and the &quot;one owner, one date&quot; rule is built into how the team works.</p>
<p><strong>Objectives as checklists.</strong> Inside each mission, add objectives: the checklist of what done looks like. &quot;Homepage wireframe&quot; might have objectives for desktop layout, mobile layout and an internal review. Attach the files alongside, so the latest version is always on the mission. See <a href="/docs/checklists-and-attachments">checklists and attachments</a>.</p>
<p><strong>The T-minus countdown.</strong> Missions keeps the time left to a due date in view, so the team sees what is approaching rather than discovering it on the day. It is a small thing that makes slipping dates hard to ignore.</p>
<p><strong>Board and calendar views.</strong> Use the board to run each week's flow, with columns for your own statuses such as To do, In design, Client review and Done. Switch to the calendar when you need to see how the launch week is shaping up, or whether QA and content deadlines are colliding. Both views show the same missions, so nothing is entered twice.</p>
<aside class="bcta bcta-trial"><span class="bcta-ic" aria-hidden="true"></span><div class="bcta-t"><b>Try Missions free</b><p>Plan your projects, assign every mission and track time in one place. No card needed.</p></div><a class="btn btn-accent" href="/signup?utm_source=blog&amp;utm_medium=inline_cta" data-blog-cta="trial">Start free trial</a></aside>
<p><strong>Share the project with your client as a guest.</strong> Invite the client contact as a guest on their project. They can follow progress and comment on missions, so feedback lands in one place instead of five, and they do not see anything else in your workspace. Read <a href="/docs/what-guests-can-see">what guests can and cannot see</a> before you share.</p>
<p><strong>Your own branding.</strong> Because the client sees the project too, Missions can carry your logo, colours and font, and even run on your own domain. To the client, it looks like part of your agency's service.</p>
<h2 id="common-mistakes-to-avoid">Common mistakes to avoid</h2>
<ul><li><strong>Starting design before the sitemap is agreed.</strong> You will redesign pages that later disappear.</li><li><strong>Leaving content to &quot;later&quot;.</strong> Put content tasks on the plan with the client as owner and real dates.</li><li><strong>Collecting feedback everywhere.</strong> Agree one place for comments at kickoff and stick to it.</li><li><strong>Skipping QA because the site &quot;looks fine&quot;.</strong> Forms and redirects fail silently.</li><li><strong>Calling launch the end.</strong> Handover is part of the project. Plan and date it like any other phase.</li></ul>
<h2 id="wrapping-up">Wrapping up</h2>
<p>A good client website plan is not complicated: a signed scope, a sitemap, clear phases with gates, and every piece of work owned by one person with one date. Put that plan somewhere the whole team and the client can see it, and most of the usual delays never get the chance to start.</p>
<p>When you are ready to put your next client site into Missions, compare plans on the <a href="/pricing">pricing page</a>.</p>]]></content:encoded>
<media:content url="https://missionnops.com/assets/site-blog-c5b4417b-ed93b3b71e.webp" medium="image"/>
</item>
</channel>
</rss>
