Estimating the Effort of Documenting an As-Is Process

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.

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 Experience – Context 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.