原创 Seven things that can silently kill your project

There are few things more dispiriting 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 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. 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 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, 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!

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

#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 project finally dies.

#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 hurry can be extremely dangerous, especially when production decisions start to get ahead of themselves.

A great example is when the product's mechanical design or look and feel is being used to drive its 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 check out, 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 too 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 other additions s a few months later, these seem completely harmless. But they can be deadly.

The biggest problem with scope creep is that the changes are usually subtle. At first glance a change looks like it’s just a few day's work. But with each addition the system's complexity rises. Complex systems require more testing and possibly more debugging. The scope creep can thus change the system to such a degree over time that the original software architecture and design become obsolete or even the incorrect solution! The end result is a project that is far outside its budget and behind its delivery date, with little to no end in sight.

Conclusion
There are no guarantees for success when developing a new embedded system and there are many factors that contribute its success or failure. These are what I have identified the top seven silent project killers. These are subtle clues that can indicate your project is on a slow and silent death trajectory.

What other indicators do you think might be signs that a project may never reach completion? Do any projects you are working on right now exhibit more than one of these listed here?

Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. He is an avid tweeter, a tip and trick guru, a homebrew connoisseur and a fan of pineapple!