How I Wrote Why Projects Fail book and What I Learned
People love success stories-the shinier, the better. Yet the title of my book is a question most folks avoid asking out loud: Why projects fail? Not “pivot,” not “learnings,” not “unexpected outcomes.” Fail. There’s stigma in the word. Careers wince. Sponsors clutch pearls. And because nobody wants to stand near the F‑word, I set out to walk straight into it.
I wrote Why Projects Fail book (Amazon) because I couldn’t find a clear, evidence‑based answer to the question in the title-at least not one that pulled together data, case studies, and practical fixes in one place. Also, I’m a project management professional who likes puzzles, spreadsheets, and a good post‑mortem.
Below is the behind‑the‑scenes process I followed-wars, wins, and what I’d do differently if I had a time machine and a stronger coffee machine.
Why Bother?
Three reasons:
Intellectual curiosity. I found the topic endlessly fascinating and under‑served. We celebrate moonshots; we whisper about misfires. I wanted to turn up the volume on the whispers.
Professional growth. I knew the research journey would sharpen my PM craft, help my consulting practice, and, yes, give me better war stories to share.
I like writing. Some people knit. I outline 🙂
And because the premise needed to resonate with readers, I anchored the book in data and real examples rather than “because I said so.” That principle guided every decision from here on.
Step 1: Brainstorming
I began by dumping high‑level ideas into a mind map-causes, symptoms, failure modes, industries, and questions I wanted answered. Mind maps are terrific for corralling chaos: you start with a hairball and end up with a topology. I used simple mind‑mapping software (think XMind or FreeMind) and kept it scrappy. The goal wasn’t elegance; it was coverage. If a thought popped up in the shower, it went on the map. If it popped up during a shower, it went on a Post‑it first, because laptops and water don’t mix (trust me; that’s a failure mode).
Tip: If you try this, give yourself permission to be messy. Brains do their best work before the grammar police arrive.
Step 2: Outlining
Once the mind map stabilized, I switched to an outlining tool (any outliner or even a spreadsheet works). The outline became my blueprint: chapters, subchapters, arguments, and the specific issues I wanted to probe-scope creep, unrealistic baselines, stakeholder misalignment, incentives, governance, estimation errors, you name it. I also sketched which case studies would carry each chapter (e.g., a famous IT rollout for risk, a public‑sector debacle for governance).
Outlining changed the project from “book‑shaped cloud” to “book.” It also made dependencies obvious. If Chapter 7 relied on stats I hadn’t collected, I could plan that research deliberately instead of hoping to trip over it later.
Step 3: Researching
This was the era before AI copilots fetched quotes while you sipped espresso. So I did it the old‑fashioned way:
Wide net: academic papers, industry white papers, credible journalism, and well‑sourced blogs.
Evidence first: I prioritized data and studies over hot takes. The world had enough opinion pieces; it needed synthesis.
Folders by chapter: Every relevant item landed in a folder that matched my outline. If an article touched multiple chapters, it got clones or cross‑links.
Quote discipline: If I couldn’t footnote it, it didn’t make the cut. No hand‑wavy “everyone knows” claims.
Research took as long as writing-maybe longer. I learned two things: (1) the internet is a labyrinth where Minotaurs are replaced by paywalls; (2) a good bibliography is a gift to your future self.
Step 4: The First Draft
I wrote the first draft in a dead‑simple text editor. No grammar checkers, no style nags, no “it looks like you’re writing a sentence-would you like help with that?” mascots. A few hours every day for a few months. Chapter by chapter, with frequent boomerangs to earlier sections when a new finding changed the narrative arc.
My rule: don’t polish confetti. Finish the argument; fix the commas later. It’s amazing how many writing problems are really outline problems in disguise. When a paragraph fought me, I asked: “Is this in the right place? Or am I sneaking in a second idea that deserves its own section?”
Small rituals helped: same mug, same playlist, same “don’t even think about email” sticky note on the screen. Consistency strips out decision fatigue so your brain can do its job-turning research into prose readers won’t hate.
Step 5: Design & Layout
A lucky break: I found a designer willing to collaborate for symbolic compensation in exchange for testimonial and portfolio rights. We went back and forth on:
Typography & hierarchy: Because hierarchy isn’t just for org charts. Good headings make a book navigable.
Charts & diagrams: Visuals that earn their keep-not clipart that’s there to meet a quota.
Layout constraints: Page count, white space, and readability. (A dense page is a failed project in miniature.)
Those visuals did more than decorate; they clarified. Readers later called the presentation “professionally‑presented” and “high‑quality,” which, for a PM book, is as close to “page‑turner” as we get.
Step 6: Editing & Proofreading
Another stroke of luck: a generous editor agreed to help pro bono. We did multiple passes:
Substance edit: Do the claims follow from the evidence? Are we over‑generalizing from a single fiasco? Where are the counter‑examples?
Line edit: Trim flab, kill clichés, stitch transitions.
Fact check: Dates, figures, names, sources. I’d rather find the mistake in Track Changes than on X (Twitter).
I also shared the draft with colleagues and a few brave friends who promised honesty, not flattery. (If your beta readers only say “looks great,” you don’t have beta readers-you have bystanders.) Their comments tightened arguments and flagged places where my “obvious” assumptions were obvious only to me.
Step 7: Final Draft & Publishing
Every book reaches a moment when perfectionism becomes procrastination. That’s when you ship.
I chose Kindle Direct Publishing for speed and control. The workflow was straightforward: final manuscript, cover specs, interior files, metadata, categories, and pricing. I opted not to chase a traditional publisher. Fewer gatekeepers, fewer delays, fewer headaches-more time to talk to actual readers. And talking to readers is where the whole cycle pays off.
Was It Worth It?
Financially? No. If my hours had billable rates, the royalties would look like the world’s most modest change request.
Morally and professionally? Absolutely yes.
I loved the process-researching, writing, testing arguments, collaborating with a designer and editor.
I learned a ton. The next time someone says “We’ll make it up in testing,” I have a chapter and three case studies ready to go.
It opened doors: keynotes, workshops, client work, and more nuanced conversations with teams stuck in the swamp between “kickoff” and “uh‑oh.”
Lessons I’d Pass to Any Aspiring Nonfiction Author
Start with the question you can’t stop asking. If you’re bored, your reader will be comatose.
Outline until the structure clicks. A solid outline is a schedule baseline for your book; change control begins there.
Collect evidence, not anecdotes. Your job is to synthesize, not sermonize. (If you can’t footnote it, reconsider it.)
Draft ugly, but draft daily. Momentum compounds; so does avoidance.
Design is content. Diagrams and typography are arguments in visual form. Invest accordingly.
Find a ruthless editor. “Ruthless” is love in editorial clothing.
Ship before you’re ready. Because you’ll never feel ready, and iteration beats imaginary perfection.
Expect a non‑linear ROI. Money might be modest; impact rarely is.
Keep your receipts (sources). Your future interviews, blog posts, and skeptics will thank you.
Stay curious after launch. The conversation with readers is part of the book. Treat feedback as your post‑implementation review.
A Few Behind‑the‑Scenes Nuggets
Folder discipline saved me. Each chapter had a dossier: sources, quotes, figures, and case notes. When it was time to build charts, the raw material was ready.
Case studies are bridges. They carry readers from abstract principles to “Oh, that’s exactly what happened on my last project.”
Humor helps. There’s only so much schedule variance one can take without a quip. I tried to sprinkle in wry observations without trivializing the stakes. (“Scope creep: the only creep you’ll miss when it’s gone.”)
Simple tools win. The fancier the writing setup, the more time I spend tuning the setup. A plain editor did more for my word count than any AI‑assisted fountain pen.
Closing the Loop
Writing Why Projects Fail book was, ironically, a project at constant risk of failure. The scope was ambitious, the timeline optimistic, the temptation to keep researching infinite. What kept it on track was the same thing that keeps real‑world projects on track: clarity of purpose, honest constraints, and relentless iteration.
If you’re thinking about writing your own book consider this your kickoff meeting. Build a messy mind map. Hammer out a sturdy outline. Gather evidence like a detective. Draft without mercy. Edit with even less. And then, when it’s good, ship it.
P.S. If you’ve read the book and left a review: thank you. Reviews are how ideas travel. If not, now you know the story of how it came to be-and why I still think asking “why projects fail” is one of the most productive questions in our field.