Project Controls: Earned Value 101

by Okitanye Gaogane

warning-signsIf you own one of those sophisticated cars with fancy dashboards, then you have project management analytics right in front of you.

We have all experienced that orange tank. Are you one of those drivers that take heed of the sign and get to the nearest petrol station to refuel, or do you let the car come to a stop first, call a cab, buy a container and go and buy extra fuel? The car operates off of resources and the dashboard acts in an advisory capacity. Taking heed of the warning indicators on the dashboard is metaphorically what Project Controls is.

Now here is a classic office case that explains project performance, project analytics and simplifies earned value management. Our office has an 80L capacity petrol tank car and when you drive at normal speed doing 12km/L the fuel will cover 960km. Gaborone-Kasane is 924km, so if we send a consultant on a Kasane mission on a full tank we have a nice contingency of an extra 36km.

I have a colleague, who shall remain anonymous in this article lest the law enforcement officers start following him. If I give him this car, by the time he is halfway to the destination, the fancy dashboard will be reading Distance To Empty DTE: 100KM. If he ignores this he will not even make it to Nata.

How does this relate to project management? This consultant I am referring to, the only thing that matters to him is time. He breaks traffic (project management) rules and is very wasteful in terms of resources (petrol) because to him the most important thing is Time; not necessarily a bad priority. We have seen this in a number of projects, haven’t we? His argument is that there is quality in the ride, and I say he is a risky and wasteful fellow in many ways.

Back to earned value. What is earned value?

Englert and Associates, Inc. define it as, a method for measuring project performance. It compares the amount of work that was planned with what was actually accomplished to determine if cost and schedule performance is as planned.

In our scenario, the plan was to have used 462km worth of fuel (P293) this is referred to as earned value. The dashboard says we have used 860km worth of fuel (P545), this is called actual performance. Our cost performance index says that for every 53 km traveled we are spending 100 km worth of fuel. This does not take a genius to figure out that to arrive in Kasane at the same speed we need and estimate to completion of twice the original budget. The beauty of analytics is that you now have to make informed decisions on whether you will do a budget change request and continue at the same driving behavior or sacrifice speed for resource conservation.

Cutting the story short, if you are leading the project and you have no way of reporting current performance and extrapolating future performance, then you are as good as driving a car without a dashboard. You will get a lovely surprise when the car stops in the middle of nowhere. At a national level, I can only hope that future projects have at a bare minimum cost controllers, schedule controllers, planners, and risk managers to manage the MEGA Pula project analytics. This is business, we need to EARN VALUE for every taxpayer-PULA spent.

Okitanye Gaogane holds the position of Academy Manager at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw.

Do Engineers Make Great Project Managers?

By Pardon Baleni

“Are you less likely to have an accident while you’re on the driver’s seat or on the passenger seat?”When posed with the question, most people will choose the former as their answer. We make ourselves believe that when we are in the driver’s seat, we can avoid accidents or we`re better protected against drunk drivers, tyre bursts and whatever else could possibly come our way. That’s a daring illusion!

Without prejudice, some Engineers think they can manage projects better if they are the ones on the driver’s seat. Trust me it is good to be an Engineer, however being a good Engineer does not necessarily make someone a good Project Manager. It takes a man/woman with in-depth knowledge of soft skills and experience to be a good Project Manager.

The skills required to be a good Project Manager are distinctly different from the focused skills cultivated in disciplines which require subject matter expertise such as science, technology, and engineering. Besides needing excellent analytical skills, the Project Manager must also have interpersonal skills necessary to communicate with nearly anyone across the breadth and depth of an organization as well as leadership characteristics necessary to build teams and lead people.

The Project Manager must have the ability to grasp different concepts and know when they are out of their parameters.When managing large projects for a big organisation, a lot of time and effort is spent on the scope, budget, cost control, schedule, politics, dealing with corporate managers and directors across the world as well as local stakeholders, unfortunately, not all Engineers are skilled in these aspects.

Many companies do not recognize this unique set of capabilities so they promote successful Engineers into positions of leadership. “Anything that works will be used in progressively more challenging applications until it fails”- That`s the ‘Peter Principle’ at work. This theory purports that the selection of a candidate for promotion is based on the candidate’s performance in their current role, rather than on abilities relevant to the intended role. The results are evident; the company loses an excellent Engineer and gains a terrible leader. The rest is history.

