Discussion about the selection and use of formal processes for innovation projects (An Opinion Piece)

Key Meta-Level Project Risks

From experience, there are some key non-obvious insights about the challenges of leading AI-empowered digital solution R&D projects…. Two hidden meta-level sources of critical risk frequently defeat innovation projects. Understanding and mitigating them is essential. An informed, strategic selection of processes (methodology, framework, or lifecycle model to structure the approach) can help, but only if it matches the project.

The first hidden meta-level source of critical risk: An insufficiently-defined objective problem

Underneath the surface statement of desired project outcomes, there will be one or more important, probably complicated, real-world, objective problems that must be solved to move forward. At the start of a new innovation project, it is common that the project sponsor representative(s) and the project performance team collectively do not have a critical mass of key, non-obvious, special insights, from empirical experience about the underlying problem(s). It is likely that if the problem were already sufficiently understood to enable constructive ideation, a solution would be obvious.

Some degree of problem framing work will be required to achieve a sufficient level of operational understanding of the problem to decide on an initial direction for technical design ideation. Problem-framing activities will typically include a coordinated series of scientific empirical activities to extract the missing insights and build a foundational understanding to enable design ideation. Skipping the work to mitigate this risk will result in extreme waste of resources naively pursuing distractions of the irrelevant, impractical, low-utility, or low-value.

The second hidden meta-level source of critical risk: Spillover of sponsor internal context

Sponsor representative(s) assigned to oversee the innovation project [we use the term “sponsor” to refer to the investor who funds the project] has pressures put on them from their organizational executives and management. Sometimes these can be constructive, and drive moving project work forward toward progress on some pre-defined externally-valid objective outcome. However, it is more common for these pressures to be comingled with distractions related to the internal political dynamics and personal dramas from within the sponsor organization.

These can include: (A) unreasonable expectations for the representative(s) to have a priori comprehensive understanding of the problem and how to solve it; and (B) unreasonable expectations for rapid demonstration of compelling intermediate results, to show “progress” and keep the project “sold” internally. Such pressures, projected from the sponsor organization’s internal context, can be extremely intense, high-consequence, and intractable. Commonly, they reflect a culture of strategic irrationality that typifies high-stakes human politics and executive-level negotiations within most large organizations. Spillover creates dilemmas for the sponsor representative(s) and introduces risks for innovation work.

The Dilemma

The performer team (the team performing the innovation project for the sponsor) must avoid getting involved in the sponsor context. Instead, the team has to find a way to both: (1) supply their sponsor representative(s) with the tangibles and narratives the sponsor representative(s) need to succeed within their organizational context; and (2) minimize diversion of project resources away from tasks needed to solve the objective problem. The level of difficulty in finding a balance here is usually relative to the level of sponsor-side internal pressure put on the sponsor representative(s) who oversee the project. In extreme cases, demands by the sponsor representative to generate off-topic artifacts to support their internal organizational conflicts, can threaten to consume all project funding (with nothing left to perform any objective work).

Mitigation of meta-level risks: The potential leverage of project-structuring process

It is essential to identify all project requirements from the sponsor representative. Some will be related to the objective problem, and others will be related to the sponsor organization’s internal political dynamics. From experience, creating a formal and official requirements documents (focused on those requirements related to the objective problem) is an important step in limiting the scope of sponsor internal political dynamics the project will address. Once the requirements documents are drafted, then hold a requirements review meeting with the sponsor organization (including executives and managers). This gives sponsor leadership the opportunity to openly commit to a specific scope and direction for the project.

Unfortunately, because of the social natures of the two meta-level risks described above, human beings are generally not equipped to handle either well. Individual project leaders typically do not have the raw skills and attitudes to lead an innovation project through these risks without help. The more difficult the objective problem, the more serious the effort needs to be. And, the higher the irrational spillover from the sponsor context, the more dispassionate and objective the effort needs to be. The needed levels of seriousness, commitment, and radical detachment for an innovation project leader can be inhumanly high. There is a category of project management tool, however, that has the potential to augment leaders and make them sufficient. This is structured processes. If done right, adopting a well-matched process can be very useful in mitigating project risks or all kinds. If not done right, however, a bad-match process can destroy a project.

Selecting a structured process: Every project must have an objectively-selected and specially-customized process

