Weekly Digest – 8-17

Welcome to Practical Analyst, a site specializing in practical insight for business analysts and project professionals. If you're new here, you may want to subscribe to my RSS feed or follow me on Twitter. Thanks for stopping by!

Here are some links to interesting articles and information I’ve found during the past week.

If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not work even more than one year late (shocking!). It’s a very interesting read. Among other things, the plaintiffs refer to prototypes or mock-ups as a form of deception by demonstrating “fake software.” In any case, the moral of the author’s story is that, “even when buying a COTS system (an ERP is a big COTS), you do need the expertise of requirements engineers.”

While on the legal theme, have you heard that the State of Indiana has made use of a waterfall methodology a criminal offense?

“Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch Daniels said at a simple signing ceremony held at a meeting of the Central Indiana chapter of the Project Management Institute (PMI). “This bill will end the tyranny of big upfront planning, big upfront design, and litigation style change management.”

It’s a fun read. I actually did “LOL”. Before you go calling your whole team to your cube to tell them about it, please bear in mind that the article was, in fact, penned on April 1.

Here is an interesting take on what a “dev guy who has done app maintenance, DBA work, testing and performance analysis” wants to get from the business analyst. He is fairly detailed in describing his expectations of what delivery teams need from the BA in order for:

the developers to build the application

the DBA to understand the data model

the operations guy/gal [to understand] what kind of information they would get at run time

the testers to write their test scripts

the performance tester to determine what are their targets

the trainers to write a course on the application

the stakeholders to know what they are paying for

the BAs (both client side and your side) to understand what need[s] to be going on.

Lastly, many analysts are aware of the informative articles from IBM that describe software development and methodology, often in concert with their own software and service offerings. Here’s an informative article from IBM on creating a system specification from the user’s point of view by using UML to create a user model. The article includes lots of examples and diagrams as well as links to related information.