The SPICE Conference 2012 takes place in Palma de Mallorca from the 29th to 31st of May. Now in its 20th year, the conference will focus on some of the implications of the new, more open architecture based on the work in-progress for the revision of the ISO/IEC 15504 family of related Standards (renamed as the ISO/IEC 33001-99 series with the common theme of Process Assessment).

The keynote speakers are:

• Giuseppe Lami, “Green IT and Sustainable Software Engineering”
• Roger Southgate, “The COBIT Assessment Programme”

The programme includes tutorials on the 29th and a variety of interesting talks from “Integrated Process Improvement Approach: Case Studies in Skype Technologies Ltd.”  through “Best practices for achieving Automotive SPICE Capability Level 3″ to “Gained Experience by Making Intervention to Improve Software Process in Very Small Organizations” and much more on the 30th and 31st.

There is also a small social network for attendees of the conference to connect with each other.

The catch phrase “change” is also a predominant theme at the Gartner PPM and IT Governance Conference, which is held on the 14th and 15th June in London. In economically “turbulent times” especially management and planning need to be improved. Constant change just requires adaptation. The agenda is divided into three tracks: “Better Governance – Challenges and Solutions”, “Programs, PMOs, and the Action ‘Engine’” and “IT portfolio and IT Investments: It’s All About Maximizing Returns”. In addition, interactive workshops, round tables for analysts and  how-to sessions will be offered.

Guest keynote speakers are Steve DelGrosso, Director of Project Management Center of Excellence, IBM and Anne Skare Nielsen, Chief Futurist and Partner, Future Navigator & Future Navigator Club. They keynotes from Gartner are given by Michael Hanford, Gartner Research Vice President and Summit Chair, and Audrey Apple, Gartner managing vice president.

As of now there are no keynote speakers known. But we will inform you here with updates.

### UPDATE

The keynote speakers have been announced:

• Michael J Wild – Functional Safety Expert at Motor Industry Research Association
• Bashar Nuseibeh – Professor of Software Engineering and Chief Scientist at Lero – the Irish Software Engineering Research Centre
• Carol Dekkers – Internationally recognized expert on the importance of communication and measurement, lean and Kan Ban

The program is also available now.

The IPMA holds its yearly congress this year in Istanbul, Turkey.

The main theme of the 24^th IPMA World Congress (Istanbul 2010) is to identify the changes that need to be made to tackle the challenges and seize the opportunities brought about by new realities in the world economy.

For more information see the IPMA World Congress 2010 page.

With ProjectCrunch we want to create an exciting magazine that will appeal to our target audience: project managers, IT executives and management consultants, who all share the same passion: the leadership and the management of information technology. While various media offerings in this area already exist, we believe that time has come for a lean, interesting and comprehensive web content that targets managers and experts who have little time for lengthy and complex stories. We will make things short and interesting – simply worthwhile.

For that reason, we did not intend to create a full-blown online magazine. However, we did not want to create just another blog page. We decided to be flexible (or: agile, if you like). We will publish both small articles and pieces of compressed information for quick reading, but we also will sometimes offer longer (but not too long) articles on interesting issues.

“ProjectCrunch” is supposed to facilitate the nature of this magazine’s content. We mix a lot of interesting information and try to “crush” and “crunch” them into smaller bites. The topics are a cross section of what our interest group is concerned about: project management, process improvement (CMMI, SPICE, agile methods, ITIL, etc.), but also information technology in general (i.e. new smart phones and other innovations, such as programming languages and middleware), especially under the particular aspect of their future prospects and their (potential) value added.
In a sense, ProjectCrunch replaces our old page, Consulting Times, which has gone offline simultaneously with the activation of ProjectCrunch. Consulting Times articles have been moved to ProjectCrunch and remain available.
Last but not least, taking the globalized nature of our readership into account, ProjectCrunch is offered in two versions: English (ProjectCrunch.com) and German (ProjectCrunch.de). However, we have decided not to pursue a strictly bilingual strategy. Some articles will appear in both editions (as a direct translation), but ProjectCrunch.de ProjectCrunch.com and are otherwise independent.

