Chapter 2

Set Your Expectations

Summary

What does it mean to get started on this project? Let’s set a scope for what this project will include, as well as give some thought to what “success” means – and your realistic chances of achieving it.

Does This Apply?

Yes, for every project. Indeed, without knowing what needs to be done, there is no project, and without communicating the expectations of the project, there is no buy-in.

This phase might be done in varying degrees of formality, but it will be done whether it’s the writing of a formal document that takes years, or a quick meeting over coffee where everyone “gets on the same page.” The larger the project, and the more moving parts – especially external parts – the more detailed the scope will need to be.

Narrative

There is no greater representation of a project’s need for solid scope and clear expectations than the Stonehenge scene from the 1984 film This Is Spinal Tap.

The band – David St. Hubbins, Nigel Tufnel, and Derek Smalls – are on stage in front of a dwindling, but still adoring, crowd, belting a signature England-meets-sweaty-spandex song about druidic rock formations.

Smoke fills the air as we reach peak show-metal: a bit of stage magic as Stonehenge itself is lowered onto the stage.

But, not quite.

The set piece is only eighteen inches tall.

This Is Spinal Tap is a film filled with shattered egos and miscommunication, but this comes at the climax, as managers clash and the band comes to grips with its slow decline. In the heat of everything, Nigel passed a sketch of Stonehenge to a contractor, and (because the sketch lacked any actual measurements) that contractor took the sketch literally.

As leprechauns dance around their mini-model of Stonehenge, the band looks at each other with confusion and anger. The joke always falls on Nigel for writing down the wrong height (“Nigel gave me a drawing that said eighteen inches! Whether he knows the difference between inches and feet is not my problem – I do what I’m told.”) But at the risk of taking all the fun out of everything all the time11The never-ending curse of the consultant, really.Close, no one really faults Nigel. We fault manager Ian Faith for passing on clearly questionable information, and we fault his contractor for acting on that information.

We fault the lack of effective scope, and we fault that expectations were never discussed nor communicated in any way.

A project often hinges on acceptance and approval of a predefined set of expectations, going off the rails not because a feature is broken or a timeline is missed, but because there was confusion in those predefined expectations.

Which means once we’ve gotten through the glow of the initial decision to do a web project, we need to dive deeper into what that project will actually entail.

When we talk about expectations in this chapter, we’re focused primarily on the expectations of your team throughout the web project. We’re focusing on helping people understand what’s happening, especially for those who are (or consider themselves) stakeholders, including those who may not be involved in the day-by-day process of strategy, design, and implementation. We’re focusing on keeping things transparent, because misunderstood expectations are like very small Stonehenges: they will always be there ready to trip you up.

Agree on What You’re Trying To Do

In the last chapter, we focused on the history and purpose of the initial project spark – how we got to where we are. Now, we need to start determining what that spark means. What will this all entail? What do we expect of the team?

Over the next three chapters we’ll talk about the scope of your project, the people you’ll need for your project, and how to begin planning for work within your project. We begin by looking at the various “layers” of a web project and how they relate to business goals and the future state of the website. The number of affected layers means a more complex project, and the more complex the project the more difficult it is to keep within a scope, which means we need to really zero in on what we’re going to tackle. To do this, we ask two core questions:

• What is the business goal?
• Where is your current pain?

Yin and yang, we can reach the two extremes of a project in these two questions: what’s your ultimate, perfect scenario, and what are the horrible things keeping you from that scenario? Web projects are positioned as lofty end goals, but are often embarked upon in an effort to remove or lessen a source of organizational or procedural pain.

Just as business goals vary wildly, so too do the types of web projects. When you consider the vast landscape of how to approach your particular situation, the first thing you need to do is agree on what you are trying to do. Are you just doing a design facelift? A navigation reorganization?

A CMS forklift or “lift and shift?”22A forklift is a type of project where the underlying CMS is swapped for another, but nothing else changes. The new CMS is templated to look the same as the old site, and all the existing content is migrated to the new CMS.Close Or are you doing a total rebuild from the ground up?

What this scoping stage provides us with is a structure. It tells us what we need to do: the layers of the project. It shows us where we need to be flexible: the inflection points. And, it helps us better understand what will make the project a success.

The Stack Model

Every website has layers. Sometimes these layers relate to technology, and sometimes they relate to people. For the purposes of this book, we’ll call this “The Stack Model.” The nomenclature derives from a project structured as a group of disciplines and intellectual assets “stacked” on each other. You start with strategy, then planning, then content, then information architecture (IA), then user experience (UX), then development, etc.

In this book, we’ll look at The Stack Model as follows:

