Answers to the Management of Embedded Product and Software Development Projects

Is the Effort for a Specification not a Waste?

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!

Does the Tool make us Much Faster?

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.

Can Agile Methods Save us?

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.

Do Freelancers Save the Specification Effort?

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.

We think that you should try the methods that are the best solution for your problem. That you should have the courage to use only parts of them and adjust your approach if necessary. And do expect no quantum leaps, especially if they are promised by quasi-religious zealots.

How do I Manage External Projects Efficiently and Effectively?

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....

Should I Buy Engineering and Consulting like Screws?

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?

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!