ProjectCrunch is now officially unveiled. See you in the next article!

If the only tool you have is a hammer, you tend to see every problem as a nail. – Abraham H. Maslow

The pressure on the team is growing every day. The introduction of the process area “Requirements Management” was defined as one of the measures in the course of the process optimization. The entire CMMI project is firmly planned and must be finished by the end of this quarter. Previously, the organization was examined; efficiency gaps were found and systematically analyzed. The resulting work packages were defined and planned. All tasks were budgeted: the CMMI consultants, the additional project members and the expert working groups within the customer’s organization.

The final version of the process model was recently delivered, reviewed and released. All requirements of the 2nd CMMI Maturity Level were solved cleanly, most of all the traceability. In the process area of Requirements Management, the CMMI clearly demands a well-defined and maintained traceability between different work results. The procedure was arranged straightforward: when the requirements manager receives a new feature, he registers it in a prepared Excel sheet and passes the requirements on to project planners, system analysts and architects. They report the updated plan data and component IDs back to the requirement manager, who registers them in the appropriate columns of the Excel sheet and updates all relevant requirement statuses. The Excel sheet is placed on a shared drive, where everyone can see the current status of the requirements. Only a few users have the write access, e.g. the requirements manager.

„Tools are unimportant, only the process counts“

How beautiful is this simple solution. Since an ordinary Excel sheet was used, expensive tools and all efforts associated with their introduction could be spared. “It is not important, what tools you use, it’s only the process that counts,” says the chief consultant. And he surely knows what he’s talking about.

In a pilot project, how this concept works in practice is to be examined. The pilot project is under full steam, just like all others teams in this organization. The pilot project is well on its way, and the first phase of the requirement analysis is just taking off.  Two hundred and thirty new requirements flow into the Excel sheet. They are systematically analyzed, estimated and planned. The requirements manager has plenty to do; each day he processes all the data that pours in via email from his “customers:” Comments on the requirements, status changes, plan data, system component IDs from the Impact analysis. The smart-looking bar and pie charts look magnificent. Everything makes a very correct and professional impression.

The pilot project testing the process area “Requirements Management” picks up the pace. The workload of all team members reaches its natural limit. In the rush of  everyday project work, it turns out that some requirements were forgotten. These must catch up really quickly. In addition, some requirements were recognized as doublets and must be split. During this activity, it frequently turns out that the impact analysis of the alleged doublets was based on different assumptions, thus different results were collected. These requirements still need to be divided, but they must remain interconnected. This is quickly fixed by using predefined ID ranges.

„Why don’t they just let us do our work? Things were so easy before… “

Soon it becomes clear that the Excel sheet is not error-free. The requirements manager must now handle 350 entries and 35 columns. That makes 12250 single entries. To err is human, but the process does not allow it. It shows that a simple self-control is not a sufficient measure to assure the correctness of the quickly growing amount of requirements data. More and more resources are busy with the quality assurance of the various versions of the Excel sheets. Weekly reviews, complex checking scripts, smart macros and a large set of formulas are used to stabilize the concept. Still, the number of inconsistencies is growing. The requirements manager must simultaneously play the roles of a quality assurance responsible, a script developer and an Excel expert. He is increasingly working overtime. It seems that the requirements manager has failed and the resource planning was incorrect. It becomes obvious that at least two requirement managers are needed to handle the workload. The management is now under increasing pressure to make this sub-project successful. Another requirements manager is hired. From now on, two persons are working simultaneously on a single Excel sheet. What happens now is what was foreseeable: Discrepancies, ad hoc parallel activities, mutually overwriting changes become increasingly frequent. Excel sheets are not made to be multi-user friendly. The errors are corrected through even more reviews and expert questioning. The project workers begin to mutter: “Why don’t you just let us do our jobs? We are drowning in this bureaucracy. It was all so easy and straightforward before … “

The story – taken from the everyday IT-project life – moves down its predestined track. The project planners, architects, analysts, testers, customers – they are increasingly fed up with the frequent questioning and lengthy interviews. Frustration and the chaos in the requirements management are reaching staggering levels. The CMMI project is finally put on hold, the consultants are sent home. Without a functioning requirements management the CMMI maturity level remains unreachable. The optimization project has ultimately failed.

