Tag: Project Documentation

Improving Your Project Documentation

Documentation will always be part of life for Project Managers, sometimes more than you’d like.

But how can you make sure it is useful and ultimately delivering value for your project? There are a few basics which, if you get right, will help guide you on the way to project success.

Documentation. Often a dirty word in the modern Project delivery environment, which loves to extol the virtues of approaches such as Lean and Agile. Those approaches can be extremely useful; if used appropriately, however when planning large and complex Projects then documentation will always be part of life. That documentation could be management work products created only to aid the delivery of the project (Project Brief, Communications Plan, Exception Plans etc) or an actual deliverable of the Project (Test Plan, Software Release Note, User Training Materials etc) The key is to produce effective documentation that actually adds value, and to avoid the creation of shelfware.

But how to achieve this? Below I’ve given an overview of key considerations when producing any sort of documentation as part of your Project.

Product Based Planning Approach

Firstly, adopt a “Product Based Planning” approach for your documentation, meaning identify up front and establishing it as a product of the project like any other. As such, abandon the negative label of “documentation” and instead refer to them as “Work Products.” During your initiation/startup phase, you should be aware of every single document that needs to be delivered during your Project, who for and why.

Product Descriptions

Before you try to produce any document, you should first be defining and agreeing on a description of what the work product is. This will make sure you set off down the right path, and don’t waste time creating something different from what users imagined – or that doesn’t help anyone, and truly does become shelfware. Define what format it will take, what content it will have, what information will it provide – and what it will not provide. By producing product descriptions, they can also be used as a benchmark set of “Verification Criteria” to review the Work Product against when it is produced by the Project at a later date. Ideally, your organisation will define standard work products as part of your tailored lifecycle approach, and define standard templates which automatically direct authors to meet the product description almost by default – reducing the chance for issues later.

Configuration Management Control

Your Work Product will likely go through many versions before it is finalised, and then may change yet again at a later date. The mechanism of this change needs to be understood and defined in advance because uncontrolled change could potentially have a disastrous effect on the project. If the design of a bridge was changed, but the construction team not informed, or the material order not updated, then the project will soon hit major issues. The key consideration here is to identify and define the required level of configuration control depending on the nature of the work product. For simple items which don‘t require any level of formal control (think emails etc.), we clearly shouldn’t waste time or effort, however for more important work products we should look to bring in version numbering as a minimum, recording when versions have changed and what the associated content change was. Beyond that, we would look to record who updated and approved the version changes, a communication process to inform stakeholders of changes, and in the most critical of cases a formal change control process. In this case, any change to the work product needs to be formally requested via a Change Request (CR, sometimes a Request For Change – RFC) submitted to a Change Control Board (CCB). Your organisation should define standard levels of configuration control, and then define what level of control each work product requires; do this by creating a Project or Organisational level Configuration Management Plan.

Quality Review and Approval

There’s no point the project expending effort on a work product if it doesn’t meet its original aim; that is if it is not of a required level of quality. At the planning stage, work out who needs to review and approve each work product using a peer-review process. The approach and associated logistics to work product reviews should be planned in a Project Quality Plan, covering things such as the process for the reviews, what tool will be used, timescales for reviews, etc. The draft document will be circulated to the reviewers for comment, and then once the initial review phase is complete, the author will review all comments and update the document as they see fit, and respond to each comment (were they accepted or rejected?) The document will then be circulated for a shorter second review period for reviewers to confirm that their comments have been addressed, or that they agree why they might not have; if there is further disagreement then the author and reviewer should follow up to resolve. Once the review is complete, and reviewers are happy, the final step is for them to confirm their final approval of the work product. This is especially important for key approvers who are the relevant authority or subject matter expert for your organisation – it may be a department head or regulatory body.

Risk, Uncertainty and Continuous Planning

When a project kicks off it is like rolling the dice, you never really know how things will turn out until the end.

Experienced and rational project managers understand that risk management is an integral part of planning and that planning is a continuous process throughout and beyond project life into the operational process that the project sets in motion. These PMs consider uncertainty to be a certainty. They realize that everything is subject to change and that each change has ripple effects.

Project managers expect change in resource availability, requirements, organization structures, policies and procedures, and technology. They realize that the duration and outcome of testing cannot be predicted with certainty. It is testing, and it is done to find defects. How many defects there will be and how long it will take to fix them can be estimated but cannot be known until testing is complete.

