A practical approach to project management procedures
by Garry Dudley, PMP
When do theories meet reality? At implementation time, of course!
Although you read many articles on project management, are you getting the information you really need? If you are looking for an article short on theory and long on practicality, keep reading—you've found one.
One of the starting points for better project management processes is a precise set of project management procedures. But how does one go about actually creating procedures or updating a manual that needs to offer more definitive guidance? This article is about just that: developing procedures and writing a procedures manual. Since we all live in a world of finite resources, the project team at Airport Integrated Systems (AIS) chose a method that emphasized directness and practicality. Our approach required us to ask, and then answer, these six questions:
■ Why do we need project management procedures?
■ What are the specific benefits expected from a stronger project management program?
■ Would a project management model help?
■ Why do we start with standards?
■ What is the target and how do we approach it?
■ Where do we go next?
Why Do We Need Project Management Procedures? For us, this was an easy question to answer. We just had to look at our past project performance. As we reviewed the specific areas for improvement, we could see clearly emerging patterns, and they were squarely in the project management discipline. Specifically, causing the greatest concerns were the areas of scope definition, scope control, communications, reporting, and change control. We clearly saw the need for a stronger project management effort.
Garry W.Dudley, PMP, is director of operations for Airport Integrated Systems in Denver, Colo., USA. He is a retired U.S. Air Force officer with extensive project management experience, both in and out of the military, who has worked in large, medium, and small companies and has led the effort to establish project management offices or implement project management procedures in three different organizations.
The AIS Project Management Model
Exhibit 1. Initial implementation is top-down, while support is from the bottom up. In practice, it is dynamic in both directions.
We knew the path to improved project success would begin with better procedures. We all know projects cut across functional lines and that project management procedures place requirements on people outside the direct supervision of the director of Operations. Therefore, to implement a stronger project management focus, we needed the full support of the senior staff. How to get that support is an important question.
What Are the Specific Benefits Expected from a Stronger Project Management Program? All proposals, even internal ones, need to be approved and the expected benefits of the desired actions clearly communicated for a successful proposal. This effort was no exception. We needed to communicate the specific benefits we expected from a stronger project management focus to all team members, starting with the senior leadership.
The strength of AIS lies in the creativity of our people and the visionary leadership of the senior team. However, the long-term success of any company depends on the ability to execute flawlessly. Readers should individually determine and communicate those benefits most appropriate to their particular organizations; however, the expected benefits listed here are the ones emphasized at AIS:
■ The efficiency and profitability of the projects would be improved.
■ The number of errors attributed to the project manager would decrease by having the clearer direction that stronger project management encourages.
■ The projects would contain more repeatable processes so that learning and increased efficiencies would take place.
■ All processes would be closely integrated.
■ We could (and should) promote our project management as a competitive advantage.
Would a Project Management Model Help? Before we barreled headlong into the development and writing of a procedures manual, we had to come to grips with two very critical issues. Specifically, we needed to ensure that the new procedures supported the company's goals and would indeed result in better project performance. A model was needed to guide, focus, and help communicate our efforts. Exhibit 1 shows the AIS project management model.
A discussion of the entire model is beyond the scope of this article. The emphasis here is on the relationship between standards and procedures.
Why Do We Start With Standards? At the center of the AIS model are project management standards. This was our starting point. We wanted to adopt standards that already existed and that are widely understood and accepted. We needed standards that would facilitate communications with customers, suppliers or subcontractors, stakeholders, and other project management professionals. The standards should also connect us with training materials and programs widely and readily available.
The Project Management Institute's (PMI®) generally accepted practices in the PMBOK® Guide met our criteria and were adopted as AIS project management standards. As mentioned earlier, the standards are a starting point. A look at the model reminds us that the standards may need some modification to meet the business needs or to fully support the vision of the company.
The selection of standards also gave us an immediate training focus. Knowing the standards we wanted to achieve, we could seek applicable training. This allowed “fast tracking” of some needed training of project management basic concepts, by placing that as a parallel activity while we continued to develop our procedures manual. Another important aspect of adopting the PMBOK® Guide practices for our standards was the Project Management Professional (PMP®) certification process. This certification served as a goal for individual self-development efforts that paralleled the company's goal.
What Is the Target and How Do We Approach It? In the business world—whether it's manufacturing or consulting—quality records are a must. By quality records, I mean those records that verify that quality procedures and guidelines were used to develop a quality product, one that meets the customer's expectations for feature, form, and function. Quality records are maintained to verify that the promised quality control efforts were made and quality processes were followed at the appropriate time in the product development process.
We had an epiphany! If we could establish what the documents on the shelf at the end of a highly successful project would look like, we could work backward from that point. To restate: “What documents and records, particularly quality records, would be necessary to ensure that solid processes were followed during the project's lifecycle?” We worked from the project's envisioned final documents to develop our procedures manual.
With this thought in mind, the project records became the target to get us to a project management procedures manual. But be cautious here: you need to be sure the target is correct! If our soon-to-be procedures manual drives the generation of the required documentation, will we obtain the project performance increases we are looking for? We needed to ensure the new procedures would indeed result in better project performance. Only time, with good metrics and a solid feedback system, would tell us for sure; but we could increase the odds of success by a smart approach, reviewing and learning from the generally accepted practices, and by maintaining a flexible stance.
The next step was to use whiteboards to describe the procedures. Keeping in mind that the project manager in the field would actually have to live with the procedures, we outlined the kind of documents that would be needed. This is where a solid knowledge of PMI's generally accepted practices, standards, and basic concepts again came into play. The generally accepted practices provided the structure and the basic concepts provided the starting point.
Looking at our model, we see that procedures support the standards, and the standards provide input to the procedures. For example, examine the process that generates the scope statement, as described in the PMBOK® Guide. Our procedure discusses and defines the basic concepts of scope statement development. We can reference additional sources of information and establish a common understanding of scope statements in general. This was an excellent starting point to which we added items, making the procedure AIS-specific. We added a short checklist of questions to ensure that the scope statement contains all of the additional elements that are specific to our company's requirements or expected within our industry. Mandatory is the inclusion of all customer deliverables and their corresponding dates, as well as the constraints and assumptions used in developing the scope statement. Items identified through lessons learned are also added when appropriate.
We wanted to adopt standards that already existed, and that are widely understood and accepted….
The generally accepted practices in the PMBOK® Guide met our criteria and were adopted as AIS project management standards.
Reporting is another example of creating a procedure. We continually emphasize that while the schedule and plan are unique to the customer and must be flexible, the internal reporting process must be standard. Senior leadership can have insightful understanding across all projects only if there is a standard process with standard reporting formats and common definitions. This is the key point: Standards provide the basic concepts and structure; procedures add the specific requirements of the corporation and industry.
At AIS, we require that project management software be used to generate the reports. Too often management inadvertently distracts the project manager from using and updating the primary project management tool by requiring reports to be generated by other means. AIS's procedure requires the project manager to update, in the schedule, actual costs and resource usage and to enter actual completion dates as tasks are completed. This improves the project management tool's accuracy in forecasting and also improves the accuracy of project data collected, which is used in future planning endeavors. This places the emphasis where we want it: on managing the project.
To ensure that our procedures include the extra discipline and accountability required, we've encouraged what I call verifiable accountability. The gate reviews are rooted in the standards and basic concepts. The AIS-specific procedure requires a checklist be reviewed, signed, and presented at the Senior Management Review, stating that the required documentation has been properly accomplished and is in the project files. We have taken accountability one step further. This is clear direction for project managers.
The previously mentioned caution bears repeating: The procedures and the resulting documentation must be on track. There is a management adage that says, “What gets reported and gets rewarded gets done.” The opposite is often true: “What is not monitored and reported may not get done.”
At AIS, we approached the development of the procedures manual by:
■ “Selling” the need for a stronger project management program
■ Creating and using a model for guidance
■ Starting with generally accepted practices, which became our accepted standards
■ Working backward from the “target,” the project records.
Where Do We Go Next? We will continue to refine the procedures and update the manual as we receive input from the field. The real test will be the project metrics. We are confident the metrics will show improvement because we followed a logical process to develop the procedures and the manual.
At AIS we believe that commitment to project management along with systematic refinement of procedures will ensure our continued success.
PM Network June 2001