OC 3 – Chapter 12: Creative Commitment

«Alea iacta est.»
[The die is cast.]
Julius Caesar

Some people know exactly which project they want to realize — and then work on it. Sometimes this happens by choice, sometimes because the project is given to them, e.g., in work contexts.

Often, however, several possible projects are available, so a decision has to be made. That decision may be spontaneous, obvious, or deliberate, based on Wayfinding (see pages 149), Project Segmentation (see pages 165), both, or neither. But at some point, there is a decision to realize a project.

And that changes things in the creative system.

Implementation Focus

Once the decision to implement a project is made — once the Rubicon is crossed — the project shifts from possibility and exploration to constraint and execution. This changes the nature of ideation and of the work itself.

Now things get real.

Free or Open Creative Ideation is reduced (see page 99), because ideation becomes more focused as constraints are applied and ideas have to work. Previously, ideas were just ideas and you could play with them. Now they encounter resistance, limits, and reality.

As the project will either be realized or not, there will be a result. If it fails, it is a real failure, if it succeeds, it will be a real triumph.

In this sense, starting a project is an integration test — both for the ideas and for you: Can the ideas survive contact with sustained work and reality? Can you invest the energy and craft needed to make them work under real conditions?

Constraints as Consequence

Realizing a project depends on much more than conviction alone, e.g., valuing a project or deciding to focus on it. Historically, crossing the Rubicon was not a statement of intent, but an action that created consequences. In creative work, the equivalent is introducing consequences that make progress unavoidable.

This can mean reorganizing conditions — environment, structure, obligations — so that the project advances despite competing possibilities. Such constraints give the project priority in practice, e.g., reducing competing claims on time or energy, suspending competing projects temporarily, allocating fixed work time, producing work that requires continuation, or exposing the work to real deadlines or audiences. Two especially useful constraints are Release and Kill Criteria. They prevent both overcommitment and project hopping.

Without these constraints, a project may be started because it feels right, but as other activities displace project work, it quickly drifts or stalls. The result is often a feeling of personal failure, of not being motivated enough, when in fact the constraints were insufficient. With constraints, a project becomes a contract with your future self — you will either release the project or abort it.

Because starting a project is essentially a large-scale integration, you can use the ▯ Integration Worksheet to test the consequences and evaluate whether this change leads to sustained realization or merely shifts intention. If the structure does not hold, adjust it. If it does hold, the project has moved from exploration into implementation.

Scope of the Project

In order to decide whether to implement a project, a rough idea of its form and scope is needed. What will the project be?

Sometimes this is obvious — e.g., an app that performs a specific function, or a book on a specific topic. But even then ask: What is needed for that project to be viable?

Can you write down what the minimum viable project is and what its distinctive value would be? Can you imagine it, play with it, e.g., walk through how a member of the target audience would interact with it?

Form and scope can still change during realization. There is rarely a straight line from idea to realization, and the design space often contains surprises. But being able to define the initial form and scope shows whether the project has enough conceptual clarity.

If you cannot yet see the project clearly enough — e.g., to answer the Rubicon Criteria (see page 181) — the project is probably not ripe for realization. In that case, keeping it in the idea collection and letting it grow as a Central Project (see page 168) might be more useful.

Standards, Release and Kill Criteria

Projects usually benefit immensely from having clear standards, as well as release and kill criteria. Otherwise the risk of producing zombie projects (see Project Realization on page 195) or not releasing the project (see Project Release on page 233) is too high.

Standards protect the project both from unreachable perfectionism and from gradual dilution. They help to apply the craft logic of «If I’m gonna do this, I’m doing it right.»

This craft logic combines the decision to do it at all — commitment — with the standard you are holding yourself to.

Most people separate these questions. They drift into commitments half-consciously (e.g., «Let’s start doing that …»), then negotiate quality downward to conserve effort (e.g., «I think this might be good enough …»). The craft logic prevents that. Once the standards are set and the threshold of entry is crossed, dilution is off the table.

So what would «doing it right» mean for this project? How polished should it be? How much should be created? How fast? How consistently? How many resources can be used? At what personal cost?1

These standards are then bounded by the release and kill criteria:

Release criteria define what has to be implemented for the project to be released. They are not «success criteria», because success is determined at least in part by the field. But they set and maintain the standards.

