Sometimes it's hard to know how all the pieces of a project come together. This is a general overview of everything that will happen in a project during its lifetime. We wanted to pull external client facing items and internal Cantilever specific process into one easy document. This will help us keep track of where we are at in any given project and what still needs to happen.

This doc is a good starting point for all new hires, in particular for the PM discipline. It is a comprehensive guide on how to start, run and close a New Build project, and also provides links to all of the documentation required at each stage. It allows us to know not only HOW to navigate the different phases, but also WHY we go through each phase.

As with all methodologies, it may sometimes need to be adapted to the relevant scenario, but overall, this framework gives us a solid outline to work from.

The individuals responsible for these various steps will vary case-by-case, but the PM should ensure that all of these steps happen.

While a project is still a sales lead, the Production department collaborates with the Sales team to help identify if we are a good fit for the prospect. The Sales team is the accountable, responsible party in this case. They are in charge of deciding when they should bring it the Production team. Sales and Production work as a team to create a compelling project vision that is then expressed to a prospect.

Typical help during this stage is providing high-level estimates, taking meetings with prospects, and showing work. Occasionally, Sales can request that Production create demos or spec design to illustrate our skills and credentials. With our modern diagnostic process, we try to minimize the amount of time Production staff need to take at this stage.

If a proposal for a

The Diagnostic is where the Sales and Production teams collaborate to create the project vision. The production team should do about half the work during a diagnostic process. The Strategist is responsible for coming up with the final vision for the project. The PM is responsible for writing paperwork that matches that vision.

The extent of each diagnostic is different and is determined during the sales phase. For a full diagnostic, like we did with APC, we interviewed 10-15 internal staff including their leadership and sales teams, along with interviewing one of their clients to hear about the experience of using APC. For a briefer one, we might only do two meetings with a core group of stakeholders.

The typical structure is that we start out just asking people about the client. We get to know their business intimately. We become experts in their field. Then we start talking pragmatically about the website and how it can solve their problems. So a typical structure is a two-day model: One day learning about the company, one day discussing the website and even starting to sketch stuff out. The second day is oriented around resolving the specific questions with which we started the Diagnostic. For example, if the client’s budget didn’t fit their desired features, the main object of day two would be to figure out which features can be deferred to a future phase at the lowest impact on the effectiveness of the project.

The final output of the diagnostic is a report which can be used as a starting point for the project documentation.

During the Diagnostic, we should also recommend a support approach to the client. This should include a rough estimate for the amount of support work we believe will be necessary over which timeframes.

After we have a signed SOW, we are ready to begin.

As soon as possible, the PM should run the opening procedure. This adds the project to all of our services and makes it possible for people to track time.

Typically there will be a window of time before the project needs to start, but the PM should still get it in the system right away so that we account for it properly in our scheduling.

Additionally, many projects require a specialist freelancer or two. Immediately after work is signed, the Strategist is responsible for ensuring that we have the team we need in place.

Prior to a project formally starting, it is usually a good idea to gather the full team who will work on it to brief them on what we have agreed to do, what the estimates and timeframes are, and so on. There is still time to back out or ask to change the plan if anyone has major reservations about either.

After the team is briefed, the PM should usually set up a kickoff call with the client to meet the team. This will constitute the formal beginning of the project. Generally the kickoff call will combine with the first phase of work, so if we are doing UX design, it acts as a UX kickoff in which the designers can ask questions and discuss ideas with the client.

Once we’re kicked off, we perform the project according to the proposal and SOW. It is important that everyone working on the project, from the Strategist to the intern, reads these documents so that they understand what we are meant to be doing. We can always change the plan down the line, but it creates a lot of confusion when people don’t thoroughly read and understand these documents to know what we originally intended to do.

During the first phase of the project, the team should generate the initial documentation, using the SOW and proposal as a guide along with the work done in the initial phase. Then during each subsequent phase, the team responsible for that phase should update the documentation. The PM should ensure that this happens.

Here is a typical project structure for a new website:

In User Experience (UX) design, we define the structure and content of the project, without paying attention to the final visual look and feel. The core deliverable of UX Design are "wireframes" – grey-box diagrams that show what will be contained on a website and how it will work, without specifying anything about color, typography, etc.

