Posted on

Lil Ms SunshineAs Business Analysts, we often feel that our work must be perfect. It is after all, being scrutinized constantly, and we know that in the end if something is labeled a defect, well… we get the blame. I frequently see and hear of formal requirements walkthroughs that go awry, situations so extreme that people cannot run away fast enough, looking like they are fleeing the scene of the crime. Why? Because the Business Analyst tried to do the impossible, they tried to be perfect.

What is it about Business Analysts and requirements perfection? We strive for perfect requirements: consistent, concise, complete, correct, modifiable, unambiguous, feasible, and testable (CCCCMUFT). We spend hours and hours documenting our requirements to the nth degree with text, matrices, models, and diagrams, all in the hope that the review by our stakeholders will go smoothly and signoff will occur. It is our work, it is who we are, and our integrity is on the line. So imperfection is not something that we naturally think of, and when you look at the word [imperfection], well it really just reminds us of what we want to be “I’M-PERFECT”. We put in the hours, we had the walkthrough of the requirements, and when all was said and done, the stakeholders were frustrated, the Business Analyst was stressed out with tons of rework, and the requirements are now behind schedule.

The problem is not the requirements themselves or the criteria we used to deem them perfect, but rather the approach we take. For example; you spend two months eliciting, modeling, and documenting requirements and then you go into a formal walkthrough with your stakeholders. Everyone reviewed all of your notes from all of your meetings so everything you have is perfect – right? What could possibly go wrong? Um… generally very, very few people read notes and provide feedback. So all of that work that you did, the ton of requirements that exist in the notes, has not really been validated. You then take those non-validated requirements and turn them into requirements that are ready for review and signoff. That story of perfection you are trying to tell will be ripped apart more often than not, because between the time that the stakeholder was interviewed, and the formal walkthrough, their opinion may have changed or they got new information. Even though the requirements get ripped apart and the impending rework ensues, we take that approach again and again. Why? We are told we have to get things done faster so we skip steps, cut corners.

Stop being perfect! Create a regularly scheduled meeting with your stakeholders to do informal requirements walkthroughs. This can be weekly, bi-weekly, monthly, or whatever you deem necessary based on the project size, complexity, time, budget, and stakeholder preference. These informal walkthroughs allow you to present requirements in a raw form that people can respond to and rip apart or praise as much as they want without you having to spend all of that time perfecting them upfront. Stop trying to use all of your criteria right away (CCCCMUFT) and take this imperfect, iterative approach, to connect more with your stakeholders bringing them onboard slowly, getting informal agreements to the requirements. By the time you are ready for a formal walkthrough, you will double check your criteria (CCCCMUFT) and if all looks good, people will already be ready to sign on the dotted line. And with this informal, iterative approach it causes a lot less bruising to our egos.

Don’t get caught up with trying to make things look pretty and perfect in the beginning. You can spend hours trying to craft the perfect sentence and it will often be a waste of time. Let people rip apart the requirements early and often. This approach will actually help remove those potential defects, and when they are found by our stakeholders, celebrate! Thank them. Tolstoy said: “If you look for perfection, you’ll never be content.” I believe that if you take the imperfect, iterative approach to requirements that you will be content, knowing that you will have less rework and less defects in the long run.

Leave a Reply

Your email address will not be published. Required fields are marked *

PMBOK, PMI-PBA, PMP, PMI-ACP and CAPM are registered marks of the Project Management Institute, Inc.