[Link to return back to Technical Discussion of Anti-Values]
[Link to return back to Technical Discussion of Methods]
Technical 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-powered digital solution R&D projects…. First, there are two hidden meta-level sources of critical risk that frequently defeat innovation projects, and understanding and mitigating them is essential. And second, an informed, strategic selection of formal 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 representatives assigned to oversee the innovation project [we use the term “sponsor” to refer to the investor who funds the project] have 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 careerism 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” [a commonplace negotiation strategy focused on controlling and shaping the context by deliberately behaving in an unpredictable way] 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 that the project will address. Once the requirements documents are drafted, then the next step is to 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. In general, the more difficult the objective problem, the more serious the R&D effort needs to be. And, the higher the distractive 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 formal processes. If done right, adopting a well-matched process can be very useful in mitigating project risks of 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 purposefully 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 driving the 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 likely not happen, and the project aims will 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 distractive 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 hyperbole, 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 is to empower a project team to succeed, but the marketing coercion to adopt an ill-fitting process injects risks that the project will fail.]
An example… in our opinion, the marketing for the [redacted] process often obscures its narrow utility. Selling [redacted] to everyone, including the many different types of companies and activities that are not a good match for it, is a thriving multi-billion-dollar business. Conceding to sales messaging and choosing to “go along with the crowd by adopting [redacted]” is an irresponsible disregard for risk that wrecks many innovation projects. [Note, the name of the process is redacted here, because we are too busy to join in pointless arguments with highly-funded marketers.”] In our experience, projects with ill-matched formal process selection, as mandated by external pressures, have extremely poor functional outcomes.
[It is not our intention here to “align with” or “argue with” with any group of process promoters. Instead, the description of the various options is included only to show the extreme complexity of this important space, and to explain Trefoil’s commitment to balancing the high potential utility of processes against its equally high potential for distraction and injection of risk.]
Table 1. A summary, from experience, of 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, and onto the sponsor. 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 can lead 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 potentially 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 in practice, 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 version of the 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. |
| Human-Centered Design / Human Factors Engineering (HCD/HFE) | Iterative formal user studies and usability testing supports problem framing efforts. | Early development of experimental artifacts (user interface mock-ups and simulations, etc.) can additionally serve to demonstrate rapid “progress” to sponsor leadership. | Safety-critical projects where it is essential to get the user interface, user services, and use cases right and bullet-proof to human error. Good for regulated and certified domains. This process, however, is limited to the development of the “front-end.” And has very weak support for the systems engineering work of building, integrating and testing the back-end. |
Process Recommendation for Innovation Projects
A single 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 custom hybrid process that does match as a combination of useful narrow pieces of multiple existing processes. From experience, the following hybrid combination has successfully structured 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;
(C) The iterative formal evaluation aspect of HCD/HFE to generate reliable insight through the problem framing work (esp. in conjunction with early cycles of PMP prototypes);
(D) Lean process to generate a VoC to clarify the definition of value;
(E) 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;
(F-optionally) After development of an MVP, if the product includes intense needs for safety and regulation, then use the SDLC W-Model to refine the MVP into an approved solution;
(G-optionally) If the software coding work during “E” or “F” must include an independent third-party software coding shop (not recommend), use the Agile process to manage their contribution.
Discussion
From experience, while leading an innovation project with this kind of custom 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 those promoting a particular process. [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 or compose an appropriate structured process for a project, but instead be assigned to use a mandated poor-fitting process. An awareness of an unfortunate injection of a critical extreme-likelihood-extreme-impact risk into a new project from the onset, 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 an impossible high-risk situation. For example, options can include: go off-process to 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; practice political skills in shifting blame; or just go with it and try to enjoy the inevitable unfolding spectacle of waste and failed aims.
In our experience, it is important to avoid 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 off-mission 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 limited amount of project funding to generate redundant or objectively-irrelevant artifacts that satisfy subjective needs. In general, it is a privilege to work on an important digital R&D project, and relaxing the approach enough to accommodate a limited degree of not-safety-related sponsor distractions is usually necessary and worthwhile [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 covertly 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 (or composing a hybrid) 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 or composition task (potentially including outsiders) can make the difference between success and failure.