OC 3 – Chapter 13: Project Realization

«Alright, I’ll give it a try.»
«No! Try not. Do … or do not. There is no try.»
Luke Skywalker and Yoda in «Star Wars V»

Realizing a creative project varies enormously across domains and fields — from creating a bouquet or planning a romantic evening to programming an app, creating a sculpture, writing a book, or doing a PhD thesis.

However, the requirements and failure modes are remarkably similar.

No matter the project, realization is where ideas first encounter conditions they cannot ignore. Something may have been clear and coherent in imagination, or even externalized on paper, but once you realize it, it gets tested. First, by your actual knowledge and skill in implementing it. Reality determines whether it is feasible and works as intended (functionality, domain). Later, it is evaluated by the field (gatekeepers and target audience; see Project Evaluation on page 211).

So, how can project realization be made more successful?

Realization Approaches

Some projects are one-shots. You have an idea, realize it, and whether it works or not, you are done. Other projects are iterative — they are built with the expectation that the first attempt will not be the last.1 You realize a version, e.g., a mockup, prototype, or a minimum viable project, get feedback, ideally from the target audience, and then develop the next iteration on that basis.

This iterative approach has several advantages. At the outset, the understanding of the situation and of an appropriate solution is necessarily incomplete, especially regarding how the target audience actually behaves and the context in which the artifact will be used.

Each evaluated iteration therefore generates knowledge — it reveals how the solution works in practice and reduces uncertainty. Because learning is built into the process, you do not need to get it right the first time. That would be difficult or impossible in many domains, because the situation is just too complex. Iteration also guards against the «I know what they really need better than they do» fallacy by confronting assumptions with actual use.

Working in small, revisable increments keeps the design flexible rather than ossifying into something monolithic and hard to change. It also allows projects to start early and with limited investment — first ideas, then mock-ups, then prototypes, and only later a fully realized work. And it helps prevent feature creep. You know the current version is not the last, so additional features can simply be written down and considered for a later iteration.

There are different names and variants for this approach, often versions of a human-centered design process.2 It is a planned process that explicitly works through iterations.

At the start of each cycle, you analyze the situation: Who uses the current solution, where, when, under which circumstances, and what problems it should solve?

Based on that understanding, you derive requirements — aspects the solution must fulfill or avoid. These requirements then guide possible solutions, which are evaluated based on how well they fulfill these requirements. This can be done by your own assessment or by using mockups or prototypes to test designs with the target audience.

Depending on the results, you may return to the situation analysis, change the requirements, or develop different solutions. These iterations are used to understand the target audience and the task, and also to uncover which contextual factors actually matter and which dominate. These invisible forces are usually best discovered in practice.

The iterations continue until you have a solution that meets your standards,3 after which it is often evaluated more broadly.

Although this user-centered design process is usually associated with software development,4 it can be applied in any domain.

For example, imagine you want to create a truly memorable evening for your partner. You cannot plan it purely from your own idea of what would be «romantic», because what matters are the other person’s associations, tastes, and expectations. So you explore over time, trying to understand the situation from her perspective — i.e., the target audience and the context. You notice which restaurants she enjoys, try out a drink and observe how it is received, pay attention to whether she prefers quiet places or lively ones, perhaps ask indirect questions or recall past experiences. From these observations, you develop a clearer sense of what would make the evening work and what to avoid — i.e., requirements. You then can iterate and try out different romantic evenings. Small probes that help refine the plan. Gradually, a coherent picture emerges, and you shape the final arrangement based on what you have learned over many evenings rather than on an initial guess. Approaching the event this way increases the likelihood that the evening will actually fit the person it is meant for, because knowledge is built step by step in practice rather than assumed in advance.5

Larger creative projects work much the same way. Early versions, sketches, or prototypes are not failed attempts at the final result, but ways of discovering what the next iteration should be.

Another useful effect is that these intermediate steps are not merely tests, but experiences in their own right. Because they already create value, the process remains worthwhile even when adjustments are still needed. This is a useful attitude in any creative endeavor, where outcomes are uncertain and progress is often indirect.

