Note: Please understand that you won’t find what I say here in any Microsoft documentation, and this should not be construed as having anything to do with Microsoft’s online documentation. The approaches and lessons given here are things that I have learned while out in the field through trial and fire.

Once expectations are wrong it is nearly impossible for the existing implementer to correct them because credibility is destroyed. Therefore, take the beginning period seriously. While I’ve had rare exceptions, most clients will appreciate realistic expectations upfront and will often encourage you to do so if you give them something that they can use and understand with reason while eventually being able to repeat the process on their own – like functional points.

So, let’s go through the rules of using Estimations and functional points:

1. Never give an absolute estimate without gathering requirements.
   

   There are two inherent problems when it comes to estimates. Let’s deal with the first one here. Iit is well known that people often don’t know what they want until application development is well on its way. Good requirements reduce this but don’t eliminate it. However, there is no way around it, practically all good functional and technical processes assume a good requirements gathering phase. When that goes to hell, as it often does in sickly projects, the results are always bad – late projects at the least, failure of the entire ERP system at the worst.

   Instead of getting people in trouble with bad estimates that look deceptive, provide them with confidence factors. Here is a classic example from a real life estimate that I gave a client.

So, my client had asked how long it would take for me to fix a bunch of code and functional errors in the Project Module – fair enough question. The problem is that I really didn’t know what was broken, how it was customized, or exactly what the client wanted me to fix. From experience, I can tell you that one fix for an organization can be completely wrong for another organization in AX. So, never make the mistake of assuming that just because you fixed or developed something one time for someone in AX, it will be exactly the same process. I asked the client to give me 3 days to perform an initial quick analysis where I read through as much documentation as possible on the custom changes and decisions that went into that implementation. The requirements phase for fixing issues is a little different than the requirements phase for developing software from scratch. I was able to determine 6 issues and get user sign-off on them – each of them completely undocumented, and never mentioned anywhere on the .net, so I knew they wouldn’t be easy to solve.

However, having fixed strange errors before, I had a good feeling on how to estimate, understanding that this was an initial ball park figure, I provided the client with an estimate on April 13^th where I explained that I had 50% confidence that the fixes could be done by June 13^th, 75% by June 20^th, and 95% by July 7^th. I produced an external document of my findings with concise, high-level bullet-points explaining (at a high level) risks and issues. With the backing documentation, my client accepted it, understanding that we would enter into a more intense requirements phase and provide another estimate from there. That is what I wanted – we were following a well-defined, overwhelmingly recommended process for implementing an ERP system and not something without structure.

1. Never ever, ever, ever shortchange the requirements gathering process
   

   The following table will show you the expected time for requirements

There are a few exceptions to this as with any rule, but for the most part, if this amount of time is not being spent gathering requirements during projects, something is wrong. You will notice other stages having serious issues. Gathering requirements isn’t easy, but here is the thing. With development, there is always a level of uncertainty with the fact that a solution may never be figured out or what it will take to figure it out. With requirement gathering, there are well defined processes and templates. This doesn’t say that it doesn’t have it’s own issues – politics of an organization being the biggest one. I’m just saying that there are well-defined ways to go about the process and estimate that phase of the project.

1. There are many ways to calculate functional points. Find one that you like, and then use it.
   

   It’s very important to understand that functional points are absolutely important and a good practice, but I wrote a simplified example. However, if you like them, let me give you some other helpful places to go. Here is an example of a wonderful one in the screenshot below.

   

   Now, let me give you some links:

   IFPUG – International Function Point Users Group

   Excellent tutorial but dont know how long it will be up

   Function Point Counting Practices Manual

   Function points for erp systems. You can down this article by googling it for free. It is very famous.

2. Know that good developers will usually provide estimations that are 33% underestimated and count on needing multiple estimates
   

   Studies show that developers are usually off by at least 33% on individual top of the head estimates, which is why it is good to use something like functional points. But please understand, that being inaccurate on an estimation is normal. It’s when people make mission critical assumptions based on estimates that things get bad. An estimate should not be a guarantee. In fact, good software engineering doesn’t focus on eliminating the need to do a re-estimate. It recognizes that estimates will need to be redone. The idea is to try to cut them down. On some projects, you may only need to do a revision 3 times – that would be considered a big success. In other projects, you may have 8 estimates. But what I am saying here is that professional methods like function points, leaving top of the head estimations out of the equation, and understanding how to range technical work is key to being successful.

3. No matter how good your knowledge or methods are, they mean nothing without client buy-in
   

   Getting away from idealistic sales talk. Let me tell you. Dynamics AX is a top of the line ERP system, but no implementation can be successful without client buy-in. Like every experienced AX practitioner, I’ve learned that the hard way. In my entire time of practice, I’ve only had one assignment where the client just refused to implement best practices. Why companies would be willing to spend millions of dollars on a system and not want to learn sound best practices for implementing it is beyond me, but it happens. Those results never end well, and I’ve learned that there is nothing you can do except leave the project. Usually, those organizations will have a change of mind after wasting large sums of money. Sometimes, they go to the extreme of completely failing on the implementation. Thankfully, this isn’t a situation that you will run into that often. Most people will learn to embrace the sort of structure that good, no-nonsense, non-sales fluff, approaches provide and build solid implementations. Trust me, I know. I walk into many projects that are considered ‘disaster’/’horror’ stories, and I often see people welcome best practices once they learn how to do them and understand why they are important.

   So, just my two cents.. Functional points aren’t a magic way to implement AX in two months, but they are sound fundamentals that get you where you need to be, following high probabilities of success. Please read on them more if you found this series helpful. Till Later!