Classic IT Challenges – Estimating Work

This is the fourth post in a series of writings to discuss issues facing Information Technology (IT) departments. The first three challenges were project work vs production support, prioritizing work and operations vs innovation.

IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group. My thoughts are more around framing the problem than presenting solutions.

Challenge #4 -Estimating Work
Estimates provide the basis for developing budgets, creating timelines, and setting customer expectations. I have suggested before that estimating is the most powerful step in the software development cycle because it determines if projects are approved or rejected.

There are a couple of challenges with estimating work. The first is that despite processes that call for initial estimates and then re-estimates when more requirements are defined, most of the important decisions are based on the high-level estimates. Project budgets, timelines, chargebacks, and approvals are most often formed at the beginning of a project and often before the requirements are truly understood.

The second challenge is trying to keep the amount of time spent on an estimate within reason and to keep the time spent on the estimate from impacting active work. Creating an estimate requires time from an analyst. So there is a cost! Organizations should be mindful of this because spending money on a project that is not yet active or approved lengthens the the time to recognize return on the investment and it could possibly take people away from working projects that are already approved.

Example 1
A team receives a high level description of a project and is asked to provide an estimate. A timeline is built from the estimate and shows a final delivery in 90 days. 15 days into the project a discovery is made that two systems are not compatible and that a major assumption about equipment availability is not true. The new information will require an additional 30 days on the project timeline. How does the team and react to this information? Is the budget revised? Is the timeline revised?

Example 2
A portfolio management organization has five active projects. Three new project requests arrive. The same people working on the five active projects are the estimators for the new work. If they stop work on the active projects it will create delays in the project timelines, but executive management wants estimates on the new requests to determine what to do with the requests.

The Challenge
Estimates are by definition inaccurate. Yet, important decisions are made from them. IT team members feel the pressure not to underestimate because budgets are created from the estimates and it’s hard to secure additional funding for budget overruns. But IT team members are also pressured not to overestimate because stakeholders may cancel the project, complain that estimates are unreasonable, or take the work to an outside agency. Business stakeholders want accurate estimates delivered in a timely manner and with a minimal amount of detailed project requirements.

Next Week
Challenge #5 – Understanding Project Complexity