The Right Genes for Your Project

Every project is like a unique animal. Those “animals” are defined by their “genes,” which result in different abilities, such as agility, strength, and survival chances in various environments. The project’s purpose defines what genes are best. For example, a Chihuahua wouldn’t be very effective in defending your home. A Great Dane would be more successful in intimidating a possible home intruder. It is, therefore, crucial to define projects according to their natural inclinations and intentions: their project “genes.”

Facing a frequent struggle to manage the mushrooming complexity of modern systems, project teams often push for quick and straightforward answers on software design methods and the general approach to project management. Should we be more agile? Or do we need a heavy-weight process with hard-to-achieve quality gates and systematic traceability, and all of those even more strict functional safety features? Or should we expect all of it at once, as many recent development contracts suggest? The opinions in this regard range from a total rejection of rational, heavy-weight process thinking to a complete dismissal of agile methods.

When a project gets in trouble, the blame game often starts. The “agilits” say, “See? That’s because we are trying to impose a waterfall V-model thinking upon our team! We are not agile!” while the rationalists state, “Without tightly following a V-model approach, we are failing. We are out of control!” The resulting frustration can reach critical levels. At some point, crucial experts have enough of it and start quitting. At that point, the project frequently becomes a “death march,” as described in Eduard Yourdon’s book Death March.

It is a bad idea to try to suppress such fundamental conflicts. The kind of demand like “It doesn’t matter how—just do your job already” forces the remaining key developers out of the project. It may be too late and the “death march” project will continue until its bitter end. Effective damage control begins with telling the truth about the fundamental flaws of the project strategy and has an honest alignment with the team on the root causes of the project’s problems. It is often still possible to prevent the worst-case scenario: losing the key developers in the middle of the project and eventually causing the project to fail.

Among the many explanations of project failures and the failure root causes, the fundamental project agenda, the “development process,” appears especially interesting in this context. The often unwanted (but necessary) discussion regarding the project approach, “agile vs. rational,” often remains unresolved. I am firmly convinced that such strategic decisions must be discussed, finalized, and formalized in simple terms as soon as possible, optimally, before a project starts. I say “simple” because writing a several-hundred-page long “process description” just takes too long, is never precise enough, and its usefulness is reversely proportional to the size of the process documentation. Once the project description appears final, it is already outdated and needs to be overhauled already.

Instead, the fundamental process strategy (the fundamental approach that defines all subsequent activities in each thereon-based project) must be defined in a written form and organizationally institutionalized. That strategy must answer questions such as:

• What team structure do we want? Hierarchical or flat?
• What kind of personality profiles are required?
• How much formal documentation do we need?
• Is the project driven by the customer or by internal influencers?
• Is the stability of the project scope or creative ideas more critical?
• How much formal quality (testing, validation, auditing, and quality tracking) is needed?

The seemingly endless discussion “agile vs. rational” continues until we realize that both camps are right depending on the project type.

Project Typology

There are various ways to classify projects. Harold Kerzner, a leading authority on the subject of project management, distinguishes four project classes: individual projects, staff projects, special projects, and matrix/aggregate projects. Other project classifications available in the literature include industries (like aviation, home construction, etc.), licensing type (open source, shareware, or commercial), or customer-type (government vs. private), as well as more vague classifications, such as “simple vs. complex” or quantitative (small/large).

However, the more fundamental, strategic decision is whether an existing customer defines the project’s requirements or if the project is driven by assumed but still vague future needs. Is the project purpose of delivering a customer-specific product or its component, or is it a project meant to be developed for many future customers? In other words: who is the immediate, direct benefactor of a project?

There are two fundamentally different project classes:

• R&D (research and development) projects, and
• Made to Order (MtO) projects.

The difference between those two project classes is substantial, especially regarding the “weight” of a process in each of the above cases. For example, fewer formalisms are needed in a lightweight R&D project, such as low-level peer-reviews or standard process compliance, thus reducing the overall development effort. In a Made to Order project, on the other hand, a comprehensive set of formalisms are often contractually obligated, such as peer-reviews an all levels of the V-model (customer requirements, system requirements, system architecture, software requirements, software architecture, and software detailed design/units), as well as the formal verification proof on the same levels.

Process weight could be defined as follows with a focus on the automotive business with emphasis on functional safety:

Such categorization is naturally a radical simplification. For instance, the general assumption of a project is a “safety-relevant” discipline, with the effort between ASIL QM and ASIL D projects can result in an overall effort deviation by factor 3 or more. Furthermore, in the case of R&D projects, the proof of ISO 26262 compliance may be questionable as long as the project is not about to become a commercial product and a formal assessment is unavoidable, in which case a project class is converted from an R&D to an MtO project.

