How do you provide guidance for project managers to help them implement preferred practices at the “just right” level needed for management visibility and control? There is often a delicate balance between implementing useful practices project personnel understand and support versus what they view as a hindrance to getting their work done.
Maintaining that balance is one reason for making the effort to implement a scalable project control system. It supports finding that “just right” level of control for each project. As discussed in a previous blog, scaling is the art of selecting the appropriate level of data detail, project control discipline, and range of project control practices to match a project’s characteristics. The project control practices become more robust as the demands of the project increase.
Providing useful guidance to a project manager on how to scale your project control system takes some thought so it reflects your business environment and is easy to use. A decision tree, matrix, checklist, or table can all work. What follows are some suggestions that you might find useful to build out a framework for your project personnel.
Creating a Framework
Step 1. Identify the general categories for the scope and rigor of the project control practices for the different projects you typically perform. Two examples for you.
Example one: Two general project categories as illustrated below.
For this example, Category A would use basic project control practices. Category B would require more robust project control practices with more data detail and project control discipline to manage the project. In situations where the project categories are very clear-cut, a decision tree could work very well. Not everyone is that lucky.
Example two: The “Goldilocks” categories: small, medium, or large as illustrated below.
Category A would use basic project control practices. Category B would use additional practices with more data detail and project control discipline. Category C would use a greater range of practices and data detail with more robust project control discipline. There is an advantage to something other than just “A” or “B” without going overboard on the number of categories. It allows the project manager to find that “just right” level of project control. They can tailor their approach within an overall framework.
Step 2. List the project characteristics or attributes that would help guide the decision making process for the categories. What are the most important factors in your business environment? For discussion, perhaps your list looks something like this:
- Type of work
- Scope of work requirements
- Contract value
- Complexity
- Project duration
- Skill mix
- Risk score
- Subcontractors performing work
- Contractual requirements
Step 3. Qualify the attributes. These are the specific attribute details to help you decide what project control practices apply and what level of project control discipline is required. Using the list from Step 2, you could build out a table that looks something like this:
| Type of work | T&M, services, or support | Discrete or measurable | Development, discrete, or measurable |
| Scope of Work Requirements | Well defined | General with decision points and funding gates | Adequately understood, may change and evolve |
| Contract value | < $20M | = or > $20M and < $100M | = or > $100M |
| Complexity | Low | Moderate | High |
| Project duration | < 18 months | > 18 months | > 18 months |
| Skill mix | Normal in-house resources | Normal in-house resources plus resources from other division of the company | In-house resources plus hire or out-source for specialized resources, resource mix is critical to project success |
| Risk score | < 50% | = or > 50 % and < 70% | = or > 70% |
| Percent of subcontract work effort | < 40% | = or > 40 % and < 60% | = or > 60% |
| Value of subcontract work effort | < $5M | = or > $5M and < $20M | > $20M |
| EVMS FAR or DFARS clause | N/A | May be included in contract | Included in contract |
| EVMS reporting (IPMR DID) | N/A | May be in the CDRL | CDRL requirement |
For this to work, you will need to determine the scope, range or other specifics about the attributes as illustrated in the table above. For example, what do you consider to be:
- Low, moderate, or high contract value?
- Low, moderate, or high level of complexity? This may be related to the nature of the work scope, resource skill mix, external risks, and other factors specific to your environment.
- Low, moderate, or high risk? Perhaps your risk/opportunity management system risk scoring process helps you define what this means to you.
You could also use a checklist or point system for specific attributes to help guide the project managers. With a point system, you could assign more weight to those attributes that have a greater influence on determining that “just right” level of project control. This could reflect management priorities or other factors in your business environment.
What’s Next?
Now that you have that framework of project categories and defined project characteristics for each category, the next step is to define the expected practices for each category. The table below illustrates one approach: a list of project control components with implementation details for each project category. This includes the level of data detail and project control discipline.
| WBS, project OBS, control account level | High level | Scale to fit an intermediate project needs | Scope of work determines appropriate level for work authorization, management visibility, and control |
| Work packages | Longer duration with interim milestones | Shorter duration, objective completion criteria |
| Basis of estimate | High level | Detailed |
| Activity to work package relationship | One-to-one | One-to-one or many-to-one |
| Accomplishment criteria | High level | Specific; quantifiable backup data for performance measurement |
| Actual costs and estimate at completion analysis at | Control account level | Work package level |
| Rolling wave planning | Usually not necessary | Establish rolling wave planning cycle, routinely use control account planning packages and summary level planning packages for future work effort |
| Variance analysis thresholds – what is considered “significant” | High level or simple. May reflect thresholds for number of days (schedule slip), number of hours, or cost value in excess of plan | Contract or project manager determines – may be based on reporting level, risk, or other factors |
| Schedule risk assessment | Optional | Optional | Required |
| Risk/opportunity (R/O) management | Risk register optional | R/O register, risk qualification | R/O register, risk qualification and quantification |
| Baseline change requests | High level or simple log | More formal documentation, log | Formal documentation, what-if analysis, change tracking log, reconciliation |
| Change control board | N/A – project manager approves changes (within specific parameters) | Optional | Required |
| Internal baseline review | N/A | Optional | Required |
In a scalable environment, project managers could produce project specific directives describing how they intend to implement the standard project control system on their project. This could be part of the project management plan developed during the initiation or planning phase of the project immediately following authorization to proceed.
You can also use this framework to organize specific templates or expected inputs or outputs that project personnel use for the different categories of projects – basic, moderate, or robust. This helps to increase consistency in how project personnel apply the preferred project control practices for a given project.
Are you working on the best way to scale your project control practices? We can help. Our cross-functional project control experts can provide the assistance you need to create a framework for your business environment.