Few Guidelines for Estimation and Replanning

1. Estimation Factors
This does not include the defined estimation process; rather, it deals with the possible factors that affect the project if not taken care upfront whilst estimating. This would list down some of factors that influence the estimation. The factors are further classified into SDLC and non-SDLC types.

2. SDLC Factors
This section is devoted to list down the SDLC factors that impact the overall estimation. However, this does not list the regular SDLC phases in the life cycle. This would be in addition to the regular estimation for the phases. These can be termed as tasks that are qualified for chargeback.

2.1 Change Request Inclusion
Once the project is approved for development, we usually come up with estimation for known, regular phases that includes development of the business requirements, functionalities. However, during the progress of the project, there could be a change in the business requirement, due to constraints or other compelling factors. The time that is going to be spent on Change Request has to be included in the original estimation by having buffer/additional.

Whilst estimating, a new task to capture these Change Requests hours has to be created in the list of tasks that are scheduled. It may include subtasks Updating Requirements Document, Design Document etc.,

2.2 Time spent on Re-work
This has to be another task in the schedule. This means, to track the number of hours to be spent on re-work. The re-work includes, defects identified in reviews/unit testing/integration testing. Once the defects are fixed, patches are ready for release; again, testing has to be conducted. Thus, the sizeable number of hours may be estimated & allocated for this re-work task. This rework is within the SDLC phases. This means, rework effort in each phase needs to be captured.

2.3 Re-planning
This could be a potential task in the schedule. The reason is, during the course of the development, considerable amount of time would be spent in brainstorming sessions, meetings/discussions to plan the hours, resources during the course of the project. A separate task in the project schedule would help us capture, track the hours.

3. Non-SDLC Factors
There are factors that indirectly impact the overall estimation of software development. Their contribution might be a small percentage individually; however, in summing the overall estimation, this could be a significant percentage and these need to be taken into consideration whilst estimating. Moreover, these can be termed as Non-CAP tasks in the schedule and these may be exempted from chargeback, in terms of cost perspective. If any of these factors is not available as detailed, then that needs to be reported as downtime. And this can be considered as Administrative hours.

Many times these are assumed to be available 24×7. This is not the reality as this work with constraints.

3.1 Systems Availability
As this is a significant factor for executing our tests (unit, integration and other types). If projects involve iterations, then, at the end of each iteration, the functionalities have to be tested and the availability of the system is very important. If the system is not available, then system downtime has to be logged. This way, the system down time is tracked.

3.2 Resource Availability – Domestic & International
This factor influences the overall time, significantly. If the resources are not available, nothing would progress. The resources’ availability has to be considered with their vacation plan etc., their presence is very vital in the execution of the project.

3.3 Network Availability
As all the systems are well-connected, any break in the topology would be a disaster. The network has to be up & running excluding any maintenance window, if any. In addition to this, the network speed is also very important. If it is slow, then it would consume more time than required. This includes connectivity to remote regions, downtime as well.

3.4 Infrastructure Availability
As a known one, by default, the required software and hardware components have to be readily available. The licenses, active period of software/hardware have to be considered. If anything is not available, that needs to be treated as downtime. This has to be considered while planning the cost of the project.

3.5 Time spent on Non-Project Meetings
This is also major factor. Since, there could be situations where staffs spend time on inter-group meetings or that are not specific to the project in development, this factor is quite significant one.

3.6 Training & Learning Curve
This is one of the important contributing factor, since, if any system/project/process specific knowledge is required, staffs do spend time on this training. And also, if a staff is new to the project, the time spent by that staff to come up to the speed also needs to be counted as part of learning.

3.7 Post Construction Activities
Many times, this activity could be ignored. Since, once the construction is completed, there is lot of steps involved in making the work products available for release. This involved, checking-in the sources into a common repository (part of Software Configuration Management), publishing the information to stakeholders, follow-ups, building and deploying the images into various regions (development, test, production). The time spent on this activity should be considered.

Please note that this is a kind of, dependency with Network Availability and Software Availability

3.8 Post Implementation Activities
There may be times, we feel, we have completed the implementation (turnover) successfully. But, it is not over yet. The factors for the defective implementation or turnover could be, incorrect version of sources deployed, deployment on few regions – missing out on the remaining, defects/fixes/meetings/analysis time and many such more can be included in this activity.