Pre-Requirement Estimation for IT Projects

Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objectives of the change, and what are the requirements a change must meet to satisfy the objective.

Implementing the change usually starts with someone needing to know what the change is going to cost!

Therefore, the typical first step after the high-level objective is established (usually in the form of a lofty “vision” statement) is to estimate the time and cost of the project. This leaves us with the following quandary: the detailed requirements needed to ensure each component is designed and built correctly simply don’t exist. The unfortunate paradox in software development projects is that these very detailed requirements can often take long hours to implement, test and deploy. An estimate can swing wildly as a result of these seemingly small details.

So how does an estimate lead – project manager, IT architect, or some other role – deliver a time and cost estimate on time in the early phases of a project without succumbing to analysis paralysis and detailed requirements gathering before this activity is even funded? Simple: Assumptions.

The most important lesson you can ever learn to ensure your software project estimate is successful is this:

Use Assumptions To Drive Estimation

If you are responsible for leading and facilitating cost estimation activities – as we at Systems Flow often are for our clients – you have to understand the perspective of software project business sponsors in a typical medium/large enterprise:

• They have a vision, want the vision to get on its way – NOW
• They don’t have all the requirement answers, but need funding and resources to even begin to draft the answers, in the form of business requirements

You also have to understand the perspective of IT stakeholders in a project:

• They need certainty – how can they accurately quote, for example, how much storage is required if the business line hasn’t decided how long they want data retained?
• They have been burned in the past by providing “swag” estimates in early scoping that they are unfairly held accountable for later in the project when actual requirements and true scope are clarified.

Assumptions are the only thing that can allow all these competing concerns to reach an acceptable compromise.

When a Systems Flow consultant leads an estimation effort for a client project, he is the focal point for questions from IT stakeholders. These stakeholders want the business to say exactly what it is they want on every point:

• DBAs need to know how many transactions per second a new operational database will experience in order for them to select the right RDBMS and size the support infrastructure
• Software Engineers need to know the nature and number of service interactions they must build with backend systems to automate the business processes
• IT Security Engineers need to know where in the solution any confidential data will be transmitted and persisted, to determine if penetration testing will be needed (and estimated)

Aside from the fact that a business sponsor really isn’t (and shouldn’t be) in a position to respond to these technical design considerations, the fact is that the IT Architect won’t know the answers either. But an educated guess must be made – an assumption – on each of these detailed questions in order to move the project forward.

A well-managed waterfall project will have checkpoints after each important milestone prior to the Build phase, to refine the original estimates as requirements then are completed. This allows the business to continually re-assess requirement priority, adjust to new realities around timeline and cost, and generally manage the change more efficiently.

Stay tuned for a later post about Systems Flow’s specific model for estimating that relies on Confidence Rating to gauge the accuracy of estimation.

Comments