Thus, a minimum viable project is not a reduced version of the work, but a deliberate instrument for learning quickly and with limited investment. Instead of committing extensive resources without feedback and risking getting it wrong, development proceeds together with the target audience.

The users involved in such explorations must, of course, be reasonably representative of the wider audience the project addresses. This is trivial in the example above, but much harder in product development, where feedback often comes mainly from particularly motivated or easily accessible users (see Project Evaluation on page 211).

Project Constraints During Realization

Realization gives ideas form — but which form? Ideally, the constraints were already determined when crossing the Rubicon (see Creative Commitment on page 177). Otherwise, feature creep, mission drift, dilution of standards, and frequent mutations are likely, and the energy just diffuses.

During realization, especially with iterative approaches, form and scope can change. However, the essence of the project should remain stable.6 This preserves compatibility with both domain and field affordances and makes successful and accepted work more likely. Determining constraints in advance also ensures that later changes in form and scope are deliberate decisions.7

For projects that are or may become commercial, issues such as copyright and plagiarism also have to be considered, e.g., regarding texts, images, or fonts.8 Similarly, release and kill criteria have to be maintained in order to avoid zombie projects.

Long-Term Focused Implementation

The time and energy needed to implement a project must remain available until the project is either realized or aborted. With larger or more complex projects, this can easily mean months or years.

Focusing on one project (see Creative Energy on page 165) ensures that implementation energy is not fragmented across multiple projects. However, environmental constraints are still needed to protect that time and energy from other activities. Otherwise, daily business crowds it out. Ideas start projects — routine finishes them.

Implementation focus is especially vulnerable during emotional dips such as boredom, self-doubt, or bouts of meaninglessness. Usually these pass.9 Sometimes by pushing through — embracing the suck or simply starting to work for 20 minutes even if you are not in the mood (e.g., time blocking, Pomodoro). You will likely either get into the mood or notice that you do not need the right mood in the first place. Sometimes it helps to remind yourself what you want to achieve — form, scope, meaning — but in general it is better to create environments in which work happens irrespective of mood.

Because the energy is needed over long stretches of time, both intensive work phases, e.g., focused sessions of deep work, and rest phases are necessary. Actual breaks and break days restore the needed energy and keep the mind flexible. Breaks also create distance and make it easier to check whether you are still on the right track. Longer breaks allow you to look at the work with fresh eyes before committing to continue building on it.10 Without sufficient breaks and break days, work phases usually become shorter over time, available energy declines, and motivation drops — up to the point where you cannot stand the project anymore because it has become your whole life.11

At the same time, a core project usually suffers if breaks last more than a few days. Even if you cannot work on it directly — e.g., while traveling — you can often still do related work, e.g., learning, skill-building, or secretarial work.

You see what works for you in the current project by tracking your progress — output, deep-work phases, milestones, weekly reviews, or similar markers. That allows time-limited trials to see whether your way of working is actually producing the desired results (see also ▯ Integration Worksheet).

Craftsmanship

To increase the likelihood of a successful project that is actually useful, knowledge and skill have to be applied deliberately. Your standards (see Standards, Release and Kill Criteria on page 179) combined with the project constraints give you a clear target. Gaps between the idea and reality will still occur, but these are usually craft issues. For example, you know that a scene has to happen in the story, but not yet what it looks like.

Ideally, the work itself holds you accountable by providing clear feedback on whether you are meeting your standards. In some domains the material pushes back directly — wood breaks, colors run into each other, or musical notes sound wrong. In other domains, feedback from others is needed — e.g., whether a text or an app is understandable (see Value of a Solution on page 224).

While standards may seem constraining, they link effort to visible progress, orient you toward something higher (e.g., excellence, beauty), and enable a sense of accomplishment when they are met or exceeded.

In short, they make it possible to celebrate doing good work.

Pragmatic Planning

Your minimum viable project specifies what has to be done to complete it. This allows you to align behavior and environment with the task and to check whether progress is being made.12

