The Six Deadly Sins of Project Management Leadership
Tesla, which is well on its way to becoming the Apple of the automotive market, decided not up upgrade its SAP implementation and instead develop its own software. It has worked out well so far. This approach can bring clear tactical advantages if you can pull it off but rather high strategic costs, which is why moves like this are rare. Be aware that whatever path a firm takes, it will likely talk about the good parts and leave off much of the bad so as not to appear stupid. Having looked at both approaches over the years, the only time I would recommend this path is if purchased software was excessively expensive or if required modifications to that software were extensive. We often take the advantages of packaged software for granted, and that is why the problems with do-it-yourself projects tend to bite us, by surprise, in the butt.
Let me explain.
Packaged Software Pros and Cons
What we take for granted in packaged software is the development, maintenance, testing and refined patching process. Most of this happens out of sight and what we tend to see are the things that cause us problems: the cost of the package, which can be very high for enterprise software, any incompatibilities that have to be addressed, bugs that make it through quality control, and changes in our relationship with the vendor. In short, we take for granted what went into bringing the product to market and see in great detail what annoys us.
So it becomes relatively easy to think we can do it ourselves. We don’t value, because we don’t see, the work that resulted in the product. After just seeing the problems, we start to think that it shouldn’t be that hard to do better. And initially, it may not be.
Do-It-Yourself Software Dev
Basically, to do a major project like this yourself, you have to build your own internal software company. You have to develop the same processes, generally by hiring people from software companies to help you. You are far closer to your own needs, or at least think you are, and can better create a product, or believe you can, that meets those needs. And this is what Tesla appears to have done. Except you aren’t motivated to compare what you did to what you otherwise would have gotten from SAP. You are motivated, given that the costs are far from trivial, to hang up the “Mission Accomplished” sign. But, like with George Bush and Iraq, the hard stuff is yet to come.
You now have to maintain and update this software and you have basically a customer of one. This has often led IT organizations to try to sell their custom package. This approach has rarely been successful, to my knowledge. The reason firms try to sell their solution is that they have to broaden their revenue base; maintaining the staff needed to update the software is very costly. And worse, if you lose those folks, the knowledge needed to maintain the custom software goes out the door with them. This group has to maintain the same connections to hardware vendors that a software company does over time. Often, this effort isn’t resourced until the first catastrophic hardware upgrade.
Executive management, which often looks at benchmarks against other firms, sees that their IT shop is staffed more heavily and moves to reduce that cost, not realizing that this extra staff is required to maintain the custom software. Once the people are gone, the firm is left with an aging system that fewer and fewer IT folks know how to maintain. A future CIO coming in will, at massive cost, move to replace it with something they know.
Finally, if a massive problem with the custom software package arises, there is only one throat to choke: the CIO. This, I think, above all else, is why this kind of undertaking is relatively rare.
NT Custom Example
This lesson was made incredibly clear to me back during an event Microsoft had called Scalability Day. Microsoft had gone to Firestone and custom made a Windows Server NT solution that replaced its packaged mainframe offering. It worked very well, however, the final cost analysis came to over three times the cost of the hardware/software solution that the new solution had replaced, largely because it was custom. A software company spreads this cost across all of its clients. A custom offering carries all of the costs itself, cradle to grave. Custom software can have a lot of advantages but cost should never be one of them. I’m an ex-internal auditor, and I can tell you that, generally, when cost appears to be an advantage in these cases, it means someone cooked the books.
Advantages to doing custom work include control. Massive disadvantages include one I haven’t mentioned yet: IP risk. You aren’t allowed to swipe someone else’s IP to create your solution. If you can’t assure you can retain the staff to maintain the product properly, this is not a path you should undertake. The cost will not only be higher, which is a given regardless, your exposure will be excessive and the end result catastrophic.
Wrapping Up: EMC’s Pivotal Hail Mary
One of the more interesting projects to get the benefit of custom software without the cost is the software partnership between EMC, VMware, and GE, which created the company Pivotal. In effect, GM will be getting custom software, which will have IP protection and be sold to other customers, successfully cutting its cost. It is not yet a success, but on paper it may actually represent the best of both worlds. However, pulling off something like Pivotal is likely beyond the capabilities of most firms. It might point the way to how Tesla could avoid the coming problems it will face by going its own way. We’ll see if Tesla gets the hint. If it doesn’t, I expect it will go back to packaged software, with far less press, within five years.
Just remember: A CEO, particularly an iconic one like Jobs or Musk, even when wrong, is always right.