The three project types can be further refined into project areas using the Automotive SPICE reference model (analogously to CMMI), which emphasizes specific project disciplines, such as design or testing.

Example 1: R&D Project Complexity

The four complexity categories can be further refined using the Automotive SPICE reference processes. A hypothetical R&D example project could be evaluated as follows:

Figure 1 Grade of formal documentation mapped to Automotive SPICE reference process (R&D)

Legend:
SYS.1: Requirements Elicitation SYS.2: System Requirements Analysis SYS.3: System Architectural Design SYS.4: System Integration and Integration Test SYS.5: System Qualification Test	SWE.1: Software Requirements Analysis SWE.2: Software Architectural Design SWE.3: Software Detailed Design and Unit Construction SWE.4: Software Unit Verification SWE.5: Software Integration and Integration Test SWE.6: Software Qualification Test
MAN.3: Project Management SUP.1: Quality Assurance SUP.8: Configuration Management SUP.9: Problem Resolution Management SUP.10: Change Request Management

In this example, a formal ISO 26262 compliance is not emphasized. It may still be required later once the project is converted to an MtO project. In an R&D project, system and software requirements (SYS.2 and SWE.1) are relevant (albeit not unnecessarily emphasized). Change request management can be minimal, as well as SUP.1 (process quality assurance) and detailed verification, such as SWE.4 (unit test) and SYS.4 (system integration test). 

Example 2: Made to Order (MtO) Project Complexity

The same project, originally an R&D project, once classified as MtO (Made to Order) project, would automatically change the complexity rating to be maximal, as illustrated in the following figure:

Figure 2 Grade of formal documentation mapped to Automotive SPICE supporting and project management processes (MtO)

In functional-safety-relevant projects, all V-model processes (SYS.1 to SYS.5, SWE.1 to SWE.6) would have to be “perfect,” while other (supporting and project management) processes should not be overweighted. The ramifications of the transition from R&D to MtO are significant. The MtO team size is typically a multiple of the original R&D project.  In addition to generally expensive internal developers and other technical specialists, external assessors must be hired while the production facility needs to be physically developed and tested. Furthermore, verification on all levels must be fully covered by approved requirements (on system and software levels), and so on.

In other words: the resulting MtO project is an altogether different “animal” from the original R&D project.

The Challenge of Choosing the “Right People”

The right team structure is a critical aspect. The AI (artificial intelligence) software engineer–an artificial developer, if you will–is not expected to be invented any time soon. “Peopleware” will remain a decisive asset in systems development for many decades to come. Thus, the development process and the project team must harmonize in the best possible way, and this harmony depends on the selection of the team members. Executives and entrepreneurs often mention the need to have the “best possible” talent on their projects, but what is “best” depends on the type of project venture. For example, someone who thrives in a more flexible, creative project R&D environment tends to be less satisfied and likely perform worse in a heavily regulated and formalized MtO project.

You can’t have everything in the realm of human resources. There are not enough Supermen and Batmen in this world available for your project—you will have to make tough choices. Every one of us has different abilities and inclinations, and the decision is difficult when it is based on mere gut feeling. A standardized personality test can help rationalize project staffing. The problem is that there are hundreds, even thousands, of such tests (see a small sample here). Some of them are widespread, while others are obscure or virtually unknown. How do you choose an appropriate personality test?

Perhaps the original intent of a personality test may give some clue of their suitability for our purpose. For instance, one of the leading tests, the Myers-Briggs Type Indicator (MBTI), was initially inspired by its inventors as a way to assess the personality of a potential spouse. The assessment tends to aim at the character of a person rather than their behavior. While it does not generally discredit the test’s usefulness, it tends to add an unnecessary blurriness to the test questionnaire. Numerous other tests, such as the “The Big 5“, also fall in this category as they attempt to assess a person’s character.

Other tests, such as DISC (Dominance/Influence/Steadiness/Conscientiousness), appear more suitable for project team staffing’s purposes. DISC focused on behavior instead of the character of a person.

Note: All of the tests mentioned above are controversial, including MBTI and DISC. Choose an assessment model that appears suitable for selecting technical staff, such as developers and test engineers, as well as quality and team leads, including project managers. For the sake of consistency, stick to one assessment model over extended periods (years rather than months).

Using the DISC approach in the context of the project type (R&D vs. MtO), teams could consist of the two staff profile types:

	R&D	MtO
