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 DRI should ensure that all of these steps happen, whether or not they execute them personally.
Note that we have recently updated the role of the Diagnostic in the running order but not yet updated this to reflect that. All new projects should have a Diagnostic which resulted in a diagnostic report.
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 project DRI is responsible for writing and agreeing to the final paperwork and agreement with the client.
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 DRI should make sure the opening procedure happens. 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 Production 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 DRI must secure those individuals. If someone previously known to the DRI is a good fit and is available, great, but sometimes the DRI will have to coordinate with the Head of Production to recruit a freelancer or even a new team member, depending on the nature of the work.
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 DRI 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 DRI 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.
The DRI is accountable for translating this original intention into project documentation which then lives on throughout the life of the project, even after its eventual transition into support. They may delegate this duty to project staff as appropriate. 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.
Here is a typical project structure for a new website:
We use a discovery phase in cases where the project vision is not clear from the outset. This is typically the case in larger website builds. Often a prospect will come to us with a sense of what they would like, but no clear, tight scope. Or if they have a clear list of desires, it may not fit their budget. This is the role of Discovery.
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.
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.
QA is its own department, so in this phase, the Production department is essentially engaging them in partnership. The Production department is responsible for providing all pertinent information on the website, its vision and history, and access to an environment to test. Projects should generally have one QA engineer, who will be attached to the project for its whole lifetime, so it is important that they get to know the project well.
QA’s final output is to validate to the DRI that the project is ready to launch. QA must also tweak the documentation as it discovers various details and quirks around the project.
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 production 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.
Project Closure and Handoff
After the project is completed, the project organizer must run the closing procedure. This accounts for things like closing the relevant 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 DRI 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 DRIs who create websites should also be adept at managing a retainer. This is a new mentality for us, and some PMs may need to meet with others who are more experienced in retainer management in order to be prepared.