Other common UX design deliverables are a "Content Model" document that outlines all the content on the website and what its requirements are, and a "Wireflow", which shows the structure of the website from a zoomed-out perspective.

Reviews and approvals will depend on the size of the project. For a typical 300-500 hour website project, UX design will typically be done by a designer under the guidance of a creative director. The creative director must approve all work before it is shown to a client. Additionally, as the UX gets close to finalization, the QA engineer on the project should review the UX to double-check that it meets our accessibility standards.

The final output of UX, in addition to the above deliverables, is updates to the project documentation that reflect the changes and additional decisions made during the UX phase. At this stage, the design team can also link to the actual wireframe for a page when that page is described in the documentation.

Visual design is where we finalize the exact look and feel of the website, without touching the underlying structure defined in UX.

Nowadays, Visual Design mainly centers around large design choices like colors and typography, which then integrate with the UX design work to create final page layouts. Modern web design tends to be on the more minimal side, so visual design is often somewhat simpler than UX design. Accessibility is a major focus of our design process. No design should be shown to a client without ensuring that it is WCAG AA compliant – or verifying that it is OK to waive this requirement for the specific project for some clearly stated reason that the strategist has accepted.

For a larger project, we will do "mood boards" which act as an abstract touchpoint for the look and feel. This allows the client to assess our aesthetic choices without seeing a full page mockup. For smaller projects, it is more efficient to just design a page or two and get their reactions.

Reviews are similar to UX. Visual Design should almost always be OK’ed by someone internally before being shown to a client, and the QA engineer on the project should validate that it the final product meets Cantilever accessibility standards and provide input on potential changes we can make if needed.

The final output of visual design are of course the completed visual designs, but also updated documentation. Any changes or new decisions must be catalogued in the documentation. Additionally, pages referenced can link to their final visual design, not their wireframe.

Once visual design is complete, we build the site using modern code. The details of each buildout are highly specific to the project, but in general, we begin by importing core functionality from a starter project or existing similar project, then mold that to meet the specific needs of the project. Then we build all the new code required for the project. We generally focus on the frontend (user-facing) portion of the website first, then integrate the backend (functional) portion, including a content management system. See this article on this approach:

The final output of development is a complete website that is ready for QA. At this stage, the development team should not know of any existing flaws or issues with the site. The development team should feel as if the site is launch-ready. When QA has to find obvious issues, it wastes time. So projects should be really solid by the time they go to QA.

In addition, the development team must continually update the documentation. By the time the project goes to QA, the documentation should be 100% accurate to the final specification that the client will expect, and should reflect adjustments made during the development phase to work around unforeseen issues.

The final stages of development should include so-called "Preflighting" work to make sure the site is ready for its eventual liftoff.

In Quality Assurance (QA), we validate that the website meets our standards of usability, accessibility, and technical quality. All design/development projects should have a QA engineer assigned to them. Engineers tend to stick with each site over time. You can find the current dedicated engineer for a given site in the .

As deliverables are being created by the team, the PM should alert the QA tester that they are coming. When the deliverables are ready to test, the PM should assign a QA task to the tester according to the

QA’s final output is to validate to the Strategist that the project is ready to launch. QA must also tweak the documentation as it discovers various details and quirks around the project.

Additional Reading:

Launching a website is a delicate process. We try to launch at times when the public is less likely to see the new site, just in case something comes up. We are big fans of Cloudflare (See how to setup Cloudflare), a reverse-proxy service, which makes it easy to switch back to the old site if needed.

The project team is responsible for executing the launch of the site and monitoring it closely after launch to ensure it is working properly. While a full QA pass after launch is usually not necessary, we like to have the whole team quadruple check key functionality from multiple devices in their own location. This helps validate one more time that everything is good to go.

After the project is completed, the PM must run the closing procedure. This accounts for things like closing the relevant Asana, Harvest and Basecamp projects, conducting a retrospective meeting, alerting the social media team, and so on.

If we decided to recommend support work during the original Diagnostic or during the project, we must now come to a final agreement with the client. The Strategist is responsible for prompting this conversation.

Most of the time, project support should be handled by the same staff that did the original project. This ensures continuity and simplicity of the client experience. This means that Strategist who create websites should also be adept at managing a retainer.