As the demand for websites grows, budgets shrink, and ambiguity reigns, the value of a comprehensive digital division within an in-house studio is continually rising. Yet delivering websites comes with its own unique types of challenges, not least of which is how to talk about websites. In Part One of this series, we discussed discovery and design. Part Two deals with the equally critical phases of execution and quality assurance.

Phase Three: Execution
In a traditional website lifecycle, execution begins when the discovery and design documents are approved. At Merck Creative Studios (MCS), we'll hold a kick-off meeting, invite all the internal stakeholders and review the approved deliverables to date. Often, due to the complexity of the project and the duration of execution, we have multiple developers assigned and we also have roles for the Information Architects (IAs), Business Analysts (BAs), and designers who have contributed to the project up to this point.

There are dozens of ways to effectively execute a website, but they all have some common characteristics - chiefly communication and coordination. If nothing else, make sure your kick-off is effective by establishing everyone's role, a calendar of milestones and the expectations and rules for communicating. This alone won't ensure effective execution, but it will allow the team to identify issues before they become critical and provide a common platform of accountability.

At MCS, we assign a lead developer to work with project management to create work packages that, once complete, will meet the specifications of the approved deliverables. We then have the IA validate the work packages and add exit criteria, which are simple behavioral specifics for which the developer must test before marking her effort complete. Work packages are defined as an effort one developer can do on her own with obvious start and end points. Work packages can be dependent upon each other and together, the lead developer and project manager will work to organize all the work packages to meet specific milestone dates.

Some practices to help avoid common mistakes in execution include:

  • Don't let the process get off track. Make sure your milestones, while denoting a point of relevant progress, are numerous enough to provide for the opportunity for course correction.
  • Don't assume what you thought you knew on day one will hold true on day two. Project plans must be written with the expectation they will change, and work packages must be flexible enough to accommodate emerging specifications. Some changes will need to be negotiated with the client, too. This is often seen as a failure, but in truth, especially if a project is complex, this should be seen as evidence of a process that is working.

Phase Four: Quality Assurance

QA is about effort. If you invest resources in QA, you can do it well. Conversely, small investments have bad results. Like execution, we'll hold a kick-off for QA bringing unbiased people on board and giving them context for review. We'll have different people validate the project from different vantages. A designer will compare the site against the approved mocks and where there are no mocks, against the experience brief. We'll have a copywriter read through all the user interface labels and directions, making sure copy reinforces function. We'll have an IA review the site against the wireframes and the Business Requirements Document (BRD), ensuring the site behaves as we intended.

A project manager is responsible for coordinating all the feedback, organizing it and getting it assigned to the proper people. We'll do QA fixes in one-week sprints by holding a planning meeting in which specific work packages get their assignment, estimate and deadline. Sometimes fixing one problem results in a new problem - this is normal in the early stages of QA. We'll add those new issues to the list and continue with one-week sprints until the entire list is closed.

Some practices to help avoid common mistakes in QA include:

  • Don't sacrifice QA with the idea it will improve project health. More so than any other phase, QA is where commitment to project success softens. There are methods for effective QA, but they require time and energy and far too frequently QA ends up under-scoped. Here is a typical scenario: In the middle of executing on a project, something occurs that could be construed as the studio's fault resulting in additional effort on part of the team. Because of concern over the studio looking badly, it's decided that the team will make up the effort by dipping into the time and hours set aside for QA. To limit the impact of this it is decided that rather than investing time onboarding unbiased reviewers, the people doing the work will QA themselves or it will be left to project management. As a result, a myriad of issues are missed in QA and the project, mistakes and all, goes to the client resulting in precisely the outcome the studio wishes to avoid - them looking bad.
  • Maintain your investment in QA. It is far preferable to deliver high quality with transparency rather than gamble on quality by not doing what's necessary.