Tips for Avoiding Software Project Schedule Under-Estimating
Software projects almost never seem to finish on time, even when managed conscientiously and with the best intentions. While it may seem to be a foregone conclusion, there are several ways that you can adjust your approach to increase your chances of success. It all begins in the pre-project planning and estimating.
by Peter Cunningham
1. Resist the temptation to over-promise. If you manage projects or people, you are going to be asked to provide a lot of estimates in your professional career. Generally, you will be asked to provide estimates by the project sponsor, your client, your boss, or someone else who is influential or significant to you personally; someone, in other words, that you don't want to let down. It is extremely tempting to provide a "best-case" estimate. An optimistic estimate might be the difference between completing a sale with a prospective client and getting passed over. It also allows you to avoid a confrontation about whether your estimate is legitimate or justified. It feels good to be the "can-do" person that can take on a tough assignment and come through for the team.
In the long run, your reputation and reliability are on the line. If you provide an aggressive estimate now, it is almost certainly going to be necessary to adjust your estimate later. Having that conversation midway through a project is far more difficult than having it at the beginning before the project even begins. You will need to explain why your initial estimate was not correct, and why the project's financiers will (probably) need to spend more money than originally projected to complete the project. Any estimates you provide in the future are more likely to be greeted with doubt and skepticism.
If you provide a realistic estimate that your project sponsor feels is untenable, you can stand your ground in a constructive way. You can emphasize that you understand the constraints that the project sponsor is operating under, and that you would like to explore ways to meet his/her expectations. You might ask if the scope of work could be reduced, or prioritized in such a way that some portion might be reclassified as "nice to have" but not critical for project completion. You might also ask if additional resources can be made available. Finally, you can ask the sponsor to help you to establish a risk mitigation strategy for a schedule overrun. Even if the sponsor is completely inflexible on the schedule, the scope, the budget, and the resources, your concerns will be on record. You will also have an immediate action plan if your suspicions turn out to be well founded.
2. Provide a ranged estimate for long-term milestones. At the beginning of a large, complex project that spans multiple years, estimating a single target completion date is not practical, and is misleading in its simplicity. Contemporary project schedule estimating techniques (just like presidential polls) have a margin of error that is unavoidable. The further distant the milestone is, and the more individual activities and assignments that need to be completed, the larger the margin of error becomes.
If you are using project management software like MS Project, you will have a single date for each milestone that is determined based on the task durations and resource availability for all tasks on the critical path. For executive-level status reporting, you might consider reporting both this single date (as the "most likely" completion date) along with a ranged estimate that reflects the uncertainty relating to this estimate.
Ranged estimating technique is a topic unto itself. One such technique is called Program Evaluation and Review Technique, or PERT. Click here to read more about project estimating using PERT.
3. Use your experience on past projects as a predictor. Project schedule estimates are derived primarily in one of two ways top-down estimating or bottom up estimating.
If you are performing top-down estimating, your goal is to identify the high level phases for the project, and then to determine the amount of time that you estimate will be required to perform each phase. For example, you might break a software project down into 4 sequential phases; the Design Phase, the Implementation Phase, the Testing Phase, and the Data Conversion Phase. You might then estimate that the Design Phase will require 3 months, the Implementation Phase will require 3 months, the Testing Phase will require 3 months, and the Data Conversion Phase will require 3 months. This gives you a total project duration of 12 months.
Top-down estimates are especially good candidates for analogous estimating techniques, in which you use a past project that is similar to the current project for an estimating baseline. For example, imagine the Testing Phase of a similar project required 6 months, instead of the 3 months that you estimated initially. You can start from here, and make adjustments based on significant variations between that project and this one. If you estimate that the scope of the current project is 66% as extensive as the scope of the past project, you might refine your estimate from 6 months to 4 months.
Beyond generating good estimates, analogous estimating techniques are also a great way to learn from the mistakes of past projects. You should be mindful of the lessons learned from those projects, and ensure that you are incorporating those lessons into your planning and estimating.
4. Recognize impacts of the culture. Estimates for your project can be heavily influenced by the culture and structure of the organization in which you are working. Consider the policies and protocols that the organization follows when making key decisions. Are there multiple layers of escalation? Are many different stakeholders involved? If so, you need to ensure that your schedule estimates have sufficient time built in to allow key problems to be resolved during the project.
5. Plan time for planning. Finally, don't forget that projects big and small require time built in for planning to run smoothly and efficiently. Most of the planning will occur at the beginning of the project, permitting the project manager to develop all components of the project plan; a communications plan, change management plan, scope management plan, project schedule, project budget, etc. You should also build in some planning time between major phases or milestones.
In The News is brought to you by WinMill Software, the premier resource for systems development and integration, expert consulting, quality assurance, technology infrastructure, and software resale. For more information, contact a WinMill Account Manager at firstname.lastname@example.org or 1-888-711-MILL (6455).