Medecins Sans Frontieres Doctors Without Borders

Join the PM.com.au Community

Project Manager

Australia's online resource for project management professionals


How do project managers lose control?

Defining project controls

Several months ago at the Project Governance and Controls Symposium in Canberra I was asked to define project controls. The Australian Institute of Project Management (AIPM) has a project controls Special Interest Group (SIG), the Project Management Institute (PMI) has a couple of ‘Communities of Practice’ (COP) focused on aspects of ‘controls’. PMOs do ‘controls’ and everyone talks about the importance of ‘controls’. Where there is no real agreement though is in agreeing exactly what is included in project controls and how controls relate to other disciplines such as project governance.

The term control or controls is used widely and there are at least three distinctly different uses:

  • Control systems
  • Management directing and controlling work (PMI’s monitoring and controlling)
  • Project controls discipline

Control systems measure progress versus the plan and then, through an adjustment, correct any observed deviations. The steering mechanism in your car, when connected to your eyes is a control system. Your eyes and brain assess the current trajectory of the car and compare this to the desired trajectory and by adjusting the steering wheel, you alter the progress of the car.

Every manager controls the workforce s/he is responsible for: by definition management includes directing and controlling a workforce (for more on management see: Defining Management).

Then there is the project ‘controls discipline’, which I’m trying to define. My proposed definition for ‘project controls’ is:

Project controls are the data gathering, data management and analytical processes used to predict, understand and constructively influence the time and cost outcomes of a project or program; through the communication of information in formats that assist effective management and decision making.

This definition encompasses all stages of a project or program’s lifecycle from the initial estimating needed to ‘size’ a proposed project, through to the forensic analysis needed to understand the causes of failure (and develop claims).

The functions undertaken by project controls professionals includes estimating future works, determining the current status of work in progress, understanding the reasons for this status and recommending appropriate actions or alternatives based on the observed status and trends.

Within this framework, for a recommendation or prediction to be useful, the reliability of the information upon which it is based needs to be understood, and additionally, any realistic estimate or forecast must take into account uncertainty and the cost and time consequences of identified risk events.

Consequently, the project controls discipline can be seen as encompassing:

  • Project strategy, planning and methods studies to optimise future outcomes
  • Scheduling, including development, updating and maintenance
  • Cost estimation, cost engineering/control and value engineering
  • Risk management
  • Earned Value Management and Earned Schedule, including WBS, OBS and other breakdown structures
  • Document management
  • Supplier performance measurement/oversight (but excluding contract administration),
  • The elements of a project management methodology that integrate these disciplines both within the controls’ domain and with other project management functions; and
  • The ability to communicate effectively the information generated by these processes.

This proposed definition deliberately excludes the actual management of the work needed to accomplish the project scope, including scope related disciplines, such as quality control and administration, and general management disciplines such as team development, stakeholder management and communication.

Quality control versus project control

Quality is an integral part of doing the work; quality is built into the fabric of a process in exactly the same way team performance is. Given the basic assumption in the definition above that project controls professionals are not involved with the direct management of the work, they cannot be directly involved with the management of quality (quality is designed in, not inspected in).

Even quality inspections (quality control and/or testing) are simply work items undertaken by the project team to complete the required scope. The work is defined by activities in the schedule and has associated costs, etc but is fundamentally the same as digging holes or pouring concrete. Similarly, contract administration is an integral part of doing the work. Administering a contractor is fundamentally the same as directing the work of employees in a project team and is very much a function of management.

The consequences of the team’s ability to achieve quality, administer contractors and perform effectively, and any other aspect of actually doing the work will generate or influence data that may be important in planning, monitoring and/or predicting project outcomes and this aspect of ‘observing the actual accomplishment of work’ is implicit in the definition.

The surveillance aspects of time, cost and risk are intimately linked to how well the team can accomplish the project’s scope, to the required quality standards. And to close the loop, the information generated by the ‘project controls professionals’ based on their observations is an important input to these and other management functions.

To summarise, the role of ‘project controls’ is information generation, the role of management is to make effective use of the information. Project controls professionals work with the team and other stakeholders to plan the optimum way of accomplishing the work, then measure the actual performance of the team against the agreed plan and use this data to recommend future actions and predict outcomes. This means project controllers are the experts who gather, manage and analyse data to generate useful information and insights for others to use. And the primary users of the ‘controls information’ are the project management team and project governance and oversight entities within the organisation such as PMOs and ‘project control boards’ (PCBs).

