I am writing this post after a discussion with some people on product development and project management processes.  The discussion took a turn to process intensive approach or not to use a defined process.  There are many ideas of how this can work, for example the Capability Maturity Model Integration is an example of the technical or knowledge areas and levels of associated processes.  This document describes the many processes and individual capabilities from each process area, for example, requirements management contains a number of specific goals with a number of specific practices.  I was reminded in this discussion, of a time when I was developing and documenting the processes for a department.  For each activity, we had an objective.  There was a reason for the activity and if the reason was not valuable, then that task was eliminated from the workflow. That seldom happened.  However, there were some steps in the work that were fairly common and we documented these. For each step, we clearly articulated the objective, the reason why we are doing this step in the development process. Then we described the inputs, the process and articulated the expected output in terms of tangible quality attributes.

In today’s fast paced environment it is sometimes a desire to be flexible.  We see times when some of the prerequisites are not met, yet we must find a way to proceed.  That is the reason for articulating the objective of each of the steps.  Knowing the objectives provides us with the context for the step, we can understand when an objective does not apply to a project or product.  In that case, that specific step can be removed from this particular project.  Knowing the objective of the step also provides us with some ideas for an alternative approach to the task should we need to meet the objective but the prerequisites or processes are missing.  In these times, we have to think creatively about how we are going to meet the demand without those things we say we typically need to do so.  We can find other solutions to meeting need rather than eliminating a key step as is sometimes the case.  If the step is needed, but cannot be performed as described in our process documentation, we need to find another solution or way to achieve the objective.  Determining this alternative approach is possible when we understand the objective and is a fundamental premise of agile as “individuals and interactions over process and tools”[1].

The problem comes when we just remove or eliminate steps without considering the ramification and determining a suitable substitute method. 

1. Think of the working environment as a system and identify the goal or objective the specific task was to achieve, and any implications if we do not perform the task.  Some examples of the areas the task may address are below.
   1. quality (and reliability)
   2. project or product cost
   3. timely delivery
2. Identify actions that can be taken given the limitations. For example, in lieu of design review (perhaps due to the availability of staff or time constraints) we can substitute a review of the design by subject matter experts.
3. Institute those actions best possible

 A capitulation of the objective is not the same thing as finding alternative solutions. If the action does not need to be done, then do not do it.  If the activity has an impact on the outcome, then find the best way to meet the objective. That means adapting. That may include pairing down the way we would typically handle the task and objective.  If you must eliminate the task and objective, ascertain the worst that can happen from doing so.  Think about the development as a system and theorize the worst case outcome for eliminating.  If you find that acceptable, then perhaps elimination is what you need to do.  Consider also any mitigating actions that can be taken should the worst case risk comes to fruition.