Avoiding inertia and estimating how long it will take to write requirements

Back in 2007, I decided to take a couple of months off from writing on this blog. A few months stretched into a few years really easily. Once a habit is broken, it's very easy to give into inertia. I guess this is why one should aspire to never miss a workout.

Recently, I received an email from Georgia on one of my posts in which she asks, "..., I was wondering if you have any tips on how to estimate how long it will take to write requirements for a project you've been assigned to. The project is new, you know nothing about the business, how can you provide an estimate? Should you just give a high-level estimate and then adjust as you go along and see the progress?"

Why do businesses execute projects? To improve how things work, to meet regulatory and compliance requirements, to capitalize on new opportunities or avoid potential threats.

At some points in your career you'll be asked to work on projects where you have little to no expertise. Don't be discouraged however, this is how we learn. What approach should you use to estimate how long it will take you to write requirements? Here are some thoughts:

1. Decompose the project into the key basic business processes which will be impacted (e.g., billing, order entry, inventory reconciliation, campaign deployment, etc...)
2. Create a matrix using the business processes versus the different stakeholders involved - such as finance, marketing, customer service, warehousing, etc...
3. Indicate which teams are involved in which processes and which team is the ultimate owner of each process (who do you go to if you need a decision.) The more teams involved, the more potential stakeholder complexity.
4. For each process indicate how complex you feel it is. If you don't know much about the process, rely on the stakeholders and management for guidance.
5. Using the information you've gathered determine which processes have high, medium or low levels of complexity. As a rule of thumb you could say high = 10 days, medium = 5 days and low = 3 days.
   
6. Add up the total number of days and this will provide a really rough estimate.

Understand this is merely a high-level estimate and as further analysis is performed the estimate will become more precise. This is project estimation after all. At the start, you might provide an estimate with 100% contingency, however as the project starts to execute the level of contingency drops as more things become known.

One side benefit of using the matrix is it will also help you plan out your requirements gathering sessions (you know exactly who needs to be involved for each process.) Use this to secure participation from those teams and your project's sponsors.

Webinar: Bits and bites

BPM: Aligning People, Process & Technology
Monday March 26 @ 12:00pm (EST)

Join Paul Harmon, Executive Editor, BPTrends and Principal, BPTrends Associates and Roger Burlton, Founder, Process Renewal Group and Principal, BPTrends Associates, for an insightful and lively discussion about the advantages of aligning your people, processes and technology to achieve improved enterprise performance.

Deliver what the business expects
One of the webinars mentioned in a previous post has made its slides available as well as access to a 2006 IDC research white paper by Ballou.

Simple process flow diagramming - Part 2

Let's expand a little on why initial process flow diagrams should be kept simple. Answer this question, "For a process, is it more important to know what or how?" The how question can lead you down a treacherous path.

Common Problems

• Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
• Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
• We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.

To be or not to be?

Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."

Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.

To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)

In Conclusion

• You may choose a less optimal solution path (e.g., build something that can be purchased.)
• You have not used your time effectively.

These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.

Simple process flow diagramming - part 1

A picture says a 1,000 words... or so the saying goes, but do you really need 1,000 words to communicate a process? In truth, it depends.

Many times, on business analyst engagements, I've asked people to describe, in picture form, the basic processes that are important to their business. What I usually received was something that required a plotter to print... a huge, complicated process flow that took into account every single odd-ball anomally (even if it would only occur every 5th blue moon.) Why did this happen?

• Subject-matter-experts (SME) can talk ad nauseum about what they do.
• SME are detail-focused people; every detail is important to them.
• SME do not like to see their business processes trivialized into one or two little boxes on a process flow diagram.

My own learning point was to find another way of getting what I needed to know rather than ask this of the SME directly. When diagramming a high-level process flow I usually follow some basic guidelines:

1. Identify the initiator and actors of the process.
2. Be technology and system agnostic.
3. Understand what is required to move from one part of the process flow to the next.
4. Show the main process flow not the alternates.
5. Understand the goal of the process.

The time will come when more detail is needed and the process will be flushed out. But I do not feel you have to start like that. Simple and elegant always win out.