ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 2
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.
Read all our ArcherPoint Developer Digest blogs.
Rita DeVrieze on identifying which users are assigned a particular permission set:
A report from Table 2000000053 Access Control will give you a record per user per Role ID.
Alan Campbell on project success shared the following, taken from an article in BusinessAnalystTimes, Three BA Metrics You Should Be Tracking:
When I ask leaders of PMO offices what percent of their projects are successful, they typically reply with an answer of between 80-90 percent. When I ask the business sponsors the same question, time and time again I hear that only 20-30 percent of their projects are successful. Funny, isn’t it?
PMO: 80%-90% of our projects are successful
Business Sponsors: 20%-30% of our projects are successful
So, I ask how they measure it.
PMOs often measure by cost and schedule.
Business sponsors measure by, “Did I get the value I expected based on the money I paid?” or, “Was the project worth doing—is my life better?”
The BA’s primary job is to identify and protect the sponsor’s value proposition, so the success metric needs to be driven by the sponsor’s perception of value. It’s critical to the requirements and BA role.
Alan Campbell, on agile project management, shared this article from Jack Notarangelo’s Application Engineering Blog about Watts Humphrey’s Requirements Uncertainty Principle, considered a cornerstone of Agile’s approach to defining system requirements:
This creative design process is complicated by the generally poor status of most requirements descriptions. This is not because the users or the system’s designers are incompetent but because of what I call the requirements uncertainty principle:
For a new software system, the requirements will not be completely known until after the users have used it.
The true role of design is thus to create a workable solution to an ill-defined problem. While there is no procedural way to address this task, it is important to establish a rigorous and explicit design process that can identify and help to resolve the requirements uncertainties as early in the developmental process as possible.
Alan Campbell, on the Waterfall model for software development and its “creator”, Winston Royce:
The Waterfall model for software development is mistakenly attributed to Royce; in fact, he demonstrated that, while the development of large software systems required a more thorough approach, there was inherent risk in a single-pass sequential approach. He proposed an iterative and incremental approach and advocated that projects should pass through this at least twice.
Darren Atkins adds: “Fascinating paper…he actually describes an iterative method and diagrams it all out—change management, why waterfall will 100% of the time result in project overrun. I like the section titled ‘Involve the Customer.’”