If I had to go back, past all the lessons learned (many courtesy of the school of hard knocks), the most precious one was learning how to give realistic timelines for estimated work. Most projects fail because inaccurate estimations were made in the early stages resulting in wrongful assumptions. After that, schedule pressure sets in and then everything goes to hell. In this series, I’ll share the process that I go through to give estimations, which uses a modified version of the 1984 IBM Method for ERP systems. In part 1, we’ll start slow defining things. In part 2, we really get busy and see how to make a real-life estimate calculation. In other words, don’t be fooled. In this series, you will learn how to utilize a formula for real-world AX estimations. I recommend studying the first post hard.
Disclaimer: There is no such thing as a 100% full proof estimation process. But it is has been proven over time that it is far better to use a proven method or expensive software than to give an estimation off the top of someone’s head. Functional points have withstood the test of time and are the most commonly used methods for software estimation.
So, before we begin, I’m going to introduce you to the terms for this method with one twist. Because I don’t like big words, I’m going to translate 1970’s computer terms into modern day language that a person like me could even understand.
Now, what really confuses people about this method are all of those 70’s terms, so let’s make a table where we define everything and use Brandon’s terms.
Brandon’s made up Term | Old 70’s Term | Simplified Definition |
Form Fields | Inputs | Number of places in a form that a person can type in which get saved to a database |
Read only message screens or forms | Outputs | Reports, screens, graphs, or messages that show stuff and that you can’t directly input information in. |
Database queries | Inquiries | Number of database queries used to produce information |
Tables within AX used | Logical Internal Files | # of dynamics AX database tables in use for development task |
External data sources | External Interface Files | # of external sources used such as services, files, other databases |
None – current term is recent | Business Rules | Functional configurations that really make an ERP system |
The first 5 terms are used just about everywhere and extremely popular. But the 6th rule is what really makes the system adaptable for Dynamics AX, Falfernig and Salbrechter introduced this to take into account the complexity of ERP systems. I run into developers all the time who start looking over the code and noticing common things like “case” statements and what not, thinking that it will be easy to develop in AX. That isn’t where the difficulty lies for AX. What makes ERP estimation so hard is the complexity associated with dealing with an integrated system – functional configurations, business processes, ect. The 6th category, Business Rules, takes that into account.
In Part 2, we will actually see how to use the terms to produce a formula which will give us an exact estimate of hours and time for completing our Sample Dynamics AX task. Later, we will learn how to apply best practices for realistic estimations. Till later!!