How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?
The Lay of the Land
Your IT director knows she needs something to give to her development and test teams. She’s looking to you to tell her what it is you need to deliver. Oh – and while it isn’t explicitly a constraint, her expectation is that you’re looking at something less than a couple of months of effort. To increase the pressure a little, she also tells you that her program will likely have a steady, ongoing need for requirements development – for now, she needs a “single capability” defined.
Her approach is really pretty rational. She’s rolling out a brand new initiative for the company. The initiative will drive tens of millions in profits for the company. There is a huge user base, there are stakeholders all over the globe, it is a “high pressure” environment – very visible internally, high external pressures, and there’s a palpable sense that continued employment is dependent on the success of the initiative.
There is an ocean of work involved in this particular initiative. Your director’s initiative needs to demonstrate momentum, so instead of boiling the ocean, she’s releasing new business capabilities incrementally. She’s working with the business stakeholders and customers to define “what first”, and then she’s working with internal teams to enable those capabilities one at a time. Each business capability is being treated as a distinct program – distinct funding, staffing, and timing. Sort of an “enterprise agile” – certainly an incremental approach.
The capability that she needs next (she has already prioritized it as “next” for the initiative) is also needed by other directors, for other initiatives. The enterprise IT folks intend to leverage the capability across many different programs and areas of the business. Each program has common and distinct needs, and different timing objectives. There are many moving parts involved in defining this capability across a multi-billion dollar enterprise.
Your mission is to figure out how best to validate your customer’s approach, identify what she needs, and estimate what it will take to make it happen – given the above environment. Do you try and boil the ocean, defining the requirements for the business capability across all the initiatives? If not, how do you define and manage deliverables for this one program?
One At A Time
There’s an interesting dynamic that comes into play when working with teams across and within an enterprise architecture. You have to think about the big picture (the ocean) in order to really understand things. At the same time, if you try to accomplish all of the needs of the disparate teams (boiling the ocean) at the same time, you will fail. Each group has its own dynamics, politics, deliverables, hangups, issues, and pet “favorite features.” If you try and tackle all of them at once, you will get mired in the bog of analysis paralysis and never make forward progress.
The best way to knock down all the dominoes in this case is to knock them down one at a time. Think of it as sequential product releases, each one targeted at a different market segment. Because that’s really what it is. As you build out a business capability (like “provide hosted service X”, or “sell products online”) for each program you are identifying a different set of internal stakeholders, end users, and often, delivery and test teams. They are independent projects that happen to share a lot of goals.
Dominoes make for a great analogy, because although you start out by knocking down the first one, you knock it towards the second one, with the intent of knocking them all down eventually. The more you understand about the other dominoes, the better a job you will do in knocking down the first one. But you have to focus on the first one first. The other knowledge provides context, and hopefully understanding that leads to insights.
Knock down the first one first.
How Much to Do?
You can approach this top-down (as we normally do with structured requirements), or bottoms-up. Either way, you end up with the same answer. We’ll work backwards in this article – since we’re identifying the deliverables, not creating them.
- Software Requirements Specification (SRS). We already know we need this – because the development and test teams at the company expect to work against an SRS. If your company uses something else to communicate requirements to development and test, substitute that artifact here.
- Fact Model and Glossary of terms. Explicit agreement about language and terms is critical to avoiding confusion and ambiguity.
- Use Cases. The requirements in the SRS are defined to support use cases and goals. So we need use cases. The team you are working with, and the complexity of the business needs / processes will influence the format that works best.
- Actor Hierarchy and Personas. You have to identify the actors by role, and the personas that describe them.
- Business Requirements Document (BRD). Describes the goals of the business stakeholders.
- Vision & Scope Document. Describe the vision for your program, and its scope. Especially valuable in avoiding ratholes in this environment – be articulate about what you are not doing. Set expectations that the second domino is second – only the first domino is first.
You can reverse this list to create a top-down set of deliverables: Vision & Scope Doc, BRD, Actor & Persona definitions, Use Cases and SRS.
And Estimating…
The devil is always in the details when it comes to estimating. How long will use cases take? How many interviews will you have to do, and do you need to travel to do them? And a hundred more questions.
We aren’t trying to tackle the estimation details here – too many project specific variables, and as I just read somewhere, “estimating is more of an art than a science.” Although you can apply some science to expose and mitigate the risks around your estimates by using PERT analysis.
But now you know what you should deliver, and what you now have to go estimate.
Added the fact model and glossary of terms to the list of deliverables. Shame on me for missing that last night. We’ve been using them on a large enterprise project and getting significant value.
I find estimating requirements work to be ‘risky business’. An overall architecture which shows how the dominoes fit together, more than the order, can help. Otherwise, I favor Time Boxes: give me 4 weeks and enough requirements will be delivered to keep your developers busy. I can’t say now what those requirements will be, but there will be requirements… but as Dennis Miller used to say “that’s just my opinion, I could be wrong”… or at least not right.
Hey Dave, thanks for commenting!
I agree with you, I definitely prefer time-boxing too.
I have an interesting sticky-wicket here, I have to do a “deliverables based SOW” – structured more like fixed-fee than T&E. In this situation, what makes the most sense to me is to time-box each deliverable against an hourly estimate that allows me to operate effectively within the terms of the SOW.
Oh – and I’m a big Dennis Miller fan too! Just wish I were knowledgeable enough to understand everything he says.
So what does an SOW for Requirements work look like? How does the Customer know that you delivered the ‘work’? And when requirements depend so much on customer input, how can you be sure you will get enough to complete the work?
Hey David,
That’s an awesome question. I’ll reword it a little bit more generally, and then tackle an answers.
“How do you create a fixed-fee statement of work for something that is never ‘done’, and with many unknowns about the time required to create it?”
The first part – about it never being truly done – is the crux of the issue. The second part – about not knowing how long it will take – is a risk mitigation problem. Let’s look at the easier of the two first.
For the SOW, we have to plan in enough time to get a reasonable amount of customer input. And we have to manage how much time we spend on getting that input.
I’m approaching it by time boxing the amount of time I expect to spend in getting validation. The first thing I have done is crisply define the scope, both in what must be documented and in what documents will be created. I have an estimate of how much time I will be able to spend in review sessions, and on revising the document. I have to manage the risk of delivering that work, just like any other fixed-fee activity. My preference is not to create a fixed-fee SOW, but that is the reality of my situation. So there is unavoidable risk. The better my estimates are, the less risk. Time will tell.
The second challenge – delivering something that is “never done” is harder. I’d love to know a better way to approach it, but what I have so far is a definition of “done” that is relevant only in the context of the SOW. A document, in the SOW context, is done after it has been delivered, reviewed, revised, and reviewed.
What I like about this language is that it explicitly exposes the risk that the document will be incorrect or incomplete.
In the end, the client absorbs the risk of not exposing all of the requirements, and the consultant absorbs the risk of execution not going as planned. It is a sharing of risks, induced by the fixed-fee structure.
I’m very open to alternate approaches – this is the best one I’ve seen to date (and I don’t take credit for it, btw, I just accept it as the best approach I’ve seen).