Estimating the Effort of Documenting an As-Is Process

Question Mark Dominoes

Estimating the gathering of requirements is hard. Not as hard as scheduling innovation, but easier than estimating implementation effort. One step in gathering requirements is often the documentation of the “as-is” process – how things exist today. We provide a framework for building those estimates – making the job a little bit easier.

As-Is Process Documentation

There are many methods of eliciting requirements. Different types of projects will use different methods of gathering the requirements. When working on migration projects where an existing system or process is being replaced, a good approach is to start by documenting the as-is process. This documentation provides a starting point for defining what will change. This approach has the added benefit of making it very easy to crisply define scope for the project.

The as-is process is a simple as it sounds – it is a documentation of the existing steps that a business or individual takes in order to achieve an objective. An as-is process is usually documented as a series of steps and decisions. A great way to do that is with a diagram of the process combined with supporting prose.

One benefit of using the combination of flow and prose is that the documents can be used to target communication about the process at either a high or low level, as needed. By “talking to” the flow diagram, we can ask questions or make statements about the process while “waving your hands at” the details. This allows us (later in the process) to elicit requirements about the big picture, and overall goals. We still have the supporting documentation to provide the detailed information when we need it. People who don’t think about what they do as “processes” – and many don’t – can still easily follow along a diagram, and nod their heads in understanding as you manage a discussion about the process.

Approach To Estimation

When we’re planning to use as-is process documentation as part of our requirements definition process, we need to be able to estimate how much time and effort will be spent documenting the “as-is” world. In NeverNeverLand, our client would already have as-is process documents that were detailed and accurate. Most contracts these days are in StarkRealityLand, where our client has out of date, incomplete, and inaccurate documentation, if he has it at all. Therefore, we have to estimate how long it will take to create it.

Our approach to estimation is to decompose our documentation effort into its constituent steps, estimate the time for each step, and add it up. While we’re doing that, we will also identify the people who will be involved in each step and define the scope of the process to be documented.

Process Scope

Each process should be defined as the work required to achieve a particular objective. The size of the objective does matter – we want an objective that takes between 6 and 12 hours of analyst time to estimate. This is a circular reference, but one easily resolved. If, after completing the estimation effort for the process, you find that it take 20 hours to document, then the process is “too big” and needs to be decomposed into two or more smaller processes. Some example processes could be

  • Hire a new salaried employee
  • Send out monthly invoices to customers
  • Rebalance investment portfolio

Decomposing Elicitation

It would be fantastic if requirements elicitation followed the following formula:

  1. Interview Expert
  2. Record Information
  3. Distribute Information

But it never does. Our experience has been that the following steps are more realistic:

  1. Initial interview of subject matter expert (SME).
  2. Create draft document (diagram of flow + documented prose).
  3. Review draft document (expect 25% to 50% changes).
  4. Revise document.
  5. Review document (expect 5% to 25% changes).
  6. “Final” revision of document.
  7. Approval / signoff process (varies with client).

If the process is “right sized”, the time estimates should look like the following:

  1. Initial SME interview – 90 minutes
  2. Create Document – 120 minutes
  3. Review Document – 60 minutes
  4. Revise Document – 60 minutes
  5. Review Document – 60 minutes
  6. Revise Document – 30 minutes
  7. Approval Process – 30 minutes

Total time – 7.5 hours.

wrong size pants

One Size Does NOT Fit All

Every team, and every process is a little different. There are factors that you need to consider to adjust the previous estimates. Here are some common things to consider:

  • BA Experience Level – Less experience increases the likelihood of having an additional unplanned iteration. It also means that interviews and reviews might take longer – because staying on-topic may be harder.
  • BA Domain ExperienceContext is everything. Without the ability to ask relevant follow-up questions, rework is likely to go up. Interview time may also be increased in order to gain an understanding of the domain on-the-fly. And documentation time can go up, as explicit time “thinking about the problem” may be required, beyond the implicit time spent thinking while doing (an important senior BA skill).
  • SME Expertise – Some SMEs are people who “do the job everyday” while others are people who understand the relevance of each step of the job. The more of a “doer” a SME is, the more rework we can expect in the first review. Also – the first review must have an actual expert even if the SME isn’t an expert. This may mean extra work for the business owner. Without this understanding, we can’t hope to write complete documents.
  • BA Skill – Work isn’t just about experience, it is also about aptitude. A BA who can ask good “assimilation questions”, write unambiguous prose, diagram with clarity, control a review meeting, and navigate signoff will meet their time estimates. One who can’t will add time wherever skills are lacking.
  • Business Owner Self-Awareness – Some business process owners (people who approve documentation and are responsible for the existing process) do not think in terms of processes. They may be following an ad hoc process today, and may not have rigid processes. Worse yet, there may be multiple owners, who disagree with the each other and/or the SME about what the process really is. These rudderless ships will increase rework, possibly add a review-revise cycle, and can extend meeting times.
  • Interdependent Processes – Most enterprise software projects will have a dozen to a hundred business processes (at the right size) that are being affected by the migration to the new solution. When these processes are highly entangled (calling each other, referencing each other, and relying on or deferring to each other), extra time may be required to validate the touch-points between each pair of processes. This time should be captured in the steps that involve updating the documents.

