“There are no problems, only solutions” – John Lennon
On the third maturity level of the CMMI model, a comprehensive process model must be defined. Process modeling is well-known to be a challenge that has some interesting aspects. For example, the question: what does a “defined process” actually look like? Interestingly enough, the CMMI doesn’t help as much with this answer; According to the CMMI glossary: “A process used in the CMMI Product Suite, consists of activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.”
This definition basically stresses the importance of process activities. In our practice, we observe that this is a wide-spread way of thinking. The process designer usually starts modeling the standard practices as process activities in the first place, and creates a chain of process steps similar to the following simplified example:
“develop requirements” -> “review and baseline requirements” -> “create architecture” -> “create design” -> “implement” -> “test” -> “deliver”
This looks quite plausible; however, it still lacks the relevant process roles and the just as important work products (results). The latter means any objects created, used, and updated during the process execution. Identified and placed on the process chart, those usually quite numerous elements frequently lead to large and almost unreadable diagrams. The question is: how to reduce the number of elements in such a huge process chart? What elements must stay there, what others can be omitted? The general question is: what is basically more important and must remain in the diagram: the activities or the work products? When in doubt, should we remove all work products, or should we reduce the number of activities?
The good news is: there is a solution. At this point, we would like to present a little inspiring insight from the motivational research: Whenever we keep thinking about problems, we tend to view the world in terms of problems. However, when we focus on solutions, the world seems to be full of solutions to any- even unspoken- problems. Here is another interesting insight from the behavior research: Imagine driving a car in a sharp curve. You are going too fast, start to skid, and instinctively look at the tree on the roadside quickly coming nearer. It turns out that you are more likely to collide with the tree when looking at it than if you kept looking aside. In short: it is “mind over matter” all over again.
Applied to our previously expressed dilemma, all that is written above would suggest that if we concentrate on process activities during the process design, we are likely to have a lot of work defined. If we concentrate on results instead, then we get a goal-oriented process definition. In Brief, if you think of work and you get a lot of work, focus on goals and you get results.
It sounds plausible: most of us work just to gain some desired results. This observation is nothing revolutionary. It is an essential part of diverse management theories and methods, such as MBO; the famous “management by objectives.” MBO concludes that it is practically impossible to create a complete and detailed set of work activities required to run any non-trivial organization. Despite several well-known problems with MBO, it has proved to be a very successful approach in business management. Given clearly defined goals, a good way of achieving it will be found without detailed guidelines; provided there is a solid quality assurance procedure defined. Knowing that, why not define processes based on results? The path that leads us there is secondary; it is the goal that is important. In the practice, of course, the staff will still need assistance, e.g. manuals or training courses, so that new co-workers can learn the process quickly. However, for the experienced staff, targets (objective definitions) are sufficient.
Applied to our previous example, our target-oriented principle is likely to produce a result as follows:
“requirements model” -> “requirements baseline” -> “Architecture” -> “Design” -> “Executable” -> “Test statistics, bugs and release baseline” -> “shrink-wrap product”
Look closer at both examples and decide for yourself which one is easier to comprehend.
The above observations have become an essential part of our “ Process by Objectives” (PBO) approach. We have successfully tested this principle in our projects. We start with rough milestones, move on to particular results, and eventually create the complete process definition including all relevant activities. It turns out that this approach clearly increases the acceptance of new process models. This is particularly the case in IT apartments. For example, in software development teams are frequently known for their aversion to strict process specifications. It is amazing to see how quickly and readily the very same persons accept clear target definitions instead of work activity descriptions.
We recommend trying the PBO approach in your projects – you’ll be pleased with the results. Your daily practice proves every time that PBO is the most pragmatic and effective way of defining CMMI compliant processes.