Skip to main content

Flexibility Is Key in Project Estimation

So often we hear of projects—especially government funded projects—exceeding their budget, and for a long time my knee-jerk reaction was that hanky-panky was afoot. I’m sure sometimes that’s true, but when consulting became my career and sizing a project became a necessary skill, I realized it wasn’t so clear cut. In most cases, there are no simple formulas where one can fill in the blanks, where the variables are precise and predictable values, and where change doesn’t throw a curveball at any stage of the process.

The thing I most dreaded in negotiation and formulation of a project estimate was answering questions like “How much will it cost?” and “How long will it take?” I dreaded those questions because they were impossible to answer with certainty. I learned early in my consulting career that fixed price contracts were a recipe for disaster, and I learned the hard way by agreeing to one. Fortunately it was a small contract I performed myself, so I sacrificed a week and finished it. My client hadn’t been completely forthcoming—more from ignorance than intent—but it was worth the loss to learn the lesson.

I never accepted a fixed price contract again, for I’d learned the importance of thorough vetting, and even more importantly, constructing a billable, detailed project plan to estimate the necessary person hours. A prospective client often balked at the cost, but when I explained the project plan would be theirs as well as any findings that came from the research my staff and I performed, they understood that these were two valuable deliverables even if they or someone else did the work. In virtually every instance they agreed, and if they didn’t, it demonstrated they weren’t willing to do the up-front work so necessary to any IT project. I wanted no part of that.

Obviously, clients have good reason for asking about project cost and duration, and they need a good answer because a given project is only part of the workload an IT department manager is responsible for. They have approvals to secure, commitments to obtain, and most likely hardware, software or other related components. Both clients and consultants need to be highly sensitive to each other’s needs; my firm’s motto is “Success is an exercise of finding win-win situations,” and that’s what an estimate and an agreement must be.

Estimation Requires Research and Planning

My way of estimating an IT project’s size and duration has three steps:

  1. Interview members of the IT staff, starting with the management, followed by technicians
  2. Review the system structure (i.e. dataset layout, hardware configuration, software configuration, operations and scheduling procedures, etc.)
  3. Hold a kickoff meeting with all relevant staff and produce a first-cut, high-level project plan identifying first- and second-level tasks that include estimated completion times

Then, I ask the client’s staff to review the project plan and provide corrections, which are used to revise the project plan. A project management tool is used to produce a total hours estimate, which is a starting point for an overall project estimate. Additional recommendations such as workload balancing and safety margins are provided, and further recommendations may be made based on interviews and system structure review. The total hours estimate is modified into a range (e.g. plus or minus 100 person hours), because that’s a more useful value for pricing and planning.

Areas of Uncertainty (subhead)

Unanticipated events or issues can have a drastic impact on an estimate, which is why a project plan should include time and human resource allocation to handle unexpected surprises or mishaps. These changes might include:

  • Changes in a new software release or hardware device, which can be problematic due to incompatibilities with existing components. This may result in errors, performance degradation, transient or temporary errors, or other unexpected dysfunctions. This can also require other software or hardware changes or modifications—work not initially built into the project plan.
  • Rarely used or outdated components (printers, card readers, network interfaces, etc.) which, due to their rarity and age may not support new technology, and because of infrequent usage, may not have been tested for compatibility or suitability
  • Key staff member skills. Skills likely need upgrading, not only because of new components, but because interfaces may need tailoring and customization to function with new products or devices.
  • Dependability and reliability—especially disaster recovery—procedures and infrastructure, which may be impacted from both hardware and software
  • Software and hardware defects or errors, which may have changed or been replaced with a system upgrade. This may require changes to procedures or documentation.
  • Product documentation, which may change with new releases and may need to be repopulated

Estimates Need Built-in Flexibility

Because of the variability just discussed, the gotchas (my term for incompatibilities, problems, personnel changes or other unexpected, unforeseeable diversions) require that flexibility be built into the estimate. Time must be added for gotchas, mistakes and unanticipated external influences. Criteria needs to be established on how or how not to proceed, and a negotiation protocol must exist so clients and consultants can jointly determine the issue, construct a solution, then either proceed, determine a new course of action or amend the scope.

No, I’m Not Naïve

I’ve had many preliminary engagement visits where a potential client took my hesitation to provide specific prices or completion dates as a sign of inexperience or uncertainty, and I’m happy when they do because it provides the opportunity to explain why building flexibility into an estimate and proposal is so important. I explain that a project and related plan is a living, evolving entity. It’s a virtual certainty there will be unexpected roadblocks due to inherent complexity, gotchas and new technology. I use experience to teach, describing how changes cost money and time, but are inevitable for a successful project.

Every project I’ve run ended well, and flexibility was a big reason. Another was the clear delineation of work responsibilities and details, and a thorough, joint project management and tracking discipline that measures progress and adapts to changing circumstances. Diligent communication abets the process, constant questioning uncovers issues and anticipating changes avoids most gotchas. Making promises that can’t be kept is a recipe for disaster, but building a flexible project plan that’s constantly monitored and approved by everyone involved is a formula for success.

A Flexible Estimate Defines Boundaries

I inform all prospective clients that problems and issues will inevitably arise. One memorable contract involved a large school system of 6,500+ schools and 130,000+ students, supported by an IBM mainframe that processed online student records and business processes (accounting, inventory, history, etc.). They needed a system upgrade of system software and vendor products, so my staff and I created a work estimate and proposal as described here, and won the contract. The school vice president asked me to bid lower than the estimate for political reasons, stating she had more budget available if necessary. I agreed and added the clause: “No work beyond agreed contractual price will be performed unless client compensates based on time.”

Scheduling production system testing was difficult, because the system was only available on three-day holiday weekends, and the first try uncovered several significant problems. The good news was the problems could be reproduced in tests, but the bad news was that the time to determine fixes, test them, and build them into the new system exceeded the contract’s cost. Initially, the vice president refused to pay, concerned about bad publicity, leading to several contentious conference calls until I invoked the contract clause. She unhappily agreed, and we got the production system updated, tested, operational and problem free exactly as scheduled. In a dramatic turnabout, I received a very gracious and delighted (her words) letter, because her school board congratulated her. Flexibility saved the day, proving that a job well done–not a job cheaply done—is the definition of success.