How to Estimate The Duration of Consulting Effort for a Software TCO

Executive Summary

• Brightwork Research & Analysis uses an assumption regarding how long it takes to implement an application.
• This is a critical point in determining TCO.

Introduction

Of all the many factors that go into the implementation duration, the most important is its quality, specifically its implementability. We assign an implement-ability score to every application that we review. This is important because so many companies assume— implicitly—that all software applications included in the software selection exercise are equally implementable. They don’t differentiate based upon this factor. However, this is a false assumption. Some software is designed to be sold more than designed to be implemented—one of the best examples of this in SAP. At SAP, Sales has most of the say in the organization, and that the application “has” functionality is emphasized rather than making the functionality implementable. Therefore, SAP projects typically have many problems and take a long time to implement—and continue to have more problems after implementation.

How Configuration Ease Fits into Implementation Duration

The best of breed applications that we compare to SAP is much easier to configure. More functionality works and the users find the application interface easier to use, so the implementation time is shorter. Companies that are unhappy with how long their implementations are taking need to look at the software they are selecting because the application is the greatest determinant to both the project duration and the implementation’s success. We are really starting to see this happen in the business intelligence market. The overwhelming cost and implementation time of self-service applications like Tableau make the TCO advantage almost too obvious to ignore versus older solutions in the market.

Realistic Project Implementation Duration

Estimates Most vendors would not be happy with the implementation duration estimates developed by Brightwork Research & Analysis. However, these estimates are based upon years of analyzing how applications are actually implemented, which is far from the optimum values that are often quoted. We have performed the research. The statistics are clearly on our side—enterprise software implementations take much longer than is generally assumed, not only by the software vendor but also by the project implementing company’s project management. Have been many attempts over the years to reduce implementation timelines, yet they remain sticky. One exception to this is SaaS, which consistently has shorter implementation durations than on-premises applications. SaaS-delivered applications allow a company to get closer to the optimum implementation time.

One reason for this is there are fewer hiccups, and the infrastructure is already in place. Besides, more of the vendor’s expertise can be leveraged at any time (the SaaS vendor has one hundred percent access to the application at any time because they control the box)—and that can mean literally any time; some SaaS vendors offer twenty-four-hour support and since so many SaaS vendors offer some support from countries on opposite time zones—notably India—work can be done when clients are asleep in the US or Europe. These are just a few factors that explain why SaaS implementations tend to be so much faster and smoother than implementations of on-premises applications. But most applications are not delivered through SaaS; they are delivered on-premises, and realistic implementation times are necessary because we are not developing TCO estimates for a perfect world but for companies that have to implement software in this world. Nucleus Research addresses this exact issue with other similar applications like i2 Technologies.

“Nearly 70 percent of the i2 deployments lasted longer than project teams had planned. For these companies, deployment took, on average, nearly three times longer than expected while increasing consulting personnel costs and slowing the realization of benefits from the solution. “Don’t let vendors dictate your expectations of how long it will take to deploy a certain tool in your environment. Make an independent estimation based on internal planning and the experiences of similar companies that have implemented (the application).”

Including Problematic Implementations as Part of Durations

Another factor that can lessen an application’s overall implementation duration is that often people will not consider the duration of problematic implementations, as if, for some reason, problematic implementations don’t count. It is unscientific to remove problematic implementations from the equation unless there is an excellent reason to do so (such as the company stopping the implementation from working on a different project before returning to the implementation of the first application). This is called “outlier removal” and is a primary method by which research is falsified across disciplines, as discussed in the following article.

I was recently contacted about a re-implementation project. For two years, the company had attempted to implement a combination of SAP modules and never brought the system to a live state. It then waited a year and a half and then attempted a re-implementation. What is the duration of this project? There are other examples of problems in time estimation. An application will often go live, but the company finds the application is not adding value to the business. I have seen this numerous times with applications where the configuration and settings were not set up so that the business could benefit. Instead of adjusting the settings, which would have been the right thing to do, the faulty configuration was rolled out to more regions to keep on target with the initial timelines. A person in management may measure the time the application officially went live as its implementation time; however, the way this is measured at Brightwork Research & Analysis is that the application should not be counted as live until it begins to add value business. It is, in fact, quite easy to bring up an application so that it is “live.” All that has to be done is client-specific master data setup, integration performed to other systems, and a generic configuration. I refer to this as a 100% IT implementation—the system is working, and all the server lights are blinking.

Conclusion

Implementing the software in a way that adds significant value is the actual goal, not simply hitting a deadline. However, in multiple studies, it has been found that companies have no other way of objectively determining project success beyond the meeting of project deadlines.