Projects considered harmful - Part 1

The problem with broken feedback loops

Uwe Friedrichsen

10 minute read

Boats lying on harbor ground at low tide

Projects considered harmful - Part 1

What is a project?

Lots of fancy definitions of the term “project” exist but in its core, it boils down to this:

A project is a temporary work structure set up to accomplish a particular task.

We take people from their regular organizational structures, group them together in a project team, give them a task and usually also a project organizational and process structure. Besides the deliverable, the task usually also contains a set of constraints, most commonly time and budget constraints.

So far, so good.

Why do I consider projects harmful?

Okay, let me be a bit more precise: I consider the practice of developing software as projects harmful. I talk about the software development projects that are still the norm in enterprise software development. Therefore, let me rephrase the question:

Why do I consider software development projects harmful?

I consider them harmful for a number of reasons. The most important ones are:

  • Due to broken feedback loops, wrong incentives are strengthened. As a consequence, the viability of the related IT system landscape is compromised.
  • Due to the project blinders effect, local optimizations are enforced, leading to a complexity explosion of the related IT system landscape.
  • Software engineers, doing the actual work are tossed around from project to project which is problematic in terms of individual motivation and performance as well as in terms of team dynamics – both leading to suboptimal results, compromising the quality of the related IT system landscape.
  • If everything needs to be a project, if nothing can be accomplished without setting up a project, the regular organizational structure is deeply broken. Instead of setting up everything as a project, the regular organizational structure should be fixed.

There are more reasons, but these are the most important ones for me. Let us go through them one by one. In this post, we will discuss the first reason. In the second post (link will follow), we will discuss the other three reasons and summarize our findings.

Broken feedback loops

The probably biggest problem of projects is that they break required feedback loops, reinforce the wrong incentives and as a consequence purposefully impair the dependability of the IT system landscape they contribute to.

Software solutions tend to run a long time. They interact a lot with other software solutions. They must be changed throughout their lifecycle to preserve their value. Thought and work is required to make software dependable, a property expected and needed at runtime. If the software is not dependable, it does not create the value it is intended to create because it does not work as it is intended to work. Software also has several other unique properties that are often misunderstood and need to be considered if software needs to be dependable.

It is all known for decades. However, software development projects ignore all of it.

A project manager 1 is incentivised for accomplishing the project objectives, i.e., completing the task – in software development projects typically a software deliverable of a given scope – in time and budget. While this may be reasonable for a project in general, it surely is not for a software development. The problem are the project constraints that apply. The goal is to have some software of a given scope delivered until a given date, costing a given budget at max.

Accomplishing any of the aforementioned things that are relevant for software running in production over a long period of time, especially dependability, is not part of the project goals and constraints.

You might say: But these are quality attributes and quality is part of the things a project manager cares about. Well, not really. The usual triplet of a project manager’s reality consists of scope, time and budget.

Triangle with the corners “time”, “scope” and “budget” and the hint “Pick two, compromise the third”.

This is the “CAP theorem for project managers”: Choose two out of the three but be aware you always will compromise the third one. So, the project manager’s primary goal is to juggle time, scope and budget in a way it pleases most of the stakeholders (it is almost impossible to satisfy all stakeholders). Quality is not part of the game.

But quality is part of the deliverable, i.e., of the scope, you might say. In theory, you are right. The problem is that in practice, quality tends to be implied instead of specified. This means, quality usually is not in the people’s minds while they define the project scope. It is just implied which in practice means that perfect (or at least sufficient) quality is assumed without reserving an explicit budget to implement it.

Personally, I prefer a slightly different representation of the project manager’s triangle that visualizes clearly what tends to happen. In this triangle, quality replaces budget as an axis and budget becomes the triangle’s perimeter.

Triangle spanning along the axes “time”, “scope” and “quality” with “budget” defining the perimeter of the triangle.

In this representation, the length of the perimeter equals the budget available. The more budget is available, the bigger the triangle can be, the higher quality, the faster delivery, the more scope is possible. 2

Two triangles spanning along the axes “time”, “scope” and “quality” with “budget” defining the perimeter of the triangle. One triangle is bigger than the other, i.e., reaches better targets at the three axes because the budget is higher, i.e., it has a bigger perimeter.

So far, so good. This means, in theory we only need to define the required scope, delivery time and quality, then calculate the required budget to meet all three needs and everything is fine.

In practice, however, things tend to work a bit differently:

  1. The delivery date usually is fixed before anything else is defined.
  2. Then either the budget or the scope will be defined (depending on the project planning and approval process of the company).
  3. Finally, the missing part, i.e., scope or budget, is added.

