A Few Quick Links – 12/18/08

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 a few items I found interesting and wanted to pass on.

• Using a WIKI for Requirements Management. Ever thought of using a wiki as your requirements management tool? I hadn’t until I read this article, but I have been very interested in the recent emphasis we’re seeing on collaboration between the business/user and solution sides of the systems development equation from a processes and tools perspective. The focus on collaboration is just the point that  author Oscar Berg emphasizes:

[I]t seems reasonable that a wiki could increase stakeholder participation in the requirements management process. With a wiki, it will be easier for team members and stakeholders to access and find information. For novice users of versioning systems, it is often problematic to access and find the information. A wiki would also allow them to tag any conflicts and misunderstandings as well as incorrect, incomplete or missing requirements, and to discuss with each other on how to solve these. In addition, instead of mailing word documents to stakeholders for review, they can simply visit the wiki and read the documentation online. A wiki also provides versioning and a detailed revision history for each page (document), which is essential for managing changes of requirements. But most importantly, it is the collaborative aspect of wikis that make them interesting as tools for requirements management.

• Study: 68 percent of IT projects fail:

According to new research, success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.

• The Project Management Basics Glossary is a pretty exhaustive list of project-related terms and definitions. I found more than a few that were new to me. It’s a nice quick reference.

• Stop ‘gathering’ IT requirements! This isn’t the first critique I’ve read of the notion of “gathering requirements.” Part of me wants to say it’s just a whiny game of semantics, but at the same time, I think author Paul Glen has a valid point in that requirements elicitation isn’t the passive activity that some might make it out to be. If done right, it is actually pretty hard work. Here’s a teaser to get you started, but do go read the rest.

The problem with gathering requirements is right there in the word gathering. What images does it conjure? For me, it’s an image of a harvest, of a group of people standing among endless rows of vines picking ripened grapes and carefully placing the bunches in a bin. For others, it might be an image of a child collecting seashells on the beach or of a group of people huddled together at a town meeting. What’s common in all these images of gathering is that there’s something out there to be collected, like crops, shells, or people, and that those things are already whole and complete.

So if we’re gathering requirements, we assume that they must be out there, ready to be assembled like a roll of coins. Our problem is finding and selecting the right ones. [....]

Of course, this is ridiculous. Requirements don’t exist out in the ether just waiting to be discovered. They aren’t out there whole and finished. Clients and users aren’t playing an expensive game of hide-and-seek with us. Usually, the clients’ pockets are empty. Most of the time, they don’t exactly know what they require. And even if they do, it’s in the form of incomplete and inconsistent ideas that can be only partially articulated. Projects rarely start out with clear objectives or requirements; they begin in confusion and ambiguity.