• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Just the Docs, Ma’am!

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.

2 Responses to Just the Docs, Ma’am!

  1. Jeff December 10, 2015 at 10:39 am #

    I am curious about the request to deliver requirements documentation after the system has been delivered… Would you not then just want “as built” information. Requirements are arguably intent versus reality anyway… and, having the system now, why not just document that. In my mind, it should be easy to create… The implementers should have some idea what was built, how it works, and what problems it was solving(?) (Crossing my fingers)

    I would consider offering two views – system implementation and user view – and then both baseline realities are represented for viewing and for future changes. The customer or sponsor gets to see what they GOT versus what might have been REQUESTED. If its been delivered, the intent seems superfluous… unless I am missing something. Then again, it was not made clear why a requirements doc would even be useful – typically a transient document aimed at specifying what we HOPE to implement.

    But maybe the docs demanded were for some need (compliance?) that I do not understand.

  2. Geraldine December 11, 2015 at 1:41 pm #

    Jeff is correct, we weren’t really delivering ‘requirements’ on this project. We were chasing down and documenting existing processes for sending and receiving files with various partner organizations. This documentation wasn’t required for compliance – the driving factors were shortening the amount of time it took for IT resources to respond to problems and ensuring that future software development projects had the documentation they needed to avoid disrupting existing process.

    The challenge to estimating this type of documentation was that it was outside of our normal ‘documentation as part of a software development project’ process. So when we started, we weren’t sure what format or level of detail would be needed in order to meet the client’s needs.

Leave a Reply

Your email address will not be published. Required fields are marked *