After we wrote what estimation is, why it is important, and how to approach it, now we gonna take a look at some possible issues and useful guidelines for project evaluation.
It can happen that project managers resort to scheduling estimates in order to estimate the size of the overall project. This happens due to time constraints, i.e. deadlines that are determined mainly by management or by the marketing team.
However, for whatever reason, if it happens, then it is difficult to estimate the schedule at a later stage and adjust the change of the project scope. Even good estimates contain inherent assumptions, risks, and uncertainty – and yet, if they do, they are often treated as if they were accurate.
The best way to express estimates is through a number of possible outcomes.
For example, the project will last 5 to 7 months instead of stating that the project will be completed on a specific date or in a fixed number of months. Caution is required when committing to a timeline in a range that is too narrow because this is equivalent to setting a specific date. It can also be done to include uncertainty as an accompanying probability value. For example, there is a 90% probability that the project will be completed on or before a certain date.
The estimate may be questionable if the organization does not collect accurate project data because the accuracy of the estimate also significantly depends on historical data, so this may present a problem.
Each project has the shortest possible schedule that allows for the inclusion of the required functionality and production of quality results. If there is a schedule limit made by the management and/or the client, the scope and functionality need to be renegotiated accordingly, so it can be delivered.
It is important to agree with the client on the extent of management slowdown to avoid schedule overrun. Failure to accept contingencies in the final assessment causes problems. For example, meetings, organizational events, etc.
In addition to the above, resource use should be considered at less than 80%. This is because resources are productive for only 80% of their time. If more than 80% is allocated to resource utilization, there will inevitably be a slowdown in the project.
The following guidelines should be kept in mind when evaluating a project:
- During the assessment, one should gather the experiences of others, but also rely on their own experiences.
- Assume that resources will be productive only 80% of the time. Hence during resource utilization, estimates should take up less than 80%.
- Resources working on multiple projects take longer to complete tasks due to the loss of time between the projects.
- Include management time in each assessment.
- Always build a backup plan for troubleshooting, meetings, and other unexpected events.
- Take enough time to properly evaluate the project. Quick estimates are inaccurate and high-risk. For large development projects, the assessment step should be considered a mini-project.
- Whenever possible, use documented data from similar past projects. It will result in the most accurate estimate. If historical data is not preserved, it is necessary to start collecting.
- Use developer-based estimates because estimates that are prepared by other people, instead of those who will do the work, will be less accurate.
- Use several different people to evaluate and use several different estimate techniques.
- Align estimates. Observe the merger or expansion between estimates. Merging means that you have a good estimate. The Wideband Delphi estimation method can be used to collect and discuss estimates using a group of people, with the intention of producing an accurate, unbiased assessment.
- Evaluate the project several times during its implementation.
There are several assessment techniques. Here are some of them:
FP (Function Point)
FP expresses the amount of business functionality of the information system or product provided. It is based on measuring software size. Thus, there is a widely accepted industry standard for functionality sizing, so-called ISO standards (International Organization for Standardization).
A series of related interactions between the user and the system that the user is allowed to achieve the goal. The use case checks the functional requirements of the system.
A structured communication technique, originally developed as a systematic, interactive prediction method that relies on a panel of experts.
As the name suggests, it includes three value elements: the most optimistic estimate (O), the most probable estimate (M), and the pessimistic estimate, that is, the least probable estimate (L).
E = (O + M + L) / 3
PERT (Project Evaluation and Review Technique)
This assessment takes into account three values: the most optimistic estimate (O), the most probable estimate (M), and the pessimistic or least probable estimate (L). It is very similar to the three-point estimation, so there is very often confusion if both of them are not known well enough, or how they work has not been explored well enough.
E = (O + 4 × M + L) / 6
Used to calculate data on a similar project to estimate the duration or cost of the current project. The estimate you can use is just limited information when evaluating the current project.
WBS (Work Breakdown Structure)
Project decomposition focused on the delivery of smaller components. WBS is a key result of a project that organizes the work team into manageable parts. WBS elements can be product, data, service, or a combination thereof. WBS also provides the necessary framework for detailed cost estimation and control while providing guidance for schedule development and control.
Combines three assessment methods: The Wideband Delphi Technique, Analogous Estimation, and WBS.
While estimating, there are many different reasons that can cause some issues, so it is important to express estimates in a number of possible outcomes. This is one of the reasons why it is important to keep in mind the estimation guidelines mentioned above, no matter which of the described estimation techniques you choose.