Dominance	++	+++
Influence	+++	+
Steadiness	+	+++
Conscientiousness	+	+++

Figure 3 Desired team member profile (+ = lowest priority, +++ = highest priority)

The above example is naturally just an average value regarding each DISC aspect. It would vary according to the project role. For instance, in the case of a project manager (it would most likely be a Product Owner instead, according to the Scrum terminology), the candidate should ideally be on the “+++” level in all categories, especially regarding the “Dominance” DISC rating.

In general, the differences of the team inclinations tend to be project-class-specific. For example, an “S” steadiness) developer can get frustrated in an R&D project but would thrive in an MtO project. Thus, a resulting standard role matrix would contain all roles two alternatives: one for an R&D project, one for an MtO project. 

Different Lifecycle Models

It should be evident by now that, because of the fundamental differences between the project requirements and team profiles for R&D vs. MtO project types, having just one “process for all” is unrealistic. It is also naïve to say, “we do Scrum, so therefore we have a process.” Scrum is just a small part of the whole, especially in customer projects. Insinuating that this is enough and that the rest will “self-organize” often results in organizational turmoil and potentially expensive confusion. That is especially critical in safety-relevant projects, such as the automotive business, particularly in the automotive supplier business, and absolutely indispensable in automotive OEM customer projects. They are usually of MtO type, and such projects better follow an entirely different approach from R&D projects.

Because of that, fundamentally different lifecycle models (i.e., process models) must be defined and implemented. A few examples of the key differences between those project classes are listed in the following table:

Project Aspect	R&D	MtO
Lifecycle	Sprints and a few optional milestones suffice V-model can be incomplete	A fully defined lifecycle as stipulated in the contract, including customer’s milestones, etc. A full V-model is explicitly demanded (all SYS.* and SWE.* processes
Team roles	Product owner, a committee, other options are possible	Project manager
Team hierarchy	Flat, only a few roles required	A full top-down team chart must be defined and approved, with all responsibilities explicitly defined
Schedule	Sprints	Releases as defined in the contract, based on customer needs, and contractual obligations
Project scope	Variable, changes can be informal	Each project scope change implies a formal change request
Definition of team activities	Can be redefined with each sprint	Implicitly or explicitly defined in the project contract
Project risks	Only strategic risks	Risk assessment required for each release

Figure 4 Example of key differences between R&D and MtO project lifecycles

MtO projects lifecycle must be easily adaptable. For example, a different project iteration cadence, instead of the standard two-week-sprints in Scrum, is frequently required. Thus, an effective MtO development process lifecycle must adopt different cadences whenever the customer needs it. This flexibility should be integrated into the standard process definition for all MtO projects.

In R&D projects, on the other hand, a simple, Scrum-based development approach is usually sufficient. These projects can be exceedingly “lean and mean,” as there is not much formal process design required.

However, when an R&D project is awarded and is about to become an MtO project, an orderly transition from an R&D project type to an MtO project should also be ensured. This conversion should be straightforward and smooth. To ensure that, requirements and designs must be of a higher quality than the R&D test specification for safety-relevant projects. All of those details should be stipulated within the standard process definition before any project starts.

By the way, a conversion of a project from R&D to MtO must be disruptive. I would strongly discourage attempting to have a gradual transition into an MtO project. An MtO project is a different “animal” altogether from an R&D project and should be treated as such.

Summary

Instead of a “one-fits-all” approach to development process design, at least two project types are needed: R&D and MtO project types. New projects should pass the following decision-making sequence:

1. Define the project type: either R&D or MtO.
2. Refine the level of required documentation for each process, tailoring them, for example, from 1 (simple, low documentation requirements) to 4 (for safety-relevant projects) for each Automotive SPICE (or CMMI) process area.
3. Hire the right people based on the predefined team profile, the project type, and the DISC model (for example).
4. Stick to the plan—never change the project type “on the fly.”

To return to the original analogy in this article: your “animal” should be the “right breed” from day one.  You cannot have everything in your new project; it must be clear what the “nature of the beast” is supposed to be. MtO projects are typically customer projects, and they need to be structured according to the customer’s needs. To assume that it suffices for an MtO project to be “self-organizing” and vaguely “agile” poses an incalculable risk and the best recipe for a costly project disaster.

Let us be realistic. If you need a Big Dane “project,” do not buy a Chihuahua “project” instead. A Big Dane will require extra care, a different diet, space, and definitely more doggy food, but you will thank your “project animal” one day.

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).