Using a mission statement to provide "checks and balance"

/
Image from fastProject, starting point for defining the scope of a project during planning

Image from fastProject, starting point for defining the scope of a project during planning

The first thing we do with a team while defining a work breakdown structure is to define a mission statement.

Two things usually happen. The first response is the eyes start rolling ("why do we need to do this?"). The second response is usually "it's obvious", "everybody knows it" and when asked what it is, the response is usually "to get the product out last week to make a lot of money." Well, quite frankly that kind of mission statement is as about as useful as a wet rolled-up newspaper.

A good mission statement, is short and concise (so people can remember it) and has one or more key elements of:

  1. Product cost: ASP, COGs, BOM, etc.

  2. Schedule: when its needed by

  3. Performance: any performance metric such as "passed such and such standard"

  4. Customer: who it's for

  5. Product: what is the product

So, when we walk the team through defining a mission statement using these elements, it turns out that everybody usually isn't on the same page and more often that not, cannot either answer or agree on the answers to these simple questions. Hence the reason for defining it. Touche. It turns out, it;s one of the hardest things a team does: they are fully aware of the detail but lost when it comes to the big picture "what are we trying to do."

The reason why it's so important to define a good mission statement is so it acts as a driver for the program, the team and means to provide checks and balance. We worked on a Bluetooth system development, where the mission statement went along the lines:

To develop an FCC approved Bluetooth model for an BOM of <$10 for [customer x] by September 2000

Note how all the 5 elements above are evident in the mission statement and it is short and concise. This mission statement was in every team member's mind. The moment the BOM when over $10, it was immediately brought to the attention of the core team. Trade-offs were discussed and decisions were made quickly.

Without this check and balance, engineers would happily "add" to the product and it would not be until late in the program they would have had to deal with a product that was too expensive...and expensive to change. Well worth the one hour time spent defining it.