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.
#7 -- Team turnover
Every company experiences employee or contractor turnover but excessive turnover of key personnel 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. This can be a distraction that takes others away from development work, with the end result an increase in development costs and delivery timeframe.
#6 -- Go stop go syndromeThere 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, claiming that the project has to get out the door by a certain date. Developers work weekends and put in extra effort. Then, just as quickly as the big push came the project is stopped dead in its tracks. Months later it is once again an emergency. "Hurry we have to ship by X!" And the same thing happens again.
The repeated urgency followed by stopping the project that is later urgently started again has a psychological effect on the development team. The developers come to 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!
MORE FROM DESIGN NEWS: How to Handle Design Disagreements
#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 attitude is that it is impossible to build the perfect system, write 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 once that is achieved. 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 rapidly 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 increase 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. Instead, design occurs on the fly in the programmer's mind. Going slower and doing things right will get to the end solution faster.
MORE FROM DESIGN NEWS: When Good Companies Make Bad Decisions
Go to our sister site, EDN.com to read about the top three silent project killers, then come back to Design News and tell us what we may have missed.