Are your project control process and procedures written for the right audience? Companies often write and organize them for everyone but the people who need them. Sometimes the focus is on meeting corporate management expectations. Alternatively, the focus may be on satisfying an external auditor to demonstrate compliance with a business system standard.
For example, this can sometimes occur with companies working to become ISO 9000 compliant. Documenting the quality management system takes precedence and colors other business functions including project controls. Another example is the EIA-748 Standard for Earned Value Management Systems (EVMS) 32 Guidelines[i]. “Compliance” becomes the focus instead of making sure the people planning and managing the work have accessible, useful guidance to do their jobs effectively.
If your project control process and procedures are written for someone other than the project personnel, how do they know what to do to perform their day-to-day project control tasks?
What are some of the indicators your process and procedures may be written for someone other than project control personnel? Are you noticing:
- Project personnel are using ad-hoc, one-off project control documents, forms, or other materials? When project personnel can’t find what they need, they frequently reinvent it or reuse something from another project. This could be good or bad. Either way, project personnel are left to their own devices when they perceive a common standard for preferred practices hasn’t been established.
- Schedulers or project control analysts using “side drawer” schedules or spreadsheets? The typical response when questioned is “Oh, what’s in the toolsets doesn’t represent what I am really doing.” A good indication something is seriously wrong with the quality of the project control data or people don’t know how to use the toolsets properly.
- An overabundance of guidance or overly prescriptive guidance? This is a common result from the usual prescription to any problem – we need more documentation or we need more training. That will solve it! What usually results is more “guidance” piled higher and deeper. Frequently the stack of documents have sections of repetitive or similar content on the same topic. Another problem then surfaces – the multitude of documents provide inconsistent guidance. Which one is “right”? How do people know which one to use?
- Your project control process and procedures are organized by external standards or reflect what someone assumes an auditor would be looking for? There is a high probably the process and procedures don’t reflect the process flow someone would normally follow. The documents become “shelf ware” to check off something for management.
- Project personnel don’t bother finding, let alone reading and following, documented processes? This is a common indication documented processes are confusing, dense, provide conflicting guidance, or people simply can’t find what they need to resolve an immediate project control issue. No one thought about the issues project personnel might run into! This can happen when people who have no idea what project controls means produce a raft of documentation that doesn’t reflect real needs.
What can you do to make an immediate difference?
Should you find yourself in this position, what are some things you can do to make an immediate difference?
To help with this discussion, the image below is a model that represents the levels of project management or project control process and procedures that may come into play. You may have different labels for them and perhaps you organize them differently. Maybe you don’t have everything illustrated here. The main idea is there is typically a hierarchy to them.
- Level 1 – Management Policy. Corporate management high-level rules, objectives, or overall statement concerning project management expectations for all projects.
- Level 2 – Process Description. Describes the process a company follows to manage projects.
- Level 3 – Workflow Procedures. Some companies incorporate this lower level of detail into the process description or they are a separate set of documents. They include swim lane flowcharts with labeled steps noting who is responsible for what. They discuss the process flow for specific process areas and may provide additional details such as applicability, entrance and exit criteria or expected outputs from the process. Examples include the work authorization process or the process to develop a resource loaded integrated master schedule.
- Level 4 – Implementation Guides and Training Materials. Not all companies have implementation guides, some of them may be role based. Examples include a Project Management Plan for new projects, risk management guide, or scheduling guide. Training materials may be focused on process or the toolsets and may be role based. The most effective training combines how to apply the process or follow a procedure using the toolset.
- Level 5, the lowest level, is the content most useful to those using the toolsets to do their project control tasks.
Start at the Bottom
To make an immediate difference, one approach is start at the bottom – the desktop instructions for project personnel. Desktop instructions provide the step-by-step directions on how to use specific toolset functions to accomplish project control tasks. They focus on accomplishing one task in a specific tool such as creating a new WBS. Provide screen captures and notes to help people accomplish their tasks to support preferred best practices and to create quality data.
Why start at the bottom? A top down approach frequently takes too long because of approval processes and working through the chains of command. It can take months to develop and agree upon the process and procedure content without making a difference in how projects do things right now.
Focus on creating a core of desktop instructions for the most important tasks or focus on areas where project personnel are having the most difficulty. For example, how to enter or code level of effort (LOE) activities in the network schedule so they do not affect critical path calculations.
As you are going through this process, keep in mind you may need to revisit how you have configured your project control toolsets. In hindsight, you may discover you need to recode your data so you can properly integrate your schedule and cost data. A schedule and cost data quality assessment can help in pinpointing the problem areas. This in turn can lead to enhancements in the process and procedures to eliminate issues at the detail level.
Don’t try to solve the entire project control process and procedure issue. Tackle the day-to-day tasks and align them with your preferred practices. As you progress, you can add things that complement the desktop instructions such as:
- Templates or examples. These provide people with a place to get started or model to follow. Extremely helpful to learn what is expected.
- Decision trees. These are helpful for scaling project control practices or providing guidance on what to do in response to different conditions.
- Checklists. Always useful to help people verify they have performed all the steps, entered the necessary data, or performed data traceability and validation checks.
If you need help creating desktop instructions, PrimePM has the expert toolset resources to do just that. We frequently assist clients to implement project control toolsets and work with them to produce desktop instructions as job aids for project personnel.
Also see our next blog on designing the project control process for project personnel.
[i] Instead of purchasing a copy of the EIA-748 Standard, an alternative is to download a copy of the NDIA IPMD EVMS Intent guide for the EIA Standard for EVMS available on the Division Guides and Resource web page.