Planning by Doing: A Practical Approach to Software Project Planning

Meet Sarah, a software developer, working on a new e-commerce platform. Her team had spent weeks building a complex checkout system, carefully coding every detail based on initial requirements. Just as they were about to launch, the product manager announced a major change: the checkout process needed to include guest checkout, a feature no one had considered earlier. The change required significant rewrites, throwing their timeline into chaos. When Sarah expressed frustration, she was told,

“It’s part of the iterative process — change is inevitable in Agile.”

As someone who once believed that upfront planning was a waste of time especially for software projects, I understand the skepticism to traditional project planning. Early in a project, you have the least knowledge about what’s truly needed, and any plan created in this stage often feels like a shot in the dark. History is full of Gantt charts that failed to stay on schedule or reflected a reality far remote from what unfolded on the ground. This has been particularly true in software, where rigid, waterfall-style methods of gathering requirements upfront and executing in a straight line have consistently failed. These failures led to the rise of agile and iterative approaches, which promise adaptability and incremental progress.

Yet, despite these innovations, most software projects still fail to meet their goals. They either underdeliver on benefits, run over budget, or, more often than not, frustrate developers and stakeholders alike with constant changes. And what’s the common response? "Change is the only constant. Adapt to change." But let’s pause and think for a moment: Is this how the rest of the world works?

Imagine a skyscraper being built, only to find out halfway through that the architect misaligned the structure. Such a professional would almost certainly lose their job. Yet, in the world of software, these kinds of major missteps are normalized under the banner of iteration and flexibility. We live with them, often at great cost to our teams, timelines, and our sanity.

Are User Needs Really Evolving—or Is It Just Your Understanding?

The need for iterative software development or Agile stems from a widely accepted narrative: user needs are constantly evolving, making any upfront planning obsolete. But we must ask ourselves, is this really true?

Unless you’re in an industry that genuinely changes daily, it’s hard to envision a scenario where user needs themselves are shifting so rapidly. More often, what’s evolving is your understanding of those needs, not the needs themselves—a key distinction. Users may have always wanted a fast checkout process, more intuitive navigation, or better search functionality, but it took time and exploration for you to identify these specific needs.

If user needs were truly evolving at the speed this narrative suggests, you’d essentially be aiming at a moving target—a challenge no iterative process can reasonably solve.

So, what’s the solution? Do we swing back to spending months meticulously planning, risking analysis-paralysis before any meaningful progress is made? Or do we accept that it’s completely normal to discover things as we go, embracing chaos as part of the process?

I believe the answer lies somewhere in the middle, in an approach I call Planning by Doing.

This isn’t about abandoning the iterative mindset that has proven invaluable in modern software development. It’s about recognizing that the best insights often emerge during the process of building, but these insights need a structure—an intentional framework—to thrive.

Take Pixar’s approach to movie development, for instance. Every Pixar film begins with a "storyboarding" phase where ideas are explored with minimal resources. Teams use rough sketches and temporary voiceovers to create an animatic—a low-fidelity version of the movie. This allows them to iterate quickly and identify flaws in the story without the expense of animating fully rendered scenes. Mistakes at this stage are embraced as part of the process, and entire storylines can be discarded or rewritten without significant cost.

Once the story is solidified, however, Pixar moves into a "production" phase, where the stakes—and the commitment—are much higher. With the foundation in place, they invest heavily in animation, voice acting, and rendering, going all-in to bring the vision to life. Changes can still happen, but they’re far less drastic because the groundwork has been meticulously laid. This two-phase approach—lightweight planning followed by full-scale execution—strikes a balance between flexibility and precision, allowing Pixar to take creative risks while ensuring their movies meet their high standards.

This approach is not unique—in fact, it’s common in other fields where balancing creativity and execution is critical. In construction, for instance, projects begin with a conceptual design phase where architects test ideas through models and simulations. Changes are frequent and encouraged at this stage because they are low-cost and improve the final plan. Once the design is finalized, the project transitions into the construction phase, where deviations become rare and costly.

