We have many requests to develop a small project or improve some functionality under fixed-price contracts. Such IT projects usually take several weeks and are executed by one developer, which means that all project tasks are done sequentially, step by step.
To find out all requirements a business analyst discusses a project scope with stakeholders and then invites a technical specialist who is most familiar with the project’s specific nature of the project at hand to define all the activities involved and create a work breakdown structure. Engaging a technical specialist at the decomposition stage leads to better and more accurate results. The project is typically decomposed into smaller components called activities that represent the work to complete. The activity list includes activity identifiers and a detailed description of the work scope of each activity’s to ensure that we understand what work is to be completed. These specified activities provide a basis for project performance at all stages: estimating, scheduling, executing, and controlling. When all the activities are defined, the business analyst and technical specialist sequence the activities using logical relationships and decide on a development path. The determination of a critical path and critical chain is out of this topic because we cover only small projects executed by one developer and not requiring any rolling wave planning due to a short period of project execution. Nevertheless, some milestones can be set to mark significant points or events in the project.
The determined and sequenced activities are estimated by the technical specialist and business analyst in work periods, usually days or hours. They use a combination of the following tools and techniques:
- “Expert judgment” provides estimate information from prior similar projects
- “Analogous estimating” uses parameters such as technology, size, complexity, etc. from previous, similar projects, as the basis to estimate the same parameters for the current project. We use this type of estimation when there is a limited amount of detailed project information.
- In “Bottom-up” estimating requirements are developed, detailed down to the work package level. Next, each package’s cost and duration are assessed separately (the assessment starts from the lowest level and goes up). The sum of estimations of the packages shows the total cost and duration of the project.
- “Parametric estimating” uses a statistical relationship between historical data and other variables to estimate activity parameters.
There are no major or minor techniques; depending on the project, they are used differently.
Any activity estimate (pointed above) as a rule has two figures:
- Minimum duration (Min) – the number of time periods required to complete the activity if everything is going as expected.
- Maximum duration (Max) – the number of time periods to complete the activity if some risks arise. Unfortunately, sometimes an activity implementation may bear risks. For instance, risks of using API of an external tool, ambiguity of using a better tool, providing API of other developers involved in the project, etc.
Min and Max duration periods are equal if there are not any known risks. Having Min and Max duration periods, we can get some time intervals showing how much time the project will take. For instance, the project completion takes from 100 hours to 150 hours – 100h if no risks arise, 150h, if the foreseen risks arise. However, effective customer relationship is based on exact data, that’s why we have developed an excel document to calculate all possible risks and determine the most probable project duration (see it below).
The most probable project duration helps create development forecasts and make further plans.
- If there are several duration periods of equal probability, then we analyze them anew to select the only one.
- If there are many most probable duration periods, we use a three-point estimate originated from the Program Evaluation and Review Technique (PERT).
PERT is similar to the method of “Expert judgement”, but the technical specialist, in turn, gives not one, but three assessments: the most probable, pessimistic and optimistic. This method is suitable because it adjusts the most probable estimate considering the number of risks associated with the task. If the pessimistic assessment does not differ much from the most probable, the technician does not see the significant risks associated with it. For example: if the most likely estimate is a week, and the pessimistic estimate is seven weeks, it will mean the task has serious risks.
An example of PERT you can find in the shared document at the end of this article. We use a three-point estimate to define an approximate range of activity duration: most likely, minimum and maximum. According to PERT analysis, we calculate an expected activity duration using this formula:
duration = (min + 4*“most likely” + max)/6
and the resulted estimate is the precise number. During the project execution, the estimate allows measuring project progress against the time baseline and making forecasts.
Read also Budget With Float Scope Contract Type
When the estimate is ready we calculate the project cost derived from:
- Provided estimate – the most likely project duration or the precise number of PERT analysis
- Business analysis and project management – allowance for managing project scope and change requests to avoid scope creep and provide expected delivery on time and under budget. Dependent on provided initial project scope and understanding deliverables, business analysis, and project management take between 10% and 30% for small projects.
- Contingency reserves – allowances for unplanned but potentially required changes that can result from the realized risks. The amount of contingency reserves depends on the foreseen risks, project environment, etc… There is not any ordinary amount of contingency reserves. Some projects have 0%, but some have more than 10% of the provided estimate.
- Cost of quality – costs cover the appraisal of the product with respect to conformance to requirements and costs incurred over the life of the product by investors in an attempt to remove nonconformance to requirements. The total price of quality is dependent on the list of requirements and provided by QA specialists. Speaking about web development, we should remember that the more browsers and devices we support the higher prices are.
- Management reserves – a budget reserved for unplanned changes to project scope and cost. The amount of management reserves is dependent on the completeness of the provided project scope, openness, communication quality, etc… They are usually around 5%, more rarely over 10%.
For example, the shared google sheet of an imaginary project shows that the:
- Most likely development estimate – 153h
- Business analyses and project management (20%) – 30.6h
- Contingency reserves (10%) – 15.3h
- QA estimate (30%) – 45.9h
- Management reserves (5%) – 7.65h
The calculation of the total project price calculation is based on 277h and includes a product with few bugs and free bug fixing during our 6 months warranty period. Moreover, Time and Materials contract can save the Customer 15% of the price due to contingency and management reserves that are the customer’s responsibility.