Tools cost money. Missing tools cost a fortune.

Excel sheets are sufficient for provisional solutions or one-time actions. They are a bad idea as a sole tool for a systematic professional requirements management. The constant pressure to reduce costs and the widespread belief that Excel would be a solution for complex management tasks is in fact a frequent reason for the failure of many process improvement projects. In the discipline of requirements management, more than a simple spread-sheet analysis is needed. Many things must be available, such as a configurable state machine for the work-flow, access rights concept, multi-user ability, a baselining function, a minimum of ergonomics, integrated consistency checking mechanisms and so on. Interestingly, nobody would get the idea to use a simple drawing program instead of a CASE Tool when it comes to software design; even if the drawing tool is much cheaper and produces really nice pictures. In other process areas however, this is frequently the case. Using cute spreadsheet templates, projects are planned, risks, defects and requirements are managed, large numbers of test cases are written, etc. In most cases, at the beginning of a project the spreadsheet-driven solution seems to be a perfectly right choice. Eventually, it ends up in more or less complete chaos. It hits those organizations the hardest that manage their entire process models with text processing and spreadsheet applications. Such artifacts are often called “write-only documentation.” A “write-only“ process definition is pointless and even dangerous, since it creates the deceitful impression that the organization is well-managed and stable. The money that was saved on the tool is eventually spent on extensive manual data administration and intense attempts to obtain the necessary process acceptance within the staff. However, process models that are not supported by proper tools, and instead include repressions and penalties for making mistakes will hardly find any acceptance.

Tools must be introduced, deployed and integrated

Various tools are needed for different tasks: Project planning, requirements management, architecture and design, quality assurance, etc. In large-scale projects, dozens of different expert tools are used. In order to assure the correct data exchange between these tools,  e.g. a consistent traceability between requirements and the project plan, those tools need to be properly integrated. Otherwise the data exchange quickly becomes error-prone and expensive manual work. This tools integration is a complex venture; each tool must potentially interact with all other tools, the systems have incompatible data interfaces and various needs in every process area must be carefully considered and implemented. It is essential to realize that without reasonably functioning integrated tooling, no organization can really properly function. Important is also the insight that a tool introduction costs a considerable amount of money. An introduction of new tools is in fact usually just another regular (sub) project. Resources and time must be paid, organized and planned systematically. ROI (Return on Investment) analysis is difficult in this case however. It turns out that an optimization project without proper tools shows a substantially higher probability of a total loss of the investment if the tooling question is ignored.

Summary and advice

We briefly summarize our observations below:

• Without suitable tools, process optimization projects will almost certainly fail.
• Proper tools significantly increase efficiency and are vital if it comes to the new process acceptance issue within the organization.
• Tools rarely work “out of the box.” They must be customized, scripted and wisely introduced.
• Tools must be integrated, so that an efficient data exchange is possible.
• Properly configured tools are a better way to assure process conformity in the organization than process definitions, punishment threats, and frequent audits. Process conformity assurance that is based on any kind of “penalty clause” will not work
• All tools must fulfill CMMI requirements; particularly regarding quality assurance and configuration management.
• Excel is no substitution for specialized tools.

Reaching any CMMI maturity level requires a good tooling concept. There is no alternative to this rule. Therefore we recommend:

• Distrust anyone who tells you that tools are irrelevant, and that the good process model will fix all problems instead.
• Define a sane budget for the tooling sub-project. Unfortunately, it’s a common mistake to underestimate the complexity of this task. If you do not have the money for your tooling, it’s actually better not to start the process optimization project at all and save all the vain expenses.
• Chose a tool specialist team that is also familiar with CMMI, or is at least lead by an experienced CMMI consultant.
• Generally distrust all Excel-based “solutions”
• Chose tools that can be adapted to all of your processes. The customization should be done by a team at (hourly) rates that were agreed upon before the project started.
• While reviewing your new process model, demand clear references to tools and the information on how those tools are integrated. At least on a low (detailed) process level, this must be sufficiently described.
• Listen carefully to your team. If the new process is said to be “too complex”, then you probably have an urgent tooling issue.

