Several times in my best practice recommendations I have referenced "high expectation tasks."
A few people have asked me what I mean by that, so I'll offer this point of clarification.
By "high expectation tasks" I mean those tasks that must be done precisely (hence the vernier caliper above) in a certain way.
Often in engineering, something has to get done, but you don't really care how it gets done. For example, you may need a test harness built, but you may not care what language it's built in, or how elegant the design of the harness is, as long as it will pick up unit tests, run them, and show you results. The actual building of this test harness could be viewed as a low expectation task. Someone still has to get it done, but it isn't necessary to micro-manage how.
Just as often, you'll care about not only what gets done, but how it gets done. For instance, if you already have a test harness, and you need modification to it, you will care what language the mod is done in. You will care about syntax, and comments, and other coding standards, because you are adding to an already extant tool, and you don't want to make it needlessly complex or messy. In this case, you have a high expectation task on your hands.
When you have a high expectation task, it's important to take the time to document your expectations in clear, concise language. Very often when I debug "broken" global teams, there is a feeling on one side or the other that expectations aren't being met. In almost 100% of these cases, the expectation was strongly held, but implicit. That is, there was a high expectation task, but no one had written down or otherwise communicated the expectation.
A few quick examples of high expectation tasks might be:
- Coding standards
- Check-in procedures
- Test execution procedures
- Conference call "protocol"