Whether a project is scheduled for six months or for four years, the tone for the remainder of the project is set during the Requirements Definition phase. If the requirements are developed accurately and specifically in this initial stage of the project, then the design, development, and the testing of the system software will flow more smoothly. If the requirements are wishy-washy, or if end-user participation changes frequently, then the follow-on phases of the project will have more uncertainty, and the end result will not be to the client’s satisfaction.
To that end, the client organization bears much of the responsibility for accurate requirements definition. I often advise my clients to bring their own experienced scribes to the requirements gathering workshops to ensure that the requirements are documented accurately. The workshop facilitator will have his own scribe; but to ensure that the requirements are captured as the client participants stated them, having one’s own scribe is invaluable. Particularly where the client’s review of the system requirements may be separated from the requirements gathering by several weeks, copious and accurate notes by one’s own scribe are extremely helpful in that review.
Many of my clients are state government agencies. Unfortunately, they often do not have the resources to add experienced scribes to the requirements gathering workshops. I recently served as PMO oversight for a large system development project, for which the systems integrator was Deloitte Consulting. Deloitte creatively solved the client’s lack of scribes by utilizing projectors during the sessions. As requirements were discussed, they were captured by Deloitte’s scribes and projected for all to see. The client participants were able to see the requirements as they were being formulated, and were thus able to participate more effectively. At the end of each session, the Deloitte and client participants were able to review the entire session output collaboratively on the screen, and agree on the accuracy of the requirements as documented. This made the follow-on process of requirements review and sign off much easier.
As a humorous aside, I recall a situation where the client’s acceptance testers reported a system defect, indicating that a key function was working exactly opposite of their business process. The contractor’s IT lead informed them that the function was working as designed. To prove his point, he showed them the signed-off requirement. The testers read the requirement and agreed that it stated exactly what was required. I read the requirement and agreed that it stated exactly what was required. So if both teams agreed that the requirement was stated accurately, and the system was working 180º from what we just read, why was the IT lead digging in? Then it dawned on me. I reread the requirement from the IT lead’s perspective. When read from his perspective, exactly the same words had exactly the opposite meaning. I did wonder, however, how the two teams could have discussed this function in the requirements gathering sessions, agree on the wording, and still have opposite understanding of what was needed.
Precision in the statement of requirements is an absolute must. Creative techniques such as the one described here help the understanding of both parties. Nothing is as rewarding as hearing the client say of its new system, “That’s what we wanted, and we got what we asked for.”
www.ElitePMStrategies.com • The Human Aspects of Project Management • Copyright ©2013-2014. All rights reserved.
Permission to reprint all or part of this article in your magazine, e-zine, website, blog, or organization newsletter is hereby GRANTED, provided: 1. You give full attribution to the author; 2. The website link to www.ElitePMStrategies.com is clickable (LIVE), and 3. You leave all details intact (i.e. links, author's names etc.).
Latest posts by Merv Jersak (see all)
- The Olympics of Project Management – Control and Balance - February 12, 2014
- The Olympics of Project Management – Unstoppable Performance - February 11, 2014
- The Olympics of Project Management – Competing with the “Big Guys” - February 10, 2014