[Also available as a podcast]
One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.
Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.
There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.
What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.
These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.
I am getting hungry just writing about it!
Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.
We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.
Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?
Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?
Wait, let me look at the other 34 flavours first...
And which one goes best next to Liquorice?
It is so hard to choose...we need some help!
What we need is...a good Requirements Definition Process.
One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.
Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.
There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.
What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.
These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.
I am getting hungry just writing about it!
Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.
We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.
Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?
Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?
Wait, let me look at the other 34 flavours first...
And which one goes best next to Liquorice?
It is so hard to choose...we need some help!
What we need is...a good Requirements Definition Process.
Tell Me What You Want, What You Really, Really Want
I have to admit, The Spice Girls nailed the key elements of a very successful Requirements methodology with their lyrics "Tell me what you want, what you really, really want".Well, maybe not the whole song - perhaps just the chorus.
But it is definitely about Requirements - and we do have some lessons to learn from them.
We need to get into the details - and in the most effective, efficient way possible.
A successful Requirements gathering methodology involves three main steps, that progress from higher to lower levels of detail.
Tell Me ...
Generally it is sufficient to kickoff off your project with very high level requirements, so that everyone has a common "big picture" understanding of what it is we are trying to achieve. However, once you actually start the work of the project, these requirements must be refined into finer and finer levels of detail.
Part of the project
planning should include tasks and the associated investment of time and
effort into the requirements refinement so that the project deliverables can
actually be designed, developed and delivered. Not only that, but the
delivered items should match the business need. So hopefully we can collectively nail down the requirements clearly enough with the customer that when we do develop exactly to spec, it is exactly what they asked for - and is what they actually want.
You look at the board, the size combinations, and realize that you might not be able to eat 42 scoops at once. Maybe not even 11.
I need to think about this a bit...
...What You Want...
I think we have all had the experience of delivering something to a customer (hopefully on-time and budget) and having them say "yes, I know it is what I asked for and you delivered it to spec, but it's not what I wanted!"
So the solution is apparently simple then - just find out what they want, document it, and then deliver it!
Boy that Ice Cream looks good. I like this flavour, and this flavour and this flavour - and...oh wow! I haven't had that since I was a kid, better get that one too...
...And yet here is where we run into some major stumbling blocks that have to do with Communication and Expectations, seemingly no matter how hard we try. The key issues generally are:
1.
They think you know what they want, in great detail... from the vague
outlines in the Project Charter, RFP or High Level Requirements. Oh, plus the word picture they gave you months ago while standing in line for coffee at Starbucks. You must understand what they need from that! They certainly described it to you well enough...right?
2. They think they know what they want... but sometimes they don't - at least, not in full. This happens more often than they will admit.
3. They don't know what they want. At least, not yet. This happens often - and especially when a customer is migrating to a new system. They know how the old system worked, they know what they could produce from it - and they don't yet have a full understanding of how the new system functions or what it can do.
4. We don't know what they want. It is generally safe (and wise) to approach the project with the attitude that you don't know exactly what the customer wants, at least, not in detail - so approach it with open eyes, ears and mind, asking questions.
5. We don't know what we don't know. It is inevitable that even with a rigorous requirements collection model, things will be missed. People may forget to bring them up until later, not on purpose of course, but because they forgot.....or sometimes, we just don't have enough information yet and it is truly an "aha" moment brought to the table later on.
Ok, so I think I can handle three scoops, or maybe just two. They look pretty big.
Getting Down to Brass Tacks
We need to break the bonds of assumptions and pre-conceptions of "this is how we used to do it" and get down to what it is they want - in words that both the customer and you can uderstand - and hopefully agree on the same meanings for the same words.
Gather as much detail as you can at this stage - and WRITE IT DOWN! If possible, collect samples, photos, screen shots, diagrams, anything that will help remove ambiguity from the requirements. A picture may be worth a thousand words, but a screen shot or report sample definitely does not cut it on its own - there is an iceberg worth of business logic detail hidden beneath that small sample.
So, we sit down with the customer, talk to a few people, write things down and thereby "document the requirements". Many people stop here, shake hands all around, get the specs signed off and get ready to start designing and building. Mission accomplished!
Well, not quite. In order to make sure we have covered the bases, we need to validate the assumptions around the requirements to make sure nothing was missed - before signoff.
We need to check and ensure that what they have asked for, and what they have documented as "what they want" is also what they need.
I have five favourite flavours, now I just need to choose which ones for today's masterpiece...
...What You Really, Really Want!
In
my experience it is often the case that the users or persons responsible
for writing the requirements (either with or without you) know what they
want, but they don't always know what the end users need. But they think they do - and therefore, so do you.
"What's
that?" you say. "Of course they know what they need. They are writing
the requirements so what they write simply ARE the requirements. What they want is what they need."
Well yes...and sometimes no. As thousands upon thousands of Change Requests every year around the globe will attest.
Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.
Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.
And
quite often, they simply forget to write things down because of the
embedded culture...meaning "well, everybody knows about that part because it is just
they way it is around here" ... and things get missed - especially if you as the vendor/contractor are not part of their culture.
In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)
In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)
The truth and your project salvation lies in the
questions...lots of questions. And without those questions we are often lost in translation.
"What they want" is not the end game. "What they Really Really Want" when you dig deeper is more representative of what they actually need. Sometimes you may find that these indeed are one and the same thing - and the customer does have an excellent grasp on what they need, and articulate it well. And sometimes, that little bit of digging deeper will save thousands of dollars or hours of rework (whether or not it is a paid change request, it is still better to be able to meet the need the first time).
"There is never time to do it right the first time, but there is always time to do it again." - Unknown
If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc.
"There is never time to do it right the first time, but there is always time to do it again." - Unknown
If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc.
Which type of chocolate scoop do you want? Chocolate, Dutch Chocolate, Triple Chocolate Swirl?
If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.
"It takes less time to do a thing right, than it does to explain why you did it wrong." ~Henry Wadsworth Longfellow
If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.
"It takes less time to do a thing right, than it does to explain why you did it wrong." ~Henry Wadsworth Longfellow
Sometimes those "missed requirements" are small omissions with small change requests, but sometimes they are big ones.
You can't un-scoop an Ice Cream if you changed your mind.
The Cost of Requirements Change
We have all heard about how the cost of change increases significantly the further you are along the path of delivery. If the unit of effort to make a change to the requirements is (1) at requirements stage to accommodate a change, then in design it increases to (2-5X), in development it jumps up (to say, 10-20X) and once delivered it increases again to (100X+). Or perhaps a different scale may apply in your business, but you get the idea.
With one of our recent clients, there was a piece of custom programming work that went through a formal requirements process, reviews, signoff, development, delivery, testing...it was on the verge of acceptance when one of the end users identified that they did not want whole numbers (Integers) on the report output, they were supposed to be decimal (xx.xx) numbers in a particular type of result.
In most situations, this would be a relatively minor change. However, in this case, due to the complexity of the overall report code, and the specific and unique solution developed to accomplish what was required, this was not a simple change. In fact, in this case it was a HUGE architectural change that required a full redesign of the report and the coding logic.
The solution to satisfy the new requirements ended up being even more complex than the original.
This might be a 1 in 10,000 case, but in this specific scenario, if the original estimate was (X), the cost of the rework was actually (X*1.1), so the TOTAL cost of the custom report ended up being (X*2.1), or 210% of the original estimate.
When you change your mind about flavour after you have started eating or have finished the cone, you need to buy a whole new cone...you are not just asking for a few sprinkles on top.
An extreme case perhaps - but still true. Missing the fact that they needed the decimal places vs integers at the outset was an acknowledged requirements failure by the customer, but it was still a very expensive mistake.
So, Ask The Questions...
How many scoops? (So they choose the right base)
It is through
the interactive dialog that great requirements can be elicited and
documented. The better you are at asking the questions and understanding
the big picture and the detail level, the better your requirements will
be. This has the benefits of:
- Better estimating process
- Better initial quality
- Lower overall cost (time, effort, $)
- Delivering what the customer needs- Better reputation for insight and delivery
Ice-Cream? Sherbet? Which flavours? ...And FYI the Bacon is next door.
...And Remember to Actually Read And Use the Requirements!
When you have the requirements, good ones or exceptional ones, you can still fall flat on your face. When you are executing (designing, developing, building), make sure to read, re-read and read the requirements again. And before you say you are ready to deliver to the customer, re-check the requirements to make sure you have done it right, to the specs.
And if you come across something that looks odd or not quite right, or incomplete - raise the red flag and ask questions. Clarify the requirements with the customer. There may be a question of interpretation , there may be a clarification needed, or there may actually be a Change Request needed, if the requirements don't accurately match the need based on current information.
Remember, the cost of making the changes to your project deliverable get increasingly higher the longer you wait - so after you have re-read and you are still not sure - ask the questions as soon as possible - and if a Change Request is needed, better to catch that in Design than Development, better in Development than in Testing, and better in Testing than in Production.
Summary
"Good" requirements analysis and documentation is often not good enough. You need to go that extra step to validate that what they are asking for is actually what they need. So work closely with the customer, and follow the three-step process towards developing Excellent Requirements.
1. Tell Me
2. What You Want
3. What You Really, Really Want!
Don't stop at #2.Too many people do.
1. Tell Me
2. What You Want
3. What You Really, Really Want!
Don't stop at #2.Too many people do.
Today, I am going to have two scoops, Dutch Chocolate and Orange Chocolate Chip. Next time, I may choose the Mint Chocolate Chip and Rocky Road. Now that I actually live in New Zealand, Pokeno is not that far away!
Decisions, decisions!
Good luck with your projects, and keep an eye on those Requirements!
Well written and insightful as always, bro! E
ReplyDelete