# 1 – … and the number one factor affecting the probability of project success or failure is, by far, the accuracy of the estimates themselves. It really does come down to that. Budget for the project is allocated based on the ( resource time and cost ) estimates. Target completion and milestone dates are based on the ( task effort ) estimates. Design and cost/benefit decisions for what’s in, what’s out and the best way to accomplish the in-scope deliverables are based on the estimates. You need to get this right, everything else depends on it.
Despite advances in software estimating techniques and software engineering in general, the art of producing accurate estimates remains elusive. Without a good estimate, it is virtually impossible to deliver medium to large software enhancement projects on time on budget and as specified. After years in the industry, and trying everything from function point analysis to lines-of-code complexity metrics, I came to the conclusion that biggest challenge was the accuracy and source of the information used to base the estimates themselves on. Let me explain.
First and foremost, you need to get a clear understanding of in-scope deliverables. Next, you need to recruit a team of subject matter experts to gather intelligence for the estimating process. At the early stage, it can be difficult to get the attention of key programmers and systems analysts within an organization. These same resources are typically frantically finishing off or recovering from implementation of the last big project they were on before being allocated to your new project team. What to do? You need timely, accurate and complete information about the scope and complexity of software changes you plan to make.
From my personal experience, using ballpark estimating tools and techniques like function point analysis gets you in the ball park at best. You have no formal list of actual affected items to support your seemingly outrageous estimates when sitting in a room with the stakeholders and they say “come on, you can do it faster or for less than that … it’s just a couple of tweaks here and there”. In fairness, how can you argue with that? Without an objective list of “here’s exactly why and what’s affected” to support your proposal, you only have your educated guess, reputation and charm as back up. Ever been in that situation? Wouldn’t it have been nice to have just such a list … instead of bending to the pressure and adjusting your estimates down to an unrealistic and unattainable doomed target? It’s a story too often experienced and told.
Even with good estimates, it is critical that the project itself be properly managed. Stay focused, on task, in scope. Communicate. Don’t be afraid to ask for help when needed, raise the red flag when you run into unforeseen circumstances that you recognize may affect your ability to complete tasks as estimated.
The old saying is true, garbage-in, garbage-out. You have to get the estimates right. Stop using ballpark Wild Ass Guess tools and techniques, and look for products and tools that can create accurate checklists of exactly what would be affected throughout your entire application if you change software component or database table “x” to deliver feature “y” in the requirements specification. When you have accurate and complete change lists, you are empowered to:
- determine the precise scope and complexity of each task
- identify the ideal resource skill-set requirements for each task
- produce estimates that will reflect the actual effort to complete changes with the highest possible degree of certainty
- justify and defend your estimates with objective facts
You must log in to post a comment.