Are Projects Still Needed or an Old-Fashioned Relic of Yesterday?
Part 1: Why Hardware Development Needs Projects, But Still Must Change
A colleague calls me and says:
“Uwe, I have a big problem, but also already have a solution!
Our product development isn’t fast enough. There are new competitors bringing better products to market much faster than we can manage. We urgently need to change something, or we’ll be pushed out of the market!
The solution is a new development methodology. It’s called SAFe and is an agile approach that everyone is using now.
We don’t need project organizations anymore, people organize their work themselves.
There are also no more project goals and schedules, we now work agile with backlogs and features.
Take a look at this, it’s definitely something for you too.”
Is he right?
Of course I’ll look into it!
That’s just how I am, I don’t believe anything without examining it. I want to understand.
If you’re interested in what assessment I’ve come to, then keep reading. I’ll tell you about it in this and the following articles.
I want to make it understandable and easy to follow, therefore I will examine the individual aspects of hardware, software, and mechatronics development sequentially one after another.
So let’s start today with the development of pure hardware products.
Development of a Product Consisting of Mechanical, Hydraulic, Pneumatic, or Electrical Systems
When I think about this type of product development, the following sentence immediately comes into my mind:
Hardware development is complicated and lengthy, but plannable.
Let’s look at these three characteristics in detail so we can assess whether this is true and what it means for the way work is organized.
Why Is It Complicated and Not Complex?
The behavior of typical hardware disciplines (mechanics, hydraulics, pneumatics, electrical engineering) is predominantly complicated and rarely complex.
Complicated means there are causal cause-and-effect relationships.
If I do this, that happens.
These disciplines are scientifically researched and can be worked on with engineering methods and tools.
However, this is also where a problem with the complicatedness lies.
These cause-and-effect relationships are not known to everyone.
You need subject matter experts who are very well educated and experienced in their respective field, who have completed extensive training and who master the required methods and development tools.
Lets record this insight:
Hardware products are based on disciplines that typically have causal, scientifically researched, and engineering-implementable mechanisms of action. With subject matter expertise and systematic working methods, product requirements can be realized reliably and predictably.
The existence of universal geniuses who know and can do everything are an unrealistic wishful thinking.
There are specialists who master subject areas in depth, and generalists whose expertise lies not in the individual subject areas themselves, but in understanding how they interact and connect. We need both in a development project.
If we want to meet the product requirements for a hardware product, it must be determined by what means and technologies they should be fulfilled.
You can use mechanical structures, then you need people who are familiar with technical mechanics.
You can use hydraulic systems, then you need people who are familiar with hydrostatics and hydrodynamics.
For pneumatic systems you need fluid dynamics.
And then there’s also thermodynamics, electrical engineering, vibration theory, control engineering, materials science, and much more.
Each discipline in itself is already complicated, and the interaction in a product makes it even more complicated!
And that’s exactly where some complexity comes into play after all.
Because everything is so highly complicated, errors and prediction inaccuracies are immanent and unavoidable.
However, you don’t know in advance where and when you’ll be wrong. That’s pure chance!
At this point we no longer have a causal cause-and-effect relationship.
And then there are always circumstances that are causal by nature, but whose laws are either not yet researched, i.e., unknown, or for which there is no method yet with which they can be adressed.
In these cases, there is no alternative but to select solutions based on experience or, in the worst case, to choose randomly. At this point too, it’s unfortunately not predictably certain that you’re always right.
Unfortunately, this happens relatively frequently in practice in hardware development, which is why we also have to deal with substantial amounts of complexity in hardware development.
That’s then my next insight:
Errors, inaccuracies, and educated guesses are random and do not result in consistent results. They cause surprising problems and disruptions in the development process that must be identified and resolved early.
And Why Do Hardware Developments Always Take So Long?
This is partly because many errors and mistakes can only be found out empirically.
There are problems for which there are either no theoretical development methods yet or no practical ones.
If this is the case, physical prototypes are needed to resolve these situations.
Building physical prototypes takes an immense amount of time.
Materials must be procured, tools and fixtures must be built, then the parts must be manufactured and the product assembled and put into operation.
Depending on the type of product, this can (rarely) take days, (often) weeks, but it can also take months before everything is finished and you can work with it.
So I can record the next insight:
In the development of hardware, hardware is needed during development. The creation of which consumes significant time and causes high costs.
But there’s another time consumer in hardware development that you can’t get around.
And that’s the problem that hardware wears out and ages.
The system behavior and product properties of hardware change over time.
This has the consequence that you can’t just look at the new condition.
All states over the entire life time, from new to end of life, must be considered and validated.
This topic is scientifically particularly demanding and is therefore still mostly solved empirically today.
So the investigation takes quite a while. As the systems and parts must have the chance to develop wear behavior.
Even if the product’s lifetime can be condensed into a shortened period with statistics and acceleration, significant time spans still remain.
Formulated again as an insight:
Wear and aging lead to long development and validation times in hardware development
Unfortunately, the last two insights also occur simultaneously.
Imagine that I only find out towards the end of a test series that I was wrong about my assumptions about how the product behaves towards the end of its life.
Then in the worst case, prototypes must be built again and the test repeated.
Except for the Errors, Hardware Development Is Plannable
If I look at the four insights, then I can conclude that except for the errors and inaccuracies, hardware development is fundamentally well plannable.
You know the mechanisms of action in principle and can therefore structure and prepare the approach well and sensibly.
It even has a great advantage to plan, because once I’ve created and executed these plans, I can subject them to a continuous improvement process.
With each further development, the plan then gets better and fewer errors occur.
As they say: Don’t make the same mistake twice!
This reduces complexity with increasing experience and development becomes more efficient and faster.
So Should I Rather Set Up a Development Project or Work Agile?
The major project management organizations (IPMA and PMI) are relatively agreed on the definition of criteria that characterize a project.
A project is a time-limited undertaking of an interdisciplinary project team with defined requirements, clear boundary conditions, and a specified result.
In contrast, agile development is characterized by an iterative approach of self-organized generalist teams with rapid delivery to the end customer and short-cycle improvement of the product based on customer feedback.
If I now put the puzzle together, the following comes out.
Time-limited can be done because it’s well plannable, so this speaks for a project.
Interdisciplinary must be, because high expertise in diverse subject areas is needed, so this also speaks for a project.
Specified result. Customer expectations are relatively stable but must be met safely, also speaks for a project.
Defined requirements and boundary conditions are given, so also this speaks for a project.
Iterative approach helps with errors and inaccuracies to keep development loops short, so this speaks for agile.
Self-organized teams. Since many experts are needed, a very large number of employees are usually involved, so that self-organization is numerically difficult. A dedicated project management resource seems appropriate. This speaks rather against agile.
Rapid delivery to the customer is not feasible due to the long prototype manufacturing and validation times. This is strongly conflicting with agile.
Short-cycle improvement based on customer feedback. Hardware development is expensive and therefore has a long capital return time. If the product is revised too quickly, it doesn’t earn its money back. Not agile!
Since predominantly causal effect relationships exist, the occurrence of problems can be effectively prevented with risk management. Risk management is a project management method.
For pure hardware development, the project approach is well suited because it fulfills the typical requirements and addresses the inherent characteristics effectively.
So, What Exactly Needs to Be New Then?
In classical project management theory, a project is completely described and planned out from beginning to end.
However, the complex matters I explained, completely defy prediction and therefore cause constant plan changes and readjustments to the project.
This creates immense inefficiencies and wastes resources, since the entire planning process—with all its coordination efforts and investigations—has to be repeated multiple times, each time from the current project stage all the way to the project end.
Complex matters can be controlled better and more efficiently with agile project management methods, where planning is done only for the timeframe that can be foreseen and assessed with reasonable accuracy.
Therefore I propose a hybrid approach.
It consists of a high-level project plan that establishes the key long-term milestones that can and must be reliably determined, while the details are planned incrementally as certainty increases.
I call these incremental plans Drum Beats. I’ve already written about this in an article and will go into more detail on it in the future.
This hybrid approach is an essential success factor when it comes to making hardware development faster, cheaper, and more efficient.
In the next article I will look at software development, so please subscribe to my newsletter so you don’t miss it.
If you have any comments or feedback on this topic, please write them in the comments
or send me a direct message.
We can also chat about it.
I'm looking forward to hearing from you!
If you found this article helpful, don’t forget to share it with others who might enjoy it too!
And if my newsletter resonates with you, please consider sharing it with others.