Guest blogger on Project Management – Part 2

Guest Blogger – Rick Wyatt

This is the second part of an 8-part series which looks at how IT and Business Leaders and Stakeholders can avoid common project pitfalls.

Be careful what you ask for!

You’ve probably seen the cartoon circulating over the years that illustrates the importance of requirements in delivering what’s needed.  It’s about a tree swing and the disparate interpretations of the deliverable when requirements are misunderstood.  Just search the Internet for “requirements cartoon” and you’ll find several versions.

It’s good for a chuckle, but the sad part is that it’s absolutely true!  The single most important piece of any project is requirements – clear, documented, validated, approved, understood and executed.  Here’s how to avoid requirements pitfalls in your projects:

  • Clear – Be specific and don’t assume people will just intuitively know what the customer needs.  If requirements are not spelled out in basic terms, they will be misunderstood.  As much as possible, requirements should be written to transfer the mental images and meaning from the mind of the customer to the reader’s mind.   This is not the time to show off vocabulary or writing style – keep it simple, crisp, to the point, descriptive and non-artistic.  Diagrams and screen shots are extremely helpful in conveying the desired information, but stop short of designing the solution – that comes later.
  • Documented – An artifact is needed that can be shared with your customer and the team, one that can be referred to repeatedly during the project lifecycle and that can be retained for audit purposes.  It doesn’t matter so much what format it’s in, so long as the format captures the specifics of the customer’s need.  There are lots of templates out there to choose from – Use Case, Business Requirements Document, etc.  Pick one that covers all the aspects of capturing the customer’s need and that can effectively convey that need to the team, then use it consistently in all your projects.
  • Validated – Once the requirements have been clearly documented, circle back with the customer to validate that what has been captured is complete and correct.  This reality check is essential to make sure nothing was missed and to edit the document where needed to clear up any fuzzy terms or concepts so that the customer’s need is clearly stated.
  • Approved – After validation, formal approval of the requirements document by the customer is needed with the understanding that the validated and approved requirements define what is in scope (and not in scope), they provide a definition of project success and they are now frozen.  This will provide a control for managing project scope and preventing scope creep.  Any subsequent changes to requirements should require formal approval by the project Sponsor and could impact project duration and cost.
  • Understood – Requirements define the customer’s need (the “What”) and the project team uses them as the basis to create the solution design (the “How”) that will meet that need.  To be successful in this process, it’s essential that requirements are completely understood by the project team.  The best way to ensure complete understanding is to conduct a Requirements Review meeting for the customer and the team to jointly walk through the document, discuss each requirement in detail and get all questions answered.  At the end of the session, everyone should have the same understanding of what is needed.
  • Executed – Requirements drive all subsequent activities in the project.  Technical Specifications and Design combine requirements with technology to form the solution.  The Test Plan and Test Cases are created to confirm the solution works as intended and all requirements are met.  User Acceptance Testing (UAT) provides the customer an opportunity to confirm what they asked for has been correctly and completely delivered.  In the end, each requirement should be traceable through the entire project life cycle to ensure all have been appropriately addressed in design, development, testing and deployment.

The time spent up front in the project process on requirements will have a huge return on that investment when you successfully breeze through UAT and deploy your project.  On the other hand, skimp on requirements and you could find yourself bogged down in rework, or worse.  It truly pays to be careful what you ask for!

Copyright 2010, Rick Wyatt, IPT Concepts, LLC