Share This Post

Have you ever worked on a project where you were tasked to create documentation after the fact? Have you needed to span that bridge between business analyst and technical writer? I’ve done a couple of these, and the challenge I’ve had each time was effectively estimating the work involved. Many traditional business analysis estimating techniques and tools assume that the BA’s work is part of a software development project and base estimating assumptions on the type and size of the development effort. For a documentation-only project these projected assumptions can require a lot of tweaking or be just plain useless.

For a recent documentation project, we went through a multi-step process to determine the scope and estimate the work that would be involved. Because it’s an excuse to make a process flow, here it is:estimation flow

Around steps 7 and 8 is where we figured out that we had a problem, because our initial estimate was about twice as big as our budget. We realized our initial plan was probably a bit “pie in the sky.” We identified some possible cuts, but we couldn’t refine the plan with getting better direction on priorities from the project sponsor. Luckily, our sponsor was a down-to-earth person with realistic expectations, so the negotiation and modification of the plan went pretty smoothly. Although we’d like to be able to create a visual model for each report we are documenting, we can achieve our initial goals without doing that.

If your estimating process gets bogged down and the negotiation isn’t as easy as ours was, you might need to step back to look at the goals and ensure those are realistic and clear. In our case, we had the simple situation of a lot of knowledge in the heads of contract team members that needed to be elicited and documented well enough that new team members and others within the organization could find the basic information needed to prevent future process and software development errors. Understanding this allowed our team to focus on the key documentation deliverables that would meet that goal and cut extraneous activities.

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.