Need help with your project control system? Call us today at 877.447.0290

Scaling project control practices

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.

Scaling a Project Control System

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.

Two project control categories

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.

Three project control categories

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:

Project CharacteristicsRange of Project Control Practices
Type of workT&M, services, or supportDiscrete or measurableDevelopment, discrete, or measurable
Scope of Work RequirementsWell definedGeneral with decision points and funding gatesAdequately understood, may change and evolve
Contract value< $20M= or > $20M and < $100M= or > $100M
Project duration< 18 months> 18 months> 18 months
Skill mixNormal in-house resourcesNormal in-house resources plus resources from other division of the companyIn-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 clauseN/AMay be included in contractIncluded in contract
EVMS reporting (IPMR DID)N/AMay be in the CDRLCDRL 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.

Project Control Components Level of Data Detail and Project Control Discipline
WBS, project OBS, control account levelHigh levelScale to fit an intermediate project needsScope of work determines appropriate level for work authorization, management visibility, and control
Work packagesLonger duration with interim milestonesShorter duration, objective completion criteria
Basis of estimateHigh levelDetailed
Activity to work package relationshipOne-to-oneOne-to-one or many-to-one
Accomplishment criteriaHigh levelSpecific; quantifiable backup data for performance measurement
Actual costs and estimate at completion analysis atControl account levelWork package level
Rolling wave planningUsually not necessaryEstablish 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 planContract or project manager determines – may be based on reporting level, risk, or other factors
Schedule risk assessmentOptionalOptionalRequired
Risk/opportunity (R/O) managementRisk register optionalR/O register, risk qualificationR/O register, risk qualification and quantification
Baseline change requestsHigh level or simple logMore formal documentation, logFormal documentation, what-if analysis, change tracking log, reconciliation
Change control boardN/A – project manager approves changes (within specific parameters)OptionalRequired
Internal baseline reviewN/AOptionalRequired

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.


Subscribe to our blog