Agile Information Management

Generally on a topic so important I would spend the time to write about this in a more palatable manner - but as time is limited I am going to give you the information without couching it in a example. For that please read Dr. Kevin C. Desouza's book - "Agile Information Systems: Conceptualization, Construction, and Management" which was very helpful to me when I had already reached the same conclusions during a very high visability consulting gig. His book allowed me to defend my position definatively and objectively. (http://www.amazon.com/Agile-Information-Systems-Conceptualization-Construction/dp/0750682353)

Don't wait until you are working on a project that matters to you (read: "=$$$") to understand that we may live in a world once inhabited by dinosaurs but using old clumsy methods are not an effective way to create and scope new software projects or manage information effectively. Here's the straight dope --

Agile development models include just in time information gathering processes. Agile information gathering processes include rapid collection of content and the clear appearance of the resulting documents. Collecting technical business requirements and immediately folding them into the client template is an agile information management method in planning software requirements.



Business Analyst Teams need to capture requirements as they are clarified. This is especially important when:
1. The deliverable is the requirement document first and foremost
2. The outline for documenting incoming requirements already exists
3. Tight deadlines exists and there is any risk of delays in documentation, or in overlapping out-of-date information being presented to the client–
4. Or if the document control tool, which is commonly used for working together interactively, is flakey and as a result document versions may become dated

It is not an agile process to wait to add known requirements. For example having project management, or development directing a business analyst to wait until later to add or modify incoming requirements prior to a document presentation. It makes sense to put the correct and current requirements into the current document. It is more logical to keep found things found by categorizing them immediately. (It's a little like keeping the kitchen clean - do it right away).

1. It is a waste of time and money, searching when editing the same document repeatedly, or by different individuals, when the requirement should be added on the fly
2. It is frustrating for the BA trying to keep track of multiple versions of the same requirements, it is frustrating for the client when they read out of date requirements
3. It creates unnecessary control issues
4. It runs counter to the clients' actual needs and requests
5. It isn't agile any more, it is an outdated technique!

Presentation of business requirements is 50% of the job of development consulting, that is, what a document actually looks like really matters to governance and business people.

1. Because governance and business people spend all their time in documents, generally they want them to look familiar and be formatted correctly, so it makes sense to use their existing templates
2. They care about documentation, and delivering documentation is your value to them, in other phases they may care about the actual software project delivery or user interface
3. Your clients will never have your depth of knowledge regarding technology, which means you will have to explain your processes and reasons if you do it any other way (slowing the process down) besides using their processes and procedures
4. The business and governance or project management office people will participate in decision making about actually building the project, or not, and you want them to want to work with you, by showing that you will work with them!

When things go south in a project managed and maintained by old, confusing, out of date, clumsy methods - at least YOU will know why. And if you get really great at sniffing out these kinds of information management control issues, perhaps you can head them off at the pass, and get your posse working together effectively to collect the information you need and turn it into the requirements you need right now.