Project Delivery, or Is It?

You are working on a project.  You have a documentation delivery expected from a part of the organization today, yet you have not heard from those expected to produce a specification document, so you send an email wondering where things are, and let the team know that you need the said document to by 3:00 pm.  The specification arrives at the appointed time, and you pour over it to see what you have.  You are the project manager and not the subject matter expert that would be required to heavily critique the specification.  However, as you move through the document you find something interesting.  In general, the numeric designators for the chapters, sections, and subsections are hierarchical as below:

1
1.1.
1.1.1.

However, as you work your way through the material you notice a set of sections that look like:

9
9.1.
9.1.1.
9.1.1.
9.1.1.

This is in the released version of the specification, which presumably means the document has undergone some sort of documentation review as defined by your company work instructions.  The questions begin. Such questions as:

Project and Technical Specification

This is in the released version of the specification, which presumably means the document has undergone some sort of documentation review as defined by your company work instructions.  The questions begin. Such questions as:

1. If this went through a review, how did this get missed? What else has been missed?
2. If this did not go through the review, what can be said of the technical quality of the material since something as simple as the section headings are incorrect?

Rewind the Specification?

The time for the creation and review of the documentation has passed.  It is not possible to go back in time, and fix this, but it could still be a good time to understand the risks that may be associated.  A real review of the document could inform the project team of the suitability of the document for the objective.  It may be possible to delay the project while this happens, or perhaps the review is conducted in parallel with the other project activities and will alert the project team to the risks that may reside in the document.  Even if the project can not be delayed while this happens, perhaps it is still in the best interest of the project to ascertain the quality of the document.  It could be appropriate to identify the most critical portions of the specification and review only those, for example by:

• safety implication
• the feature most expected by the customer
• the first elements of the product or service to be built (technical dependencies)

If we review the specification in small doses we can perhaps find the defects in the work in time to have a positive impact on the product quality.

Alternative to Finding Out at the Last Minute

We perhaps should have reviewed the specification progress in our list of project management metrics all along the way.  That would include periodic reviews of the specification if our processes indicate or our project identifies the need.  We could have defined specific sections that should be built by specific dates and include the review of the document along the way. Once we see that the progress is not to our expectations, we know the end result is not likely to be to our expectations either.  That would give us time to consider alternatives, perhaps reassign resources, or alter the project schedule.

Though the problem seems to have just happened, the event has been in the offing if we would have raised our gaze.  Measurements are an important part of project management.  Understanding how the parts of the project go together,