Structured processes are tools designed for specific kinds of jobs. Choosing a tool that does not match the job can make the work impossible. This topic, unfortunately, is another extremely difficult subject for many people. Experience shows that a significant percentage of people prioritize their personal preferences for their favorite type of work above the objective aims of a new project. And they will engage in strategic irrationality to promote the selection of a structured process that matches their preferred type of work, regardless of objective fit for the project. If they are successful in coercing selection of a mismatched process, the project will be transformed into the type of work they prefer. As a side effect, the actual work needed to achieve the objective project aims will not happen, and the project aims will completely fail.

The task of selecting a structured process for a project is, therefore, both critical and difficult. It is best done with the aid of someone who has: process-neutrality; selfless objectivity; proven experience delivering to objective project aims; and immunity or indifference to irrational pressures. Identifying the right person to lead this, or bringing in an outsider (as appropriate), and can make the difference between success and failure.

Structured process options: Each with a specific narrow use

There are multiple established structured processes, and each is proven to support a specific narrow category of project type. It cannot be overstated, that identifying and committing to a specific process that matches each project’s aims is essential. Unfortunately, the majority of people cannot collaborate on the trade-space decision-making at the level of abstraction and objectivity required to select a process that matches a project. Another thing that makes this hard is the high volume of misinformation and exaggerated promises within the literature from organizations promoting and marketing various competing processes. [It is ironic that the main potential utility of a process should be to empower a project team to succeed, but a marketing coercion to adopt a process that is not a good fit for a project injects risk into the selection.]

An example… the marketing hype for the Agile process is especially deep and obscures clarity about its narrow utility. Selling Agile to everyone, including the many different companies and activities that are not a good match for it, is a reckless, but thriving, multi-billion-dollar business. Conceding to sales messaging and choosing to “go along with the crowd by adopting Agile” is an irresponsible disregard for risk and can wreck an innovation project. Projects with ill-matched process selection, as mandated by external pressures, have poor objective outcomes.

Table 1. A summary, from experience, of how a variety of highly-popular structured processes, and how they address two key meta-level sources of risk for innovation projects

Process	Challenge One: Insufficient Non-Obvious Insight into the Problem	Challenge Two: Sponsor-Side Project Context	Best Fit for this type of Project
Prototype Model Process (PMP)	Early prototyping supports problem framing efforts where everyone collaborates to extract critical missing special insights on the problem, and iteratively create a shared external requirements document that shapes technical design ideation.	Early prototypes, esp. if they are visually attractive, can additionally serve to demonstrate rapid “progress” to sponsor leadership	Innovation projects with a lot of uncertain ground to cover quickly, and potentially simultaneously, in problem framing work. This can include supporting “voice-of-the customer” (VoC) efforts to identify and quantify buyer values.
Agile Process	This risk is not mitigated, but instead shifted outside the project. The sponsor accepts full responsibility. The development team is free from the costs and responsibilities associated with striving to achieve long-term aims, or objective success. The lack of team understanding of the problem leads to shortfalls in direction and system architecture.	Project funding is prioritized to rapidly and iteratively deliver changing intermediary immature versions to show “progress” that track sponsor leadership’s changing perspectives.	Performance projects focused on quickly following a sponsor representative(s) across dynamically-changing aims. Resources are prioritized for rapid iterative construction with minimal leadership. Not for safety-critical or regulated contexts. Best for SISP projects, and “per-hour” independent third-party software development shops.
Plan-Driven Software Development Life Cycle (SDLC) Processes:	A full definition of requirements (including an insightful description of the underlying problem(s)) is defined first as a foundation for starting the project. In practice, this problem framing work is typically not included in the project, but done at proposal time by a panel of experts. Getting it done first-time-right is: critical, but near-impossible, unless the problems are simple.	Sponsor leadership must be prepared to accept drafts of requirements documents as evidence of positive “progress.”	Development projects focused on producing extremely large systems, often with intense needs for safety, and in regulated contexts. Comprehensive documentation (e.g. CMMI, UML, etc.), coordination across very large teams, and administrating large fixed budgets are prioritized above efficiency.
– V-Model (1-pass approach);
– W-Model (2-pass approach)
– Waterfall (irrationally inflexible, & sequential V-Model)
Lean Process	Prioritize identifying buyer “value,” and clearly documenting what buyers/ customers (not the project sponsor) are willing to pay for. It is assumed that buyers own their own requirements, and pursue their needs through purchases from options among an existing and established product category.	Sponsor leadership must be prepared to accept documents defining buyers’ values, or “voice-of-the-customer” (VoC) as evidence of positive “progress.”	Commercial development projects focused on creating “line extension” products cheaper and faster than competitors. Project efforts focus on developing minimal viable products (MVPs) that match buyers’ values, and win sales through lower costs and faster reaction to changing buyer preferences.
Integrated Product and Process Development (IPPD), including Integrated Product Team (IPT) structuring	Assemble a multidisciplinary stakeholder panel, including representatives from every related group and function across the entire organization that will make and own the product. This panel collaborates on problem framing and identifying the full life-cycle of requirements for every aspect of the product, not just its initial development	The sponsor representative and their leadership are included on the stakeholder panel. Sponsor leadership must be prepared to accept multidisciplinary full-spectrum requirements documents as evidence of positive “progress.”	Full life-cycle productization activities, include: not only creating a new product, but also maintaining, provisioning, supporting, financing, extracting value, etc. Best for large complex projects that include interdisciplinary integrated components, e.g., hardware, software, electronics, services, etc., potentially with large, manufacturing setup costs.