For complex projects, some kind of plan — e.g., milestones with deadlines — provides orientation and concrete goals to strive for.13 Such plans keep the work on track while remaining flexible enough to handle unexpected turns during realization. Without them, energy is hard to focus, progress is difficult to see, and confusion is likely. Order first, motion second — the clarity creates momentum.

However, planning and monitoring can also become a trap. Compared to realization, planning often feels safe, and that safety is seductive. It can easily lead to avoidance, over-planning at a level of detail that creative work does not permit, and paralysis.

So planning is just a means to an end — the realized project. Its level and scope have to fit.

Planning usually includes what is needed to make meaningful progress on each workday, e.g., deep-work phases (often best before daily commitments strike), breaks and break days, tools (available? better tools?), and regular workplace preparation (e.g., mise en place,14 clear to neutral, low distraction). Mentally playing the realization phase through can make it concrete enough to plan, though the planning fallacy will usually still lead to optimistic planning.15

Treating planning like a trial, with regular project reviews to check whether planning and work actually integrated, keeps planning honest and turns it into a design parameter that can be improved. Depending on the situation, the plan may be too optimistic or not challenging enough, and the invested time and effort may have been too little or too much.

Regular Evidence-based Reviews

Long-term projects mutate and drift easily. Sometimes that is desirable — for example, when deeper engagement with the topic and feedback from the target audience lead to better ideas and solutions. Realization is not a straight line, so detours, changes, and setbacks are expected. Other times, however, the changes are just relaxed standards and a slow dilution of craft. In both cases, comparing the work to the Project Constraints During Realization (see page 198) and the Pragmatic Planning (see page 201) helps ensure that the project is developing in the right direction.

Because these changes happen gradually and are hard to notice, regular reviews are needed. Scheduling appointments for such reviews — e.g., every one or two weeks — helps ensure they actually happen.

To base the review on something solid, it helps to document the work. For example, answer the question «What do I want to achieve today?» before working, and after working answer «What did I achieve today?» and «What is my assessment of the day?» One sentence is usually enough. Done routinely, this produces a reliable behavioral trace that can be used to evaluate changes, e.g., via the ▯ Integration Worksheet.

If the work slows or other issues appear, regular evidence-based reviews catch them and make adjustment possible. Even better, they make progress visible and allow you to celebrate it deliberately — for example, when a milestone is reached.

Common Failure Modes of Realization

Frequent failure modes when realizing a project are Blocks, Zombie Projects, Lack of Implementation Energy, Mistakes, Fear and Self-Doubt, and Someone Beat You to It. For Aban-donment or Project-Hopping see page 188, for too many projects, see Diused Energy on page 173.

Blocks

If blocks appear during realization and the hard problems were already solved (see Creative Commitment on page 177), they are usually local rather than project-concept problems.

The typical «writer’s block» or «artist’s block» is often either a lack of structure (looks too complex, cannot grasp it, no coherent thread), doubt (see Fear and Self-Doubt on page 206), or Lack of Implementation Energy (see page 204). Lack of structure is especially common at the start of projects. The scope feels overwhelming, and you do not know where to begin.

Whatever the cause, structural blocks are not solved by more raw material or more ideas, but by structure — ordering the material, making an outline, or otherwise imposing form. Sometimes the best way to structure a project is to start from the end. You may not know where to begin, but you usually know where you want to end up. From there, the next step often becomes obvious.

Zombie Projects

A project that fails still produces something — experience, clearer judgment, and material you can build on. It also frees you to move on. Some projects, however, neither succeed nor fail. They remain in limbo indefinitely, occupying time and attention while preventing you from doing other work that you could actually complete.

Sometimes the project keeps mutating — feature creep prevents both realization and abortion. In other cases, this limbo is maintained by a toxic mixture of escalating commitment and sunk-cost fallacy, combined with doubts about quality and fear of judgment once the work is exposed. In both cases, the project is neither alive nor abandoned, but quietly blocks everything around it.

In such situations, incremental improvement is often the wrong instinct. What helps is a forced change of conditions, e.g., publish a fragment, impose a hard deadline, or deliberately set the project aside for a defined period. Switching from a one-time release model to iterative development with multiple releases can also help. And sometimes the most productive move is not to untie the knot, but to cut it and move on.16 Just kill the project and learn from it.

