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 each project should almost always have a lead "Organizer" who ensures that all of these steps happen, whether or not they execute them personally.
All projects should also have a lead Artisan. On a small project the lead Artisan may be the only person doing any production work. On a larger project, the lead Artisan is the “team captain” who directs the work and helps the team get it done. The lead Artisan may change phase-by-phase, for example, a creative director may lead the UX and Visual Design phase while a lead dev comes in for development and launch.
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 in the production team. They must not avoid this, though, since it is important for Production to have input on what Sales agrees to do. 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 estimates, taking meetings with prospects, and showing work. Occasionally, Sales can request that Production create demos or spec design to convince a client of our skills and credentials.
If a proposal is accepted, the sales team is responsible for putting together an SOW. Sales should consult with Production to ensure that the language in the SOW is accurate to the intention that Production had and explained to the client.
After we have a signed SOW, we are ready to begin.
As soon as possible, Production should run the opening procedure to add the project to all of our services and make 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, Production must secure those individuals. If someone previously known to Production is a good fit and is available, great, but sometimes Production will have to coordinate with HR 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, Production 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 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.
Production is responsible 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. During the first phase of the project, Production should generate the documentation, using the SOW and proposal as a guide along with the work done in the initial phase.
Here is a typical new website structure:
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.
The extent of each discovery is different and is determined during the sales phase. For a full discovery, 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 Discovery. 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 discovery is completed documentation for the project. We used to do a separate discovery report, but it actually makes more sense to integrate everything into the documentation, which allows it to have maximum effectiveness over the long term.
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.
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 lead artisan. The lead artisan 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.
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. However, we will deviate from this order when the client needs earlier access to enter their content, or for other logistical reasons.
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 project Organizer 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, we must now come to a final agreement with the client. The support department must make the final agreement, but production should facilitate the conversation.
Once the client signs a support contract, the handoff should include a call between the production team and support team to ensure that the support team understands the nuances of the website, its goals, its gotchas, and so on. The support team will continue to ask questions and seek clarifications as they work within the code.