The state of California’s Employment Development Department has run into major problems with its new EDD software, leaving as many as 300,000 unemployment claimants unpaid due to glitches in the system. In addition, the system has now cost California taxpayers double what the original estimate was to develop the software. The tab for the new bug-riddled system is $110 million. Now the people of the state of California and its lawmakers are looking for answers.
The vendor in this case is New York based software development firm Deloitte Consulting. According to the LA Times, Deloitte has an unfortunate track record of delivering buggy projects which are over budget. Deloitte has also been blamed for similar problems with upgrades to unemployment software in other states including Massachusetts, Pennsylvania and Florida. In Massachusetts, the state senate is holding a hearing next week to investigate its $46 million system that is two years behind schedule and $6 million over budget. Yet Deloitte is one of the state of California’s largest contractors and continues to be hired over and over again for state software projects.
While the new EDD software system is no doubt highly complex, there is a right way to approach such a complex engineering task and a right way to price even a project of the scope of such an extensive system. All too often however, a sales department and the engineering department will find themselves at cross-purposes. Large consultancies need to feed their project pipelines and their sales teams are out to pitch projects at price-points that potential clients can green-light. These scenarios often lead to unrealistic (but “sellable”) price quotes and unencumbered-by-reality project scoping, leaving engineers scratching their heads wondering: “How on earth are we going to complete this project successfully given this size team and this timeline?”
The question of pricing generally starts at the very beginning of the sales cycle. Clients often want to know how much something is going to cost before an engineering team has made an accurate assessment of the effort required. This is most often because the client “Doesn’t want to pay someone to tell them how much something is going to cost.” However, a software consultancy must expend time and energy to investigate the systems in place and determine how best to move forward. The solution is a win-win: a professional, informed technical assessment of the current system and the system to be built. Such an assessment is necessary for any software project (especially those currently in use) so that good money isn’t thrown after bad.
The Boomcycle system assessment process is known as a “Discovery”. The Discovery looks at the following considerations:
- The functionality and interactions of current systems
- Bugs to be addressed in the upgrade
- New functionality to be implemented
- Any data migration necessary (moving data from one system to another)
- Existing hardware and any new hardware which needs to be purchased
If your company is facing a large software development project, you owe it to your bottom-line to engage with a competent development partner in a Discovery process. Completing the Discovery ensures that all parties have carefully examined the most key development issues from an engineering perspective which directly informs the delivery date and cost estimate. Unfortunately in the case of the state’s EDD system, a misunderstanding of what is actually supposed to be built is most likely to blame for the cost overruns and buggy nature of the system. All too often, the person writing the check is more interested a supposed final price-tag instead of a thorough examination of the problem and a viable solution: “I don’t know what I want, but I don’t want to pay a lot for it!” This is the most assured path to disappointment.
They say “the devil’s in the details” — that’s never more true than in software engineering.
Contact Boomcycle today to find out how we can help your company avoid the mistakes of large organizations like the state of California.