• Design: The general page layout, color schemes, typography, and media assets that give the site its brand presence.
• Content: The words, images, video, and supporting files that convey the information of the site.
• Information Architecture (IA): The organization of content, manifested in navigation, labeling, index structures, and search interfaces. (Search itself might be considered its own layer, but we’ll include it in IA for simplicity’s sake.)
• Content Management System (CMS): The technical platform for managing the content of the website.
• Integrations and Aggregations: The external content and functionality that plugs in to your CMS, such as API integration or embedded social feeds.
• Analytics: The analytic tools (how you track) and implementation (what you track) that provide data about the usage of your site.
• Hosting and Infrastructure: The technical infrastructure on which the site is hosted, either within your organization or externally.
• Governance Model: The organizational roles, accountability paths, and communication mechanisms in place to keep a team working together over time.

When looking at the above list, understand that, in theory, anything in this list can be swapped for a new version without changing anything else in the list.

We say in theory, because the very nature of complex sites often causes a blur between layers. Yes, technically, you can rework design within the same content structure, but often there will need to be some adjustments just to get things past a minimum viable product. Also, some of these layers overlap, certainly. For instance, your CMS will be impacted heavily by your hosting environment, and vice-versa.

Some projects use just some of the layers in this theoretical stack. You might just be reorganizing the content on your site to make it easier to find, for example, which would involve some work on the content layer, the information architecture layer, and, finally, forming content operations to implement the changes. Your CMS might not change, nor your hosting environment, nor your basic governance model.

Other projects impact every layer, from top to bottom – the “full stack.” Those can be the most overwhelming, pulling in multiple different disciplines, all of which have their own way of thinking. A full-stack project approaches things with every possible avenue laid bare, which can bewilder teams and leave them with “paralysis by analysis.”

Inflection Points

Thankfully – and we really do mean thankfully – nearly every project has some restraints, even if it’s a from-scratch full-stack project. There’s a saying that claims a project will “flex” on at least one of three axes:

You can have it fast, cheap, or good. Pick two.

Hackneyed and trite as it is, this saying isn’t wrong. It points out the three major axes of a project.

1. Schedule
2. Budget
3. Features

You can have two of the three, and the project flexes on the third. It’s a game of project musical chairs – there are two chairs, and three players, and when the music stops, the one standing up becomes the inflection point.

It can be cheap and fast, but it likely won’t be good. It can be good and cheap, but it’ll take a long time. And it can be fast and good, but it’ll cost a fortune.

This model can actually be a good way for you to examine your project and ask yourself where it flexes and where your hard limits are. For example:

• “We are absolutely limited to spending $250,000 (rigid budget) and it has to be delivered by the end of the year (rigid schedule). I want to get as many features as possible within those boundaries (flexible features).”
• “Our old CMS isn’t compatible with the new CRM project that goes live on June 1 (rigid schedule), so we have to have the new CRM integration (rigid features) by then, no matter what the budget (flexible budget).”
• “We’re limited on available funds (rigid budget), but we still want a high-quality product (rigid features), so we’re willing to take some of the development in-house, even if it takes longer (flexible schedule).”

Logically, a project has to flex somewhere, or it would quickly spiral out of control. If you have unlimited funds, unlimited time, and want unlimited features, then you have a project that will never end. Your desire for more and more features would expand the budget and schedule infinitely.

Realistically, it’s most common for a project to flex on features. Schedule and budget are normally firmer – no one has unlimited time and money. More often than not, those two variables are the constraints, and an organization is looking to see what can get done within those boundaries.

In Design is a Job, author Mike Monteiro claims “A designer solves problems within a set of constraints.” The same is true in scoping (or “project design,” if there is such a phrase). Your job is to take a long view of your pain points and determine the best possible strategy for solving them within a set of constraints defined by your organization. It might be true that these constraints are determined by you, which means your ability to not only communicate those expectations but also stand by your decisions can make or break the project.

Ultimately, these constraints are the “load-bearing pillars” of your project. They are the first level of expectations we are tasked with maintaining: the very basics. They are the walls of our home, and from here on out any remodeling, interior decorating, or room determination must happen within those walls.

Defining Success

When we talk about success, we’re not necessarily talking about key performance indicators (KPI) like time on page or click-through rate or conversion rate. We’re talking about higher-level goals – goals that should pull directly from those initial “why are we doing this” discussions.

For example, if the reason for this new project is …

There’s a desire to incorporate personalization into the website

… then the goal – and the success therein – will partly be measured by our effectiveness in incorporating that technology into the website.

If the reason for the new project is …

The CMS is no longer supported by the vendor

… then success will, in part, be measured by our ability to choose and implement a new CMS that works for the organization.

