PC-3.0 Contract Management

Location:  PMKI > Project Controls 3.0 > PC3.0 Contract Management.

Project Controls 3.0 (PC-3.0) is designed to build onto the existing developments in project management and project controls to:
- Overcome problems in current project management
   and controls practices,
- Implement a simple, robust system that is effective
   for all types of project delivery, and
- Refocus the controls effort on helping management
   craft success.

Topics included in PC-3.0 Contract Management:

- Project Controls 3.0 - Contractual Requirements 
- PC-3.0 Delays
- Useful Papers & Resources.

Other related sections of the PMKI:

- Project Controls 3.0 (PC-3.0) 
- Work Performance Management (WPM) 
- Traditional Project Controls 
- Basic Contract Law
- Forensic Analysis

---

Project Controls 3.0 Contractual Requirements

Introducing PC-3.0 and the use of Integrated Project Teams (IPTs) for each WU whilst benefiting from a supportive head contract, does not require much change in this level of documentation. The client wants its project delivered on time and to the required quality standards. If PC-3.0 is achieving this everyone will be happy. Generally, a client cannot dictate how a contractor performs its work, and while having client representatives embedded in each IPT is desirable it is not essential.

The project’s subcontracting and procurement activities is where change is needed. The relationship with suppliers and subcontractors needs to be developed to facilitate an adaptive approach focused on success. Various forms of alliance, partnership and gain-share/pain-share contracts are needed.

Blg: Complicated vs Complex – Understanding Complexity. Estimating, planning, and managing a complex project requires a different approach. This post looks at some of the key differences between managing a complicated project and managing a complex project.PC-3.0 has been designed to work in both situations.

---

PC-3.0 Assessing Delay

Contrary to modern dogma, you do not need a CPM schedule to assess delay and disruption. Projects using PC-3.0 will inevitably be subject to changes, variations, and disruptions in the same way every other project is, and has been for the last 100+ years. The law relating to contracts, delay, and liquidated damages, was determined in the 19th and early 20th centuries, decades before critical path scheduling (CPM) became commonplace in the 1960s.

Assessing delay and disruption in projects that are not using CPM requires the same fundamental fact to be demonstrated:

• An intervening event occurred, disrupting the work
• The intervening event caused a delay to the work of the project which flowed through to cause a delay in completion
• Under the terms of contract, the delay is claimable.

All that changes is the way the delay and its consequences are demonstrated.

The assessment of delays and disruption shifts away from its effect on an arbitrary sequence of activities in a CPM schedule, to understanding the effect of the intervening event on the productivity of the resources working on the project. The best way to make this assessment will depend on the nature of the intervening event. Four adaptations of this basic concept are outlined below:

1. Full project delays. Delays affecting all the work of a project are the easiest to assess. Events such as project wide industrial action, major weather events, and other similar occurrences that stop the work simply need the duration of the delay to be determined.
    
2. Homogeneous team delays. Many projects are worked on by an integrated team of people, where to a large extent one person can cover the work of another. This is common in many soft projects (particularly IT), but can occur in other situations. Basically, a team of people are assigned to deliver the project, and they work as a homogeneous, cross-functional team. In this situation a delay occurs when an intervening event reduces the productivity of the team.
    
3. Driving resource workflow delays. In other projects, typically hard projects, the work is delivered by a series of discrete resource teams working in coordination. The members of each team are generally not interchangeable, having different qualifications and skill sets. In this situation assessing the disruption to the key resource that is controlling the overall workflow may be a more appropriate way to measure delay.
    
4. Work volume delay assessment. Some changes do not have an immediate effect on productivity or require changes to the short-term work sequence, but will delay the project, these are usually changes in scope. Provided the change is made sufficiently early in the project, the only consequence is the team has more work to do.

How these types of delay are calculated are discussed in Assessing Delays in Agile and Distributed Projects.

Click through to see more on assessing delay and disruption.

---

Useful Papers & Resource

PP: Assessing Delays in PC-3.0 (Agile & Distributed) Projects. This paper focuses on assessing delay and disruption in PC-3.0 projects where there is no CPM schedule, other agile or adaptive approaches are being used to manage some or all of the work. This paper offers a practical solution to the challenge of assessing delay and disruption in this type of agile and distributed project, where the traditional concept of a ‘critical path’ simply does not exist and the effect of intervening events has to be considered in terms of loss of resource efficiency.
Download the PowerPoint: P215 Assessing Delays In Agile & Distributed Projects PPT 

Click through for more on Forensic Schedule Analysis.