joshua hoover

It’s amazing to me how many projects start up without a clear vision. I’m not talking about an idea. I’m talking about a no kidding vision. And, no, I’m not picking on those who start projects on the side or just for fun. I’m picking on the those of us who are involved with projects for our organizations and customers that started up without a clearly defined and well understood vision.

I’ve found that agile projects are especially suspect to charging full steam ahead prior to a vision being created and communicated. Dietrich Kappe from Pathfinder Development wrote a post on this topic and made a similar observation. My favorite line from Kappe is where he points out an advantage waterfall projects have over agile projects in this regard:

Waterfall, by comparison, is marginally better in this regard (but worse in most others), since the right thing to do in the face of poor vision is to not develop software until that vision has been clarified, and waterfall is excellent at not developing software until pretty late in the project.

For some reason many believe agile principles and practices will overcome the lack of a vision for a project. We get so charged up about how we’re going to deliver early and often that we get lost in developing potentially shippable software without a clear picture of what we’re trying to accomplish overall. Before we know it, we’ve got a bunch of stuff developed and that’s about it. I’m guessing that some of this is a result of the following line from the Manifesto for Agile Software Development:

Working software over comprehensive documentation

Why would this one short line cause people to not develop a vision for their project? I think it may be that too many of us have been scarred by attempts to communicate vision in multi-page documents that end up saying nothing and no one reads once they are written. As a result of our past bad experiences, we replace these nonsensical vision docs with working software. In the process, we throw out the baby with the bathwater.

I recently came across a succinct template that I think almost any project or product can use effectively to communicate vision. Joel Spolsky posted one of Jim Highsmith‘s articles on setting a product vision. Highsmith uses the formula from Geoffrey Moore’s book, Crossing The Chasm:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

To put the template into practice, let’s pretend it’s 1999 (and really, who wouldn’t right now considering the economy?) and NetFlix is getting started. The vision for NetFlix might go something like this:

For people who enjoy watching movies and similar media from the comfort of their homes, NetFlix is a web based service that provides the largest inventory of movies, TV shows, and other video available for rent with Amazon.com like product search/browse, recommendations, and reviews, combined with great customer service. Unlike the major brick and mortar video rental chains, our subscription based service can be enjoyed entirely from the comfort of the customer’s home without any worry of late fees.

Not too bad. People might actually understand and remember the vision. Imagine that!

Some may think the template above is only good for products or product focused companies. Internal projects or those that aren’t developed for resale can still make use of the template. The challenge is to think differently about certain concepts. For example, the competition for internal projects is normally one of legacy systems, manually intensive processes, or the status quo.

Bottom line, don’t start a project without a vision. If an active project doesn’t have one, stop now. Get with the key stakeholders and write one together. Remember, vision statements don’t need to be (nor should they be!) long winded, they need to cover the important points in a manner people will remember and carry with them as they get busy developing the solution.