We have omitted a number of further details, as it would overextend the given space in this short article. Besides, all of our recommendations must be further refined: Each project has its own specific aspects with different tools that are used differently. However, the right tools are the core prerequisite for any successful CMMI project. It is essential not to ignore it and instead, to believe the puristic slogans that suggest the “right” process definition would save you from having to choose, customize, integrate and deploy the proper tooling.

(Originally published: 29 Juli 2008)

The approach appears to be simple.

The following simple procedure appears simple and logical:

1. Define a process model structure with several detail levels (from rough to fine)
2. Interview the business experts within the target organisation and collect the results: work steps, responsibilities, work products
3. Review all partial results
4. Compile all parts to an overall model and, again, conduct a comprehensive review
5. Consolidate the results in a single, integrated model and establish them as the obligatory business processes. Finished!

Brave new world! However, let’s take a closer look at these measures.

1. Define a process model structure with several detail levels (from rough to fine)

In contrast to software design, where the modelling language UML is the state-of-the-art notation, there is no industry standard for process modelling. No catalogue of criteria exists that would help determine what to put on the first, second, third, etc. process level. Under each of these levels one can imagine virtually anything. Even worse: the borders between a process of the 2nd and a sub-process of the 3rd are diffuse. In a large process, a partial work sequence appears as a sub-process, while in a smaller process stepping one level down might appear unnecessary for the very same sequence. Consequently, the choice of the process level granularity seems arbitrary.

2. Interview the business experts within the target organisation and collect the results.

The experts may be good their actual job. However, they are usually not as good in sufficiently describing their work. The results rarely fully correspond with the reality.

3. Review all partial results.

How much insider knowledge about the target organisation does the process designer need to eliminate redundancies and discover gaps? And will a review with the experts actually unveil all weaknesses of the process model? Often, the reviewer doesn’t have the experience needed to cope with the review tasks.

4. Compile all parts to an overall model and, again, conduct a comprehensive review.

The overall view is afflicted with the same weaknesses as the sub processes. Additionally, the reviewers’ abstraction ability varies widely.

5. Consolidate the results in a single, integrated model and establish them as the obligatory business processes.

It is to be clarified whether the senior management is really ready to commit the process as “valid and obligatory.” In many cases, it is not.

Consider the warning signs.

These challenges are often extended by more frightening scenarios, for example:

• The process analysis is conducted while downsizing or announcement is ongoing. In this case, the support on the part of the experts will be fragile.
• If the main goal is to obtain some kind of a formal certificate (ISO 9000 or CMMI appraisal) e.g. for marketing purposes, the consultant should think twice before tackling this task.
• In an immature organization, processes are very hard to analyse. Informal communication paths are pervasive and implicitly established. Risky “short-cuts” in organizational structure are hard to manage. An attempt to capture all those alternatives makes the process model useless at best, and misleading at worst.

Probably the most important and most frequently overseen problem however, is whether the experts are actually willing to disclose all details of their daily work to the process analyst. This “hidden” know-how of important business processes is frequently regarded as part of the personal, strategic advantage. The larger an organization, the more likely the experts would prefer to keep their important insider knowledge to themselves. In reality, the employees of large companies spend a significant part of their working time securing their own position and extensively networking for their own career purposes. These activities (call it “social efforts” or “personal politics”) can completely fill up the schedule.

(Originally published: 16 May 2008)

The following night seems endless. The consultant keeps asking himself how he is to actually transform the process of understanding and thinking into a linear ten bullet list. With the morning-grey, after many drafts and moments of despair, he comes to the conviction that one cannot define a “thinking” process. In the practice, the domain must be analyzed and precisely transferred into a language understood both by the business people and IT specialists. He sits down and writes the following list:

• Interview all stakeholders.
• Classify the results according to their functional and non-functional nature.
• Review the requirements with both customers and the IT; ensuring an understanding of the requirements.
• Write Use Cases, review them again and pass them on to the IT.
• Track the implementation.