They should be high enough for ethical craftsmanship — the work is actually good and you are willing to stand behind it — while avoiding perfectionism, because perfection is impossible (see Figure 5 on page 61).

Without release criteria, it is too easy to end up in endless optimization loops, where one attribute is maximized (e.g., readability) at the cost of another (e.g., completeness), and the work oscillates without moving toward release. Especially when invested effort raises fear of evaluation by the field, endless fiddling without substantial improvement becomes likely.

Kill criteria are conditions that, if they occur during realization, lead you to abort the project (e.g., «If by date X, I have not reached state Y, I’ll quit.», via Duke, 2022). Setting them in advance and in writing prevents you from having to make that decision while tired, emotional, or exhausted.

Kill criteria protect against common fallacies and traps, e.g., sunk-cost fallacy, escalating commitment, or shifting from hard problems to easy ones in order to preserve the illusion of progress. Once triggered, they stop you from continuing to invest resources in zombie projects that are not worth it and drain resources from projects that might actually work (see Project Realization on page 195).

Kill criteria can also protect against project hopping by not triggering. Even when a project becomes tedious, because of organizational overhead, formatting, or other friction, that does not meet the kill criteria. So there is no reason, or excuse, to postpone or abort it.

There are some situations in which kill criteria may justifiably be ignored. For example, if your planning was off because intensive work uncovered additional material that makes the project much better, then the changed situation may justify an extension. In contrast, if the work was haphazard because your heart was not in it, the kill criterion should end the project and free you to invest in something better suited.

So, looking at your project: Under which conditions will you release it or abort it? When does implementation stop? Which deadlines are non-negotiable? Who holds you accountable?

Rubicon Criteria

The following checklist shows decision criteria that can be applied once the Scope of the Project (see page 179) is clear.

It is meant as decision support to help answer the question whether a project is ready to cross the Rubicon, i.e. whether it would make a good Core Project (see page 167). Not all criteria will matter for every project. For smaller projects that take only a few days and few resources, just trying to realize them is often more efficient.

There is also something to be said for planning optimism, i.e. underestimating the amount of time and work required. Many creative projects would never have been realized if their creators had known in advance how much work they would take.2 But for larger projects, these criteria can help avoid suboptimal choices that waste precious resources.

1. Contribution

First determine the target group. What actual contribution does the project make for it?

  1. Usefulness: What concrete problem is the project supposed to solve? What makes that issue relevant?
  2. Value: How high is the actual — not merely assumed — value or impact for that group?3
  3. Newness: Is the idea or project actually new? Who is the competition? What is the status quo you compete against? This requires research into similar or identical ideas, e.g., via market, literature, or competition research.
  4. Acceptance: How well will the target group understand it? How well will they accept it?

2. Feasibility

Second, how feasible is the project?

  1. Solvable Problems: Are the hard problems (monkey problems) solved, or are there at least promising and tested ideas for how to solve them (see also Hard Prob-lems Not Solved on page 185)? To avoid paper solutions, ex-ante evaluation, preliminary analysis, prototypes, rough drafts, a quick check of whether the numbers work, or expert feedback can help.
  2. Sufficient Resources: Can you actually implement the project with the resources you have? These include time, money, material, access to the domain and field, etc. Is collaboration or delegation needed and available? Rough estimates are sufficient, but the planning fallacy will usually lead to an underestimation. Looking at past planning versus reality can serve as correction.
  3. Access to the Field: Can you get feedback from the people who decide whether the project is creative (target audience or its gatekeepers)? How about distribution?
  4. Timing: Is the timing right (Zeitgeist)? Is the necessary technology or infrastructure available and stable enough? This is hard to predict, but it is possible to be too early, and being the first-mover is not always an advantage.

3. Personal Fit

Third, how well does it actually fit to you?

  1. Wayfinding: Is this project a worthwhile waypoint in relation to your aspiration? Better than the alternatives?
  2. Person Aspects: Do desire (e.g., motivation, interest, meaning, resonance), craft (e.g., knowledge and skills), and will (e.g., courage and persistence) align?

4. Ethical Fit

