Why existing estimation tools are not realistic for Digital Project Estimation

Why existing estimation tools are not realistic for Digital Project Estimation

by Bollapragada Sairam, Rajesh Mohandas, Dattatreya Rao, & Ravi Pandikunta

Digital for some executives is primarily about the technology. For others, digital is a new way of engaging with customers. And for others still, it represents an entirely new way of doing business. None of these definitions is necessarily incorrect. But, the variation results in piecemeal initiatives and misguided efforts.

Industry experts have started to believe that digital should be seen less as a thing and more a way of doing things … this creates complexities with respect to estimation, how can one estimate and cost a concept. In digital projects “basic concept” is a starting point for estimation, or at least an idea, but it’s loose and not particularly well defined. Sometimes that’s because there hasn’t been time to develop it or there simply isn’t the ‘appetite’ from the creative to think through the detail.

Unlike traditional development parameters, the Digital World carries many more and they are unique in nature, variety of products, applications, data bases, technologies, middle-wares, hosting types and the entire eco system. Few more elements such as, sensors/devices, platform/infrastructure, testing, integration, security, scalability, robustness, seamlessness are multi folded efforts in development.


Some cost estimation models used in software development today are

Cost Model Description Best Fit Environment Formula type
COCOMO Constructive Cost Model Large corporate and government software projects, including embedded firmware Logarithmic
COSYSMO Constructive Systems Engineering Cost Model Large corporate and government projects, including embedded firmware and hardware Logarithmic
FP Function Points Software projects of all sizes, mainly desktop OS based platforms Linear
WMFP Weighted Micro Function Points Commercial software projects of all sizes and environments, including embedded firmware Linear
REVIC REVised Intermediate COCOMO Large military software projects, including embedded firmware Logarithmic

Some typical challenges with traditional estimation techniques in software development:

Unlike other industries, here often the estimates are done with partial data and sometimes with incorrect data, too. Several techniques / tools have been introduced over the years to make the process systemic and not a gut-based guesstimate. However, lapses still occur and this is still one of the toughest to-dos for a project. Following are few more parameters

  1. Poor design: Poor design results in unnecessary code tweaking and heavy-duty maintenance applying pressure on schedules.
  2. Not splitting the tasks enough: Most common method is to split project tasks into a WBS, but sometimes they are not broken enough to be conceptualized with clarity.
  3. Top to bottom scheduling: This is a practical problem one needs to deal with. Instead of doing bottoms-up estimation, most projects start with – “I need this done in 6 months” and then a work breakdown is done where the task estimates are retrofitted inside these 6 months.
  4. Factoring the dependencies right: Often, an external dependency or a decision point is missed-out causing the project to suffer, this is “coordination neglect”.
  5. Factoring right buffer: This is a common challenge and there is no simple formula here.
  6. Analogous Estimation Risk: Often, project estimates are done based on an expert judgment or from past projects’ experience. While picking an analogy and mapping the estimate might seem like an intuitive thing to do, it’s often risky because of the numerous variables in a project and the unique elements and dependencies, the people involved and their skillset, diverse tools and technologies adopted and the infrastructure and resources in place.
  7. Ignoring Team Capacity: There is a lot of debate about what unit or estimates need to be factored – should we measure complexity, time or effort? Irrespective of what unit is followed, many Project Managers tend to ignore considering their team’s capacity. It seems obvious that different people would take different time to code, but when we draw estimates, we come up with a standard effort estimate.

One other challenge is not only the technology but also the periphery elements on the topology, network, security and emerging areas like Artificial Intelligence, Autonomous vehicles, Cloud Manufacturing and 3d Printing, IoT and Connected Devices, Robots, Drones, and social media platforms couple with decisions on the emerging approaches like DevOps, Dockers, Microservices etc… add further complications into the estimation cycle.

Changing expectations from the customer are forcing service providers and manufacturers into a hyper personalization spiral, thus adding cost pressures. In these cases, the technology needed to solve our problem is well established indeed; in fact, it’s possibly the most important technical innovation in the history of humanity ranging from B2B, B2C, B2M, C2C etc…

The players in the market too have made the situation complex, though each provider promotes “On Demand and Pay as you Go” models the terms and conditions are quite different, for example the pricing metric in case of AWS is number of messages, Cisco looks at Cellular, GE bills on number of instances, IBM looks at data ingested and bills accordingly, Microsoft costing is depended on Number of messages, devices and feature set while SAP looks at an annual fixed subscription model and there are many more such elements to consider in your costing model…

The exponential growth in the technology as well as diversification of the same, new solution components, hyper-personalization, and other needs, all mushrooming towards building of modern solutions; but one cannot ignore that there is a dire need for building standard cost estimation frame-works where the conventional methods cannot be afforded….