“Mr. Consultant, why are you bothering me with such trivial stuff? That is much too high-level and too general. I’m sure you know exactly how you are going to proceed with the use case analysis, in detail.” The customer is well-prepared for the meeting and goes on summarizing the method, presumably taken from some classical Use Case book, concluding that that the use case analysis is a creative process; mutual understanding and classifying of the use cases must be done carefully etc. The summary is basically identical with the consultant’s paper. “I know all that,” the Customer continues. “But you, being a professional process specialist, shall please deliver a detailed description of the use case analysis process in ten simple steps. And don’t forget the meta data!”

“Meta data? Good heavens, how could I forget the meta data?“ thinks the consultant, deeply frightened. But wait: what ‘meta data’ was actually meant? Another sleepless night follows. By the next morning, the consultant is definitely sure: the way the human brain works definitely cannot be described in “ten simple steps .” There is no “meta data” replacing it. It appears that the customer has read something about meta data in content management systems in an on-line newspaper and just passed it on to the consultant. Time has come for the consultant to decide how to make it clear to the customer?

These events are taken from the daily project life; they are not horror fiction. Computer scientists have a big problem: Excel users often tend to assume that software development is just as easy. Interestingly, a customer is not very likely to ask a construction or hardware engineer to please describe in 10 easy bullet points how the design, the processor board or a new railway bridge are created. Why? Because most of us have accepted the fact that building bridges requires a complex knowledge and thus it should be left to the experts. However, in IT-projects that kind of micromanagement is frequently practiced. It leads to such absurdly detailed inquiries as described above. In this particular case, our consultant resisted the temptation to create an obsolete “bullet list” seemingly describing the actual “thinking process.” Obviously, thinking is not a linear, easy-to-understand activity.

Requirements analysis has served us here as an example. No process area is safe from the attempt of being defined on a microscopic level. The process of the requirements development is particularly susceptible to such inquiries, because it is very complex and difficult to understand for non-experts. However, many other process areas fit this scheme; such as “Technical Solution” (software design, implementation).

Our consultant could have sketched a list riddled with shiny technical terms (meta data, traceability, reuse, etc. would definitely have to be mentioned several times). Such a hyper-loaded list would probably be approved without examination, as it is not uncommon in the day-to-day software business. This list would automatically become obligatory to anyone working in the regarding area, with all its consequences. It would most probably contain directives of the kind: “acquire, analyse and classify the metadata” – who would ever seriously try to understand that? The result: the requirement analysis becomes suffocated by misunderstandings and too many rules. And the process conformity audits would become arbitrary. That is an example of “Viral Microprocesses.” Those are hardly visible, small beasts that continuously disintegrate the overall process and decompose it into a useless set of regulations. To make things even worse, they are contagious; once a Viral Microprocess is defined in one area, it is likely to become standard for all “neighbours.” They are likely to become an important part of statistical data presented to the senior management, to document what areas are well or insufficiently documented. The overall consequences are easy to guess. Viral Microprocesses are likely to paralyze an organisation, and they are exactly what a process designer would try to prevent at any cost; thinking regulations. The more complex a process area, the more dangerous they become, and the worse is their impact on the overall success of the project outlook.

What can be done against Viral Processes?

• When in doubt, it is better to be inaccurate than too exact. In a project environment, if real experts are at work they don’t need detailed instructions on how to do their job. Experts only fail when they work based on wrong requirements. Viral Processes will only make it worse.
• Internalize the CMMI basic ideas. CMMI appears quite complex, because it formulates a large set of practices to each process area. However, it is based on simple rules called common features:
  • Commitment to perform; do we want to do it?
  • Ability to perform; can we do it?
  • Directing implementation; conduct and tracking the work. Are we actually moving on, and in the right direction?
  • Verify implementation: is the job finished? Do we have what we wanted? If not, why not? And what can we improve?
• Do not discuss the processes democratically. If the responsible persons don’t understand from the very beginning how to create and establish a systematic work procedure, then each discussion will be led on the political, unproductive level. Consider hiring a good consultant.