Fourth, ethics becomes an issue when projects are implemented. Entertaining ideas does not mean accepting them, but once you start implementing them, you become responsible for them. See also the supplemental materials.

  1. Main Effects: What changes once the project is finished? Who can or will use it? Is it a positive contribution, or does it exploit human weaknesses?
  2. Side Effects/Far-reaching Effects: What are the possible side effects or far-reaching effects?

Assessing the Criteria

It is unlikely that a project will score highly on all of these at once. And things will change during the project, especially the person aspects. You may realize that you need more knowledge or skill — either by learning or by delegation — and projects usually contain phases that are tedious, difficult, or simply annoying.

But if chosen well, realizing a creative project should be a positive, even rewarding experience. At the very least, it should end with a sense of accomplishment.

Decision Conflicts

When several possible projects are available, more than one may qualify to cross the Rubicon. For example, you may have several Central Projects (see page 168) that have progressed far enough to be realizable — the hard problems are solved — and more than one of them would make a valid Waypoint aligned with your Aspiration (see pages 149).

Because implementation energy is limited, starting more than one would usually diffuse that energy too much. Not only would each project receive only part of the available energy, but switching costs and attention residue would dilute that energy even further. Progress is then likely to be slow and unsatisfactory.

As the unchosen projects remain in the idea collection, the question is usually not «either-or», but rather «first-second». That should reduce the pressure to decide immediately. It should also help that the unchosen projects can continue to grow in the collection and may actually profit from not being chosen yet.

In some cases, however, there are genuine goal conflicts in which the unchosen projects cannot simply be realized later. Time and resources may allow only one project, and there may be no way to combine the competing options. Nor may there be another project in the collection that beats both.

There are different methods for dealing with such goal conflicts, for example:

  • Argue: Two people, or one person and an AI, argue, one for each project. However, the sides are switched repeatedly to avoid hardened fronts and emotional attachment to one specific project.
  • Prioritization Grid: Put the possible projects onto a grid using two key metrics on the x- and y-axis,4 e.g., Impact × Feasibility, or Elegance × Functionality, or Newness × Usefulness, or Feasibility × Value. To avoid being biased by the clustering, rate the possible projects on both axes before starting to put projects on the grid.
  • Metric Formula: Use more than two metrics and combine them mathematically, e.g., by squaring and then multiplying them: Impact² × Feasibility² × ROI². Squaring them first punishes low values more strongly than simple multiplication. Separating Impact from ROI may be questionable, but it can make room for projects with high impact and low financial return.

Common Failure Modes

When it comes to deciding on a project to realize, common failure modes are that hard problems are not solved, the idea not being new, the idea not being useful, abandonment or project hopping, crossing the Rubicon too eagerly, and hesitating to start.

Hard Problems Not Solved

Feasibility is a hard barrier — see Working on the Wrong Problem on page 106. Not solving the Monkey problems first can lead to nasty surprises during the realization.

For example, some problems can turn out to be gravity problems that cannot be solved, only designed around. Others are wicked problems that are hard to define and resistant to solution.5 If you cannot solve the hard problems or they surprise you during realization, they can stall or even prevent progress. Worst case is a zombie project that does not advance and simply consumes brainpower and other resources until it is killed.

Keeping project ideas in the idea collection until the hard problems are solved avoids much of this. Focus on the problem itself and the focused ideation needed to solve it, without the overhead that comes with treating it as a full project. You may still be surprised during realization if something was overlooked, but the risk is lower.

For example, imagine you want to develop an app and need to read data from a device. Before starting the project, you first test whether the data can actually be accessed. You do not build the app itself or anything else — you only solve the thing that could break the project. A simple interface that tries to access the data, nothing more. You can even test several routes to the data and decide later which one to use. But unless that specific hard problem is solved, the project does not start.6

Not every problem needs to be fully solved beforehand, as long as there is justified confidence that it can be solved. Depending on the project, a preliminary analysis, prototype, or rough draft section may provide a sufficient proof of concept. If experts say it cannot be done, investigate their arguments. Check why they think so and whether your approach bypasses their objections. Experts do not necessarily think of the same workarounds you do. Blanket statements without argument or evidence — «Cannot be done», «Doesn’t work», or «Nobody wants that» — should be treated skeptically. If experts say it can be done, you should probably hurry with the implementation, because others may already be on the same track.

