SDLC Basics: The Vision Statement

Software Development LifecycleIn the Beginning

In the beginning, there was an idea. The idea took shape and became a project. The project became an application and the application got used.

Or maybe it didn’t get used. Maybe it was completely the wrong application for the business. Or maybe it was the right application, but no one knew exactly what to do with it.

Although there are many places for a project to go right or wrong, having a clear vision, communicated effectively to the project team, is a good place to start down the right path.

Vision and the SDLC

Maybe your New Year’s resolution is to bone up on the Software Development Lifecycle to see how your current project can be improved. Or maybe you’re about to lead your first new project. Wherever you’re at, be sure to take a step back and review the basics. This installment of SDLC Basics will focus on the creation and documentation of the Vision Statement.

The Scenario

A large software company’s sales force use five applications. One app is to track small business customers; the second app tracks corporate customers; another app tracks government customers; the fourth app is for order management; and the final application is for reports. Oh yes, and then there are the applications for calendars and to-do lists. This doesn’t sound very efficient, does it? So, someone in the company, maybe a sales manager, has an idea to create one application to access the data from the other applications and roll key data points into a dashboard.

Executives meet and the project gets the support to get underway. The Vision Statement is created and communicated to the project team. What should the vision statement look like and how should it be communicated?

Some Dos and Don’ts

  • The Vision Statement should be short and to the point, not a multi-page document. Some classic examples from successful businesses are only one sentence long;
  • The vision should be clear. It should not be cluttered by verbosity;
  • Most (and preferably all) of the project team should “get it”;
  • It should not dictate specifics. That will come later in the SDLC;
  • It should be something that can pull people back on track when “rabbit trails” have been visited.

An Example

For the scenario above, our Vision Statement could look something like this: “We will develop an application that allows our sales force to quickly see sales data and orders for any customer, anytime, anywhere.”

Effective Communication

Now that a vision has been developed, how is it communicated to the team? One suggestion is to include it in an email, memo or meeting to kick off the project. It should also be written at the top of all project documentation – the project scope and plans, development docs, test docs, etc. It’s the constant reminder to the team of the project’s focal point.

In the next installment of SDLC Basics, we will drill down into the details of a Scope Document.

Simple Share Buttons