Infosys | Microsoft

This has led me to  think of  a sizing methodology which takes the best from FP based sizing methods as well as effort based methodologies. The benefits from such a methodology should be:

• Will enable a holistic sizing of a package application (MS Dynamics in our case) based implementation.
• Allow practitioners to compare the size variations across products, eg. Variation if choice is between AX & NAV thereby enabling optimum product selection for customers
• Will enable delivery teams to measure productivity improvements over a period of time by being able to compare similar sized projects.

From a package application perspective, the client requirements can be classified under the following buckets:

1. Direct Fit with the features available in the package
2. Not a direct fit but can be met with extension of the package application
3. Requirement cannot be met by leveraging the product base feature and hence needing customizations

Among the three categories mentioned above, in principle, I could use the FP sizing technique directly for the 3rd one to a reasonable extent. But for the 1st and 2nd categories, the size becomes a challenge as the composition of the solution is  two-fold. The size has to take into account the base features provided by the product, some of which may not be of any use at all for the customer. This adds to the complexity as it is imminent to first arrive at a size for the base features of the package. The closest this can be compared to is with a book with a lot of content. The size of the base package would be akin to the size of the book. But the actual solution would be  like buying a book for one of the university exams that has some portion of the relevant syllabus but because of the other content, its size is larger than what is actually needed. :)
 
Going by this, another inference that could be derived is that, the size of a solution with the same set of requirements will be different for different packages. This would  depend on the base package application that is selected for implementation. ( Analogous to different books available in the bookstore for the same syllabus).

From a mathematical point of view, assuming that we have a standard unit of measurement for the size (sizing point), key constituents of the overall implementation size would be

• X sizing points for out of box supported functionalities
• Y sizing points for un-used out of box functionalities
• Z sizing points for additional customizations

Based on the package being considered, the value for all these variables would vary, thereby making the size different. The above illustration may look simple but arriving at X, Y and Z values is the real challenge!!!!

I am still thinking on the best approach (available already or otherwise) to achieve this sizing but am sure the same thought would have occured to other practitioners as well.

I remember one previous post by my colleague Sachin about the percentage fitment anomaly which again highlights the need for a sizing mechanism for package implementations and is not restricted to only fitment and/or effort estimation.

In this context, I do look forward to hearing back in case you come across any such methodology which is able to address these challenges.