How to Track Software Projects Efficiently
BY AKHILESH V GOKARAJU, PMP
Have you run into situations where you spend long hours to come up with the estimates and plans for a project, put them into a project plan, and then as the project goes on you forget about it? Ideally once the plans are in place, the project manager should track all parameters and take the project to its completion. However, the dynamic nature of software development means that due to several factors, plans keep changing weekly, or daily in some cases. As a result, the original estimates might not be tracked and references for future projects are lost.
This happens because development runs into challenges while designing or implementing the requirements, Quality Assurance (QA) facing problems with the test environment, changes/additions to scope, or because of unscheduled patches and service packs. When these occur, the plans are changed accordingly to get new dates. However, what rarely happens is the recording of the actual effort that would have already gone in against tasks and carrying this forward to the new plans. As a result, the monitoring and tracking of the project becomes inefficient. Moreover, revising the project plan baselines in general is done on a need basis rather than at regular intervals, resulting in a gap between planned and actuals.
Let’s take an example. A project has started with the requirements delivered by the product individual tasks or the Work Breakdown Structure (WBS). A baseline schedule is drawn up using the build drop dates, QA test cycles, documentation deliverables, etc., and the project manager starts tracking it against a four-month schedule.
One month into the project, a new requirement comes up. The team has to deliver one of the requirements in a service pack much ahead of the current release schedule. The baseline schedule is now changed to accommodate this with the end date delayed by another month. The new schedule is drawn up to accommodate completing the service pack and incorporating it into the main release.
However, the actuals of the project are generally not recorded and get lost, for example, what was the actual of the planned effort utilized during the first month? How much of the actual effort is pending? Has this been considered while drawing up the new baseline? One of the reasons for this is the lack of coordination between the project manager and the engineering team to get hold of the actuals. Ideally, the functional leads should track the actuals for the WBS and report to the project manager. However, this rarely happens because they are focused on execution and this information tends to get lost.
So how can it be improved upon? One option is a forced review and revision of the baseline every two weeks. Since the revision is closer to the changes in the project, there is less likelihood of data slipping through the cracks and a more accurate reflection of the actuals will emerge.
The concept of Earned Value (EV) can also be implemented here. The amount of work completed or earned can be solicited from the team. The amount of additional work is of course estimated, so a total of the pending additional work and the original work that is incomplete will give you the total effort needed from this point. The baseline can then be calculated accordingly and will be more accurate.
For example, the Planned Value (PV) for a feature for a QA engineer is two months. After a month, the engineer has additional responsibility to test the feature in a service pack, along with the main release and that now requires one extramonth. Therefore using the EV concept, the following is the calculation:
PV = 2 months
EV = 1 month
Assuming actual cost = 3 weeks
Therefore, the new plan would be something like this:
PV = 2 months, 1 week (1 month, 1 week of the original PV, and 1 month of additional effort)
This should be the new baseline and should ideally be re-calculated every two weeks.
The advantages of this are two-fold:
1. It is a more accurate reflection of the effort of the project.
2. It acts as an accurate reference for future projects of this nature.
Wouldn’t it be nice if software development was as efficient and predictable as manufacturing?
(Mr. Akhilesh V. Gokaraju, PMP, has 10 years of experience in networking, application performance, and project management. He works for CA Technologies, Hyderabad, as a senior team lead in quality assurance.)