Lack of Implementation Energy

Implementation energy can be insufficient when the core project receives too little of the potentially available energy.

Sometimes this is due to too many competing projects (see Diused Energy on page 173). But it can also happen because the project has lost its challenge — things have become too easy, merely craft or organizational work — or because there is a misalignment between you and the work.

Loss of challenge can often be pushed through — by trying to exceed your own standards, for example, or through emotional regulation such as listening to music. Misalignment with the work is deeper. It requires hard questions — e.g., «Do I really want to do this work?» — and perhaps some coaching. That clarity can be uncomfortable, but both the discomfort and the answers are diagnostic.17 In some cases, embracing the suck or outsourcing parts of the work may help.

Insufficient energy can also result from spending too much energy elsewhere — generating lots of ideas, other commitments drawing energy away, constant distractions and interruptions — or from burnout because breaks and break days were neglected, especially in decision-heavy phases. In those cases, what is usually needed is protection of the time for realization (e.g., environment changes, constraint planning) and strict adherence to breaks and break days — especially when that is hardest to do.18

Mistakes

Mistakes are part of creative work, because nobody has — or at least you have not — done it before. You are just finding out what works and what does not. If you make decisions on the basis of the best information available at the time, you are making defensible mistakes. The mistakes may still look obvious in hindsight, but only in hindsight.

A good way to show this is to give someone else the information you had before making a decision and ask what he would do. That person will usually make the same mistake. It only becomes obvious once one knows it will not work.

Mistakes can be minor and solvable. Usually they only cause delay and may require some focused ideation (see Ideation Types by Project Stage on page 99).

Major errors include gaps and conceptual mistakes — problems that call the feasibility of the whole project into question. These are hard problems or showstoppers that should ideally have been caught before the project started (see Hard Problems Not Solved on page 185). You may have to pause the project, though there may still be a solution that makes it feasible later. So it can make sense to park the project, return it to the collection, and perhaps reactivate it later. In any case, examine why the hard problem was not spotted earlier.

Over-Commitment

Creative projects can be important. But if everything is directed at one project, life becomes entangled with it. Too much rests on the progress and success of that project — identity, mental health, and meaning.

That kind of focus is a realization-specific risk in long projects. It can permit impressive progress. But setbacks hurt more, and failure can become devastating. It also becomes harder to maintain perspective and humor, both of which are needed for creative solutions. Bertrand Russell put it well: «One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important.» Kill criteria then become harder to apply even when necessary, and even release criteria may be ignored for fear of the void left once the project is complete.

So while a strong focus is necessary for progress, it should never be the only focus. Otherwise everything becomes too vulnerable. A single major setback or failure can derail or crash both the project and your life.

Fear and Self-Doubt

During realization, things become real, and that realness can lead to fear and self-doubt, which narrow the mind. Table 18 gives examples and possible counter-perspectives.

Fear/Self-Doubt Different Perspective
feeling stupid while doing the work Not surprising. You are doing something that was not done before.19 Drowning it out with music20 or simply doing a first version often helps (e.g., a «shitty first draft»21).
Imposter Syndrome Feeling like a fraud.22 Sometimes this comes from a mismatch between preferred ideation modes and what the domain or field expects (see Generating Ideas). Then the result has to be understood and explained through a different mode.
being wrong Evaluation will show it. Being wrong is not a moral failure if the decisions were made well. It is material for learning. See also Mistakes.
having wasted time and effort Realizing the project likely increased knowledge and skill. Learn from it.
judged by the finished work Examine why you expect negative judgment, e.g., unsupportive environment? The useful counter-question to «What if it is shit?» is «What if it is a good idea and you prevent others from using the fruits of your work?» And even if judgment is negative, think iteratively — if people stopped after the first negative feedback, no one would improve.
pushback by the field Likely with some topics. Why are you doing this work? Is it important and true? Does it provide meaning? If so, that is part of the price.
thinking the work is «trivial», «obvious», or «cringe» Expected after long immersion. It is trivial and obvious to you under these conditions. Find out what others actually think by evaluating it (Evaluation), then learn from that for future projects. And do not let «cringe» be the blocker of dreams — evaluate that, too.
feeling empty once the project is completed Release the project as well as you can, then look in the idea collection for a new core project — e.g., among central projects — or enjoy a break.
afraid of success (expectations might rise) Check the role of the environment — is it actually supportive, or merely pressuring? Supportive environments can tolerate natural variation in creative work.

