ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 10
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Tom Marshello on the RapidStart Tool:
I am working with the RapidStart tool trying to import customers into a database. I am getting an error when I try to apply the data. The error is: “The Master File Setup Defaults does not exist. Identification fields and values: Primary=” Other master records imported and applied just fine. My internet search came up short and searching for “Master File” in NAV comes up with nothing relevant. Anyone have any ideas?
Tom Marshello followed up with: Figured out the issue. There is a setup table called “Defaults Setup” found under /Departments/Administration/Application Setup/Financial Management/Finance. This needs to be opened once to initialize it even if you do not fill in any fields. Once opened, import works fine.
Dan Sass shared a link about the advantages of agile software development:
What Every Company Should Know About Agile Software Development
Dan Sass shared a blog article from MSDN on the Microsoft Dynamics NAV Application Profiler:
Introducing the Microsoft Dynamics NAV Application Profiler
https://blogs.msdn.com/b/nav/archive/2014/07/04/introducing-the-microsoft-dynamics-nav-application-profiler.aspx
From the article: “Did you ever wish you could monitor how your application code performs at real time? We have produced a sample and a video that can help you get started with C/AL tracing and application performance profiling.”
Alan Campbell on Three Point Estimation for projects:
Three Point Estimation Revisited:
A range estimate is where there is a Low and a High estimate. The Mean would be right in the middle between the two.
The three point estimate is different from a range estimate in that it has an optimistic estimate, a pessimistic estimate and a most-likely estimate. Each estimate is derived differently and can stand on its own.
Here is how you should think about deriving the three estimates:
Optimistic – this is the best case scenario. The code meets the requirements the very first time. There are little or no meetings to further define the solution. The client is easy to work with and has their act together. You deliver it and the client says “perfect”.
Pessimistic – This is a worst-case scenario. The code keeps coming back to you again and again because it does not meet the requirements. You are forced to go back and have meeting after meeting on the code. The client keeps giving you the run around in terms of conditions of satisfaction, or only gives you a piece of the puzzle one bit at a time. The client tells other people instead of you that your code is not good, which ultimately causes further meetings and discussions. You deliver the code and the client says “what were you thinking?”
Most-Likely – This is where the actual effort will probably end up. Just right.
I think more estimates should look like this:
Optimistic = 10 hours
Most-Likely = 15 hours
Pessimistic = 35 hours
In the majority of cases the Most-likely should NOT be smack in the middle between the Optimistic and Pessimistic estimates. My opinion is when things go wrong, then they really wrong. I think it makes more sense to see more estimates where the Pessimistic estimate is larger.
Cf: http://www.pmdocuments.com/2012/09/17/pert-three-point-estimation-technique/
Cf: http://www.agile-code.com/blog/easy-task-estimation-with-three-point-estimation-technique/
Alan Campbell on CPI:
CPI: CPI (Cost Performance Index) helps clients understand the status of the project. CPI is a measure of the value of work completed compared to the actual cost or progress made on the project. CPI is considered the most critical EVM (Earned Value Management) metric and measures the cost efficiency for the work completed.
For clients, reading CPI is simple and straight forward. A CPI value less than 1.0 indicates a cost overrun for work completed; a bad thing. A CPI value greater than 1.0 indicates a cost under-run of performance to date; a good thing.
The CPI is equal to the ratio of the EV (Earned Value) to the AC (Actual Cost); CPI = EV/AC. In the world of Agile Scrum, value is earned when stories are accepted by the product owner. The story points assigned to the user story completed are the basis for the EV. The AC is taken right out of the APNAV job.
CPI is like the speedometer on your car. The speedometer in your car tells you how fast you are going. The CPI in a project tells you how you are doing regarding the project budget.