Common mistakes in development effort estimates

Estimating how long individual tasks and phases will take is one of the most challenging parts of project planning. Quite often, we find ourselves using an effort estimate and resourcing level to derive duration. This method works, providing we don’t encounter unforeseen problems or issues not accounted for in the effort estimate.

If there is one phase of the project most likely to suffer from these unexpected delays, it is development. It is therefore important factor in a reasonable contingency, over and above the effort estimate, when planning the delivery of developments, as the process is almost guaranteed to take more elapsed time than the effort estimate.

• There are also a few common mistakes people make when trying to mitigate risk of development delays, which are well worth keeping in mind while planning your project:

• Adding more resource doesn’t necessarily reduce the elapsed time it will take to deliver the code. Put simply, if you have 10 days work for one developer, it doesn’t mean 10 developers can complete it in one day.

•  Distributed development needs to be carefully planned and managed by a technical architect or development manager who understands the implications of dividing the workload.
• Do not be tempted to use the availability of additional resource as your contingency plan.
• Assuming rework will take no time, everyone factors in time for testing, but many fail to allow time for rework. A good rule of thumb is to allow at least 15 percent of the original development effort for rework and post testing bug fixes.
• Monitor progress frequently and adapt based on actual progress. In our most recent projects, we held a dedicated development meeting once a week, in which we reviewed actual development progress against what we expected to get done. This meant all interested parties were aware of any delays
• Experienced in development due to unforeseen problems, and were able to start assessing the impact on other downstream processes, like testing and training, well in advance.

Note: Remember that AX 2012 is quite different to the previous versions of AX. Developments that took minutes in AX 2009, for example, setting the value of a dimension programmatically, can take considerably longer in AX 2012. Make sure that the estimates are done based on a working knowledge of AX 2012 and not experience of prior versions.