Because Engineers are educated by discipline, their ability to become good Project Managers is dependent, to a large extent on their ability to absorb knowledge about other disciplines because rarely do engineering projects only involve a single discipline. I am not ruling out that there are good candidates for Project Managers among Engineers. Engineers are singularly focused people with expertise in their relative field of study. If the project resides in their respective field and they have the soft skills and experience mentioned above, they can make for an excellent Project Manager.

Firstly, Engineers must realize that they will probably no longer be doing nuts-and-bolts design work, but instead will lead a team of people responsible for that work. Secondly, they will be going from sole proprietor to learning how to get things done through others. To do that, they need to create an environment that fosters self-motivation.

Currently, projects going downhill are likely attributed to inexperienced individuals assigned to manage projects. It is unfortunate that anyone can be appointed to be a Project Manager without interrogating their skills and capabilities for managing capital projects. That brings me to the core of my point; Why not have a regulatory body for Project Management Professionals?

Botswana has regulatory bodies such as Institute of Botswana Quantity Surveyors, and Engineering Registration Body (ERB) among others. Professional regulating bodies are an essential aspect of affording protection and accountability of those practising the respective disciplines and ensure quality is derived from its members. In this token, it is paramount that as Project Management professionals, we have a regulating body within Botswana.

Like any other regulatory body, The Project Management Professionals Body will impose requirements, restrictions and conditions, set standards in relation to any activity and secure compliance from all its members. It will verify the authenticity of professionals seeking admission to its register. The regulatory body will produce regulations to ensure that its registered members will have clear guidelines on issues of competence, authentic servicing and promoting the utmost standards of project management practices.

I’m not against giving opportunities to people who are willing to become Project Managers. However, recognition should be given to those holding the ‘protected’ title and demonstrates the right to use such a title.

Pardon Baleni holds the position of Project Planner at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw

 

Project Deviations: A Painful Project Reality, Part 2

By Victor Marathe

Why do we often get it wrong?

A project deviation is anything that deviates from the ground zero intent of the project. If it was not planned for or accounted for at inception of the project, it’s a deviation. This includes any change in cost, cash flow, schedule, execution approach, project requirements etc.

On the basis of the definition above it goes without saying that most deviations are not accounted for because they fall outside the conventional perception that project deviations are primarily only related to scope. So for instance change in specifications, design parameters and other project criteria are not always treated and handled as deviations by project practitioners. That is fatal flaw number one in deviation management.

Fatal flaw number two arises from the surface level assessment and evaluation of a deviation. That is the evaluation of deviations on face value, without an in-depth appreciation of the DNA of the deviation through establishing the reach of the deviation.

Fatal flaw number three occurs in assuming that communication of a deviation constitutes  the integration of the deviation. Also falling into this trap is the assumption that only approved deviations are communicated. Communication is no guarantee that the approval and/or rejection of a deviation will be implemented.

Fatal flaw number four occurs when viewing the cost impact from either an implementation point of view or a capital investment point of view. Every deviation has two classes of consequences and both these classes have to be assessed for a 360-degree assessment. There is the cost and schedule impact to execute and implement the deviation and the capital cost of the deviation. Both can be very costly depending on the nature of the deviation. Failure to fully assess the deviation from both perspectives is always a recipe for disaster. In both cases, the schedule impact can come with its own set of costs emanating from standing time issues, changes in procurement packages etc.

A simple technical deviation can have seemingly negligible direct costs and schedule impact. However, the execution cost can be very hefty, or it might seem to have negligible resource requirements to execute, but the capital ripple effect may be outside the financial risk appetite of the investors.

Deviation management forms the core of the project controls function. If a project executes its deviation management process well, then it is able to provide a more informed and accurate cost and schedule forecast. Without such a process, project forecast will always be more of an analytical output than the result of a physical process.

How do we get it right?

The project deviation management process should integrate all other controls functions. For a truly integrated project controls function to take effect, a 360-degree approach to project deviation management is essential and must be entrenched across all levels of the project structure.

The project environment is an exceptionally integrated environment, therefore it is erroneous to assume that a deviation in one project area or discipline will not have even a minute impact on any other area or discipline. Time and again it has proved to be a very costly oversight in many failed projects.

Good concepts and intent quickly turn into an investment and project management nightmare, and very often the disaster can be traced to one variation or another.To avoid this pitfall, the point of departure must always be from a premise that deviations are multi-layered and multi-dimensional. This premise then demands that both direct and indirect deviation consequences are accounted for by applying a multi-layered 360-degree approach.

