Documentation typically starts when a bright idea appears on the scene. The bright idea may fix a problem, expand production capacity, save operating expense, or change the way a company does business. For content transport networks, the project will likely be structured around a combination of equipment, facilities, and services. Carrying the project through to completion will hopefully have a favorable impact on revenue and operating expenses, be profitable when completed, and require significant capital investment.
Starting documentation should be done at the earliest possible time and continue throughout the project with a final release upon completion and commencement of operations. Documentation should reflect reality as closely as possible during the construction and test phases, and especially upon completion. Sloppy or incomplete and uncoordinated documentation leads to mistakes and mismatches, any or all of which can cause re-work, which can be expensive.
Missing details in the final release can impede quick and efficient repair or service restoration.
Documentation should mature as the project matures. Small projects where the project manager functions as the design authority and holds overall responsibility for the project should follow the same process as large projects with dedicated full-time design, scheduling, and financial staff. Components in the documentation include an initial sketch, first draft, preliminary release, one or more revisions, and a final release.
The initial sketch is simply a combination of a brief description of the idea in written form and one or more drawings. It may also include a high-level table or spreadsheet containing preliminary budget estimates of cost, revenue, and profit impact.
A designated project manager should prepare a first draft document as soon as the bright idea gains traction and sufficient interest. This individual should be knowledgeable about the technology and basic business financial aspects of the project. The first draft should be as complete as possible in technical and financial terms. At a minimum, it should contain a technical description, list of equipment, facilities, and services required, a statement of the impact on operational functions, an estimate of the cost, revenue, and profit impact in as much detail as possible, and a schedule or estimated time frames associated with major phases or activities making up the project.
Design review is a critical step in any project. Design reviews are nothing more than a small group of experts from accounting, purchasing, operations, and engineering considering the details of a proposed or in-progress project and making an assessment of the potential risks and unknowns associated with various aspects of the project. A design review can be conducted at any time during the life of the project after the first draft documentation is complete. Depending on the scope and size of the project, it may be valuable to stage multiple reviews as a project progresses. Design reviews may morph into project status reviews over time.
Some practitioners find it valuable to conduct the first design review before release of an RFP, and a follow-on review after responses are received, evaluated, and preliminary vendor selection is completed. Vendor presentations can be made part of a design review where all functional organizations representatives have an opportunity to gain exposure to potential suppliers and assess their ability to perform.
A preliminary release, sometimes called version 1.0, is considered the first example of final documentation. It should include all the documents deemed to be appropriate and necessary for accounting, purchasing, installation, test and acceptance, operations, administration, maintenance, and change procedures. Each document created specifically for the project should contain a reference section where specific third party documents, standards, construction codes, regulatory, and other references are noted. The preliminary release should include updated and extended versions of all documents included in the first draft. Equipment, facilities, and services should be as detailed as possible, and at a minimum include quantity, part number, or other reference identification to be used by accounting when auditing and paying one-time or recurring charges.
One important document in the preliminary release is a formal test plan and acceptance form. This document should be in a state of completion so it can be used to verify physical, functional, and performance characteristics of equipment, software, facilities, and services provided by third parties in fulfillment of purchase orders and accepted proposals. The test plan acceptance form should have matured through the RFP and contract process with each third party. Exceptions or conditions related to acceptance should be documented and any agreement to waive or delay performance as agreed in any contract should be within the context of the test plan.
The documentation should be carefully managed during the construction, test, and acceptance phase. This involves attention to physical details such as cable, patch panel, and rack label details as well as configuration parameters. For example, IP address and phone number details should be checked and double-checked from the time they are planned until final check-off on the completed documentation. Class and type of service designators must be validated.
As the documentation and construction come closer and closer to reality, it may be necessary or appropriate to make additional releases. These should be clearly labeled with a new version number, such as version 1.1, similar designator, dated, and maybe even timed, depending on circumstances and potential requirement to maintain coordinated work to continue. It is also advisable to maintain a change record summarizing the changes included in each release, why changes were necessary, and the specific section and page where the changes were made.
No comments:
Post a Comment