Process Recommendation for Innovation Projects

A single integrated, open, non-proprietary structured process may not yet exist that matches a project to create a “new-to-world” disruptive innovation that solves an important safety-critical objective problem. It is possible, however, to create a hybrid process that does match as a combination of useful pieces of multiple existing processes. From experience, the following hybrid combination successfully on multiple important projects:

(A) The IPT (an aspect of IPPD) to structure the team, distribute responsibility, and engage all stakeholders;

(B) PMP to create prototype tools to support the team through the problem framing work;

(D) After problem framing work is sufficient to support ideation for system design, use either Lean process or IPPD to define and construct a value-prioritized MVP;

(E-optionally) After development of an MVP, if the product includes intense needs for safety and regulation, then use the SDLC W-Model to transform the MVP into an approved solution;

(F-optionally) If the software coding work during “D” must include an independent third-party software coding shop (recommend only if absolutely necessity), use the Agile process to manage their contribution.

Discussion

From experience, while leading an innovation project with this kind of hybrid process, consider keeping the details about it on a “need-to-know” basis. If possible, avoid discussing process in detail with anyone who does not have a role of responsibility requiring them to fully understand. An additional benefit of using such a hybrid combination of processes (while keeping it confidential), is the project leader can usually respond with a truthful and confident “YES” when challenged by process-evangelists for whether the project is using some specific process or other. The detail that the project is using only one aspect of that specific process to structure only one topic of work within the project, does not need to be included in the response.

In practice, a project leader may not have the authority to select an appropriate structured process for a project, but instead be forced to use a mandated poor-fitting process. An awareness of such a dysfunction baked into the project, and what it means, can help the project lead predict and manage the future. This foresight can give the project leader options to consider while deciding what to do in a difficult high-risk situation. For example, options can include: covertly try to force the project to succeed anyway (with no hope of recognition); protect one’s career by covertly arranging to be reassigned and exit the project before failures become obvious; or just go with it and try to enjoy the inevitable unfolding spectacle and drama of waste and failed aims.

It is important to avoiding inflexibility in decisions about expending minor portions of project resources to address project risks that would not exist in a perfect world. The sponsor has the right to extract some degree of work from the project to satisfy their organizational internal political dynamics. If project budgets are proposed thoughtfully in advance, it can be possible to mitigate risks with reassignment of some minimal amount of project funding to generate redundant or objectively-irrelevant artifacts that satisfy subjective needs. [Note, regardless of level of externally-imposed dysfunction in a project, your employer and sponsor will always rather the project money (and your time) be wasted in failure, than for you to expose them to liabilities or embarrassments while trying to “heroically” force a project to success.]

To summarize… Selecting a structured process for a project is both critical and difficult. There are, unfortunately, many different processes, hosts of salespeople, process evangelists, and other self-interested promoters who make this decision-space very complex, confusing, and overwhelming. For a project lead, the task of selecting a process is, therefore, best done in confidence with the aid of a very few highly-experienced, process-neutral people. Finding the right people to do the process selection task (potentially including outsiders) can make the difference between success and failure.

[Link to return back to “Discussion Anti-Values”]

[Link to return back to “Discussion of Methods”]