It’s all so easy! Except you already see the issues. Expectations for success don’t always live independent from each other, and they often depend on hidden successes that we do not plan for. In fact, it’s necessary to separate the concept of a goal from the expectations that lead to that goal’s success.

Take our “new technology” example above. While we can assume that making that technology work within the existing site is an obvious goal, there are a lot of expectations going unsaid:

• Expectation: This new technology will seamlessly integrate with the current CMS.
• Concern: Is this true, or are we implementing a complex system of patches (and corresponding convoluted workflow) to approximate effectiveness?
  
  
• Expectation: This new technology will streamline our operations.
• Concern: Does this new technology add work or complicate the workflow of staff who may already be at capacity?
  
  
• Expectation: This new technology will make us a more successful organization.
• Concern: We need to develop metrics to accurately measure what we mean by “success.”

Expectations need to be addressed in the same way as the initial project charter: by clearly stating the hidden expectations and plainly defining a success metric. Listing the hidden expectations helps us better define what the project requires:

• Clear definition of how the technology will work within the existing CMS (if it does at all).
• Documentation of how this new technology will fit into existing process workflow.
• A definition of “success” as it relates to the tool’s effectiveness.

It’s only by addressing the expectations of the project – and by determining a realistic definition for “success” – that we can ever really understand the full scope of a project.

Unrealistic Expectations

Most unrealistic expectations are due to someone not knowing what they don’t know – they don’t understand that what they’ve asked for is actually impossible.

It feels like a cop-out, but the truth is that with unrealistic expectations, often the best you can do is:

1. Be clear that expectations are unrealistic, and say why.
2. If expectations cannot budge, then ask what added resources can be allowed.
3. If none of this works, run away.

Communication and Documentation

Creating scope and communicating scope are two completely different disciplines. One is focused on figuring out what you want to do, while the other is interpreting what you want to do in a way that other people can understand without confusion. One is making a list, the second is checking it twice (and also probably rewriting it and then checking it a third time).

We mentioned the idea of a project charter in chapter one, which turns the spark into a formal declaration of project intent. This charter helps guide our decisions and help others understand the purpose.

But now, we’re talking details. Now we’re starting to dole out tasks and look for resources. Now we’re taking a pipe dream and heading to Lowe’s to buy the pipes. With scoping, we’re determining what exactly needs to be done.

The work included in communicating and documenting scope depends on the number of moving pieces connected to the project – and the degrees of separation between project owners and the people doing the work. If you’re doing a quick turnaround internal project, you can maybe get by with a simple scope outline – what needs to be done and who’s going to do it.

But sometimes you’re working with people from multiple departments or even external teams. And, sometimes, a final scope is not determined until you’ve gone through a formal discovery and strategy process. For some, scope is handled in stages – a scope for content, a scope for design, a scope for development. For others, scope is required from the start – a state-run university that requires a formal request for proposal and bid process is going to need everything at once in order to secure allocation for the next year.

Remember: websites are designed and built for organizational goals, but they are often maintained by people who had little to no say in those organizational goals. The need for communicating scope in a way that makes sense is paramount: buy-in on a project begins the second it’s announced, and until things are explicitly described they will continue to be pipe dreams.

Inputs and Outputs

Potentially, there’s a project charter as mentioned in the last chapter. Often, this becomes the first point in which input is collected from more than the high-level decision makers, so input takes the shape of collected functionality needs, gripes, research, examples from other projects, feedback from customers, and dreams.

The output is a formal scope document that may or may not include deeper details. This is not yet a project plan – instead, this is a stake in the ground that clarifies the different needs and expectations of the project.

The Big Picture

This stage is the natural next step after “we need a new website” or “we need to fix a problem.” This is where the problem is formally identified and the needs are documented, and it leads directly into making sure the right people and plan are in place to move forward.

Staffing

In our experience, this phase often grows out of another consulting engagement. The organization has a lingering feeling that something is wrong, so they engage an external consultant to come in for an “evaluation.” That consultant reports their view of what the problem is, and, well, we’re off to the races.

That, of course, is just the impetus. To deliver on this phase completely, you’ll need to have considerable input from the organization. Someone likely above you will need to set the terms of budget and schedule, and business goals need to be agreed on by the major stakeholders.

This will involve a level of intimacy that can be hard to achieve from the outside, but a good consultant can concentrate on bringing people to the table and conducting interviews to get at the heart of the problem.

Normally this phase would be completed by a key stakeholder, often from the communications or marketing department, or a project manager charged with oversight of the project.

Resources

Articles

• “Pinpointing Expectations” - Susan Robertson, A List Apart – focuses a bit more on expectations from a development standpoint, but the basic concepts are there as it regards to sticking up for realistic expectations.