The "project vs. product" problem

2024-09-06

A subset of the Agile community advocates, in their words, a product-oriented approach instead of a project-oriented one, or a product mindset instead of a project mindset in their industry (computer software).

This claim has two fundamental problems that I'm going to explain in this article:

1. The name of their preferred approach is misleading.
2. Their preferred approach is usually inferior to the other.

Problem #1: Terminology

Projects don't replace product-orientation, but they are a structured way of being product-oriented. This is embedded in all project management systems and reflected in different ways, such as PRINCE2's principle called "focus on products".

Normally, each product is born with a project. In the case of important products, they are also retired by a project. Between these two key events, there may be major changes to the product, implemented by projects.

Of course, projects are not enough for generating value. In fact, projects don't create any value other than their direct social and ethical impact, and it's the product of each project that can create the value most people have in mind. Yet, the existence of a product is not enough, and it must be used in operations to generate value.

When operating the product, we encounter small problems or come up with small ideas for improvement. These minor changes can be applied on an ad hoc basis. An ad hoc approach is justified here because the structure of a project is too much overhead for a single minor change, and it may not be feasible to package many minor changes into a project because it may delay the resolution of urgent problems.

People who oppose projects in this context prefer to deliver all changes on an ad hoc basis, replacing the packaged approach of projects with a continuous one. In this sense, they do not prefer products to projects, but they prefer one way of changing the product to another. They prefer continuous, ad hoc changes to packaged, structured changes (projects).

This is the first problem: wrong terminology. Calling their approach "product-oriented" and distinguishing it from the "project-oriented" one creates the illusion that they are getting closer to the core of what creates value, which is not true. If we name their approach correctly, as another way of changing the product, we can better judge which approach is more appropriate for our situation.

You can oppose the "project-oriented" perspective, but calling this opposition the "product-oriented" perspective is wrong. You can claim that you don't agree with the "project mindset", but calling the alternative "product mindset" is misleading.

Problem #2: Suitability

So, which one is more suitable and generates more value, a continuous, ad hoc approach to change, or a packaged, structured one? The anti-project camp claims that the former is always better for software, which is wrong.

Strategy

In general, projects encourage a top-down view, whereas ad hoc changes tend to be bottom-up. This makes projects more proactive and strategic. If the changes are minor and not too many, or if they're really urgent, it's a good idea to implement them on an ad hoc basis. Otherwise, the structure of a project can help us generate more value.

Creativity

The temporary nature of projects makes them more suitable for one-of-a-kind and creative works, whereas the semi-permanent nature of the other approach resembles mass production and encourages optimization and repetition over managing uncertainties.

Inclusion

Projects also provide a mechanism for effectively involving multiple levels of management (because of their top-down approach); for example, people from the portfolio management system can be involved in the high-level aspects of the project. This is invaluable because these people, with their strategic perspective and familiarity with all investments in the organization can help align the product of the project with other products in the organization. This is something that the people working directly with the product may not be able to do because they don't have enough information about the other products and services in the organization.

Boredom

A common problem for organizations that don't package and structure their changes is that they become too reactive and lose their way in a never-ending ocean of small changes coming from left and right; changes that usually pretend to be urgent as well. Many person-years go by, and when you ask yourself what you've achieved, you don't have a good answer; maybe the only answer is that you've survived. Well, you've also made your product a lot more complicated, which will make it harder to add new features to it in the future. That may be why we see these famous companies with armies of developers and yet no real improvement in their products. It's just too reactive.

Some people who have experienced such continuous, ad hoc work gradually start to set short-term goals for themselves with a flexible or fixed deadline and some complementary controls, to make sense of the things around them. It's basically a simple form of becoming project-oriented.

Adaptation

In an ad hoc setup, we deal with details, and we can always change the sequence of work, which may appear more adaptive (Agile) to some. However, true adaptation comes from features that work together and reinforce each other toward a goal, rather than isolated ones. That goal orientation and holistic perspective is what a project structure aims to create. It also gives us a structured way to evaluate the outcome and know which structured packages work and which don't. This large feedback loop helps us define better projects in the future.