If you miss a hard problem and it turns out to be unsolvable — in reasonable time or at all — the kill criteria should trigger and end the project.

Idea Is Not New

Newness is a requirement of creativity. But checking whether an idea is actually new can be highly aversive. People usually do not want to find out that the idea already exists, because that would mean they cannot use their great idea as they imagined it.

Still, you are better off knowing. And if possible, you can build on what you find. You will likely have a different take that can improve the existing idea once you see how others have realized it. You may even beat their solution if you know how it works and go beyond it.

So deliberately setting aside enough time to find out whether the idea is actually new, or asking others to help check, improves the creative work.

Idea Is Not Useful

Usefulness is also a requirement of creativity. A project has to solve a need for a target audience. But that need is hard to assess.

If you are not part of that audience, seeing things from their point of view is difficult, especially because many constraints are invisible unless you analyze the situation or have direct experience with it (cf. Knowledge for Ideas on page 96). If you are part of the audience, the opposite problem appears — overgeneralizing from yourself to everyone else. An individual person is rarely representative of a whole group. What works for you may be too complex for others.7

Thus, getting an honest assessment of the project’s value requires deliberate work and access to the target audience8 (see Understanding a Situation on page 221 and Value of a Solution on page 224 in Project Evaluation).

This even applies to private projects done solely for oneself, e.g., creating a journal or sewing a piece of clothing. Assessing whether it will actually be useful can be surprisingly hard — many projects seem good at the moment but do not translate to long-term usage.

The value of the idea also has to be preserved during realization, which usually requires repeated check-ins with the target audience (see Project Evaluation on page 211). This kind of feedback helps keep the project on track and prevents it from mutating into something unusable, e.g., through feature creep.

Abandonment or Project-Hopping

Projects can be started, worked on, then quickly abandoned when the work becomes difficult or other commitments displace the project work.

These starts and stops are highly aversive9 and deeply unproductive. Project-hopping in particular leaves little to show for, because projects never move beyond their initial easy stages.

One reason project-hopping is so tempting is that the comparison is unfair. The other project really does look easier, because the hard or tedious part of the current project is being compared with the easy part of the other project. In reality, the other project will likely have its own hard and tedious phases as well. They are just not visible yet because the project has not advanced that far.

One way to deal with this is to create the consequences needed for project work, including kill criteria. Since «the work is tedious for a while» or «the work becomes hard» is usually not itself a kill criterion, and because the project is bounded by both release and kill criteria, the work continues.10 And while doing the core project, the central projects, with ideation and structure only, can satisfy the need for simplicity and play.

Crossing the Rubicon Too Eagerly

Realizing a project requires blocked work time, which should already limit how many projects get started (see also Creative Energy on page 165). Still, it is possible to cross the Rubicon too lightly, too eagerly, and more out of mood or conviction than because real consequences have been created.

In such cases, projects are started and then quickly abandoned when «life gets in the way» or «the mood shifts». Serial starting and abandoning is usually not just a problem of discipline or willpower. Often it points to a deeper issue. For example: Were the Rubicon Criteria (see page 181) actually applied — especially the personal-fit criteria? And what can be learned from the repeated pattern of starting and abandoning projects?

Hesitating to Start a Project

Whether it takes the form of analysis paralysis or just the question «What if I make the wrong decision?», hesitation to start is also common.

A started project will indeed absorb most implementation energy until it is either released or aborted. But it is unlikely to be the first or last project. If you use Wayfinding (see pages 149), the project is just one waypoint on a journey guided by aspiration. If the decision was suboptimal, you adjust with the next project. Even if it was a large project, you probably learned a great deal from it.11

Once you cross the Rubicon, you cross it with the best project that was available to you at that time. You made the best decision you could with the information you had. And you know in advance that the project will either be realized and released if the release criteria are met, or aborted if the kill criteria are triggered.

That mindset allows you to use your full powers on the project, make it the best it can be, and even enjoy realizing it.

Underflow, Optimal Flow, and Overflow

Crossing the Rubicon badly as well as not daring to cross at all prevent successful projects (see Table 17).