The Problem with Agile Mindset

While Planning by Doing shares some similarities with Agile or Lean mindsets—such as valuing experimentation and learning from feedback—it fundamentally differs in its structure and execution. Lean focuses on eliminating waste and optimizing processes through continuous improvement, often emphasizing incremental changes within a single workflow. In contrast, we recommend a distinct dual-phase execution model that separates exploration from execution.

Dual-Phase Execution:

• Exploration / Tinkering Phase: Engage in low-commitment experimentation, rapid prototyping, and gathering user feedback without significant resource allocation.
• Execution Phase: Commit to a plan and transition validated ideas into scalable, reliable solutions with detailed execution plans and dedicated resources.

This separation allows teams to innovate freely during the tinkering phase while maintaining focus and accountability during the commitment phase, offering a more structured yet adaptable approach compared to traditional Lean practices.

Identifying What to Tinker With

The goal of Planning by Doing is to transform unknown unknowns into known unknowns—shining a light on the aspects of a project you didn’t even realize needed consideration.

To do this effectively, you must identify which areas are ripe for tinkering. Focus on the parts of the project that are least understood, carry the highest risk, or rely heavily on user behavior or market dynamics. These are often foundational decisions, like defining core workflows, exploring technical feasibility, or validating the problem-solution fit with users.

Tinkering is not about addressing every ambiguity but targeting the critical unknowns that could derail the project later if left unexplored. Rapid prototyping, exploratory testing, and minimal viable experiments are tools to reduce uncertainty in these areas, allowing you to transition confidently into the execution phase with a clearer understanding of what needs to be done. By systematically addressing these unknowns, you create a smoother path forward while avoiding the chaos of mid-project surprises.

Why Software Projects Often Rush into Full-Scale Execution

The structure of our industry inherently resists a dual-phase approach like Planning by Doing. Software projects are often front-loaded—teams are hired, deadlines are set, and there’s immense pressure to show immediate progress. This all-in mentality pushes projects straight into execution without allowing space for exploration. After all, what will a fully staffed team do if the initial phase is focused on tinkering and experimentation?

Moreover, software teams are inherently doers—people who thrive on building and delivering. Sitting back to tinker or plan feels counterintuitive, almost like a waste of their time. Even managers, who might recognize the value of well defined plans, feel the pressure of the team waiting for direction and deadlines looming over their heads. The result? Planning is minimized, and teams jump into execution, hoping to course-correct along the way. Unfortunately, this approach often leads to costly mid-project changes and frustration, outcomes that Planning by Doing aims to prevent.

Adopting "Planning By Doing" Approach In Your Projects

The key to adopting Planning by Doing is rethinking how we structure and staff projects. Start by phasing team involvement: bring in a smaller, cross-functional team during the Tinkering Phase—just enough to explore ideas, test assumptions, and identify risks. This minimizes idle time while ensuring critical unknowns are addressed before scaling up. Once the groundwork is laid and decisions are validated, expand the team for the Execution Phase, where delivering on a plan becomes the primary focus.

Additionally, leaders need to normalize experimentation as a core part of delivery. Shift the mindset from “waiting to execute” to “executing to learn.” Teams should see the Tinkering Phase as a chance to build, test, and gather insights—not as a play time.

That’s it for now! I hope in your next project or phase, you take the time to tinker and plan thoughtfully before diving all in. For feedback or to share your insights, feel free to email me at mihirt@rapidquest.in.

Tags: software project planning, agile project management, iterative development process, software development planning, how to plan software projects, agile vs waterfall, project management tips, effective software planning, agile methodology explained, dual-phase execution model, balancing creativity and execution, common agile challenges, improving project timelines, user needs analysis, iterative vs upfront planning, Pixar approach to planning, software project tips, agile planning best practices, software development strategies, how to manage software changes.