Assessing a deviation through a 360 layered approach assumes that the first and second impact layers are primarily direct consequences and the subsequent impact layers are indirect consequences from the initial deviation. Each subsequent layer is a direct impact layer of the previous layer and hence often triggers other deviations that need to and should be assessed in their own right. That is what triggers the tsunami effect of a deviation.

The underpinning principle of a 360-degree multi-layered deviation management approach is that whenever and wherever a project deviation occurs, the project deviation should trigger an impact enquiry into each one of the management processes and technical disciplines that constitute the project profile. In turn, each process and/or discipline should trigger its own set of enquiries to each process. The response should work in the reverse order back to the change management process, which in turn informs on the cost, schedule, quality and scope consequences of the deviation.

Only by religiously applying this approach can a project accurately determine the true consequence of a project deviation and therefore make an informed decision on the way forward.

Post decision, the integration process should be started in earnest. It should involve a three step process of communication, implementation and verification. This should be applied to all decisions regarding a deviation, albeit to different levels of intensity.

The process of integrating a change is the reverse order of the assessment process. This reverse order 360-degree process is meant to ensure that all functions considered in the assessment process have considered the deviation and adjusted as necessary.

The disconnect that arises from the failure to fully implement the deviation across all project elements can be very costly. More-so that this disconnect is often realised at the tail-end of the project lifecycle.

In a 360-degree approach, a project deviation request should only be closed post a deviation integration audit. This is not an audit in the true sense of the word, but rather a verification that all project documentation has been adjusted and all related implications across all project areas as identified in the assessment stage, have been accounted for.

That’s how a well-integrated and functional 360-degree multi-layered project deviation process should work.

Get your Project Deviation Management process right, and you have won half the battle in project controls, otherwise the project controls the team.

Victor Marathe holds the position of Senior Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training Solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw

Project Deviations: A Painful Project Reality, Part 1

by Victor Marathe

Show me a project that has not undergone a change in the execution of intent, and I’ll show you a pig that can fly.

How often have you started a renovation or home improvement project which seems fairly straight forward at first, before it quickly spirals out of control? This happens because the extent of the change is often only evaluated within a very small radius of influence from the point of occurrence of the change. This domestic approach to deviation management is also widely practiced in the project arena. Project practitioners often approach deviations at face value. This is to say that project deviations are often evaluated from a visible and focal point perspective rather than delving into the peripheral and less visible impact.

Let’s consider a mini domestic case study. Say we want to add a closet in one of our rooms. Seems simple enough; break wall here, extend another wall there, shelve it and get a nice door for it. We get a quote for materials and labor, and we proceed. The nightmare starts as soon as we break the wall; there is the piping and electrical cable running through. The piping goes one way and the electricals the other. We soon realize we will have to do some plumbing and electrical re-routing. Not in our budget. And our roadside contractor does not do electrical or plumbing works. And so begins the waterfall of the quality, cost and time constraints we had set for our little project.

By the end of our little project, we have replaced broken tiles, repainted the walls, and so on. This is a rather simplistic analogy, but that is not an unfamiliar path in supposedly well planned, well-resourced industrial projects.

Project deviations or changes are the one certainty in a project. As certain as it is, it is one of the Project Controls function that is not executed well. The impact of Project Deviations can and often transcends the focal point of the deviation. They are the number one triggers of cost and schedule overruns, and yet the process is often not approached with the vigor that it should be. The attention is often misplaced at the reporting end of the cost and schedule impact. The impact on quality is often not given any attention unless something goes drastically wrong.

Deviations are not necessarily detrimental to the success of a project. It is how they are managed, controlled and integrated that dilutes the true value of the deviation. Project practitioners often fall short of a 360 degree peripheral perspective on a deviation.

The ability of a project to effectively monitor, manage and control project deviations is a key indicator of how well the project management processes are integrated. The cost and schedule management processes are only as effective as the project deviation management process.

The prevalent approach to project deviations is a one-dimensional approach. This, in essence, is applying only inherent general project management practices in dealing with deviations. This one layered approach is really a tick the box exercise and does not create the value that the process is meant to create.

There are basically two main sub-processes in managing deviations. The first stage of the process is the Deviation Assessment Process (DAP), this is then followed by the Deviation Integration Process (DIP).

The DAP is the procedure that should assess the deviation through a Registration, Definition, Evaluation, and Decision-making process. This is where the wheels usually start coming off. How well a deviation is defined and evaluated is critical in assessing the real impact of the deviation. The process should account for direct and indirect consequences.

Direct impacts are more visible and are within the immediate sphere of influence of the focal point of the deviation. The indirect consequences are more downstream and less readily identifiable without an in-depth deviation analysis.

