Improving Package Implementations Estimates using Package Points
Today, ERP is used more to drive business improvements & operational efficiencies and hence, any delays or budget over-runs could impact the business. However, most independent surveys and studies indicate that about 55 percent of ERP Implementation projects incur budget overruns. According to Standish Group, a research firm, the average IT project runs over budget by about 43 percent. Among the litany of reasons quoted (such as excessive focus on technology at the expense of business processes, communication shortfalls, project management and operational issues) estimation & bad planning rank high in the list.
While effective monitoring & control of scope, risks, communication etc., can streamline the ERP implementation, there is no alternative for a robust and accurate estimate. Given this critical need, it is surprising to note that there is no common, industry benchmark for estimating a package implementation size. Commonly used IT techniques such as Lines of Code (LOC) and Function Points (FP) do not hold good in this case since custom development is only a portion of the project. The most common technique used is experiential estimation where the practitioner derives the effort and timeline based on the ‘perceived’ size and complexity of the implementation. Although this provides a lot of flexibility, it is inherently dependent on the ‘experience’ and ‘risk appetite’ of the practitioner and the repeatability is poor. Another shortfall of this technique is that there is no baseline size for computing productivity or comparing across projects.
To derive consistent and repeatable estimates, we have introduced a size measure called as Package Points for package implementations. The three factors that affect an implementation size are Scope, Tasks (activities & deliverables that are part of the implementation) and the project Complexity. 100 Package Points have been defined as the size to implement a “Standard Module” for a “Standard Task List” with “Simple Complexity”. The Standard Module has been defined to contain 10 business processes; each process has 4 setup activities (nodes); each node can be setup using 1 front-end interface (form); each form has 10 fields; each field has 5 possible values.
The model maintains a library of various functionalities offered by a package and functionality size in terms of the standard module. Selecting the required functionality will derive the solution size. The model also has the Standard Task Album defined, which contains the activities & deliverables of a typical implementation along with the fixed & variable impact of these Tasks to the Solution Size. As a second step in the model, these tasks are selected to calculate the Task Impact on the solution size. Impact of the tasks on solution size varies with Complexity Factors of the project, which help in pegging the Task Impact in the range of Low (Best Case) to High (Worst Case). The third step in the model captures the impact of complexity factors on the solution size to finally derive the Package Points.
I have elaborated further details about the Package Points model in the whitepaper “Estimating the Size of Software Package Implementations using Package Points (https://pub.infosys.com/default.aspx?cid=MTI5O29yYWNsZS93aGl0ZS1wYXBlcnMvZGVmYXVsdA%3d%3d-gtOtZSHtZCo%3d) – the link will prompt you for registration on the Infosys site. Please provide your comments on what you think about this methodology and yes we have tested it in our live projects and have found that the estimate is more accurate than the traditional experiential estimates, although more involved and time consuming.
