Project Management: Answers

"...develops C++ software and VHDL programmable logic. Creates schematics and layouts and then commissions the hardware itself. Additionally performs EMC and CE certification and handles functional safety and IoT security certification..." This is the not atypical job description for a developer or the self-description of one-man development vendors.

Is that even possible? Sure, there was a time when it was possible in a similar way. But: that was in the last millenium: 8-bit processors, no EMC regulations worthy of the name, 1K EPROM, 256 byte RAM, the language was called assembler, the development environment was called "monitor"... We believe that this time is definitely over!

But we still see today that one or two people alone take on all these tasks. And unfortunately, we see examples again and again where the project ends in disaster: A control system was created that actually worked. And then shortly before the start of production, it failed the EMC tests because layout and EMC basics were not observed. During the production ramp-up, it became apparent that the soldering yield was subterranean because footprints were faulty. The first prototype at the customer's site crashed, and no one knew why (the first parameter the customer changed had no error handling, as did all the others...). The safety audit required a complete redesign. And so on...

Why is it like this today? Why did this work in the past? There are three reasons:

• Increased complexity: In embedded electronics and software, systems are in use today that would have passed for servers a few years ago. Their inherent complexity ensures that only specialists who work well together can efficiently carry out such developments.
• Time-to-market: How fast did new products have to be on the market? There were projects that took ten years. Would that be accepted today? The components would already be obsolete when production starts....
• Non-functional requirements: Most product specifications think in terms of functional requirements, in the straightforward case. That was enough with the 8-bit microcontroller, everyone was happy if you were able to squeeze the function into the available memory. Thirty years later, the functional requirements of a system are fulfilled within 20% of the development time. Then come the non-functional requirements: certification for CE, EMC, operational safety, functional safety. Most devices have graphical interfaces with touch operation, resulting in demands for usability and multilingualism. And Industry 4.0 also demands IoT functions, which immediately entail cyber security...

Giving all the work for electronics and software development to only one generalist is probably one of the most momentous decisions for project success. And unfortunately the one that puts embedded developers in a bad light: "It always takes much longer and doesn't work anyway".

What does that Mean?

For us, embedded development is teamwork. No one can do everything, put together a team for the project in which all embedded disciplines are represented by a real specialist.

Isn't it a waste to create more or less detailed requirements for a product or even more for a software? Wouldn't it be better to just start with the development to bring the product to the market as fast as possible?

Even though in times of "agile" this is not necessarily popular, according to our experience, a clear goal helps to speed up development. This is because, especially in embedded systems, subsequent changes and the correction of false assumptions can be very costly, more costly than a good specification.

And there is even evidence supporting this!

The value of good requirements becomes also apparent when it comes to estimating and planning a new development, when the profitability of the product is to be assessed. At the latest during the further development of the product, a clear specification is then the solid basis for the discussions about new features or features to be omitted.

The alternative is specification on demand, sometimes " masquerading " as agile development. These projects are often "open ended" and thus no estimate of development costs is possible for a return on investment consideration.

What does that Mean?

We think creating specifications and requirements makes sense and is worth the effort. Invest in your requirements. And if you work with external parties, keep all rights to the asset which the specifications represent!

The provider of the software told us that we will develop faster by a factor. The new language promises an increase in productivity...

Do these miracle cures, these "silver bullets" exist? Unfortunately, after 34 years, the answer is still: "There Is Still No Silver Bullet", an article which refers to Brooks from 1987... Software projects can still turn into werewolves without warning, devouring resources, deadlines, money and careers.

Tools, pragmatically applied and understood, bring progress in the quality of development and have the potential to reduce effort. Except that these tools do not solve all problems in one fell swoop, they can also create new problems. Among other things, because they must first be trained, understood and properly applied.

What does that mean?

Understand us correctly, we also use many software tools and the latest languages. But we believe in using only what makes sense for the project and the product, in pragmatically choosing what brings real benefits from the large range on offer.

The Agile consultant said that everything is much easier and all problems disappear. If we follow his method exactly! Is that really the case?

The agile processes and working methods of generating specifications during the project were developed for a type of (IT) problems where they have their justification. It is often about adapting solutions to customer requirements, where both the basic platform and the basic function (web presence, web store...) are already known.

In embedded product development the resources (computing power, power consumption...) are always limited. Exactly how many are available is determined at the beginning of the project when designing the electronics. When the specifications change and more are needed, the increase of resources is usually a very expensive exercise.

So generating specifications during the project is not the cheapest or fastest option. For critical systems, it is even blocked by the standards. And here, as with the tools: "There Is Still No Silver Bullet"!

What does that Mean?

It does not mean that "agile" processes have no justification. We too do iterative delivery and integration, automated testing etc., even on critical projects, for others full agile execution, if desired.

Try the methods that are the best solution for your problem. Have the courage to use only parts of them and adapt your approach if necessary. And expect no quantum leaps, especially if they were promised by quasi-religious zealots.

One argument for having all developers on site and/or working with freelancers is that then the work does not have to be specified. This is seen as the opposite of development as a project at an engineering firm: "There you have to specify everything."

Is that really the case? We believe that the constant and unstructured definition of work during the development causes a greater effort for the team. Only, in our eyes, this has the dubious advantage that it simply disappears in the overall project effort, it is scattered throughout the project. The only, in our eyes dubious, advantage of this is that the effort simply disappears in the overall project effort, it is scattered throughout the project.

What does that Mean?

On the one hand, it means that a project becomes more efficient if the whole team has clear goals from the beginning, e.g. a specification. On the other hand, if this is not possible, an iterative, "agile" project execution allows to keep the specification effort low at the start.

If you outsource a project, then you are off the hook. Or maybe not completely?

Because there are always questions and decisions to be made about the goals and requirements of the project. Typical management tasks, in other words.

What does that Mean?

First of all, there must be enough time available for the management of the external project and also the corresponding professional skills.

Then the people who lead the external project should also be able to take back this professionalism. Because too much technical involvement, micromanagement leads to expensive additional loops. For example, if personal technical preferences are placed above project goals: "This software library is the best", "Only processors from this manufacturer are good". Especially if these passions are expressed only after some time has been spent developing with the unloved component.

And last but not least, the person managing the external project should also have the budget responsibility for the project. Otherwise, it's easy to ask for things that explode the costs, but for which someone else then has to take the rap....

Services for development and consulting should be tailored to exactly solve your problem, to exactly achieve your goals. But which partner will do it best? The decision is difficult...

Is it possible to make the decision for a partner with a spreadsheet, e.g. a utility analysis? This should make incomparable things comparable. What about the weightings? Are they really objective? Are the goals of the project really evaluated (also long-term: TCO (Total Cost of Ownership))?

Or is it the case that costs dominate the evaluation as the only exactly comparable, short-term criterion? We are convinced that it is not possible to transform the decision in such a way into a pure choice (a decision is when an uncertainty remains; when the decision can be fully based on clear facts, it is a choice).

For tailor-made solutions, the most important point is a discussion of the goals and solution approaches also with the top decision makers.

For tailor-made solutions we find the discussion of the goals and solution approaches with all stakeholders the most important point, especially with the highest deciders. Otherwise, the overall cheapest or highest value solution may be missed, or the partner who can deliver it. The optimum solution may disappear into the depths of a spreadsheet...

What does that Mean?

If you as management, as the top decision maker do not invest the time to align your goals in a discussion with your potential partners, then you may miss the best solution. Because not everything can be written down, a specification, an RFQ, an outsourcing checklist is never complete. And maybe one potential partner will ask you the important questions that you would need to discuss with the others as well?