The focus on direct impact alone is a one-dimensional perspective of a deviation and does not give an indication of the true impact of the deviation. This is the more common and documented approach in many project environments because it is the path of least resistance and satisfies most project reviews.

The DIP is the processes that facilitates the integration of a deviation into the project. This process should ensure that the deviation is approved and has been accounted for throughout the project. It is important to note that integration of a deviation is more than just communicating the deviation as is often practiced.

The next article will focus on why we often get it wrong and how to get it right!

Victor Marathe holds the position of Senior Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw

PMO Managers DIY Toolset for Self-Audit

by Jurie Moolman

PMO (Project Management Office) Managers do need to take stock of the effectiveness and efficiency of their PMO’s from time to time – but rather than always bringing in an external consultant to do this, the below article gives a framework of how the PMO Manager can go about to do such by him/herself (DIY – Do It Yourself) – maybe with the aid of a consulting company like InnoLead, if needed.

Typical project symptoms that indicate that it is time for a PMO audit could be:

  • Projects do not complete on time coupled with failure to achieve cash flow.
  • Deviations from the standard project management processes which are supposed to guide project managers to ensure the predictability of outcomes.
  • Insufficient Executive/Organisational support to projects, for example, a slow decision-making process or lack of understanding of the Project Sponsorship role.
  • Ineffective organisational structures

DIY Step 1:

PMO’s are part of a larger organisation, and the first area to take stock of – is to confirm if the larger organisation is still in support of the PMO objectives and this could be done through an objective measurement of the organisation’s project, programme and portfolio maturity by using a Maturity Assessment Model – delivering a Maturity Assessment Report and a proposed Road Map for organisational improvement.

A Maturity Assessment Model is an assessment instrument based on a set of questions that represents the knowledge areas (or process perspectives) in a Project Portfolio. The levels of maturity have a rating between 1 and 5 where 1 is “Immature” and 5 is “Mature” and it is an indication of how well the specific process step (or project methodology) is established and followed by the individual or the department or the company.

There are multiple maturity assessment models in the market but three will be highlighted below:

  • PMI’s (Project Management Institute) OPM3 (Organisational Project Management Maturity Model),
  • Kendall and Rollins PMO Maturity model based on PMBOK (Project Management Body of Knowledge),
  • The UK Cabinet Office (formerly known as OGC – The UK Office of Government Commerce) is the owner of the P3M3 maturity model and they have a range of frameworks, models and assessment tools including the Project Management Maturity Model (PjMM) which is derived from the Portfolio, Programme and Project Management Maturity Model (P3M3) which uses a set of questions that measures the maturity at 5 levels over 7 process perspectives (or business areas).

DIY Step 2:

The next area that needs to be addressed in the audit is a Landscape Analysis, listing all the existing active projects under the PMO control to ascertain the RAG (Red, Amber & Green status indicators) of each project and estimated completion dates.

The goal of the Landscape Analysis/Audit is to compile a list of active projects and to confirm the health of these projects by using a RAG status on the project budget, schedule and scope. An audit should also be done on the project management deliverables (see the potential list of deliverables below), and thus the application of Professional Project Management (PPM) disciplines. Feedback from the project and engineering managers interviewed should be noted.

  • Red (on the RAG status) could be defined as “Requires immediate remedial action”
  • Amber could be defined as “Warning that risks are likely to have a negative impact – requires attention”
  • Green could be defined as “On track, On budget and Within Scope – requires no action”

Project Landscape parameters could include:

  • Confirmation of project cost code.
  • Confirmation of project life cycle status i.e. still in Initiation or Planning or already tracking progress in the Execution phase.
  • For projects in the Execution phase: Confirmation of the projects start date (as per the Project Justification Document) and estimated finish dates and how this compared to the approved Project Justification Document or PDN (Project Deviation Notes).
  • Confirmation of the current approved project ‘budget’.
  • Current overall status of the project, e.g. Red. Amber or Green, and the reason or motivation why, e.g. is the project on schedule, within budget and within scope, or not.
  • Who is the Project Sponsor & Project Client?