Table 18: Possible Fear and Doubt and Different Perspectives.

In general, thought-based fear is just that — thoughts. Intelligent and creative people are very good at overthinking, and very creative in imagining worst-case scenarios.

However, often that is illusory fear — actual fear is much deeper in the body.

See also the supplemental materials.

Someone Beat You to It

Sometimes the solution did not exist when you started, but while you were working on it, someone else did something similar. And they beat you to it.

Parallel creativity is normal. Many people stand on the shoulders of the same giants. Someone else publishes a similar study or book, develops the same app, explores the same theme.

That can be shocking.

But first check whether they actually did the same thing. In some domains, parallel creativity can lead to identical solutions that kill the project outright (e.g., math, patents; see also page 18). In others, the differences can still matter, and the project can be taken in another direction.

Examine where your solution differs and emphasize that difference if the project remains useful. For example, if the competing app uses heavy gamification, perhaps a less gamified app becomes the better alternative — or vice versa.

Underflow, Optimal Flow, and Overflow

Both underflow and overflow are likely during realization — from insufficient planning and energy to over-planning and overcommitment (see Table 19).

Aspect Underflow Optimal Flow Overflow
Realization Approaches treating every project as a one-shot, learning too late that assumptions were wrong choosing one-shot or iterative realization to fit the project, target audience, reversibility, and risk endless iteration, perpetual prototyping, no convergence toward release
Project Constraints under-defined project, vague goals, difficult to focus on minimal viable project with distinctive value, used as a standard when changes are made over-defined project, no flexibility for improvement during realization
Long-Term Focused Implemen­tation progress too slow, work stalls, demotivation one core project, other projects only in ideation/structure, side projects if needed, breaks and break days doing the project to the exclusion of everything else, becoming aversive quickly
Craftsmanship shoddy work, rushing just to finish clear standards, excellent work, feedback from work and target group perfectionism paralyzes the work
Pragmatic Planning insufficient planning makes course correction and progress checks impossible milestones and deadlines, right scope and level of detail, regular preparation of the workplace planning with tasks, milestones, and time estimates so detailed that it no longer fits unpredictable creative work
Regular Evidence-based
Reviews		 no review means drift goes unnoticed generating hard evidence through work itself, regular check-ins, adjustment tracking and reviewing replace the work itself
Common Failure Modes of Realization Blocks, Zombie Projects, Lack of Energy, Mistakes, Someone Beat You to It enjoying the work, knowing you have done your best to ensure progress Fear and Self-Doubt, Over-Commitment bypassing Kill/Release Criteria

Table 19: Project Realization — underflow, optimal flow, and overflow.

Being clear about the project and checking in regularly should keep it on track. It also allows you to focus on the work itself, knowing that problems are likely to be caught early — and that realizing the project can still be fun.

Where it fits into your current creative process:

  1. Update your ▯ Creative System Map.
  2. What path has real work followed recently? What did you actually produce? What almost happened but did not?
  3. Mark whether it constrains output, i.e., is a potential candidate for an ▯ Integration Worksheet trial.

