When starting a project you need to know what you're building and why. The 'what' is pretty obvious, the stakeholder usually tells you they want X and need you to create it. But before I put my hands on the keyboard, I want to know 'why' and for 'who'.

'Why' and 'who' are important guide posts in a project. They'll point you in the right direction for things like user experience, functionality, platforms as well as keep you focused on what's important. This helps meet expectations, keeps everyone happy and that makes life better!

The 'what', 'who' and 'why' can be distilled out in a mission statement.

Mission Statements Are Not That Hard

The process doesn't have to be too involved. No angst filled existential endless meetings are required. In fact, you probably have a good idea of what your mission statement will be from a conversation with stakeholders. It may have gone like this:
"We need a way to manage engineer drawings. They spend too much time looking them up."

All the elements are there:

• What: a system to manage drawings faster and easier than before
• For Who: engineers
• Why: finding drawings is slow

So, the mission statement would be something like:

The purpose of this project is to make drawings quicker and easier to find for the engineering team.

Sure, that's obvious now, but when you get into the fog of development, it's easy for developers and stakeholders to lose sight of the project goal. New features are suggested, scope creep begins, deadlines get strained and ... well, you know how it goes. In the end, nobody is happy.

By filtering every feature, idea, suggestion through the mission statement, it keeps things on track.

If it doesn't satisfy the mission statement, don't do it!

That doesn't mean don't do it ever, just don't do it now, during this project. Make a note of it and review it once the project is over. As I say to clients "That's a great idea! Let's put it on the wish list and we'll come back to it."

Focus the Stakeholders

Sometimes stake holders aren't perfectly clear about what they're looking for. They know what they want, they agree it's a good idea, but maybe the 'why' and 'who' needs some fleshing out.

It's helpful to walk them through the mission statement process. Ok, there might be a little angst, but it's better now than at the end of the project when you hear the dreaded "That's not what we wanted. "

Mission Statement Template

So, the whole mission statement can really be boiled down to:

The purpose of this project is to ___[do what]___ for ___[who]___ so that ___[why]___.

Now That You Have Your Mission Statement...

Once you get the 'what', 'who' and 'why' sorted out, other thing fall into place. 'How' will be dictated by the mission statement, specifics like functionality, deliverables etc. become more obvious. In short, you know where you're going, you just need to figure out how to get there.

Development Team

Developers make decisions all day about how a program is going to work. By keeping the mission statement top of mind, it makes decisions a little easier. It's a bit like a mantra -- although chanting it while coding is not required!

Stakeholders

The reward for stakeholders is they know what they're getting and have a yard stick to measure it. If the end product satisfies the mission statement, it's a success. If not, back to the chanting developers.

Seriously, it helps set and meet expectations -- always a good thing!

Summary

I know there's a lot of different techniques for getting project requirements out there. A mission statement certainly isn't the only one and definitely not the best for all cases. However, I've found it's simple and useful in clarifying what you're building, why you're building it and who is going to use it.