Learning Lessons in Requirements, in the Shopping Line...

I was at the Children's Place the other night, grabbing some new footed pajamas for my 2 year old, when I found an interesting parallel between clothes shopping and locking down the requirements in a project. I had just been working on requirements earlier that day, and trying to schedule a meeting with stakeholders to review and sign off on requirements. So, what can I say, I had requirements on my mind.

I knew exactly what I wanted when I got into the store, went right to the pajama rack, found the last remaining size 3T pajamas and went right to the line. Also waiting in line with me, were some stereotypical annoying shoppers. Right in front of me was the couple who had a whole bunch of clothes piled onto their stroller and the wife did more shopping while the husband waited in line. Maybe there's not anything technically wrong with this, but it's annoying and I wish I had the nerve to push myself in front of them. Then, at the register was a guy who was changing his mind last minute and ran back and forth to put stuff back and get something else. Those people are even more annoying! So, fortunately they called in more register workers and the line moved a little faster, but in the time I was waiting my thoughts drifted to requirements gathering and management and the challenges of making changes in the beginning, middle and end of a project.

So, the shoppers are project stakeholders, and the time they spend walking around the store looking for stuff is the discovery process. They are not sure what they want and need time to explore and figure it all out.

Then, when they get in line should be the moment that they identified project requirements and are ready to confirm. For those who need to swap something after they have gotten in line, while sortof annoying...it won't slow things down drastically. I would compare this to making a requirements change while in the design phase. It can complicate things, but probably won't bring the project to a halt (hopefully!).

Next, at the register is development and implementation, and any changes made at this point will definitely slow down the rest of the line, and cause significant delays in our parallel project.
I'm reminded of one of my favorite software development charts, from the good people at Contrux, the cost of defects graph:




This chart illustrates the cost of repairing a defect at the beginning, middle and end of a project. The point here is to find and repair early. So, similarly with requirements, make sure they are clarified and confirmed early and make sure all stakeholders understand exactly what they are getting and the cost involved with making changes later on in the project.

So, if you're a project stakeholder or a project manager and sense anything unclear with requirements, just imagine that long line of angry shoppers behind you, furious that you're slowing everything down for them. Pick the right sizes and colors and make sure you know exactly what you want, otherwise you risk reeking havoc on your project.