Endnotes

  1. Iterative work accepts that the first version will be wrong — experience suggests that most later versions will be wrong as well, but in increasingly useful ways. ↩
  2. A formal description of this approach is given in ISO 9241-210:2010, which defines human-centered design as an iterative process involving understanding the context of use, specifying requirements, developing solutions, and evaluating them. ↩
  3. In practice, iterations are often stopped earlier because of resource limits, especially time. ↩
  4. A good example is the iterative development of the push-forward combat system in DOOM: «Embracing Push Forward Combat in DOOM» (https://www.youtube.com/watch?v=2KQNpQD8Ayo). ↩
  5. The romantic-evening example may seem unusual for iterative design, that is why I chose it. Iterative design works in many contexts — it is not limited to software development. ↩
  6. People often overlook what already works when they want to change something. Things that work frictionlessly are not noticed, because they «just work». But changes can quickly introduce friction. Akin to Chesterton’s fence: «Don’t ever take a fence down until you know why it was put up.» ↩
  7. Akin to how rules work. The function of a rule is not to coerce you into following it, but to make sure you have a good reason when you break it. ↩
  8. Plagiarism and copyright are separate issues. Plagiarism means acknowledging your sources. If an idea or text is not yours, indicate that clearly. Mistakes can happen easily when the source was not preserved, e.g., in the idea collection. If that happens, you are still responsible when it is found out. Copyright remains an issue even if you cite the source, especially for figures in non-fiction books. It also affects, e.g., the fonts and images you can use. Some fonts and images can be used freely. Others — even those that came with an application — require licenses. ↩
  9. As the saying goes, «This too shall pass. It might pass like a kidney stone. But it will pass.». Or as Joy Clarkson wrote on X: «This is your gentle reminder that one time in the Bible Elijah was like ‹God, I’m so mad! I want to die!› so God said ‹Here’s some food. Why don’t you have a nap?› So Elijah slept, ate, & decided things weren’t so bad. Never underestimate the spiritual power of a nap & a snack.» ↩
  10. For example, during a writing project — once the outline is done, you take a break of one or two days, then read it again. You will likely see things differently, revise the outline, and only then start writing the text. And the text will likely have profited from that break. ↩
  11. Some people, especially those who tend toward hyper-focus, feel they need to realize a project in one go. And intense hyper-focus can indeed be productive. But for projects that take more than a few days, breaks are usually unavoidable. It can help to stop thinking of the project as one uninterrupted act and instead as the expression of a more enduring commitment — much like a relationship or a longer course of training. Seen this way, the research, implementation, and revision the project requires can be distributed across longer time frames without losing its coherence. ↩
  12. For complex projects with group work, in-depth project management may be needed (e.g., Gantt charts, deliverables, responsibilities, etc.). For most one-person creative projects, however, a lighter approach avoids unnecessary overhead. The focus must be on doing, not managing. ↩
  13. Essentially the concept of wayfinding on a project level, with the project as the reachable version of an aspiration and the milestones as the waypoints. ↩
  14. mise en place = putting in place, i.e. lining up everything you need in its place — allows you to focus on what matters, see also Carroll (2018). ↩
  15. Planning fallacy is a common problem in project planning. People usually underestimate the countless frictions a project entails — things that can go wrong or cause delays (Dörner, 2015). What often helps is to remember the last similar project and compare the planned time with the actual time it took. On the positive side, without some overestimation of one’s abilities, people would not do some things at all. ↩
  16. According to legend, Alexander solved the famous Gordian knot not by untangling it but by cutting it, thereby demonstrating a low tolerance for problems that resist resolution indefinitely. ↩
  17. In extreme cases, a longer break or even a change of jobs may be required, e.g., when deeply misaligned with the work or the workplace. ↩
  18. Like the old saying: «Meditate daily for 15 minutes, unless you don’t have time for it. Then meditate for 30 minutes.» ↩
  19. This one-page article by Schwartz (2008) explains beautifully that feeling stupid is both normal and important when you are being creative in science. ↩
  20. See Alley (1996). ↩
  21. Lamott (1994). ↩
  22. That feeling of being a fraud can stem from a mismatch between one’s preferred ideation modes and what the domain or field expects. In other cases, it can reflect a real mismatch between role demands and current capabilities, especially when admission or selection was shaped by criteria unrelated to merit (see Cultural Environment). However, in many cases the feeling is not warranted, and an honest exchange with others on the same level can help dispel it (e.g., other students, young artists, or PhD students). ↩

Supplemental Materials

 

 

OC3 Navi