Deliverable vs. Consumable

What's the Deliverable you expect? What's are the deliverables of this process? Should I document this in some form of deliverable? These have been some the questions that others have asked me or I have asked myself for as long as I have worked. The common theme across these questions is the word deliverable. Software development process has come to a state where more and more professionals are now starting to appreciate that it is the end product (working software) that matters the most. The tools we use to get there are definitely important but the documentation is only valuable as long it is reflects the the current state of understanding and is used during software development by the people who are actually developing the software. This realization has prompted the industry to start using practices that are lightweight and produce working software in smaller and frequent cycles. Companies like ThoughtWorks (www.thoughtworks.com) are leaders in this space and are busy innovating the methodologies of business analysis and software development to fundamentally shorten the lifecycle of value delivery using software. As a big fan of these lightweight but agile practices that ThoughtWorks has been a pioneer of, I try to follow them as much as possible and have been very successful at it. It's a mindset that's a little revolutionary because of its simplicity but sometimes makes people a little uncomfortable in the beginning due to its pace, flexibility, discipline, and decentralization. This approach has crafted out a set of practices and methods that are collectively, and quite aptly, know as the Agile methods. As eluded to earlier, one of the characteristics of these Agile methods is to be lightweight - do only what is necessary. This is a hard thing to do, or at least at the start. As an Analyst my instincts tell me to transfer all I know about the client, processes, and problems in as much detail as I can. They also tell me to document these so that it's not just in my head and other people can have access to it at their leisure. This is, however, an activity that is not as productive as it may seem to for very many reasons. Top three of these are:

• Time/Effort - It takes a lot of time and effort to document it all out,
• Life Span - In today's world, things change at a fast pace and hence the docs may become obsolete very quickly, and
• Attention - Very few people have time to read the docs. The attitude generally is, "Why don't you tell it to me, rather than have me read all this."

Every deliverable that I am responsible for has to go through this filter of Time/Effort, Life Span, and Attention. This saves me a lot of time, which I can then invest in understanding the domain of my client, building relationships, sharing ideas, and solving problems, etc. This is the first stage of getting lightweight. The second is to keep the necessary document just long enough to provide relevant details. I don't write epics anymore. That's where, typically, stagnation hits. This is where I have felt choked a lot of times before, failing to improve the effectiveness and agility any further. Recently, I met a gentleman from ThoughtWorks, Inc. who has taken a different view on the whole value chain. Instead of looking at it from the push perspective he looks at it from pull perspective. What that means is that produce only what is required and when it is required. Think of yourself not as being responsible for a deliverable, but being responsible for a consumable. Not only does it keep the process lightweight, it also prevents it from being outdated.

Importance of a Business Case

In one of the previous notes I had briefly talked about a Business Case. Its importance is, however, surpassed by only a working piece of software that delivers the intended business value. As a Business Analyst in my earlier days I had seldom cared about asking for and reading the business case for any of my projects. I guess, it was always very "obvious" to me that there's got to be a good enough reason for undertaking this project that I have been asked to contribute to. Any chaos on the project, which is not unusual a lot of times, never ever made me wonder if things were in place at the helm; they always seemed to be. I always trusted the leadership and was just too impressed by the techniques that some of these leaders used to run these projects. But, slowly with time this made me realize one things - there's something that sets the tone of the things to come right from the onset and governs the confidence and direction with which the team moves ahead. It's the Business Case. There is not a single set-in-stone format of this document. Still, it should answer the following questions for the reader:

• What's the problem?
• What's the budget?
• What are the timelines?
• What are the perceived benefits?
• When will we consider these benefits to be achieved?
• Who are the key people involved and what are their responsibilities and role in the proposed project?

Some of the benefits of a business case is that it:

• Helps to remind the team of what valuable and what's not and brings them back from any digressions.
• Helps to sustain the morale of the team members.
• It keeps the possibility of scope creep to a minimum.

A business case is a vision document that outlines the final goal, an inspiration to undertake the project, which is often expressed as a problem statement. It's one piece of document that, for the reasons stated above, every team member regardless of their experience, age, and tenure should have access to and handed out as the first document. Ask for it!