The “Projects vs. Products” Debate—And Why It’s (Mostly) Silly

More precisely, there is a critically important debate to be had, but the way in which supposedly opposing sides have framed it is (mostly) silly.

For the uninitiated, there is a debate that’s been raging for some years now about whether it’s better to manage project portfolios as a collection of “temporary endeavors” or as “continuous value delivery” engines. Especially in the IT world, where custom increments of newly deployed software can be quite granular, the notion of continuous value delivery (CVD) seems increasingly relevant. The Lean and Agile/Scrum communities have fully embraced this notion, to the point of de-emphasizing the temporary-endeavor (project) aspects almost entirely, in favor of the CVD (product) aspects. Scrum even goes so far as to eliminate the role of “project manager” in projects altogether, in favor of just three roles: Product Owner, Scrum Master, and Development (Product Delivery) Team.

Our perspective is that there is actually a good bit more common ground here than might be apparent at first glance, and that the issue is one of poor definitions. Let’s start with the Project Management Institute (PMI) definition of project:

“A temporary endeavor undertaken to create a unique product, service or result.”

To illuminate the strengths and weaknesses of this definition, let’s apply it to how cobblers went about their craft a couple centuries ago. Each customer would approach the cobbler with a custom set of requirements and specific budgetary constraints, and negotiate a committed schedule for delivery at a pre-arranged price. The best cobblers would employ as much repeatability (via standard tools, templates, and techniques) as possible, in order to complete each temporary endeavor, meeting each customer’s requirements as quickly and cost-effectively as possible in the delivery of a unique product. So far, this seems to square pretty well with PMI’s definition, so producing a pair of shoes in this manner can reasonably be considered a project.

But fast forward to how shoes are typically made today, and the shortcomings of this definition immediately become obvious. For the most part, shoe factories have replaced individual artisans, turning out a much higher volume of (somewhat) unique products on much faster schedules, and for much lower cost. Can we still consider the production process of each pair of shoes a “temporary endeavor?” Is each pair of shoes still truly “unique?” One could argue that the answer is still “yes,” perhaps, but most of us would more readily characterize this process as an “operation” more so than a “project.” From a customer’s point of view, however, how we characterize the process—and the value it delivers—is mostly irrelevant.

Throughput and Reliability

What this example highlights is that, as we increase the volume of completed projects—or perhaps more accurately, “boost the throughput of value-delivery increments”—while also improving our ability to deliver them more predictably and reliably, traditional definitions of project management no longer seem to hold up very well, which is the real source of the project-vs-product debate. While we can argue over where the dividing line is between “projects” and “operations,” the more important takeaway from the cobbler/shoe-factory example is what changed from a value-delivery perspective. All that changed is how effective the standard tools, templates, and techniques became—in short, the process improved.

So, if we improve the definition of “project” to account for this, then perhaps we’ll see how silly the “projects vs. products” debate really is. Here’s our working definition:

“An investment in time and resources undertaken to generate maximal positive impact.”

Projects as Investments

So, whether the investment in time and resources is large or small, there is still an investment aspect that’s foundational. And even if that investment is super-quick or very low-cost, there is nonetheless an investment that must be undertaken before value to a customer can be delivered. Further, even if that customer is perfectly fine paying upfront for a product to be delivered later, all that’s shifted is who is carrying the investment cost, not the fact that an investment is still being made.

As for the “maximal positive impact” part of our definition, one could argue that I as a customer am not really looking to solve world hunger just by buying a pair of shoes; rather, I’m only seeking a specific product that carries a modest fixed benefit to me, no more and no less. But what if I discover that this pair of shoes ends up lasting twice as long as a previous pair that cost the same amount? I’m of course quite pleased. Similarly, what if I learn that the pair of shoes I purchased was made with environmentally sustainable materials, and helped reduce unemployment in a way that workers were able to earn a living wage? We of course welcome any positive impact that may come, with no upward limit. And from a societal perspective, the more shoes that can be produced, at a lower cost per pair, and with higher positive impact, the better.

Given the weaknesses of the “project” side of the debate, the “product” side would seem to be winning, but we believe many of its proponents tend to miss this important “investment” aspect as well. For example, Scrum concludes that fixing budgets and schedules, while allowing scope to flex, will always promote optimal value delivery. This may often be true, especially in custom software development, but certainly not always. As with any investment in time and resources, one must assess the tradeoffs to be made between schedule, cost, and scope in order to pursue optimal value delivery. And this “triple constraint” value optimization, of course, comes from traditional project management. Further, while fixing or “time-boxing” schedules can help promote a stable cadence of regular value delivery, from an investment point of view it would be even better to continue shrinking those schedules as much as possible, just as the shoe factory has done. This is simply because investors are always looking for higher returns, and improving speed/throughput without sacrificing anything else is a highly effective way to boost returns. In other words, today’s software developer resembles a 19th-century craftsperson in many ways, and over time that craftsmanship will be harnessed in a manner that promotes ever-faster value delivery, and as such will begin to more closely resemble a production operation. Indeed, this is already happening, as the “DevOps” movement highlights.