Thinking is indefinable. We must live with this sober truth. Simple, clear objectives and a healthy common sense should at least be expected of each manager. These attributes cannot be replaced by any check list.

(Originally published: 13 April 2008)

It is a frequently observed phenomenon that experienced experts often seem to reject the introduction of process models. This raises some interesting questions, e.g. regarding the effectiveness of a process-driven organization vs. implicitly performing expert groups. Which concept is more efficient: a group of process-conformant workers (“competent,” read further for more details on “competence”) or a self-organized expert team? Are expert teams and the process conformity incompatible terms? Is it possible to create an organization consisting of process-conformal experts?

These questions are more than justified, considering the huge challenge faced by  organizations introducing process models as required by the CMMI model (3rd maturity level). Due to the required budget and the high failure risk, those kind of measures must withstand a critical examination. The rationally defined goal of a process improvement is to model all relevant processes in order to reveal the weaknesses and to eventually “implement” the resulting improvement measures. This implies that one of the first steps should be converting the existing expert knowledge into a set of rules to be used as a basis for the improvement project.

But: what IS an “expert” anyway? In their famous book Mind over Machine the Dreyfus brothers introduce their famous Model of Skill Acquisition. It consists of five stages:

1. Novice (only follows context-free rules).
2. Advanced Beginner (uses new situational elements. Decisions are still solely based on rules ).
3. Competent (the number of rules has grown large, available information is prioritized, self-organizing).
4. Proficient (first intuitive decisions, holistic thinking begins, verifies own intuitive decisions using rational patterns).
5. Expert (holistic thinking, including decision making and planning).

Experts don’t waste their time on an analysis of facts in the context of sets of rules. They act immediately on the basis of intuitively recognized patterns resulting from their extensive professional experience. It is obvious that experts inevitably work more efficiently than “simple” competent counterparts who still proceed based on a large number of rules.

However, experts – as remarked by the authors of Mind over Machine – are usually not particularly good at translating their expert knowledge into sets of rules. This implies that by studying and memorization, beginners can become proficient at best. This insight explains why process improvement measures often fail or at least don’t deliver the expected improvements. When an organization decides to capture its process model for improvement, the following happens frequently:

• The process flows and results are not correctly captured – for the previously mentioned reasons, the experts just don’t give the best possible answers.
• Eventually, the process improvement action conducted on that incorrect basis delivers mediocre results.

The good news is that defined processes can help the beginners to become proficient.

However, there is also some bad news:

• The process description differs from the reality because of the erroneous expert answers used to build the model.
• An obligatory process model obviously forces the experts to reduce their holistic abilities and forces them to act proficiently (that is, two skill levels below their actual abilities)!

Based on such observations, we dare to draw the following conclusion:

Defined processes can actually improve organizations with mostly inexperienced employees. However, introduced and institutionalized in mature expert networks, they are most likely to force the whole organization back to mediocrity!

Mediocre organizations are doomed to fail, at least in the long run. Does that mean that process improvement projects are useless at best? it depends. If we do not build process models, on what basis should we discuss complex topics such as requirement management procedures or quality maintenance concepts? There is indeed good reason why we need a rational process (S. also “A rational design process: How and why to fake it.“ from David Parnas).

You might now expect us to enlist a checklist containing some hints on “DOs” and “DON’Ts.” Recommendations of this kind are to be found in numerous books and publications covering these questions. This brief paper doesn’t offer the proper space to elaborate further, or to compete with those publications. However, if the above statement is true, the question about the consequences arises. Not each employee can be a process expert, so building expert teams cannot be the answer. Tom DeMarco, the famous management guru stated a long time ago that there are just not enough experts out there to proceed that way. That is correct, but as a customer you must be at least an expert in selecting your consultants. Since process improvements are rarely possible without external assistance, you will definitely need one. You must be able to trust your intuition, and that cannot be replaced by any checklist. If you choose right, all the answers come within reach.

(Originally published: 03 February 2008)

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 mean 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 charts? 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: When ever 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 behaviour 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 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 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.

(Originally published: 27 October 2007)