Most software projects fail. There are plenty of reasons (excuses?) as to why this is the case.
The most common predictor of failure in software projects is a lack of alignment between the development team’s efforts and the purpose of the project. This is where a project purpose statement comes in.
It’s not enough for your team to know the general idea of the project, or the laundry-list of expected features. Your software project needs a clear, succinct statement to direct everyone’s effort.
A good project purpose statement is a concise, repeatable mantra that states the ultimate reason your project exists. Below we’ll cover why you need one, how to create one, and how it benefits your team and the project.
Everyone knows what it’s like to work on a project that has no clear purpose. It’s frustrating and demoralizing to work hard without an understanding of what your effort is for. Without a clear purpose, projects don’t have a throughline that connects tasks to end goals and to the overarching reason a project exists.
In addition, projects that lack well-articulated direction are especially vulnerable to scope creep. When you do have a laser-focused purpose statement, it’s easy to evaluate whether a task request is within scope. Without it, your software project could become your development team’s wild west. And no one, especially not your client, wants a lawless codebase.
When a project is off and running without a clear direction, it could implode or grow haphazardly until its original purpose is unrecognizable. For example, take Twitter’s recent foray into “Twitter Blue.” Who was it for? Why did they build it? From the outside, it appeared that no one really had those answers, and the project suffered because of its lack of purpose.
A project purpose statement is a crucial tool for creating alignment. A crisp, articulate purpose statement is a clear internal sales pitch that keeps your entire team on the same page, brings a sense of direction to each part of the project, and connects even the most arcane tasks to the end goal.
Who should write the project purpose statement? Ideally, the person who conceived of the project should be the one to get the ball rolling on the purpose statement. They know exactly why the project exists — or at least they should. Otherwise, the product lead or team leader or someone else with a similarly broad view should take on the responsibility.
When should you write it? The statement should be crafted at latest when a team is assigned to the project — whether that’s before the official kickoff or at the initial meeting. Starting off with an articulate project purpose statement ensures the whole team has the same goals in mind from the jump.
What should it contain? A project purpose statement should take a similar approach to an elevator pitch. It needs to convey its entire meaning clearly and quickly, with as little corporate fluff or jargon as possible. To be effective, your statement should answer the following questions:
A. What are we building? B. Who are we building it for? C. What concrete outcome are we trying to achieve?
This should take the form of A for B so that C.
Here are a few examples:
We’re building a A) CRM tool for B) independent HVAC businesses to C) convert 40% more of their inbound leads to customers.
We’re building an A) assistive mobile app for B) substitute teachers to C) help them build immediate rapport with students by remembering their names.
In addition to answering those three questions, a project purpose statement needs to be simple, concise, and memorable. You want your software development team to be able to commit this phrase to memory and be able to repeat it verbatim.
To achieve that goal, make sure your statement is:
There’s no room for verbosity here. Anyone can explain something in a million words. A good project purpose statement is short and declarative.
The challenge with brevity is that you will have to reduce the word count and leave something important out. Even though that may seem contrary to the entire point of the project purpose statement, it’s not. This statement is for your internal team to stay aligned on the purpose, not to detail every function of the project.
It’s unlikely that your project only does one thing, so a tightly-scoped statement can feel reductive. Though the ultimate feature set is likely to be wider than what’s contained in a single sentence, your project purpose statement needs to focus on the one thing your product must do in order to be what it claims to be. You may have to leave out parts that feel important, but that’s okay. What’s crucial is that the statement defines the soul of the product in a snappy, easy-to-remember way, so it can act as an internal compass that keeps the team rowing in the same direction.
Save the big ideas for another exercise. Your project purpose statement should be concrete and tangible. A good litmus test for concreteness is whether or not the desired outcome can be measured quantifiably. If you don’t have hard data to work with at the very beginning, consider making an educated guess. The number doesn’t matter as much as the clear line between the A, B, and C elements of your project purpose statement.
A project purpose statement needs to outline the value the project seeks to deliver. It’s hard to state in so few words the exact and entire value of a project, but it shouldn’t be impossible.
If you can’t state the specific value you’re trying to deliver in a plain and understandable way, you might need to take a step back and reconsider whether you’re actually ready to start building.
It sounds like the most obvious thing in the world: Don’t start a complex, expensive endeavor until everyone involved knows what they are building, who it’s for, and what it seeks to achieve. Amazingly, though, the vast majority of software projects don’t start with a clear, shared sense of purpose. Even fewer have a concise statement of purpose that every team member can rattle off verbatim.
This statement isn’t just a good exercise to get your team on the same page. It’s beneficial for the project outcomes, too.
It mitigates scope creep by making it easy to understand which features are necessary, and which you can talk yourself (or your coworker) out of.
It sets clear client expectations. A project purpose statement gently forces your client to reveal important details, such as how the product should help the end-user, and what an ideal outcome looks like.
In our experience, it’s the difference between a successful project and one that spirals out of control. A clear, articulate statement of purpose will help you be the team leader who forges ahead with a clear sense of direction, avoiding detours and setting your development team off on a path to success.