Embedded Basics – 7 Silent Project Killers

There are few things more discouraging to an engineer than pouring their heart, sweat and tears into a project only to have it fail.  Failure can and does provide insights and growth experiences to those involved but the loss of time and effort can strike a devastating blow.  There are many reasons that an embedded systems project can fail but there are seven key indicators that a project is dying a slow and silent death.

AdobeStock_61165756 [Converted]

#7 – Team turnover

Every company experiences employee or contractor turn over but excessive turnover of key personal can be a leading indicator that a project is doomed for failure.  There are many reasons why turnover can have a detrimental effect on the project.  First, it has a psychological effect on other team members that can decrease productivity.  Second, the loss of key personal can result in historical and critical information being lost forever which will slow down the development.  Finally, replacing team members requires training and bringing up to speed a new team member which can be a distraction, take others away from development work with the end result being an increase in development costs and delivery timeframe.

#6 – Go stop go syndrome

There is an old saying that children are taught; “Don’t cry wolf.” The saying is a warning to not raise false alarms. This warning is ignored in projects that have a “GO! STOP! GO!” cycle. A manager, client or some other entity pushes his team hard that the project has to get out the door by a certain date. Developers work weekends, put in extra effort and then just as quickly as the big push comes the project is stopped dead in its tracks. Months later it is once again emergency. “Hurry we have to ship by X!”. The same thing happens.
The repeated urgency followed by stopping the project that is then later urgently started again has a psychological effect on the development team. The developers no longer believe that there is any urgency. In fact they start to get the mindset that this project isn’t a serious project and that it will very shortly be stopped again. So why put in any effort at all? Watch out for the project that cries wolf!

#5 – A perfectionist attitude

One of my favorite phrases concerning engineers is “There comes a time in every project when you must shoot the engineers and start production”. Many engineers have a perfectionist attitude. The problem with this is that it is impossible to build the perfect system, the perfect code or launch the product at the perfect time. Perfectionism is always elusive and if perfectionism is part of the culture it is a sign that a product may be re-engineered out of business.
The right mindset isn’t perfectionism but success. What is the minimum success criterion in order to successfully launch the product? Set the criteria for success and launch the product. A boot-loader can later be used to add features and resolve any minor bugs.

#4 – Accelerated timetable

It seems counter-intuitive but to develop an embedded system fast a team actually needs to go slow. Working on an accelerated timetable results in decreased performance due to stress and more importantly a higher likelihood that mistakes will be made. Mistakes will directly influence the number of bugs that then increases test time and rework time. Another issue is that when developers are rushing and trying to meet an accelerated timetable, they cut corners. Code doesn’t get commented. Design documents such as architecture and flowcharts aren’t created but instead design on the fly in the programmers mind. Going slower and doing things right will get to the end solution faster.

#3 – Poorly architected software

Embedded software is the blood of the embedded system. Without it nothing works. Poorly architected software is a sure sign of failure. The architecture of an embedded system needs to have flexibility for growth. It needs to have hooks for testing, debugging and logging. A poorly architected system will lead to a poor implementation and that will result in buggy unmanageable software that is doomed to spend its days being debugged until the final death of the project.

#2 – Putting the cart before the horse

Developing a new product is an exciting endeavor. There is a lot to do and companies are usually in a hurry to get from concept to production. This can be extremely dangerous especially when production decisions start to get ahead of themselves. A great example is when mechanical design or look and feel is being used to drive electrical requirements. Before a working electrical and software prototype is ever proven production tools get kicked off. In these cases it always seems that the circuit board doesn’t checkout, adjustments need to be made and oops, production plastic tools no longer fit the circuit board. The horse of the system needs to be pulling the cart. Projects that rush and try to pull things in parallel to quickly usually end up taking longer and costing more due to revisions.

#1 – Scope creep

Every project has scope creep but the degree of the scope creep can be the determining factor as to whether the project will succeed or fail. One of the most dangerous aspects of scope creep is that it can be insidious. The addition of a simple sensor to the board one day, a few others a few months later seem completely harmless. The biggest problem with scope creep is that the changes are usually subtle. At first glance it’s a few days work. With each addition the complexity of the system rises. Complex systems require more testing and possibly more debugging. The scope creep can change the system to such a degree over time that the software architecture and design becomes obsolete or the incorrect solution! The end result is a project that is far outside its budget, behind its delivery date with little to no end in sight.

Conclusion

There are no guarantees for success when developing a new embedded system. There are many factors that contribute to the success or failure of a project. This article has identified the top seven silent project killers. These are subtle points that can indicate that a project is on a slow and silent death trajectory. What other indicators might be signs that a project may never reach completion? Do any projects you are working on right now exhibit more than 1 of these?

Share >

1 thought on “Embedded Basics – 7 Silent Project Killers

  1. Great article! Applies to ANY engineering project: SW, HW, electrical, mechanical…

    As my late biz partner Bill often said, “We spend the first 90% making things work, and then next 90% making things to not break. As a result, projects often take about 2X the original estimate.”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.