Aspect Underflow Optimal Flow Overflow
Constraints not set, daily life crowds out project work blocking sufficient time and energy for the project constraints so tight that they strangle flexibility
Scope unclear, feature creep, no standards preventing quality decline, no release criteria leading to endless «optimization», no kill criteria leading to zombie projects minimum viable project with distinctive value, challenging standards, clear release and kill criteria too strictly defined, preventing the project from growing and improving during realization; standards so high that release is blocked
Standards, Release and Kill Criteria not defined, quality usually negotiated downward, high risk of postponed release or zombie projects clear and high standards, release and kill criteria, but no perfectionism, accountability partner if needed over-detailed standards, release and kill criteria, not based on real constraints but on a perfect world
Rubicon Criteria insufficiently checked, leading e.g. to lack of value, undiscovered monkey problems, etc. checked, but if criteria are unclear or not fulfilled, that is recognized and chosen deliberately endless analysis and rumination, especially when more than one project could work; avoiding decision; being discouraged when some planning fallacy might actually be useful
Common Failure Modes hard problems not solved, idea not new, idea not useful, abandonment or project-hopping making an informed decision and then enjoying the project work too many projects, hesitating to start

Table 17: Creative Commitment — underflow, optimal flow, and overflow.

However, while the argument of this chapter is that starting a project should be taken seriously and made possible by real constraints, sometimes jumping blindly into a project can work as well. Sometimes there is little other choice, e.g., when work or reality confronts you with a creative problem.12

But if you have multiple possible projects in your idea collection, then making a deliberate decision about where to concentrate creative energy is both feasible and worthwhile — and it makes it possible to realize even complex projects.

Where it fits into your current creative process:

  1. Update your ▯ Creative System Map.
  2. How many projects are currently being implemented? What is their scope? Their release and kill criteria?
  3. Mark whether it constrains output, i.e., is a potential candidate for an ▯ Integration Worksheet trial.

Endnotes

  1. Realistically, if you are reading this book — especially this footnote — your standards will likely tend to be too high, possibly toward perfectionism. Ethical craftsmanship covers a wide range from good to excellent work. Producing very good work allows you to finish projects — more quickly or at all — and get feedback that improves future work. ↩
  2. Including this book. It took far longer than expected, despite a private sabbatical to work on it full-time. ↩
  3. Money is often a strong signal for value. People may say they like something, but if they spend their own hard-earned money on it, you usually know that it has value for them (excluding monopolies, social muggings, taxes, etc.). This even works in art. If you want to know which paintings are especially cherished in a museum, look at which postcards and posters are frequently restocked. Not the price of the painting itself, that is often muddled by money laundering. Sometimes the money is spent indirectly, e.g., when people travel far — at real cost — to see certain works of art. ↩
  4. Established examples include the IBM (2018) Prioritization Grid, which uses the axes Feasibility × Value. ↩
  5. Burnett & Evans (2016). ↩
  6. Failing to solve the hard problems first has threatened many bachelor’s and even master’s theses. For example, a student wanted to use data from a fitness tracker in his app. I asked whether he could actually access the data, and he said «Yes.» because he was confident that he could — but he had not tested it. Once the thesis had already started, and time was running, he found out that the data could only be accessed through a proprietary app. And that app was a data island that did not allow access to the fitness data. There are ways to save such a thesis, but testing access beforehand would have prevented a great deal of unnecessary anguish. This is only one example. The same logic applies to lacking necessary knowledge or skill, lacking access to resources or to the target audience, and much more. ↩
  7. Creative people spend a great deal of time thinking about problems and developing solutions. For them, those solutions often seem obvious because they understand how they work — after all, they came up with them. For other people, seeing how and why something works, or how it should be used, can be much harder. That gap is difficult to bridge. ↩
  8. You can make things easier by creating for people you know, like, and have access to. That sounds trivial, but it is often ignored. ↩
  9. Like climbing onto the 10-meter board and then climbing down again. ↩
  10. The work may still suck for a while, but if it has a clear end, that is usually manageable. ↩
  11. People usually learn more from bad decisions than from good ones. It still sucks. And a better project would have left you in a better position. ↩
  12. For example, if three astronauts are trapped in a broken spaceship and you need to find a way to repair the CO2 scrubber with what is available in the capsule, as in «Apollo 13». ↩

Supplemental Materials

 

 

 

OC3 Navi