Most authorities recognise that it is impossible to effectively manage or govern a project (or program) in the absence of reliable information on the current status of work in progress, and reliable predictions of future outcomes. This is supported by this proposed definition, with the key delineator between ‘controls’ and ‘management’ being the recognition that it is management’s role to make use of the information and advice generated by the controls professionals.

Once the definition of ‘controls’ is resolved, the next step will be establishing a framework of certifications and qualifications to benchmark ‘professional’ knowledge and behaviours. There is already good progress in this area with developments by AACEi, Planning Planet, PMI and CIOB to name a few (see more on PMI and CIOB credentials).

What’s lacking in the general ‘market’ is a general recognition that effective controls professionals need domain knowledge as well as tools knowledge. Developing this recognition is the next challenge. Your feedback and ideas are welcome!

admin
Patrick Weaver is the managing director of Mosaic Project Services and the business manager of Stakeholder Management Pty Ltd. He has been a member of both PMI and AIPM since 1986 and is a member of the Asia Pacific Forum of the Chartered Institute of Building. In addition to his work on ISO 21500, he has contributed to a range of standards developments with PMI, CIOB and AIPM.
has written 57 articles for us.

Comment



Need a Gravatar (the image next to your comments)? Visit Gravatar.com

Comments from the community

  • Salman Jaffery says:

    Hi Patrick,

    Excellent information……………….

    I would like to share my experience of controlling the project, actually working in bank which consists of more than 1,100 branches across the country so you can imagine the volume of the projects and more immortality the different types of stakeholders involve in these projects and to control them as per the need of the projects is a huge task…………..

    Actually, we developed a PM framework as per the need of the AUDIT…………because here in my country people give a lot of importance to a audit thing…….so we develop a PM framework which revolve around the audit requirements and thats our integral part of the project control along with another process we use to follow is ” Baseline”………..only PMO in our organization has the authority to change the baseline of the project……we are in the teething phase of this process but up till now works fine…………..

    Whats your thoughts on the above approaches we have………………

    Regards
    Salman

    • Pat Weaver says:

      Methodologies should be designed to achieve cost effective benefits for the organisation, not to meet audit requirements. See: http://www.mosaicprojects.com.au/WhitePapers/WP1045_Methodologies.pdf

      Audits should be designed to ensure the best outcomes from the project not to enforce processes. The questions a good project review asks are set out at: http://www.mosaicprojects.com.au/WhitePapers/WP1080_Project_Reviews.pdf

      • Salman Jaffery says:

        Thanks Patrick,

        Excellent write-ups…….especially the second one i.e.”Proactive Project Surveillance”…………………honestly speaking We are only following one or two aspects of PMO functions which you have mentioned………….

        As far as white paper of Methodologies is concern…..we are very much on the same page………….

        Patrick………….very soon I am coming to sydney and would like to do a job in the field of Project Management……………………what you suggest…….what sort of areas I should look at…….what should be my approach to get into the field……………..what sorts of skills i should learn to attract the market……………..need your suggestions…..

        Thanks
        Salman

  • Michael says:

    Well written!

    I concur with your definition and the reasoning behind it.

    Where I disagree is that project controllers require domain knowledge as well as tools knowledge; although, in saying that, I need to clarify what you mean by “domain knowledge”.

    If you mean knowledge of the project controls domain, then I absolutely agree with you.

    If you mean knowledge of the domain in which the project is executed; for example, product commercialisation, technology implementation, business strategy, among others, then I disagree that the project controller requires this domain knowledge. From a project controller perspective, they ought to be able to gather, analyse, and communicate the project data regardless of the project domain.

    Michael

    • Kim Smith says:

      Hi Michael. Please tell me the steps you would take to lead a review of a large utilities project controls. Is there any specific software you would recommend? The size of the companies vary but I would say medium to large size. Would you recommend Ecosys or microsoft.com to streamline data extraction and assist in forecasting. Assuming the WBS, OBS and Enterprise structure is in place with roles and such.