Avoiding Accidental Choices

“If you choose not to decide, you still have made a choice…”
Peart, Neil. “Freewill.”Permanent Waves. Mercury 1980.

With frightening frequency, we see technology projects become subject to “accidental choices“, when rigor is bypassed without a conscious choice having been made to do so.

A decision process is left by the wayside as the project careens toward some arbitrary deadline and process, approach, controls, and the use of appropriate artifacts are dumped because there “isn’t enough time” to leverage them.

Choosing to bypass rigor in a specific area is acceptable as long as it is a conscious choice to take on the risks associated with bypassing it. Bypassing it by accident is irresponsible, to say the least.

There are some strategies that may be employed to avoid these accidental choices:

1. Have a formally defined process with specific deliverables. It seems obvious, but not having a defined approach is a nice way to make accidental choices a corporate standard. :)
2. Include determining which processes and deliverables will be used on a specific project as an early step in every project’s lifecycle. This step should document the business risks the project is creating by not following the standard process and those risks should be accepted by a business stakeholder.
3. Refine determination of processes and deliverables as well as risks accepted against subareas of the project. For example, the decision to not leverage Use Cases should not be a project global decision. Use Cases may be bypassed for simple functions, but produced for complex or mission critical ones.
4. Use math to determine what the project “does not have time for”, not intuition. Someone’s “gut feel” that there isn’t time qualifies as an accidental choice to take on unnecessary risk.
5. Don’t confuse time to be rigorous with time to figure something out. Process and rigor is frequently blamed when it is actually the act of understanding the subject area that is really causing “slow down”. For example, the reason that following a design process takes time is not typically a function of the process, but the time it takes to figure out the correct design. Even if you choose to bypass a design process, the design still needs to be figured out – it will just be figured out in development, test., and production and by whoever happens to be close instead of the best individuals to contribute. You are unlikely to get “better, cheaper, faster” by haphazardly strewing design across the lifecycle.

Comments