Call it Agile, Iterative, or whatever you like. There are a lot of good things about utilizing an aggressive development approach, such as producing tangible results quicker, and proving – or disproving – concepts. In fact, I employed such an iterative approach myself when managing the developing the LoanQuotes.com website…

First we launched with a set of single forms for collecting mortgage leads. It worked and stood alone. Next we launched a blog and added some content articles. Afterward we tweaked the structure. Again, it worked as it was supposed to. Next we added the presenting of insurance leads and a quick lender finder. This turned out to be a lot more complicated than we had thought and took more time. However, the prior-standing functionality continued to work properly.

But, if we had used a traditional big bang (”waterfall”) approach, all of the functionality that worked with the Agile method would have instead been sitting on the shelf so to speak while we worked through difficulties with the insurance quotation part. One of the realities about Agile is that you produce less in terms of requirements documentation. Instead, you use mockups and prototypes. This gives you faster turn around in terms of development and feedback. Who needs all that requirements documentation anyway? Nobody, right? After all, LoanQuotes.com came out just fine, didn’t it?!

Well, let me tell you who needs that documentation. It is the large enterprise doing a major integration or any kind of replatform (among possible others). Consider this…

Example 1: Major telco. They called the project “4/23″.  But they should have named it “4/23 + six months”.

When I showed up on the job with another esteemed BA colleague, we were told not to bother the developers because they were “too busy”. I jest not! Imagine that; the Business Analysts supposedly brought in to do the requirements documentation were instructed by the PM in the politically-charged IT departmental fiefdom to not go to the building where the business owners and the developers were meeting.

The developers were designing and coding while the product managers sat in their cubicles dictating. April 23 came and went with no mention. Then May 23rd passed. Nobody said anything other than using the words “seven twenty-three” as if that had always been the case. The emperor does have clothes on, gosh darn it!

By this time it was pretty hard for my BA buddy and I to pretend we were staying busy or adding value – though we were serving the purpose of the powers that be in the capacity of being legitimately-required resources for a properly managed project. However, in this case we were not being properly utilized in a project that was not being properly managed.

Word on the street was that there was some sort of problem with there not being adequate requirements documentation. Nah, ya think? In the spare time of my official assignment of pretending to work, I took a little break to actually do some work. In about two hours I drafted a 3 page proposal for the BAs and SMEs to go to New York and hold requirements gathering meetings with the business owners. The goal would be to capture and document requirements. Wow, cutting edge ideas!

Expecting rejection from one of the PMs, I was a little surprised when she embraced it. I was taken aback the next morning when she and my boss (another PM) told me that it has been accepted at the VP level, and I was to quickly write up the plan to make it happen (and ultimately execute it).

Long story short (too late!), we created documentation that the business owners could approve, that the developers understood, and that accommodated design, coding, testing, and deployment. It could also be found and referred to for future initiatives and any replatforming. On the other hand, they had millions of dollars in cost overruns because they did not realize the value of good requirements documentation until it was way too late.

They weren’t the first, and they certainly aren’t the last.

Example 2: Global Software Developer. They designed a new cutting edge website and were ready to launch it. Actually they were not ready to launch it; they couldn’t.

After replatforming their architecture infrastructure, they needed to modify the code of their new super website that was currently running in their test environment so that it would work in their new production environment. Problem was that they had no [requirements] documentation on how their super website worked. The development team had rolled out or moved on to other mission-critical things.

They had tried unsuccessfully to recruit some BAs, and then later programmer analysts, to “reverse engineer” the new website. (”Reverse engineer” is a code phrase for “we did not document anything, but now we really wish-to-heck we did”).

OK, we already understand that they are not unique. It was worth a try to skip the requirements and save the money of not hiring a BA or two, right? Well, to that I ask this, how do you think that the PMO and their bosses liked explaining to the executives and the board that this little oversight amounted to the tune of $14 million? Maybe they would have been better off budgeting in some professional Business Analysts from the beginning to capture and document everything they needed to know. Instead, they got to start over somewhere in the middle.

Hopefully by now you have realized that my point is really not so much about which methodology is better than another, but rather that regardless of which one you choose, be sure to capture your requirements statements in writing along with whatever artifacts you intend to create.

By the way, in my Agile approach to developing LoanQuotes.com, I captured and documented all of my requirements without creating any burdensome requirements documents. It was quite interesting, in fact. I set up a simple forum on my private website for us to use. There was no emailing and no printing involved.

Example 3 – Hybrid: Large Manufacturing Company. A very conservative company with traditionally conservative development methods, but needed to show tangible results quickly.

In my opinion, these guys did it right, even though honestly I did get a little bored with how long the requirements were taking. (Being bored is not good for this BA, but sometimes it goes along with the job). The discipline of doing requirements right has become quite an area of focus throughout my career as a Business Analyst. Believe me, I like to go fast. Having started my own website development company (The MasterLink Goup, Inc.) and running it lean, I learned the importance of working quickly to keep the machine running. I also learned the importance of avoiding costly mistakes. These insights have also served me well in the corporate world.

In the case of this old leading manufacturer, their conservative views and approach had not gone away, but they were willing to adapt their model in order to be able to show something tangible early on. This was very important to the executive sponsor since her clients and higher ups were keenly aware of what the competition was doing and wanted to know [sooner than later] if her organization was up to the challenge.

As always, I began by identifying the business process areas of the organization, and then relating the desired functionality to those process areas. After segregating the functionality into development modules, the requirements gathering began. Fortunately for me I joined in at a very early stage. That way I did not inherit someone else’s notes that I had to try to interpret.

We were a small project team, and we operated with great agility indeed. But unlike the other scenarios, we had a very complete documentation set to support the requirements. And, we were able to demo certain functionality early on that impressed the clients and executives. This kept them supportive and on board.

So finally and in conclusion, as the risk of possibly restating something in redundancy maybe by saying it again and again and again, I do hereby claim and proclaim that regardless of the methodology chosen, you can and should still commit to capturing and documenting good and complete requirements (see my writeup on “requirements statements”).