January 25, 2011, I was driving back to the airport from a meeting with a potential client, my CEO in the passenger seat. “How do you think it went,” he asked. “I think it went okay.” I was kidding myself. We were ambushed. We never should have flown out for the meeting. I had a few follow up conversations after the fact, but I knew I was wasting my time at that point. The problem was, I completely underestimated who the actual decision makers were in the room. I was trying to solve a business problem for the environmental team; yet their own internal IT group wanted to solve the same problem, by building a custom solution. We were essentially invited into the room to help them scope it out.
The Buy vs Build debate has been a heated one in many organizations. I am reminded of a quote from Mark Lutchen, former Global CIO for PriceWaterHouseCoopers. Mark said,
“Everybody knows that the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance.”
Well, if everybody knows it, why is it still happening?
When DIY Doesn’t Happen
There are many reasons. Ego could be one. Perceived competitive advantage by having something nobody else does could be another. What I find, more often than not, is simply underestimating the scope of the project from the onset.
In the absence of a specification, needs analysis, software architecture, data model, development work plan, resource requirements, screen design and so on, building a custom solution looks very attractive. Most software companies invest millions of dollars and 1000s of hours to build their product. Most industrials can’t do the same thing—it’s just not their core business. Why should they when someone else has done it for them?
Here’s the rub: building custom one-off software applications is difficult, expensive and rarely economically feasible given a commercial alternative. Without a detailed engineering specification, I have doubts that any consultant or developer could give an accurate price estimate. With Off The Shelf software, you know the cost right now.
Additionally, you may be compelled to take short cuts, avoid building certain key functionality or configurations because at the time it doesn’t seem important all in an effort to keep costs down. In other words, you probably won’t end up with the application that you want or the one that will generate the highest overall benefit.
It becomes impossible to take into account the magnitude of the level of effort required to develop and document decisions, requirements and specifications. Ultimately you probably find out that “buying” software is a great deal.
Fast forward to this past summer. I get a call from that same company, only different people. The old guard was gone and the IT group didn’t hold up their end of the bargain. The business never got their solution. All the problems remained and the manager of that group lost his job. So my question, “What’s different now?,” was greeted with a laundry list of reasons why they were ready to be a customer. We took our time though, essentially starting over to make sure we didn’t miss a single detail. In the end, they had underestimated the scope and the requirements. The business, to their credit, refused to settle for a half-baked solution, and just before Christmas they became a customer.
So you are probably wondering if I felt vindicated in anyway. The answer is no. I would have preferred to help them 5 years ago and help someone save their job. A lot of the issues that still exist would have been solved, they would have already gotten their ROI and now moved on to creating additional value for their company as a whole. You never want to see people make mistakes that you have watched others make. As a parent, I definitely understand that. So hopefully, this cautionary tale could help you or someone you are working with avoid similar pitfalls.
So have you experienced this? How did it end up? What did you do?
Read this paper and see if it’s what you are looking for. Learn more about the complexities and challenges of creating your own environmental management system.