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.