/ Project Handbook

Project Life Cycle – Broad Overview

This page gives a broad overview of the stages of our projects. There are links to other pages within our documentation that have further information about these project stages.

As always, our projects vary and you might not go through each step (nor will they occur in the same order) each time, but most projects will involve some variation of these steps.

Stage 1: Project Start

All new projects will go through the steps in the New Project Checklist.

Other helpful documentation for this stage:

Stage 2: Content

Once the kickoff and initial discovery are completed and the project brief is delivered, we move to the Content stage. In this stage, we gather content, review existing assets, and set up a sitemap or the information architecture for the site. Other activities in this stage could be workshopping content with the partner and content import from an existing site.

For new sites, we should define a way for the partner to deliver the content and a timeline for doing so. High-level information architecture should be laid out and agreed upon, the TAMs might work together with designers to complete this. Brand assets and materials should be delivered. Media should be delivered, or a timeline and method of delivery should be defined. Flag poor quality or low-res media with the partner.

For existing sites, we should do a content import, get access to their current CMS, or an export. Based on the findings from the import, we should start putting together a migration plan and adjust the sitemap/information architecture if needed. Flag poor quality or low-res resources with the partner.

Other helpful documentation for this stage:

More context on the Content stage ███████████████.

Stage 3: Design

If the project involves design, see our Design Guidelines ███████████████ for a thorough outline of our design process. View this page for how to assign a designer.

The general design lifecycle may include all or any of these phases, in this order:

  • Design kickoff call
  • Sitemap (information architecture)
  • Wireframes and content strategy
  • Design concepts
  • Mockups
  • Design QA

If you plan to use an existing theme for a non-showcase partner, it’s OK to just share links to a couple of themes on WordPress.com/themes (make sure it’s a block theme). If you want to show the partner the opportunities with customizations, it’s often quicker for a designer to do this in Figma rather than in the Site Editor. Depending on comfort level with design and block themes, a designer, TAM, or developer can complete the customizations to an existing block theme.

Please also review the block theme best practices guidelines ███████████████.

Stage 4: Development

After the designs have been approved (if there was a design phase), it’s time to move on to development.

  • Helpful documentation to reference:
    • Assigning Developers
    • Developer Handbook (Contains more about our development process and the best practices we follow) ███████████████.
    • Metrics and Performance Considerations (Things to consider, or have a developer consider before starting development) ███████████████
    • Block Theme Best Practices (review prior to starting development) ███████████████.
    • Testing and QA Checklists (All sites should undergo testing and QA) ███████████████.
    • QA Process (explains how our QA Engineer and the TAM work together through the QA process) ███████████████
    • Design Reviews (explains the reasoning behind the Design Review step) ███████████████
  • To get the developer started, ping them in Slack in ███████████████ to introduce them to the project (linking to the Project P2 thread and, if applicable, the designer’s hand-off notes is helpful). Ask them to review the project info and to let you know if it’s something they can take on.
    • If the project involves creating a lot of custom functionality or lots of moving parts, it’s helpful to create a GitHub Issue for each item that’s needed and have the developer review those items to provide an estimate how long they think it would take to implement them. That will help you to build a development timeline and milestones (or refine existing ones).
    • If the site being worked on has an existing WordPress WooCommerce store, it is important to have a plan before you begin development in order to avoid new pages during build creating a conflict with ongoing Woo purchases. Make sure the developer has a plan in place to prevent this, or consult with an internal developer to put a plan in place.

Stage 5: QA

When initial development of a site is complete, it’s time for QA!

  • TAMs should reach out to the designer of the site and ask them to complete a ███████████████ to ensure the development site matches the provided designs.
  • TAMs should reach out to our QA engineer to conduct a Functional QA.
  • Designers and QA Engineers can open Github Issues for developers to address any deviations or adjustments.
  • A Design Review should be completed before sharing the development site with the partner wherever possible.
  • Design Reviews and QA may happen concurrently if necessary, but it’s preferred to conduct a Design Review prior to the full QA process to avoid duplicate issue reporting.
  • QA can be completed at initial development site delivery, or after the partner has reviewed the development site but prior to launch.

Stage 6: Launch

When you’re ready for launch, here are some general guidelines.

  • Follow our Launch Checklists in the days leading up to, and including, Launch Day (you might wish to create GitHub issues for each item in the checklist).
  • If needed, involve the developer if support is needed before, during, or after launch.
  • We avoid launching on Fridays because our working hours are business hours (in your time zone) on Mondays through Fridays. If something were to go awry with a Friday launch, there would be fewer people around to assist over the weekend.
  • Consider Launch timing based on time zone and immediate post-launch coverage availability.
    • For example, avoid launching on Friday afternoons in a later time zone, as there will be less folks around should something urgent crop up post-launch.
  • Schedule the launch with the partner, and communicate with them throughout and immediately after the launch process so that they know what to expect.

Stage 7: Post-Launch and Hand-Off

After a site has launched, you will generally remain available to the partner for the first week to handle any immediate post-launch clean-up and issues.

If the partner is particularly happy with our work or has expressed a desire to show their gratitude in other ways, consider these potential opportunities for partners to help us further ███████████████.

Eventually, you’ll hand the project off to our TAMs who handle ongoing maintenance and support for our partners. Once the site is launched, our team’s ongoing involvement typically includes: 

  • Regular maintenance and updates
  • Site backups and monitoring (through Jetpack features)
  • Fast response to any outages or security incidents
  • Continued consulting on best practices

Occasionally, if our partner’s requirements and future plans for the site necessitate continuous feature development and maintenance of the site aside from the items mentioned above (too broad in scope for us to be able to meaningfully support), we will introduce them to one of our preferred agencies for that ongoing relationship. 

🔍 Search the handbook

All pages