Confirmation of the key Project Governance Documentation could include:

  • Having a Project Justification Document (signed).
  • Having a Capital Registration.
  • Handover documents (if relevant), i.e. if the project was handed over from one project manager to another  in the lifetime of the project; i.e. was there handover documentation?
  • Scope of Work documentation.
  • Minutes of project meetings.
  • Confirmation of having project risk meetings and reviewing risk logs.
  • Issue logs and a Decision log (i.e. a Chronology of major decisions that reflects the project history).
  • Project Schedule (approved).
  • Communications plan.
  • Quality plan.
  • Cost plan.
  • Updated PEP (Project Execution Plan).
  • Signed contracts with all contractors on site.
  • Cost Register.
  • Site Instruction logs.
  • PDN (Project Deviation Note) register.
  • Delivery Sign-Off documentation.
  • Retrospect report.
  • Closure report.

DIY Step 3:

In this step, it would be important to consolidate both the Maturity Analysis and the Landscape Analysis and to compile a Recommendations Report to highlight the learnings and the roadmap going forward to address these. If the existing PMO methodology needs tweaking, then this would be the time to address such. Also consider training, awareness and support as needed. A typical high-level audit implementation approach could be as per below diagram.

High Level Audit Implementation Approach

This then concludes this article on ‘PMO Managers DIY Toolset for Self-Audit’. For any clarification or assistance.

Jurie Moolman holds the position of  Projects Controls Manager at InnoLead Consulting offering Project Management Consultancy and Corporate Training solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw.

 

 

 

 

Effective Project Governance

Any organization whether temporary (project) or permanent (business as usual) needs to be effectively governed to achieve its objective of the establishment.  Within normal operations in an organization the roles and responsibilities are very clear, however, this is seldom the case with projects. A lot of organizations executing projects do not have clear governance frameworks and this is one of the reasons that compromise the success of these projects.

Project governance can be defined as the identification and execution of roles and responsibilities on the project. This includes explicit statements on who has the authority to make which decisions on the project. It is a management framework through which decisions are made on a project.

Organizations need to put in place clear project governance structures, policies and procedures to provide a decision-making framework that is logical, robust and repeatable to govern an organization’s projects. In this way, an organization will have a structured approach to conducting both its business as usual activities and its business change, or project, activities. In the absence of a clear governance framework with associated policies and procedures, the framework for managing business as usual may be adopted with its inherent gaps with regards to managing projects thereby compromising project success.

In setting up effective project governance, organizations need to design a robust overarching project management policy.  This sets the minimum standards on what is expected with regards to governance of projects.  It outlines the various roles and responsibilities for the various entities in the Project Governance Structure. This policy can be operationalised through procedures that are detailed for each area of the project such scope, time, risk, cost management etc. A procedure on decisions rights and levels as regards to management of all project aspects should be developed as well.

PRINCE2 identifies 4 levels of authority in the governance of projects. The first level is the Corporate or Program Management level. This level commissions or triggers the project through a mandate and sets the project tolerances for the Project Board (second level) to operate within.

The second level is the Project Board or in common project nomenclature, the Project Steering Committee. This level directs the project on behalf of the corporate or program management. The Project Steering Committee’s key is to provide overall guidance to the project team. They act as champions of the project and its benefit within the organization. The Steering Committee also resolves issues outside the control of the project team/project manager such as resource provision, cross-functional project integration support etc. They are responsible for the business issues to ensure that the project achieves the business case. They also make decisions, authorizations on any changes to the project plan (scope, time, budgets, quality, approach to execution, risks) if the agreed tolerances are forecasted to be exceeded. They approve these project plans before the project execution starts. They also review the updated business case, and if the business case is no longer viable recommend for project closure.

The level after the Project Board is the Project Manager. The Project Manager manages the project on a day to day basis on behalf of the Project Board within agreed tolerances of the approved project plan (scope, budget, time, risk, quality etc). Any forecasts of exceeding these tolerances are escalated to the board/steering committee for decision making.

The Project Manager’s key role is to ensure that the project delivers the specified deliverables within the parameters agreed with the Board/Steering Committee. The Project Manager should provide timely and honest project progress updates based on an agreed frequency. The reports cover scope, time, costs, risks quality and issues that have a potential of derailing the project.

The fourth level is the Project Team that actually delivers the project’s products according to the criteria agreed upon with the Project Manager. The Project Manager assigns work packages to the Project Team and they execute and report on progress during execution until completion and hand over to project manager.

In order to enhance project success, it is imperative that each of the entities in the project governance structure understand their role. It’s not uncommon to find members of the Project Steering Committee ignorant of what is expected of them. If you do not know what is expected of you, you cannot play your role effectively and the project will suffer.

Mark Muzinda holds the position of Senior Consultant at InnoLead Consulting offering Management Consultancy and Corporate Training solutions. He can be contacted on +267 3909102 and innolead@innolead.co.bw.