Participants

Generally, there are three roles being played in the documentation of an as-is process.

  • SME – Subject Matter Expert. Someone with intimate familiarity with the steps of the process – ideally, but uncommonly, someone who understands the relevance of, underlying requirement of, frequency and cost of each step in the process. Participates in the initial interview and the first review (making the first review also an active listening exercise).
  • Business Owner. Person responsible for the execution of the process being documented. Usually the person responsible for approving that the process has been documented correctly. Participates in both reviews and in the approval process.
  • BA – Business Analyst. Person documenting the process, as a precursor to requirements definition and gap analysis. Participates in every step of the process.

Summary

A process should take between 6 and 12 hours of BA time to complete. Roughly half as much time will be spent by SME/reviewers. Basically “an hour of doc for every hour of talk.” The skills and perspective of the team can affect the time estimates too. Rolling up low-level estimates will provide for good estimates at the start of a project – better than top-down, order-of-magnitude estimates based on a shallow analysis of the area to be documented.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

9 thoughts on “Estimating the Effort of Documenting an As-Is Process

  1. I believe an essential step is to observe, first-hand, the processes you’re documenting. If you can actually participate in the process, it’s even better. Insist that your client let you do some ethnographic research.

    Unfortunately, too many companies are looking for a glorified documentation specialist, not a true product manager or requirements analyst. In such cases, the SME gets to do the most important part of your job.

  2. Great point Roger. Shadowing is a great elicitation technique. When we have time available in the schedule (we often are faced with a top-down scope/deadline in advance of doing a bottoms-up estimate), we should definitely take advantage of it. This is especially helpful when we lack domain expertise.

    I would classify this as part of the “Initial SME Interview”, and add time to allow for it – as the benefit is not just observation but asking the questions that are prompted by the SME’s actions. To estimate, double or triple the amount of time the SME would spend doing the process if you weren’t interrupting her.

    Collecting artifacts from the process helps also (generated reports, screenshots, working documents (excel spreadsheets), generated correspondence, documented procedures, training manuals, etc).

  3. Hey thanks, Bruce, and welcome aboard!

    Folks should check out Bruce’s blog – BPMS Watch – he knows a whole lot more about BPM (and BPMN) than we do – one of the folks we’re trying to learn from.

  4. Good stuff. I particularly liked the “One Size Does NOT Fit All” points. I also agree with Roger’s suggestion of conducting contextual interviews. I’ve found them to be immensely valuable, more so when I had limited prior exposure to the domain being studied or when the process holder could not spare enough time away from desk for me (like in a contact center).

  5. I agree with you Roger, I’ve worked on various projects and found shadowing to be an excellent method of capturing exactly what is happening rather than someone’s interpretation of what they think Top Down’s expectations are for the project. It avoids the ‘true’ objectives from veering into scope creep.

  6. This is very powerful… In my experience of process documentation for Global off shoring operations, I have found four major keys to successful process documentation – assessing the right quality level of documentation for the purpose on hand, estimating the effort to do so, right training to the Process Analyst to interview and document, and getting the client’s sign off! You have admirably captured the ‘process’ of process documentation… Do share more insights on key 1 – to determine the right quality level of documentation.

    1. Thanks, Ravi!

      For me, it comes down to understanding the level of expertise (in the craft) and experience (in the domain) which the consumers of the documentation have. That determines when additional information (or documentation, or clarity of documentation) is required. Ultimately it is having an appropriate level of trust in the team, based on knowing which decisions the team has the capability to make on their own, and then providing guidance to the folks documenting the process.

      Always err on the side of “too much”, because the added cost of too much documentation is far lower than the added cost of building the wrong thing (and then fixing it) because there was not sufficient shared understanding of what needed to be done.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.