One challenge in leading teams is keeping people focused on the same goals for long periods of time. All leaders fear that decisions they make won’t be remembered. It’s possible that the reasons people had for listening to them today will be forgotten or ignored tomorrow. Perhaps worse, managers themselves may forget in which direction they are supposed to be leading the project. So, the challenge of project management is not only to get things started in the right direction, but also to keep it headed that way.
Chapter 2 included a brief overview of planning documents, such as MRD, vision, and specifications. This chapter focuses on the vision document, the most important of all planning materials. I’ll explain why vision documents are worth the effort to write, what qualities good ones have, and how to continually get value from them over the course of a project. When they are used properly, they conclude the initial planning phase of a project (see Figure 4-1).
Figure 4-1. A finalized vision document signifies the end of the planning phase, just as final specifications signify the end of the design phase.
But one note before I start: there are many different ways to divide the ground these documents cover. Some organizations don’t use MRDs or business justification documents at all, and instead roll that information into the vision document itself. A few times I’ve been on very small projects where vision-type information was collapsed down into the specification itself, or simply kept on a wiki or in email. So, don’t worry about how many documents you should have or what they’re called—that’s not important. My advice applies well to any process you use.
Daniel Boorstin, author of the great works The Creators (Vintage, 1993) and The Discoverers (Vintage, 1985), once said that the written word was the greatest technology man ever invented. Without it, we’d be dependent on our notoriously unreliable memories[23] to do complex things like make dynamite (hmmm, how much nitroglycerin goes with how much charcoal?) or nuclear reactors (the uranium goes where?). Specific to the pursuit of project work, writing things down makes it possible to define engineering work or capture the overall objectives for entire teams only once, and reuse that knowledge many times. Documenting the details of decisions offloads the burden of precision and recollection from our minds down to paper; all we need to do to recover them is look at what we wrote. That freedom of mind allows us to go at full speed at the task at hand, confident that we can return to what we wrote if needed (say, when we lose focus, have disagreements, or get confused). It follows that the more complex and involved any effort is, the more likely it is that writing down some of the details about it will improve the chances of success.
The larger a project, the more complex and involved the work will be. A team of three might be able to talk enough in the hallway to coordinate, but a team of 20, 100, or 1,000, working in different time zones, doesn’t have that luxury. Instead, someone has to define the higher-level plan for all of the work before much of it begins, and she needs to document it in a way that everyone can easily use as a reference.
Writing things down also serves to communicate the intentions of a team across a large organization. If group A can represent their core ideas and high-level decisions in a short document, then groups B and C can understand group A’s intentions and raise questions or provide feedback quickly. The more complex and involved a project is, the more important that short document becomes, because complex projects have higher odds for miscommunications and costly mistakes. And, as a bonus, new people to the team (senior and junior alike) can read a distilled version of the core ideas of the project and get up to speed much faster than if they had to learn those core ideas on an ad hoc basis.
I’ve seen vision documents that were 50 pages long, carefully formatted with research, diagrams, and strategic thinking. I’ve also seen visions that were a couple of pages of bulleted items, with a few sentences describing each one. Depending on the project, different amounts of structure and planning are needed. Don’t make the mistake of thinking that planning documents are fixed, rigid things: they’re just documents. How deep or fancy they need to be depends on the nature of the project and the culture of the team. However, good vision documents tend to cover the same kinds of questions, but the material varies in depth and rigor.
To help you figure out how much structure and investment your vision document needs, consider the following questions:
How many valid questions does the team itself have about the future? How much do people expect to know about what they’ll be doing and why they’ll be doing it?
How many different people will be impacted by the project? How many different organizations are they in? How will you properly set expectations up, down, and across each organization?
How much explaining of decisions do you want to have to do in person? (A good vision should stand on its own in representing the project to many people.)
What depth of feedback on project direction do you want from others?
How much depth of knowledge and thought should a project leader provide to the organization as part of making project-level decisions? (A vision provides the evidence of this.)
During the course of the project, how much depth of strategic thinking should the team have access to?
What research do executives or senior managers expect you to do as part of project planning? How will you deliver this to them?
Will there be a need to remind the team later on of what the goals are? Are people likely to argue later about specific issues that have been agreed on recently?
The more detailed and stronger your answers are to these questions, the more value a vision document will have. If few of these questions apply, go with something lightweight and informal. If many of them apply, and reading them made your stomach churn, you’ll need heavier stuff.
These questions are more accurately questions of leadership than purely about visions. However, a vision document is the only way to simultaneously address many of them. Even if working alone (solo-superman), writing down an informal vision document (e.g., a list of goals) for the week, month, and year goes a long way toward concluding those periods of time with something to be proud of. Once things are written down, it’s easier to hold people accountable for them, even if you’re only being accountable to yourself.
To talk in detail about visions, I need to define some terms. Visions, team goals, and goals are often used in overlapping ways. Here is a clarification of how I’m going to use them:
Vision. Defines the high-level goals for the entire project. This may also include a vision statement or uber-goal. (High-level goals defined by a vision are sometimes called objectives to help distinguish them from lower-level goals.)
Team goals. The subset of the vision a particular team is responsible for, which is defined in greater depth than the vision. (For example, team A might be responsible for the database system and its goals, and team B might be responsible for the search engine system and its goals, but both share the same project vision.)
Individual goals. The subset of team goals that an individual is responsible for.
On small projects, there’s little distinction between team and individual goals (see Figure 4-2). A project might even be small enough that there’s no need for these distinctions. But on larger projects with 50 or more people, this layer is necessary. Working on large teams for much of my career, I’m used to seeing these three layers: one set for the entire project (vision), one set for each feature or area of the project (team), and one for the personal goals for each employee working on the project (individual). The first two are of public record for the entire team; the last one is between the employee and his manager.
As an example, let’s take project Hydra, an intranet web site:
Hydra vision. The Hydra web site will make the most frequently used intranet sources (search, accounting, inventory, HR, travel) easily accessible from one web site, with one easy-to-use interface.
Team A will be responsible for making search and accounting easily accessible and simple to use. Team B will be responsible for inventory, HR, and travel.
Fred (team A) will design and implement all features required for searching. Mike (team B) will drive the overall design effort and write all user interface specifications for Hydra. Bob (team B) will design and implement all the features required for HR and travel.
There is strong inheritance from the top down: team goals inherit from project goals, and individual goals derive mostly from area team goals (the primary exception being individual needs for training or growth that can’t be satisfied within the project). Provided these three levels are well crafted, everyone should show up every day, motivated to do work that makes local sense to them and contributes directly to the entire project. The time it takes to set up this structure is worth it. It creates natural synergy and makes managing a project easier (see Figure 4-2).
Different documents should correspond with these three levels of definition (or minimally, different discussions). For the entire project vision, the group manager or uber-project leader should be leading the creation of the high-level vision document. She should then expect area or component leaders to interpret those high-level directives into goals for their own areas, possibly lifting specific themes or goals from it. Finally, line-level contributors should be discussing with their team leaders what their individual goals and responsibilities are, derived from those team goals.
Because everything derives from the high-level vision, the team’s overall leader should invest more energy in it than any other early planning material. The five most important characteristics are: simplifying, intentional (goal-driven), consolidated, inspirational, and memorable.
The most important quality is a simplifying effect on the project. A good vision will provide answers to core questions and give everyone a tool for making decisions in their own work. While a vision will raise new questions, these should be fewer in number than ones that no longer need to be asked. In the early phases of a project, people should be referring to the vision all the time—in discussions, emails, and meetings—actively using it as a tool to help make decisions. The project manager should be on the lookout for this and be willing to modify and revise the vision to include unforeseen questions that will make it more useful to the team. The vision should never be like a religious relic, protected inside a glass cabinet. It should be more like a rulebook to a good board game, providing clarity for everyone involved, making boundaries clear, and quickly settling disputes or miscommunications. It should be worn out from use and have notes scribbled in the margins. Its effect should be to put an end to the preliminaries quickly and get people into the heart of the action with the confidence that the project can succeed.
The vision document is a project’s first source of goals. It sets the tone for what good goals look like, how many goals there should be in a plan, and how much refinement the goals may need before they are complete. A well-written goal defines a clear intention for the people on the team. Enough information is provided in the goal itself that people will know when it’s been completed. They should also be able to easily separate out activities that are likely to contribute toward the goal from ones that won’t. Writing good goals is difficult and highly subjective; it takes many revisions to obtain a strong, well-written goal. The fewer high-level goals, the more powerful the vision document becomes. As a rough rule of thumb, a project vision document should have somewhere between three and five high-level goals (see the upcoming catalog of good vision statements for examples).
One popular business acronym for writing good goals is SMART: Specific, Measurable, Action-oriented, Realistic, and Timely. The idea is that if a goal has all five of these attributes, it’s likely to be well defined enough to be useful (however, subjective judgment remains as to how specific or realistic a goal should be). Another technique that can help with goals is playing devil’s advocate: ask how a project can still fail if its goal can be satisfied as written. Then consider if there is a way to more carefully phrase the goal, or if another bit of supplemental information should be provided to support the goal.
For the vision document to have any power, it must consolidate ideas from many other places. It should absorb the key thinking from research, analysis, strategic planning, or other efforts, and be the best representation of those ideas. Any vision for a team is a failure if understanding it requires the reader to do even half the work of the author.
For this reason, it’s best to separate out the goals and directives from all of the supporting arguments and research behind the plan. There should be one place to easily find all of those supplemental thoughts and materials (a simple web site), and it should encourage the diligent (or the skeptical) to go deeper than the vision document itself. Consolidation does not mean jamming together a random assortment of references—it means that there should be coherence among them. They should use the same template and formatting, or at least be easily printable as one volume: not for the sake of process, but because this makes it easier to read, which forces someone (preferably the head honcho himself) to consider exactly how many references or sources are important for people to be familiar with. That number shouldn’t be zero, but it also shouldn’t be 15 or 20 papers, essays, or reports.
Inspiration never comes from superficial things (and as an aside, even superficial people require genuine inspiration). To connect with people, there must be a clear problem in the world that needs to be solved, which the team has some interest or capacity to solve. While a charismatic team leader can help, it doesn’t change the quality of the ideas written down in the vision. By giving the reader a clear understanding of the opportunities that exist, and providing a solid plan for exploiting it, people who have any capacity of being inspired, will be. Although with programmers and engineers there is a tendency to draw inspiration from technological challenges, it’s easy to derive those challenges from the real-world problem that the project needs to solve. Make sure everyone understands that the project is being funded to solve the real-world problem and not just the technological one.
Being memorable implies two things: first, that the ideas made sense; and second, that they resonated with readers and will stay with them over the duration of a project. They might not remember more than a few points, but that is enough for them to feel confident about what they’re doing every day. (Note that if the vision is too complex for anyone to understand, it’s impossible to achieve this effect. People rarely remember things they don’t understand.)
Being memorable is best served by being direct and honest. If you can strike at the core of decisions and communicate them well—even if people don’t completely agree with those decisions—they will stay with people longer than those from a vision full of ideas they fully believe in but were buried in weak and muddy writing. So, strive to make the vision clear and confident. Give the team strong concepts and ways of thinking about the work. Avoid flashy ideas that might inspire people in the short term, or capture a fad or flighty trend, but run out of steam after a few weeks, when the value of the idea has been spent.
At the heart of a vision should be answers to many of the following questions. It’s common for these topics to be major headings in a vision document or listed at the end as part of a Q&A section. (Although, when these questions are not addressed in the core document and are made into an appendix, expect to see engineers flip to the last pages, which implies something negative about the strength of the writing that preceded it.)
Answering many of these questions demands involvement from marketing, customer research, product design, or other experts who are available to you—and this should not be an afterthought. Some of the following questions are intentionally similar to questions asked in the previous chapter on planning. The difference is that these questions are angled heavily toward priorities and decisions, rather than context and understanding. During planning, there was room for exploration, but the vision is obligated to take a stand and be decisive.
What is the one sentence that defines this specific release of this specific project? (This is often called the vision statement, or for the cynics on the team, the visionless statement. Examples for this are offered shortly.)
How does this project contribute to the goals of the organization? Why is this project more relevant than others that also might contribute to the goals of the organization?
What scenarios/features for customers are essential to this project? (Priority 1.)
What scenarios/features for customers are desired but not essential? (Priority 2.)
Who are the customers? What problems does this project solve for them? What evidence or research (as opposed to opinions and speculations) supports these claims? How will customers get their jobs done without this project?
Who are the stakeholders for this project in the organization (the people with power over the project but who are not necessarily customers)? What role will they have in the project? (We’ll cover stakeholders in Chapter 16.)
Why will these customers buy or subscribe to this service? (Obfuscated versions of “because it’s cool” or “because they have no choice” are not acceptable answers. However, summaries of what target users are currently paying for, and how the new project fits into their lifestyles, budgets, or daily habits, would be. Of course, in an IT situation, the answer may be “because they have no choice.”)
Who are the competitors, and how will this project compare to them? (Prior releases of similar projects should be included as competition, or possibly nontechnological alternatives such as pencil and paper. The Palm Pilot’s simple design is attributed to seeing paper as the primary competitor, not other electronic devices.)
What solutions for customers have been requested or suggested but will definitely not be part of this project?
How is this not a technology in search of a problem?
What is the project not going to accomplish? (Don’t be pedantic: list the things people might guess or assume would be part of the project, but won’t be. Include political, business, and customer perspectives if they’re not already covered.)
What are some likely ways for this particular project to fail, and how will they be avoided or minimized? (In early drafts, there might only be risk evaluations, but without plans for managing/avoiding them.)
What other companies or groups is this project depending on in order to succeed? What other companies or groups are depending on this project in order to succeed?
At a high level, how will the work be divided across the team? Who are the leaders for each major sub-area of the project, and what authority do they have?
What assumptions are being made that the project depends on? What dependencies does this project have on other projects, companies, or organizations?
For any question or point that is considered critical, there should be rock-solid thinking behind it. The project manager should seek out the smartest and most skeptical members of the team, and enlist them to poke holes in the logic and supporting arguments behind key statements. Because these points will be the cornerstone of everything that follows, they should be irrefutable. This feedback process is often best done informally, one-on-one or in very small groups, with the project manager incorporating feedback and considering new perspectives after each discussion.
Even for those among us who naturally communicate well, visions and leadership documents bring with them the potential for great pretension. Suddenly there’s an opportunity to show to the entire organization how grand your thinking is—the ego temptation is hard to resist. But pretentious writing defeats its own purpose: instead of communicating ideas, it obscures them.
The most common mistake in writing visions is equating complexity of thought with complexity of presentation. Contrary to what many people think, it takes significantly more work to express sophisticated ideas in a simple manner than otherwise (writing code and writing essays share this relationship). Ten pages of summaries, disclaimers, charts, and diagrams can easily obfuscate the central ideas of a vision. Their inclusion might only prove the insecurities and lack of concision on the part of the author (read any academic or philosophical journal for bountiful examples of this). Sadly, this behavior is easy to copy. It tends to start at the top of organizations and bleed down, causing near-fatal levels of poor communication. In some companies, it’s hard to be sure the documents are in English.
For this reason, the vision document establishes more than just the direction of the project. It establishes the tone and communication quality people should expect from each other while working on the project. It’s a chance for team leaders to demonstrate for everyone else how to cut to the chase and communicate well. On the contrary, if the vision is bloated, jargon-laden, pompous, highly speculative, inconsistent, or even delusional, it shouldn’t be a surprise that the resulting project will have the same characteristics.
Good vision documents never shy away from their core ideas. They avoid prefaces, disclaimers, and introductions, and they make no attempt to hide from the key (and perhaps controversial) decisions that will define the project. Because of this, they are often short and easy to read. Many poor vision documents I’ve read were large volumes that were intimidating not because of the sheer brilliance of thought they expressed, but because of their physical size. The intimidation worked: no one read the document.
Many of the worst vision documents I’ve seen were generated by committees. Small committees can sometimes act as good sounding boards, but they should never play the role of primary authorship or decision-making authority. Unless there is exceptional chemistry and shared vision (generally anathema, given the politics of committees), the prospects of clear, concise, passionate writing are dismal. Therefore, the project manager or leader needs the authority to author the vision and drive one voice into it, with the full understanding that it’s her job not to write a reflection of her own personality, but instead to encapsulate the best ideas and thinking available in the organization. The one author should be a strong collaborator who is able to incorporate the best ideas and opinions of others into a single document.
A canonical reference for primary authorship is the Declaration of Independence. In 1776, the Continental Congress formed a committee to write this document. The committee met several times, but in recognizing the importance of clarity in the document, asked Thomas Jefferson to write the draft. Much like I’m suggesting for a project team, Jefferson wrote many drafts and engaged in discussions with Congress over the course of several revisions. The group delivered a final document to Congress several weeks later. This role doesn’t need to be highly visible; Jefferson did not do a book-signing tour or product endorsements for his work on the Declaration. He was simply granted the authority to make use of his skills in the best service for his team.
It should be understood that clear thought does not require many pages. The most effective leadership documents in the world were not very long. The U.S. Constitution, including the Bill of Rights, is a mere 7,000 words (about 6 pages). The 10 Commandments are 300 words. The Magna Carta is 5,000. Good, clear thinkers are able to distill ideas down to their core and central elements, and they express them in a way that is more powerful than twice as many pages. Volume should never be confused with quality. Unfortunately, because volume is easier to produce than quality, we sometimes give in to the temptation of “If we can’t be good, we might as well be long and perhaps no one will notice” (another habit of committee lead authorship). Although with this in mind, it is fair to ask why I wasn’t able to make this book shorter. Mea culpa.
All of these points imply that the ownership of drafting and revising a vision should be assigned carefully. Odds are good that the best communicator in the organization is not the person with the most senior job title. The highest probability for authoring a good vision requires the project leader to know his own strengths and weakness, as well as those of the people on his staff.
Every organization has different considerations to make in how they plan projects. I can’t offer a simple, five-step plan for how to get from day 1, with no vision, to day 20 (or 5 or 50) with a completed and fully sponsored vision. Depending on how much authority you do or do not have, it may take considerable time to get all of the necessary approvals and have all of the needed conversations to pave the way for the project.
But what’s important is that the process for defining the vision starts before the currently active project for your team is complete, and it needs to be finished before the team is expected to move at full speed on the next one. Sometimes, one individual can be pulled off a project in its last phases and can dedicate half her time to scouting out the key questions listed earlier. The project leader can then pick up the momentum from this work and drive toward a draft more quickly than he could if he were working alone.
Often, the most demanding part of this process in large organizations is working with senior management to coordinate what needs to be done (see Chapter 16). Are there plans from the CEO or executives for the entire company that impact this next project? Are there engineers or other thought leaders who need to be consulted? Who are leaders in the organization (both the local team and the entire company) that have expertise, or political influence, that you need to be aware of and build relationships with? Are there core ideas that you are expected to deliver on, or at least consider delivering on? Do other projects in the company need you to deliver something to them so that they can succeed in their efforts?
In good situations, the senior managers provide clear answers to these questions and acknowledge the uncertainty they are creating for the project when they leave good questions unanswered. In bad situations, a heavy burden is placed on the project manager to create her own answers and learn only by trial and error what the real boundaries are. (Alternatively, if you are in a small shop and have only your peers to answer to, all of these senior management questions and burdens are, for better or worse, yours.)
In any case, the nature of the work is the same. Given a projected timeline between completion of the current project and the point in time when the new project needs to be at full steam, intermediary points need to be set for rough drafts, reviews with leaders that represent the entire team, and complete first drafts of a vision for the project. Expect that at every point of review, time will be spent revising and improving the draft (as opposed to assuming that every meeting will end with the room nodding in agreement). Start small, and gradually increase support for the core ideas over time, making them better after each opportunity for feedback. The timeline for this process should be made public (see Figure 4-3), and the people in the small group shouldn’t be hidden away in special offices or in other buildings. They should be visible and accessible to the team (although care should be taken not to distract them from the current project). Encouraging questions and visibility always helps smooth transitions into new work.
Part of this process must include a presentation of the key ideas, and the draft vision, to the entire team (aka all-hands meeting) early enough that it is not complete pretense, but scheduled late enough that there is something substantive to say. While this is scary for new leaders, if a meeting is held at the point in time when core ideas are strong but some questions remain, the opportunity is created for everyone on the project to see the vision as something alive and accessible. They won’t reject it if it’s something they can still influence and question. If the vision has grown up through many conversations and opportunities for feedback, the rollout to the team will feel natural to everyone involved.
When the vision is completed, the planning phase is over (see Figure 4-3). The team should have the information needed to do good design work that satisfies the goals. If a review process like the one shown in Figure 4-2 has been used, the team should have a head start on design because they’ve been made aware of the general direction early on.
I’ve read dozens of vision documents in my career, and there are certain patterns the bad ones share. Lame visions have no integrity: they don’t offer a plan, and they don’t express an opinion. Instead, they speculate, and avoid the possibility of being wrong. If the vision doesn’t take a clear stance on what should happen, the team leaders will never fully invest emotionally behind the effort, setting up the project for failure. In the film Fight Club, Tyler Durden says, “Sticking feathers up your butt does not make you a chicken.” Writing a document with the word vision in the title doesn’t mean you have a vision. You can have all the right meetings and use the right document templates and still miss the entire point of what vision documents should do. In the same sense that having the job title project leader doesn’t magically make everything you do an act of leadership, calling something a vision document doesn’t mean it will have the effects I’ve described previously.
Table 4-1 shows some of the common things I’ve seen in impressive-looking vision documents that disqualify them from having project leadership value.
Table 4-1. Common lame vision statements
Lame vision statement | Example | Why it happens/fails |
|---|---|---|
The kitchen sink | Maximize our customer’s ability to get their work done. | Too broad to be useful. This is a mission statement for an organization, not a vision for a project. |
The mumbo jumbo | Develop, deploy, and manage a diverse set of scalable, performant, and strategic knowledge-management tools to best serve our constituents, partners, and collaborative organizations, improving the possibility of overall satisfaction among our diverse customer profiles. | This is jargon-based committee-speak. It uses complex language to hide the absence of strong ideas. No one can know what this means; therefore, it can’t be useful. |
The wimp-o-matic | We may eventually consider trying to do something that’s kind of better than what we’ve done before. At least that’s what we think our vision should be now. But don’t go too far because we think it might change again pretty soon. | Everyone will see how spineless this is, and there is nothing for the team to rally around. |
What the VP wants | Mr. VP’s vision for our corporation is to be the best producer of widgets in mid-size markets, and we will work very hard to work up to Mr. VP’s standards, using every resource at our disposal to make this happen. | “I said so” is not a supportable argument. VPs are obligated to provide reasons for important decisions, and that’s what the vision is for. |
In this section, I provide some examples of good vision statements and project goals pulled from my own experience. Although I’ve changed the details, it’s easy to imagine what working on these projects would be like, as well as what the goals underneath the visions might contain.
Here are examples of good vision statements:
SuperEdit 3.0, the editing tool for experienced copy editors, will make the top five most frequent customer scenarios easier to use, more reliable, and faster to operate than SuperEdit 2.0.
Superwidgets.com will be the premier widget-purchasing site on the Internet for purchasing agents at medium-size corporations. It will make the entire process of widget purchasing for medium-size businesses fast, easy, and safe.
The Helpdesk Automated Services Site (HASS) Version 5.5 will address the top 10 customer complaints across the university, without any negative impact on average performance, reliability, or response time across the system.
As an example of good project goals, here’s what the team of people that developed the Palm Pilot handheld organizer used to define their project:[24]
Size. Fit into a shirt pocket. Be light enough not to seem unwieldy.
Cost. Less than a luxury paper organizer ($300 USD).
Simplicity. Should be as simple as paper. Turns on instantly and uses simple conventions.
Sync with PC. Use the PC as a common point of interaction for the customer.
Good project goals like these are clear and simple, and describe the world as it will be when the work is complete. Remember that simplicity is different from difficulty. It was a significant technological and design challenge to create a product that satisfied these goals. The preceding examples of good vision statements might represent huge challenges for those projects. Depending on how “premier,” “easier to use,” and “top complaints” are defined, those projects could have big challenges ahead of them.
The claims made in a vision statement, or in project goals, should be supported or clarified somewhere in the document. So, what these statements mean by customer needs, easier to perform, reliability, and top customer complaints should be defined well enough that informed decisions can be made. If those things are important enough to be in the vision, they are important enough to enlist expert help in fleshing them out to the same precision and detail as technological goals. If claims such as “easy to use” are made, but no one has any expertise about ease of use, the team isn’t set up to meet that goal. In producing the vision, leaders should be assessing what resources are needed to be successful and how resource and skill gaps will be filled (the choices are train, hire, change vision, or cross fingers).
“A finger points to the moon. Do not confuse the finger for the moon.”
—Zen parable
Visions earned their name for a reason: they are supposed to appeal to our capacity to imagine and visualize a specific kind of outcome. By looking at a picture, we absorb many levels of information all at once. For many complex concepts and ideas, pictures provide faster access and greater clarity to more people in less time than words. I’ve had dozens of conversations in my office with programmers or architects who are struggling to clarify points of an argument, only to end when one of us finally goes to the whiteboard, quickly sketches out the idea, and asks, “Do you mean like this?” Then usually we all laugh at how much time we wasted trying to explain object models or designs with our words or our hands, when a marker and whiteboard would have been much faster. I think American culture emphasizes verbal and mathematical skills over drawing and artistic skills, and most professional people’s reflexes have been trained to go in that direction. I’m convinced that, to our detriment, we forget the power of images in expressing ideas.
The best vision documents include visual images. They provide rough drawings, mock-ups, or prototypes of what the final result might look like if the vision is followed. These were offered as suggestions and rough cuts, giving people just enough of an idea to help the goals in the vision crystallize in the readers’ minds. It’s made clear these mock-ups are far away from a final version of what will be built. Very far. Instead, they are presented as just one early attempt to fulfill the ideas in the vision. This kind of speculation enables people to talk about the work itself, rather than only the abstractions of the work provided by the vision.
Mock-ups and prototypes often resonate more with the most hardcore engineers and programmers than any object model diagram or code sample. Unlike those familiar and abstract forms of expression, the visual prototype shows something that doesn’t exist yet, but can. Skyscraper architects and automobile designers make many physical mock-ups and prototypes to help them understand the ideas they are working with and get feedback on those ideas from others. Filmmakers use storyboards for the same purpose. Good vision documents shouldn’t shy away from using similar techniques. Showing a sketch of the final thing allows every individual to put his own work in a larger context. The team members aren’t just building a component anymore. They now have an idea of what their component will make possible when it’s finished.
Just because a project doesn’t have a user interface or interact with customers doesn’t mean it can’t be visualized. How will the world change when the project is finished? Perhaps the vision is about the elimination of some problem or frustration for people (slow servers, crashing databases, etc.). This can be visualized by showing before-and-after views (or simulations) of the same web site—or a prototype that compared the sequence of steps customers will have to do before and after—expressing how much simpler things will be when the new architecture or database is implemented.
There are often many ways to visually express ideas, regardless of how abstract or technical they might seem. If the project will allow customers to spend less time at their desks, show an empty chair by a desk. If the project will make the database faster, show two demos, one before and one after. If the failure rate of an embedded system API will decline by 10%, show the graph of a test case that’s being used to measure this, before and after the project. Give the team a visual image no matter how dull or boring it is, to frame around their individual work.
If this end result cannot be visualized—even as just a sketch, a mock-up, or a chart—then I’d argue that the vision is not clear. If you can’t find any visual representation of the impact of the project on the universe, be afraid that it’s directed toward something the world doesn’t need, or that it isn’t well defined enough for you to be successful.
This skill of imagining the future and visualizing ideas, particularly when customers are involved, is the domain of designers. Sometimes they’re called interaction, product, or even industrial designers. They are professionals who have been trained in how to convert ideas into images and abstract thoughts into the details of what customers will see. While some engineers or project managers might have these talents, few have cultivated them into skills. If ease of use and customer satisfaction are goals, then the services of designers should be acquired early on in a project, and contributing this aspect to the vision would be only one of the natural contributions they would make to the project. If brought in early enough and granted authority to be truly involved, they not only make products look good, but also will contribute significantly to making the product itself good.
One of the original copies of the U.S. Constitution sits in a vault, behind thick panes of Plexiglas, in a museum in Washington, D.C. Although it’s safe and secure, I’m certain few people read it in this format. When ideas aren’t accessible or kept in the light, they fade away (unless they’re important enough to get their own exhibits at museums). Even on short-term projects, it’s easy to lose track of how daily decisions fit back into the larger whole, and the lack of visibility of the core ideas promotes this kind of entropy. People might be very busy and feel good about the modules and pieces they are constructing, but without frequent and common points of reference, it’s hard to know whether it’s all still going in the right direction. The vision, or the core ideas and goals that are part of it, must be kept alive in the hallways and offices of the people doing the work.
To keep the vision visible, a few core goals should be up on posters in highly trafficked parts of the hallway. They should be discussed openly in weekly or monthly meetings, read aloud to the entire room before the meeting starts. Slide decks or other materials used within the team should have those few core points on the first slide or the first page. Most people on the team, most of the time, should be able to name most of the goals of the project, certainly at least the ones that they are contributing to directly or are responsible for.
But this visibility doesn’t necessarily keep the vision alive. The fact that people have memorized it doesn’t mean they are continuing to use it in their work. Keeping the vision alive requires action on the part of team leaders. They have to continually reapply the same reasoning that led to its creation.
Ask the following questions at every status or leadership meeting through the course of a project:
Does the vision accurately reflect our goals for this project?
Is the vision helping leads and individual contributors make decisions and reject requests that are out of scope?
Are there changes to the vision we should consider that would make #1 and #2 true?
If the leaders of an organization can make the vision document a living thing, they empower everyone else to do the same. The vision and goals stay healthy and can be a continual source of motivation and clarity for the entire team.
This isn’t to say the vision should be modified frequently. On the contrary, major changes should be rare after the project is moving at full speed. But as with a constitutional amendment, the possibility should exist that certain situations may justify change. And that potential helps to keep everyone sharp and the vision’s central ideas in everyone’s mind.
Vision documents distill other planning materials into a single, high-level plan.
Writing things down serves the author and the team. It provides the basis for discussion and a point of reference that doesn’t rely on our fallible memories.
The amount of detail in your vision document varies with the nature of the team and the project.
Team goals should derive from goals defined in the vision. Individual goals should derive from the team goals.
Good visions are simple, goal-driven, consolidated, inspirational, and memorable.
Volume does not equal quality. It takes more effort to be concise than not.
Keep the vision alive by asking questions about the utility of the vision to daily decisions on the project.
Pick a movie (or book) you find inspiring. What attributes of the movie made this effect possible? Imagine you are the film director. Write a short vision statement for the film, listing the attributes you want the finished film to have. If you pick a film, watch the DVD commentary to hear how the film’s creator constructed the film to have those effects on viewers.
Close your eyes and imagine what the project you are working on will be like when it is finished. If the finished project were made into a film, what would its soundtrack be like? Would it be muzak (the bland music you hear in elevators and waiting rooms)? Dance music? Punk rock? Compile a soundtrack for the project, with the help of your teammates, and distribute a CD or playlist to them.
Research visionaries. Select any two: Gandhi, Malcolm X, Thoreau, Buddha, Socrates, Jesus Christ, or Confucius. What were their visions? How did they develop their ideas? What work did they do to express their ideas? To promote and popularize them?
Choose a day, and record/calculate what percentage of your time is spent reading what others have written. Be sure to include text messages, email, instant messages, web sites, billboards, and letters from home, as well as project-related documents. Also, remember to count the time you spend writing down how you spent your time. This exercise will help you understand why attention to writing a vision document is important due to all of the demands on your readers’ attention.
What can happen if someone’s individual goals are in conflict with the team or project goals? Whose responsibility is it to correct this? What actions can they take?
When it comes time for your team to write a vision or specification, print out copies of the U.S. Constitution and leave it on any spec author’s chair, with a note that says, “They wrote a spec for an entire government in six pages. How many do you need to spec a feature?” How does the team respond?
At the beginning of every project, make a communal list of jargon words to be avoided. Pick words you know people will want to use, but which have better, clearer alternatives (that you can offer). Put the list on a public wiki and allow people to add words over the course of the project.
For fun, write the anti-vision. What is the worst vision document you can imagine? What would it include? How would it be written and how long would it be? See if you can come up with vision statements worse than the lame vision statements listed in this chapter.
Identify every one on your team who you would trust to collaborate with you to author a vision document. Write down the reasons why. If you had to pick one person in your organization to be the vision document’s primary author, who would it be?
[23] Read Daniel Schacter’s The Seven Sins of Memory (Mariner Books, 2002); or, watch the excellent film, Memento. They both should help you recognize how limited and unreliable human memory is.
[24] From Piloting Palm: The Inside Story of Palm, Handspring, and the Birth of the Billion-Dollar Handheld Industry, by Andrea Butter and David Pogue (Wiley, 2002), p. 72.
Get Making Things Happen now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
