5 Common Sense Techniques to Plan Scope Validation Timeframes

The scope validation process takes time. Give the team enough time to do a thorough jobVirtually every Request For Proposals (RFP) I responded to over the course of my career prescribed the scope validation process as follows:

    • 10 days for the client to review and comment on each deliverable,
    • 5 days for the IT provider to correct and resubmit, and
    • 5 days for the client to review and approve.

What was particularly nonsensical about these stipulations was that the RFP issuer – our eventual client – was putting itself at a disadvantage contractually.

Why do I say that?

Because the RFPs all required that the respondents develop a project schedule as part of their proposals which, of course, included the scope validation timelines. However, the client organizations all dictated the durations for the review process regardless of the size or complexity of the deliverable.

For example, if the IT provider estimated a duration of 15 days to produce the Communication Management Plan, a timeframe of 10-5-5 working days (per the above-noted RFP stipulations) was added for review and approval. If 8 months were estimated to collect, document, and produce the functional requirements, a timeframe of 10-5-5 working days was added.

Do you see the absurdity?

The Communication Plan might be 75 pages long. It may be reviewed in 1 day, updated and resubmitted the next day, and re-reviewed and approved in 2 hours. Total: 2 days, not 20.

The Functional Requirements Specifications might be 1,200 pages (not uncommon in my experience). It may include a detailed Requirements Traceability Matrix uploaded to an electronic repository. The entire deliverable might require 20 days to review, 7 days to update and resubmit, and 5 days to re-review and approve. Total: 32 days, not 20.

What I never understood – and still don’t – is that if the RFP issuer required the IT provider to prepare a project schedule based on its experience in delivering systems, why would it not also require the IT provider to specify the scope validation timelines? After all, they are the experts.

As I began consulting with organizations to prepare their RFPs and to provide project oversight services, we attempted to change some of these entrenched policies. The most successful projects that I worked on used some or all of the following techniques to streamline the scope validation process:

  • Implement a formal pre-deliverable called the Deliverable Expectations Document (DED) that defines the content, format, review process, and conditions for acceptance. This removes ambiguity and misunderstanding of the purpose of the deliverable. It is specific with respect to the information the deliverable is designed to convey. The IT provider delivers to the agreement in the DED. The client reviewers focus on content and meaning.
  • Vary the timeframes for deliverable review and acceptance. This should be done based on the length and complexity of the document and accompanying information. This relieves the pressure on the review process, especially in situations where the given time is not sufficient to conduct a thorough and thoughtful review.
  • Provide opportunity for informal reviews of interim documentation. This is applicable to larger, more complex deliverables. A large deliverable will have several components. As each is completed, the review team can pre-review it for content and meaning and catch defects early. By the time the entire deliverable is submitted for scope validation, the review team is well-versed in the components they have already inspected. They can review these in a more detailed manner and focus on how all the components fit together as a whole.
  • Develop a prescribed response form for reviewers. Without this, the review team will provide its comments in multiple formats. I’ve seen deliverables with handwritten mark-ups and post-it notes. I’ve seen review comments written in a stream of consciousness in MS Word, often with no reference to the sections of the deliverable being reviewed. I’ve seen comments returned in Word and/or Excel in no particular format.

    A prescribed tabular format with blocks for comments, document references, page numbers, section headings, and other such notations provide for a quicker, clearer, more focused review.

  • Ensure the IT team is available to the review team. So much time is wasted when all communications are required to be handled via the review documentation. When the IT team is available to clarify aspects of the document that the reviewers are struggling with, review comments become clearer. Often review comments are dropped altogether.

The people aspects of project delivery demand that such commonsense processes be put in place to remove the “noise” from the review activity. Team members can focus on what needs to be accomplished with clarity and understanding.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.