Nimble Analysis

The Business Analysis Body of Knowledge (BABOK) lays out great strategies for eliciting and documenting requirements. To keep our own software projects on track, at NimbleUser we work toward five core milestones: Charter, Survey, Plan, Specify, and Correct.

Charter

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?”

Before beginning any project, the first step should be to pull together a proposed budget and adopt a project charter. The budget doesn’t have to be accurate, but it does need to indicate the magnitude of what we are setting out to do. What are the key objectives? How much might achieving each of those objectives cost? What is the total project investment, from requirements to implementation through deployment? The initial budget only needs to be a ballpark estimate that we can refine through analysis.

The project charter lays out the decision making process, and the overall analysis and implementation workflow. It calls out the participant roles and responsibilities, and clarifies expectations, so that we can keep the project on track and on budget.

Survey

“The only stupid question is the one you don’t ask”.

A simple stakeholder survey is a great way to kickoff a project. Depending on the circumstances, participants can work on the survey independently, or you can step through the questions at a meeting. Ideally, do we both. We provide the survey to participants in advance of a review meeting, and then we walk through the responses, to elicit any missing detail, and to discuss any “interesting” points. A survey document is also a great place to capture any unexpected material. If one question leads to another, we edit the survey (then and there) to capture new details.

If meeting remotely, we use a service like GotoMeeting to collaborate on the document in real time, or use a realtime sharing environment like Google Docs.

Plan

Sage advice is to never hold a meeting without an agenda, and to never kick-off a project without a plan.

Based on the preliminary proposal and detail elicited in the survey, a great next step is to outline the project, mapping business goals to the actual materials and services to be delivered. Then, using the preliminary proposal as a baseline, we separate the original items from any that were added or subtracted during the survey talks, or other discussions, so everyone can see how the scope is changing.

As with the survey, we like to present and review the outline using GotoMeeting or another collaboration environment, making realtime updates to the document during the review. The take away is to stay nimble by avoiding intermediary forms. To keep the outline clean, leave the gritty details in the survey document. It’s a good idea to reference the survey from the outline, so everyone knows it exists, but it’s not a good idea to dump minutia into the outline.

The outline should be a high-level treatment without implementation detail. A good analogy is a book proposal. Before chapter one is ever written, a publisher will want to see an outline of the entire book. Later, when the book is approved, and all the chapters in the outline are written, proofed, and typeset, then we know the book is done!

Following common practice, it’s a good idea to embed the outline in a high-level business plan document. (We call ours the “Discovery” document.) Since the plan lays out the key deliverables, we can use it to better estimate the size and cost of the project. Later, the items in the outline become tasks in a project plan, or stories in a scrum backlog.

Specify

Depending on the nature of the project, the next step is to develop a technical specification, or to work directly on the client’s system or development system.

If we are building a conventional web site, a low-level specification is needed to be sure we understand how all the pages work, and how they work together. A great way to keep a web site specification more interesting and collaborative is to use one of the new cloud-based wireframing tools, like ProtoShare or MockFlow.

If we are working with a turnkey system, like iMIS Public Views, we may walk through configuring the software interactively, rather than create a (mostly redundant) formal specification. Likewise, for a complete but customizable platform, like Salesforce, we may setup a project “jumpstart” and collaborate on the system configuration and customizations, live and direct.

Correct

It’s been said that “change is the only constant”. No matter how well we plan and specify a project, changes will occur during the implementation and even after the initial launch. When changes occur, we update the system specification. If we documented a feature in one way, but after testing, implemented it another way, then we correct the specification to reflect what happened. If a document is worth creating, we find it’s worth maintaining.

Collaborate

While not a milestone, a first, best practice is to setup an extranet site where stakeholders can collaborate on the project. Popular platforms for collaborative sites include ShareProint, Google Apps, BaseCamp, Office Online, and Open Atrium. All of these platforms make it easy to share and exchange documents and messages throughout the course of a project.

Regardless of what other BABOK techniques we use in a requirements project, we find that if we include these five milestones – Charter, Survey, Plan, Specify, and Correct – we’re well on the way to a successful launch.

-Ted.