Balance

The optimal setup balances the two types of implementing change:

• A risk-taking, growing organization can invest a small portion of its capacity (e.g., 30%) on ad hoc changes and the rest in structured change.
• A conservative, mature, slow organization can do the opposite: a small portion of its capacity (e.g., 30%) on projects and the rest on ad hoc changes.

Diagnosis #1

This type of opposing projects has roots in some elements of Agile history, so let's take a quick look at them.

Full project management

There were several first-generation Agile systems. Most of them, like DSDM and Alistair Cockburn's Crystal, were complete project management systems designed for Agile environments. They offered all the essentials you needed to implement change in a structured way.

No internal project management

The other first-generation Agile system was Kent Beck's eXtreme Programming (XP). It didn't have a project management system per se and was completely focused on the adaptive development of the product. Its implicit idea was that it would run within a project management ecosystem and that the required structure would come from there. This is evident in the interfaces XP defines between the project manager and the team.

Partial project management

Finally, there was Scrum. Some people believe it was originally created as the project management layer for XP. However, it was quickly reframed and adapted to be a standalone system. Scrum does offer project management elements, but a small subset of those elements, unlike DSDM, which offers a complete system.

For example, a common problem in projects is that initiation and sometimes even closure of the project are done by a specialized team other than the project team. This is something project management systems usually try to avoid because what this "specialized" team creates (e.g., the contract) usually turns out to be unrealistic and causes problems for the project team. What we really want is for the project team to initiate and close the project. If necessary, some people from the contract department or something like that can join the team to ensure everything goes well.

Regardless, Scrum omits initiation and closure altogether because it was created in an environment where these things were typically done without the project team (which is always a bad idea). This is an example of one of the essential aspects of project management that isn't included in Scrum.

From partial to sans

Gradually, Scrum became the dominant Agile system, and everyone was either using Scrum or something heavily inspired by it. As a result, Scrum's approach of having a partial project management system spread throughout the Agile community. Of course, if you take away half of something and like the result, you wonder what will happen if you take away the other half! That's practically what happened to this subset of the Agile community: They believe that getting rid of some aspects of project management has helped them, so they should get rid of the rest.

This reasoning is wrong because none of the good things in Agile came from removing project management elements. The good things were all about having structured exploration (adaptation), minimalism, and making human aspects a first-class concern in the system.

Scrum's implicit preference

The Scrum Guide, written by Jeff Sutherland and Ken Schwaber, originally included references to projects, and old books like Ken Schwaber's "Agile Project Management with Scrum" (2004) clearly describe a project-oriented concept. However, the 2013 update of the Scrum Guide removed references to projects, which encouraged an anti-project sentiment like the one discussed in this article. Contrary to that, later on, in the 2020 update of the Scrum Guide, interesting top-down concepts were added that resemble the common dynamics of projects.

Diagnosis #2

Another important element that may encourage some people to oppose projects is that structured changes (projects) make it clear when investments have been lost and expected results have not been achieved. In contrast, continuous ad hoc changes make it harder to see these issues.

People who want to cover up their failures may benefit from avoiding projects.

Diagnosis #3

Another reason some people are against projects is that all the project managers they've had to work with have been horrible at their jobs; so much so that they prefer not to have projects at all, just to make sure they don't have to work with such project managers. While I understand their pain and know how annoying it is, I don't think we should throw the baby out with the bath water.

Conclusion

People who oppose the idea of having projects and prefer to have a continuous flow of work instead of a packaged one should not call their approach "product-oriented" or use phrases such as "product mindset" because those phrases don't match the nature of what they are promoting.

They believe that their approach is the right one and that there shouldn't be any projects in their industry (IT development), which is wrong. We need to have the right balance of continuous, ad hoc changes as well as packaged, structured ones.

— the end —