(this post refers to my definition of objectives)
When I led my first electrical engineering team, we did not discuss Stop Criteria. We did not discuss objectives much either. We talked about how to do the tasks. We asked “how long do you need to get it done?” And answered: “That’s too long”. Call us the typical team, keeping its head above water. It was not working.
This was the late 1980’s and we were building a small rugged computer + software to run the engine of a car. Another team – mechanical engineers – worked on the fuel flow equations. But the equations changed every week! And in those days, microcontrollers came with lots of outside logic chips that needed changing as a result, so we could never get a stable design. Something had to be done.
I headed the delegation to the project manager to insist that the mechanical engineering team stop changing the equations. That failed. Something about electrical engineers not getting it. We needed a different approach.
We took a step back to discuss our objective – which involves defining the purpose. “Why are we developing this computer?” We were thinking: To run the fueling program of the engine. But we were wrong. That was a small part of it.
Our correct purpose was: Build a computer that could run – on the test car, in real-time – equations that changed week to week. It was our job to figure out a design that would allow for that.
In retrospect, it might have been a good idea for the Project Manager to make that clear – but he told us it should have been obvious. It was to him.
So now, we had a purpose. That’s half the definition of an Objective. We also needed our Stop Criteria. When could we stop working on the design? When would it be good enough?
The trick was to look at our end users. We interviewed the mechanical engineers. They could give us a new set of equations Friday evening, and they would be happy to be on the car testing by Wednesday noon. So we came up with our stop criteria: We would stop designing when we could prove to ourselves that we could turn around a new set of equations in two and one half days. The rest was technical: proving the design could handle that was relatively straightforward for electrical engineers.
* * * * *
These days, I work with teams discussing stop criteria. It’s still not so easy when teams are used to discussing tasks. So here are some of the examples I have collected in coaching sessions. Nothing is ever perfect. But I like these. I feel if I was working on those tasks, I would have a good understanding of what I must deliver.
From the coaching file:
In some cases, the stop criteria will be specific (sadly – it’s a minority):
- A simulation task that provides a margin of error less than 10%
- Software changes that pass all existing regression tests for all modules and classes in sub-system
In some cases, it is subjective – a picture of the mind – the meaning of which must be discussed to be agreed to:
- Using only our documentation, the customer’s engineers must not only understand the functionality but they must also be able to train their own technicians without our help.
- Existing user must not have to relearn how to use existing functions after we update the user interface. Design can stop after we can demonstrate that existing usage is not affected by additions to the user interface.
- User actions should not cause a failure of the system. Even though we cannot fully test for this, we need to imagine a large number of user scenarios, and no matter how weird the action, or sequence of actions, our system must be shown to withstand it and not fail.
Sometimes, it’s in between:
- Each and every technical requirement in our internal specification must link up to at least one customer requirements (objective part). The written description must be free of ambiguity. Our software and hardware teams must understand and interpret correctly what we have written, even if they have not read the customer specifications themselves. (subjective part)
* * * * *
If you feel like it, post a few more examples of your stop criteria. It could be useful to others reading here.