As we live in a capitalistic world, projects try to max out the scope while minimizing the budget at the same time. Usually, this scope-budget optimization process is pushed until it is only possible to accomplish the project under perfect conditions. “Just before breaking down” is the ideal usage of resources from a capitalistic perspective. 3

This means, time, scope and budget are fixed before the project starts. This also tends to be true for most enterprise agile settings (see also footnote #1). Additionally, the scope is maxed out while the budget is minimized, i.e., the scope axis is as long as possible while the triangle’s perimeter (the budget) is as small as possible.

The only actual variable left in the project manager’s triangle is quality which has not been explicitly defined upfront but is implied by the decision makers.

The problem with the implied quality is that most of the aforementioned required software quality properties only manifest outside the project context. Usually, they manifest only after the project is successfully delivered according to its time, budget and scope objectives. From a project manager’s (and other project decision makers’) perspective, quality is only relevant insofar as the software must pass QA (which in many companies has become part of development, reinforcing the issue). For everything else, “implied” typically means “ignored”.

This is due to a broken feedback loop. The decision makers do not feel the consequences of their decisions. While software needs to implement the formerly described properties to deliver its expected value (which unfolds at runtime) over its lifetime, the persons calling the shots during the implementation of the software are incentivized for ignoring the required properties. They are rewarded only for delivering the required scope in time and budget which inevitably leads to the following:

Triangle spanning along the axes “time”, “scope” and “quality” with “budget” defining the perimeter of the triangle. The triangle does not reach the required dependability at the quality axis due to a fixation and maximization of the other project targets.

The project manager will compromise quality to meet the predefined time, scope and budget targets because this is the only way to deliver a successful project based on the definition of project success. 4

Over time, this broken feedback loop will continuously deteriorate the dependability of the IT system landscape. The persons being responsible for the problems are not made responsible because they did everything right – according to the definition of a successful software development project.

Summary

In this post, we discussed how the broken feedback loops that software development projects create, lead to a continuously deteriorating IT system landscape, resulting in an ever-shrinking dependability – which is probably the by far most important runtime property of software.

In the next post (link will follow), we will discuss the other three reasons why I consider projects harmful and summarize our findings. Stay tuned … ;)

  1. Agile settings often do not staff the explicit role of a project manager. However, the incentive system remains the same. E.g., take SAFe. A PI (planning interval) typically defines sort of a short-term project, i.e., a task with a defined scope as well as time and budget constraints. Even if in theory a PI could be treated differently, in practice it is not. The role of a traditional project manager, enforcing the PI goals and constraints is split up between the business owners and the product managers in SAFe. Similar observation can be made for other types of agile approaches in most enterprise software development contexts: The responsibilities are distributed differently but the core incentive schema remained the same. Therefore, to keep things simple I refer to the role of a project manager because this makes the mechanisms of action easier to grasp. ↩︎

  2. Some people claim it does not cost additional money to build quality in, that it actually would cost less to build quality in from the beginning. While I basically agree with those people when looking at the bigger picture, I come to a different conclusion when limiting the view to an individual project: Building quality in costs less money in the long run. However, the attention span of a project ends at the project end date. This means the savings of quality built in are outside the scope of a project. Future projects may become less expensive but if I only look at the current project, it becomes more expensive because it costs some money to build quality in. You cannot build quality in if you try to shed every single cent from the implementation efforts to get another feature squeezed into the project without increasing the budget. It is as everywhere in life: Quality costs some money in the first place. Usually, you are much better off making the investment into quality in the first place than struggling with the defects all the time later. However, the artificially constrained foresight of a project ending at the project end date creates a broken feedback loop, neglecting project effects that become effective after the project’s end date. This leads to nonsensical decisions if regarding things from an overarching perspective. ↩︎

  3. While the capitalistic mindset, always pushing to max out what you can get for your money, has its drawbacks, other mindsets do not necessarily lead to better results. Consider, e.g., government-owned institutions that are led with a highly bureaucratic mindset instead of a capitalistic mindset. Software development projects do not tend to work any better in such an environment and similar problems will surface. The causes for the problems are different but the problems persist. However, most companies live in a capitalistic environment and thus, here I examine the effect patterns resulting from a capitalistic mindset. ↩︎

  4. Of course, nobody would admit to willingly compromise quality to achieve the other goals. All decision makers will insist they care about quality very much. However, the practice of fixing time, scope and budget proofs those claims a lie (or “wishful thinking” if you prefer a more euphemistic description). Sorry for being that harsh but this is what it is no matter if intended or not. If I fix time, scope and budget without crosschecking first what it means for quality (or even worse, expecting perfect quality without allocating any time or budget for it), all claims of caring about quality are just a deceit at best. ↩︎