Use a Mission Statement and Doneness Criteria to Provide a Check and Balance
/The first step in the planning process with a team is to define a Work Breakdown Structure (WBS) for the project. The first step in defining a program is to define the:
Mission statement
“Doneness criteria”. Often called the exit criteria, defines what it means to be “done” with the program and typically costs is of about 10 very high-level criteria
These two steps are critical as they drive the entire planning process moving forward. The mission statement and doneness criteria are usually defined initially with the core team (the PM, Marketing and the Team Leads), then input is solicited from all team members as the planning expands beyond the core team. By eventually involving all team members, they they not only get aligned with the program goals, but they get bought-in. As a wise man once said, the way you get buy-in is by involving people.
Mission Statement
When we ask a core team what the mission of the program is, the most common response is a blank stare and silence. This is usually followed by "it's obvious", or "everybody knows it". However, when pushed to write it down, the number of different alternatives is usually equal to the number of the people in the room. In other words, there is no consensus on the mission statement that everyone agrees on. This is one of the reasons why programs get off track quickly. With so many different (often conflicting) definitions, how can you plan?
A good mission statement is short and concise (so people can remember it) and has one or more key elements of:
Product cost
ASP, COGs, BOM, etc.
Schedule:
When is it needed by?
Performance
Any performance metric such as "passed such and such standard"
Customer:
Who is it for?
Product:
What is it?
It turns out, defining the mission statement is one of the hardest steps. They are fully aware of the detail of their own part of the program, but lost when it comes to the big picture.
The mission statement ultimately acts as a driver for the program, the team and a means to provide checks and balance. Back when the Bluetooth standard was still under development, we worked on a Bluetooth chipset development project, where the mission statement went along the lines:
Deliver an FCC approved Bluetooth chipset for a BOM of <$10 for [customer x] by September 2000
Note how all of 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 went over $10, it was immediately discussed in the core team. Trade-offs were discussed and corrective action was taken.
Without this check and balance, marketing and engineering would happily "add" to the product (feature creep), thereby making the product late, too expensive and not what the customer wanted.
The mission statement brings focus and a checks and balance, and is not just a management whim. It is ultimately there to help you and it will be well worth the one hour time spent defining it.
Doneness Criteria
The next step is to define the doneness criteria. This is about 10 (or so) high-level criteria that the program must meet before the program can be called “done”. They usually remove around the next level of detail around quality and performance. Staying with our Bluetooth example, the doneness criteria was (simplified):
Radio chip qualified and in production
Baseband digital ASIC qualified and in production
Bluetooth software (layer 1, 2 and 3) completed
Bluetooth certification obtained
Data sheets completed
Customer demonstration module available
A simple example of a mission statement and doneness criteria of a project
High-level Incremental Milestones
The next step is to define the high-level, incremental milestones hat will ultimately fulfill the doneness criteria. These are not functional milestones but are the main incremental milestones (when different pieces of he program come together to achieve a major deliverable).
Like the mission statement, easier said than done. Having done this for over 25 years, it’s never as easy as it looks, yet is critical as this is the start of the Work Breakdown Structure (WBS). get this wrong, and the schedule ends up being a mess.
Again, coming back to out Bluetooth Project example, the major milestones were:
Preliminary system architecture agreed
RF ASIC evaluation board delivered to key customers and development partners
Digital baseband ASIC delivered to development partner
First Bluetooth link established
Audio and data functionality verified
Piconet functionality verified
Low power modes, encryption, whitening and internal interoperability testing completed
Bluetooth internal qualification completed and certification granted
RF ASIC ramped to production
Digital baseband ASIC ramped to production
Then the doneness criteria for each of these major milestones was defined.
This is a good example as it encompasses an overall architecture phase, an RF and digital baseband ASIC chip development, software development hen all coming together to establish a basic bluetooth link. Once established, the each step gets incrementally but manageably more complex, verifying more of the system functionality until eventually the system ends up in production.
Taking a step back, the intent of each of these planning steps is to define the architecture of the program, much the same way when developing a system, an IC, software, the first thing you do is definite architecture and the interfaces. When this is done properly, each of the steps becomes manageable.
How long does it take?
When we engage with a team we ask for 2 days for this initial macro planning workshop. During these 2 days we are able to get a first-pass through the planning process outlined above, to the point where we can get a critical path to a target, in order to understand the gap between when it’s needed and when it’s going to be done). During this workshop we start the pull-in process (when the team realizes they are late before they start).
During the second day, we usually bring in more of the sub-team members to scrub the schedule.
Although people grumble that they have to take 2-days out of their schedule for “planning” (something engineers typically hate), by the end of the 2 days they are usually engaged. An analogy of not doing this is to rush into developing a system without mapping out the high-level architecture and the interfaces.
We’ve proven time and time again that the time invested upfront to define the program will result in a schedule that over time can be accelerated with the right team.