Beyond the constant push for accelerating timelines, examples of other ways to pursue higher returns abound in project space. For instance, the value of delivering twice the scope at three times the cost and perhaps even taking a bit more time might sometimes generate more bang for the buck than a smaller, more incremental project baseline. Both sides of the “project vs. product” debate often miss such value-maximization options, with traditional project-management adherents labeling such scenarios late, over-budget, and possibly suffering from extreme “scope creep,” while CVD devotees similarly perceive a doubling of scope as violating their “minimum viable product” (MVP) mantra.

Arriving at a Common Understanding

As this post hopefully makes clear, there is enormous value in traditional project-management thinking, especially as relates to optimizing the triple constraint to maximize the net-present value of any project investment. Similarly, the more we can shrink the amount of time or resources that must be invested in order to deliver a product or other valuable result—as advocates of continuous value delivery regularly remind us—the higher returns we will generate from those investments.

From a methodology perspective, what might this mean? Is there some universally applicable “north star” approach that might be grounded in common understanding? We certainly think so, but such an approach is not some hybrid or “bimodal” compromise that merely tries to meet in the middle of the project-vs-product debate. Rather, we believe that the following techniques, practices, and mindset characteristics provide a common foundation for consistently high-performing project/product-centric portfolios:

1. A stable system, backed by a stable resource pool. The overall project portfolio—whether more closely resembling a shoe factory or a cobblers’ guild—cannot deliver ever-higher returns on investments if the process or its underlying resource pool is unstable. This doesn’t always mean that a specific project/product team must remain intact, but it does mean that there is often a cost to making team changes that must be outweighed by the benefits to doing so, and that the overall system for investing time and resources must be reliable while delivering consistently high value over time.

2. The ability to optimize system capacity against demand. Even with a highly stable environment, there is nearly always a tendency to overload our resource pools with more work than is optimal for maximizing ROI (which is often hard to measure), in the name of high resource utilization (which is often easy to measure). In practice, and especially with systems like project portfolios that carry a lot of variability, this means identifying the single biggest constraint to overall throughput, and setting the cadence for execution according to however much that constraint can handle.

3. The ability to pursue ever-higher throughput. Even if you’ve already optimized system capacity against demand, a high-performing investment portfolio will always be in pursuit of getting more and more bang for the buck—in other words, seeking ever-higher capacity to deliver ever-more value per dollar invested. So, it’s necessary to understand current speed at both the project and task levels, what impediments exist that prevent faster speeds, and how to further boost throughput at the constraint. It’s also often helpful to have a sense of what the resource-loaded and leveled critical path is for each project/product investment period, even if based on somewhat fuzzy estimates, in order to promote brainstorming on feasible options to accelerate schedules and reduce that investment period.

4. The ability to optimize the triple constraint. No matter what side of the project-vs-product debate you think you’ve been on, the reality is that very few practitioners on either side even bother trying to engineer maximum bang for the buck by examining tradeoffs among cost, schedule, and scope. Traditional PM practice typically views the triple constraint as something handed down from on high and thus sacrosanct and fixed, whereas emerging practice typically tries to fix schedule and budget while allowing scope to flex (as long as it flexes above the MVP, and not below). However, common sense tells us that we should never deliberately allocate our scarce investment resources in any way other than to generate the highest returns (or maximal positive impact), so any approach that arbitrarily fixes any part of the triple constraint will immediately blind us from potentially higher-value options. Similarly, ranking some individual tasks or lower-level product features (scope) as having inherently higher priority than others—without considering the time and cost to deliver that scope—will also obscure potentially higher-value options. Techniques that employ concepts such as “Weighted Shortest Job First (WSJF)” represent a big step in the right direction, but even these tend to fall well short of true triple-constraint optimization, often failing to consider scope/schedule/cost tradeoff options in favor of a single, fixed “index” metric for a given low-level scope element.

While the four foundational elements described above are surely not the only components of a sound, universal approach, they do resolve the project-vs-product debate. Or perhaps more accurately, they make clear that we’ve been having the wrong debate all along—the issue isn’t really whether to think in either “project” or “product” terms, but that a more complete understanding of projects as investments is required in order to promote consistent, more universally applicable thinking and practice as we pursue ever-higher value delivery.