Information Technology Dark Side

One of the first PM courses I ever took was about requirements gathering. The instructor introduced a mnemonic for remembering the attributes of “good” requirements. Here it is:
Specific
Measurable
Attainable
Realistic
Timeboxed

I remember how everyone in the class was nodding their heads as the instructor talked. It makes sense, right? It’s simple and easy to remember, and if all the requirements we were given had these attributes our projects would be easy.

Of course, if our projects were all easy, I wouldn’t be needed. They could just manage the project with anybody with basic financial reporting skills, and everything would be golden. Every project would go in on time, on budget, with all the features. It would be a perfect, boring world.

I’m taking a different kind of course right now, a course by Scott Barber on performance testing. He presented a different definition of requirements that I like a lot better - things that if you don’t do you could get sued for or go to jail. That’s because they are literally REQUIRED, not simply deemed required by the business sponsor.

So what are all those things we put in requirements documents if they don’t fit this definition? GOALS. They are the goals of the project, and they need to be qualified, but not necessarily quantified. Requirements, on the other hand, must be both.

When Scott talked about requirements, it made me think of the SMART mnemonic. I found myself wondering what would have happened if we had applied this type of definition to the goals of several historic projects.

Would Lewis & Clark have every left Philadelphia if they had demanded that President Jefferson assign them “Attainable” tasks? Would Neil Armstrong ever bounced on the moon if Kennedy had been told to be realistic? Would peasant soldiers have marched to war against the greatest military force in the world if General Washington had been limited to “timeboxed” goals?

The rigor required to determine if a hypothetical project is attainable or realistic often far exceeds the cost of just trying, and this predictive process has questionable accuracy at best. More than once in my career I have delivered a project to production that a SMART project manager had turned down because it was not possible. More than once I have delivered a project to production that a SMART project manager had turned down because it’s budget or timeframe was not realistic. SMART requirements are for PANSIES.

Projects
Are
Not
Simple.
Intuition matters.
Exploration is critical.
Starting helps.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Stumble it!