Other stakeholders may not be as understanding about risk and uncertainty as PMs. Many are uncomfortable when they do not have a solid sense of what will happen. They want a guaranteed end date, deliverable, and cost.

The project manager is responsible for managing expectations using risk management, incremental and continuous planning and effective communication.

Case Study

Let’s look at an example:

A complex organization decides to acquire a commercial off the shelf (COTS) software package as the vehicle for transforming its operation by automating key business functions, including tactical decision making. The decision to go the route of a COTS solution was in keeping with generally accepted best practices to avoid the costs and risks of unnecessarily developing custom software.

The risks of the COTS approach were considered. They included the realization that the organization would be reliant, to at least a degree, on the continued support of the vendor and constrained by the vendor’s release cycle. There was a commitment to minimally customize the software to minimize cost and complexity, make needed changes to the existing business process and moderate the risk associated with significant changes to the product.

The project was planned and kicked-off. A qualified vendor was selected in a formal and well-regulated procurement process.

The vendor, assuming a large ongoing revenue stream from other services to be offered to the client, cut its price and in effect “bought” the contract. They took a risk (consciously or not). The expected revenue stream did not materialize.

The first phase of the project – the implementation of automation of point of sale operations at over 1200 locations went like clockwork. The organization’s financial systems were easily fed the data from point of sale in an interface that required no customization of the package.

The second phase did not go as smoothly. It was discovered during detailed requirements analysis and design that the package would not fully satisfy the needs of the organization without significant customization. A choice had to be made – 1. customize the product, 2. build phase II software in-house or 3. create interfaces between the package and in-house business applications to create a hybrid system.

The hybrid approach was chosen based on the assessment of the cost and risk of the options and the desirability of avoiding unnecessary business process changes.

As the second phase of the project progressed some of the risks recognized early on began to appear as issues that required rethinking the plan forward. The vendor was losing key staff and was thinly resourced. In addition, the client perceived that the loss of expected revenue would affect vendor motivation. That made it even more necessary to ensure local autonomy for future enhancements.

The internal business organization also lost staff that had been dedicated to the project and was not able to provide requirements and sign-offs in a timely manner. The training department did not engage in the project planning until late in the project, resulting in last minute discovery of business process issues requiring business decisions and systems enhancements.

The internal application development group faced significant turnover and resource shortages coupled with more extensive programming requirements than originally expected.

Risk Management and Planning Process

A risk management process was put in place from the start of the project. Risks were identified, described, assigned an owner and scored based on assessments of probability of occurrence and impact. Monthly risk meetings were held at which existing risks were reviewed and reassessed and new risks identified. Risks that materialized were identified as issues and action taken to resolve them. The plan was modified accordingly. At times, because uncertainty was great, the plan did not commit the project to a fixed delivery date.

The planning took risk into account, though did not perform probabilistic planning. Probabilistic planning is planning that allows for multiple scenarios and a range of cost and time outcomes. PERT is a classic example. Each task is estimated using a weighted average of pessimistic, most likely and optimistic outcomes. Monte Carlo approach adds a statistical capability that runs a large number of possible outcomes to predict a statistically accurate range of outcomes and probabilities.

Deterministic planning is the alternative. Here, the tasks are estimated with a single point, and the project end date and costs are predicted based on the single scenario.

Many projects are planned with the deterministic approach. One reason for this is the extra effort and skill required for the probabilistic approach. Another is that in some organizations capital budgets may not be presented as a range and may not include a contingency fund.

This was the case in the example project. As a result, the planners presented a worst-case scenario based on pessimistic assumptions – the result of risk assessment. They faced a time box that limited funding and contracts to five years.

As incidents occurred risks became issues, and the plan was adjusted to keep it as a realistic picture of the predicted outcome. The base budget was used as a bench mark. Because it was based on pessimistic assumptions, the project remained on and under budget. Resource shortages made it necessary to under spend. The time line restriction led to a reduction in scope.

Because of the scope reduction, there was a need for subsequent projects to fully implement the overall program. Operational accommodations had to be made. The changes in the vendor relationship prompted an increased need for autonomy from the vendor regarding enhancements.

The good news was that stakeholders on all levels were prepared for uncertainty. They were kept abreast of risks, issues, and changes. Expectations were managed using risk management as a means for highlighting and working with uncertainty in a concrete and understandable way.