How Can Project Management Information System Improve the Management of Meeting Minutes in Projects?

You will rarely find any project, regardless of its size, type, location or duration that does not require have meetings between the project stakeholders and project team members. Meetings are scheduled gatherings of individuals for stated purpose, to discuss and act upon matters of common interest. Meetings serve valuable purpose in the project to effectively communicate information, exchange ideas. render decisions, resolve issues, coordinate work, prevent problems among others.

Those meetings could have different subject including but not limited to Design Review, Value Engineering, Safety, Quality, Technical Review, Site Mobilization, Progress Review, Pre-Tender Clarifications, Bid Award, Kickoff Meeting, Stage Gate Review, Pre-Installation Meeting, Closeout Meeting, Handover Meeting, Claims Negotiation and Settlement Among many others. The frequency of those meetings could vary as some could be weekly, bi-weekly, monthly or when needed.

It is therefore no wonder that project management team members spend more than 50% of their time in participating in meetings. This brings the challenge on how to ensure that project stakeholders and team members are getting the maximum benefit and value of the meeting minutes that are used to document what goes on during those meetings.

The first requirement for a meeting minute is that it needs to capture the particular of the meeting such as project, subject, location, date, timing among others. Second it needs to captures the details of those invited to attend the meeting and who has actually attended the meeting. The third requirement which is the most important of all, the business items discussed during the meeting, who are responsible to address those business items and by which date, the status of this business item if it is still open or closed, the actual date this business item was closed and the project schedule activity that could be subject to be delayed if this business item is not closed as per the set due date. Of course, additional details such as business item category and type can be added to improve the classification of the business item.

Another challenge in maintaining complete, accurate and effective meeting minutes is that it is common practice that during a meeting, documents such as drawings, reports, pictures, videos, catalogues among others shared among those attending the meeting. Therefore, it is critical that documents are attached to the meeting minutes to ease their reference and review.

When the meeting minute data is complete and all supportive documents are attached, the meeting coordinator can then submit the meeting through a pre-set workflow to those who have attended the meeting as well as others who might need to be involved to review, approve and share the content.

In addition, meeting minutes require to keep track of the history of business items from one meeting to the other. Therefore, the follow-on meeting agenda needs to be generated from the previous meeting to ensure that closed items are removed and on-going items get captured in the next meeting. This will enable the project team to keep track of all business items and when those items were closed.

Another challenge that could face project team members who are involved on more than one project is how to consolidate due actions across all projects as well as share knowledge for business items discussed on one project to another. In addition, this will enable the project team if there is any conflict or overlap that could affect another project.

Capturing this data from meeting minutes will also enable having reports on pending business items as well as develop key performance indicators (KPIs) to measure the efficiency of resolving meeting business items as well as trigger actions when the performance is not in accordance with approved performance benchmarks.

PMWeb Enterprise Project Management Information System is one of the solutions that can be used to improve the management of meeting minutes across all projects within an enterprise. PMWeb allows setting access rights to restrict what projects a user can access and what actions can be done on the authorized module, which in this case will be meeting minute module. Of course, all meetings types are sessions are captured on the same repository.

For each meeting minute, PMWeb allows capturing the details of the meeting such as date, location, timing, type, category among many others. In addition, it allows capturing who are invited to attend the meeting and those who have actually attended the meeting.

For each meeting minutes, PMWeb allows capturing the business items discussed during the meeting as well as all particular details such as who are assigned to take action on the business items, by which date, when this action was completed, which activity in the project schedule will be impacted by this business item should there be a delay in taking action among other data.

Attachments to the meeting minutes such as drawings, pictures, videos among others can be attached to the meeting minutes. Those documents can be either stored on PMWeb document management repository or other locations such as your company server, MS SharePoint, Aconex and others. In addition to attaching documents, sometimes the project team might need to link other project records like Request for Information (RFI), daily report, another meeting minutes or even an email communication to the meeting minutes. All those options are available in PMWeb attachment command.

At this stage, the user can share the meeting minutes with those who have attended the meeting and others using the pre-defined conditional workflow which details the steps for submitting, reviewing, sharing and approving the meeting minutes. PMWeb visual workflow module allows creating workflow branches that will be aligned with conditions and rules to direct the meeting minutes to different recipients depending on the attribute values of the meeting minutes.


The value of having an Enterprise Project Management Information System is not limited to optimizing the process of managing meeting minutes or the many other processes that are required for managing a project but the business intelligence analysis and data visualization that will become available for the project team. All meeting minutes will be automatically aggregated in a tabular report to present the information that a project team member wants to have. This information can be grouped, ordered, filtered in any desired format. Similarly, the same will be done for data from other processes such as RFI, submittals, change orders, progress invoices, risks, issues among others.

The information of related data such as Meeting Minutes, RFI, Submittals, Transmittals, Correspondence among others can be consolidated in a dashboard that will details the performance of document management. For example, key performance indicators for volume, growth over time, approval periods, items by status among others will be captured at this dashboard. There will be other dashboards for cost management, schedule management, risk management among others.

Those dashboards will provide the input for the project dashboard which will usually summarize the KPIs of all those dashboards as well as show additional data such construction camera among others. If the project was part of a specific program, then usually another dashboard will be created to detail the program performance. Finally, all programs and projects can be aggregated and presented on the enterprise dashboard. It is very common to link projects to their geographical location where the project status can be displayed on a map as well as more details in the scorecard.


About the Author

What is the leading cause of capital project cost & schedule overruns?

The undisputed answer the world over is poor scope definition.  Check out this infographic detailing the 10 commandments of front end planning based on CII’s implementation resource, “Front End Planning – Break the Rules, Pay the Price.”  Each of these 10 practices are proven ways to improve scope definition during front end planning.


Introducing PDRI for Small Industrial Projects

Historically small projects represent 70% or more of an organization’s capital spend. Often minimal emphasis is placed on front end planning for small projects.  We assume they carry lower risk than large projects, and if a project team goes over budget or over schedule the impact seems negligible. The truth is, the cumulative effect of limited planning in small projects can have a significant impact on our overall bottom line. It’s the classic “death by a thousand cuts” scenario…

Introducing…drum roll please….


PDRI for Small Industrial Projects

PDRI for Small Industrial Projects follows the same methodology of all other PDRI templates (Infrastructure, Building, Industrial) as outlined here: What is PDRI?


It is a collaborative, facilitated process involving key stakeholders from a project, working through a rigorous checklist of project elements in order to mitigate risk by improving scope definition and identifying and documenting gaps. It covers:

  • Basis of Project Decision
  • Basis of Design
  • Execution Approach

The PDRI methodology is proven to reduce risk in capital project delivery.  It promotes rigorous scope definition and a collaborative review process during front end planning.

How is PDRI for Small Industrial Projects used?
The PDRI for Small Industrial Projects should be used as early as possible in the project life cycle.  Rather than a gating tool (focused on the score), the emphasis is on supporting small project teams in early risk identification, capturing action items and revealing scope concerns through open and honest discussion.

Our experience has shown that a PDRI for Small Industrial Projects assessment averages between 1 to 1.5 hours.

CII defines a small industrial project as:

  • less than $10 million USD in expenditure (we recently did a session for an $800K project)
  • 3 – 6 months in construction duration
  • less overall complexity than large projects
  • Includes both process and non-process projects (e.g. replacement of an industrial elevator, SCADA systems upgrade, pump replacement etc.)

By improving scope using PDRI for Small Industrial Projects, CII research has shown projects perform:

  • 16% better in terms of COST
  • 15% better in terms of SCHEDULE
  • 3% better in terms of CHANGE ORDERS

Can Carve help in implementation of PDRI for Small Industrial Projects? Yes!

Successful implementation of PDRI for small projects will likely mean more PDRIs are conducted every year, and more trained facilitators are required.  Carve makes it simple to address these needs with:


Fit-for-purpose configuration of element descriptions.  When your PDRI template fits how “Bruce Power” does small projects, it will be simpler to train facilitators, and they will deliver more value to every project team.

Consistency in facilitation.  PDRI facilitators generally have another day job.  So, Carve makes it as simple as possible to conduct a quality session. It also minimizes their effort to prepare actionable results (risks and action items) for a project team.

Portfolio leading indicators.  With one system used to manage all PDRIs, portfolio managers gain an aggregate view of front end planning risk, and visibility to consistently low definition elements.

Want to learn more about PDRI for Small Industrial Projects?

Contact CMCS today and learn about our PDRI training options and our PDRI Roadmap to Success program.

We look forward to hearing from you!

By Sandra MacGillivray
Managing Director
Valency Inc.

Better Front End Planning = Better Projects

At a high level, we know that projects are very dynamic – especially in front end planning.  Critical issues and decisions arise throughout a project’s life-cycle.  However, it is much easier to influence a project’s outcome during front end planning when expenditure is relatively low, than it is to affect the outcome once a project moves into execution.


Cost-influencemoving through the project life-cycle

The Construction Industry Institute has studied the impact of scope definition on capital projects, and identified a measurable impact on both a cost and schedule, as well as a reduction in change orders.

This correlation exists in all types of projects that have been studied including building, industrial and infrastructure projects.


Front End Planning Critical Success Factors

What are the critical success factors that will allow us to achieve a well-defined scope?

Best practices in front end planning show that critical success factors include:

  • Having a defined front end planning process
  • Using tools and resources that will help ensure scope definition is adequate
  • Carefully investigating and defining existing site conditions
  • Selecting an appropriate contracting strategy early that reflects the risk and uncertainties of the project.
  • Alignment of the project, including all key stakeholders, so that everyone is working toward a common goal and shared objectives

How do we apply this?

With a thorough understanding of both the reasons for poor scope definition and the critical success factors to achieving well defined scope, how do we put this into practice?

The great news is that this is a challenge industry leaders have quietly been addressing for over 20 years with some tremendous results.

The Project Definition Rating Index 

The Project Definition Rating Index (PDRI) is a methodology used by capital projects to measure the degree of scope definition during front end planning.


The methodology provides:

  • a comprehensive review of scope
  • it helps project teams identify gaps,
  • it supports the project team in taking actions to address gaps
  • and most importantly, it helps everyone work together to reduce risk

Origin of PDRI – The Construction Industry Institute

The Construction Industry Institute (CII) is the developer of PDRI.   They are a non-profit research organization of more than 140 owners, engineering contractors, suppliers and academic institutions. Their mandate is to create, support and bring best practices in construction and project management to their membership.

Along with supporting their membership, CII is committed to the developing and sharing their best practices with the industry at large.

So how do they do it?…And how can my project team take advantage of these best practices???

Registered Education Provider Program

CII works with Registered Education Providers and implementation specialists like Valency to market and support organizations around the world in their implementation of these best practices.

Blogpost52The purpose of the CII Registered Education Provider Program is to provide member companies and the general public with a qualified corps of instructors who are familiar with CII publications and are available to train on CII Best Practices. CMCS is partnered with Valency to offer these services across the MENA region.

If you’re interested in improving Front End Planning, achieving better scope definition, or getting started with PDRI reach out to us today ( or learn more at the PDRI Roadmap to Success page.

Poor Scope Definition = Cost & Schedule overruns

What is the leading cause of capital project cost & schedule overruns?


The undisputed answer the world over is POOR SCOPE DEFINITION.

The level of scope definition in a project is the greatest driver of cost and schedule certainty.

Front End Planning

Front end planning is often considered the single most important process in the capital project life cycle.

It is focused on achieving sufficient scope definition to address risk and make a decision to committing resources that will maximize the potential for project success

Front end planning is known by many other names including:

  • Front end loading, or FEL
  • Pre-project planning, and
  • Project development just to name a few

This process is generally defined in three main phases:


  • Feasibly, which is primarily focused on
    • defining business objectives and
    • identifying potential alternatives
  • Concept, concerned with
    • evaluating and selecting the best alternative
  • Detailed scope, which is focused on
    • defining the technical scope of the project,
    • further developing project execution plans, and
    • developing a cost estimate and schedule for project authorization

Simply put, front end planning involves:

  • Performing the right project
  • Scoping out the right product
  • And selecting the right way to execute

Scope definition refers to documenting this scope of work to form an organized plan.

Reasons for Poor Scope Definition

It is intuitive that starting execution with a well-defined scope should improve project results.  Nevertheless, there are some common misconceptions and behaviors that lead to poorly defined scope.

The top five reasons or behaviors that contribute to poor scope definition include:

  1. Pressure to get product to market faster.

A common misconception is that you’ll get product to market faster by compressing every phase, including the planning effort.

We’ve seen this surface through statements like:

  • “front end planning will just slow down this project”, or
  • “we’re on a fast-track schedule”
  1. Restricting key resource involvement.

As an example, we have worked with organizations where Operations & Maintenance resources are stretched very thin.  Their culture has evolved such that Operations & Maintenance will openly admit that they only assign resources to a capital project once funding and approval of the project is a sure thing.   The opportunity cost for the organization is that key scope requirements are missed during front end planning from a lack of involvement of these key resources.

  1. Lack of in-house design or planning capability.

Owners can successfully address this issue by engaging specialized consultants and engineers.  However, the challenge is to ensure the owner’s team remains active in planning throughout the project and doesn’t simply hand off the planning effort to the contractor and then disengage.

  1. Overly optimistic leadership

This is commonly seen with projects that appear on the surface to repetitive and lead to optimistic statements like “this will be simple.  We’ve done this hundreds of times.”

  1. Financial pressure to minimize planning costs

Without a doubt, it’s a careful balancing act to ensure you don’t overspend on front end planning for projects that end up getting cancelled.  One of the main benefits of a well-defined front end planning process with gate reviews is to identify projects that don’t meet your strategic objectives and cancel these as early as possible.

However, projects that proceed beyond the early gate reviews need sufficient funding to ensure a well-defined scope is achieved.

Research by the Construction Industry Institute shows that projects that perform statistically better in terms of cost and schedule invest 3-5% of the total installed cost during front end planning.


The Question

With an understanding of the major contributors to poor scope definition, it raises the question when we look at our past projects:

Had we done a better job of scope definition, would we have improved the performance of the project?

By Sandra MacGillivray
Managing Director
Valency Inc.

How to go from project zero to project hero…

Front end planning may be the most important process in the construction and operation of a capital asset. Industry research shows that projects with intensive front end planning efforts and a well-defined scope perform markedly better in terms of total cost, schedule performance and change orders than those with less intensive front end planning efforts. Front end planning is the process of planning and design that takes place early in a projects lifecycle “at a time when the ability to influence changes in design is relatively high and the cost to make those changes is relatively low.” (

As a project moves through front end planning, three cornerstones of success need to be established: people, processes, and systems. But how can you best get there? How do you know if you have the right people, the right processes and systems in place to complete a front end planning effort that increases the likelihood of a successful project?

If only there was a process you could adopt that would give you a definitive score and risk profile on the scope definition of your project…

This is why PDRI was created.

PDRI is an acronym that stands for Project Definition Rating Index.  It is an index that helps score the level of scope definition on a continuum that will change as you progress through the stages of front end planning.  PDRI is one of the most comprehensive risk management tools available for front end planning.  It is used by organizations around the world in both greenfield and renovation and revamp capital projects.


The PDRI methodology was developed by the Construction Industry Institute, or CII.  CII is a non-profit research consortium of over 140 members that includes owners, engineering and construction contractors, suppliers and academic institutions that specialize in construction management and engineering.  CII’s mandate is to “measurably improve the delivery of capital facilities.” 

Over the past 20 years, ten research teams have worked collaboratively to develop industry best practices in front end planning, including the PDRI methodology.  To date, over $96 billion in projects have been used to create industry benchmarks using CII’s front end planning best practices.

There are three primary benefits for project teams that have adopted PDRI:

  1. It is proven method to quantify the level of scope development during front end planning.  After a PDRI session your project team knows what and where gaps exist.
  2. It is an excellent method for promoting alignment between everyone on your project team – regardless of whether you represent the Owner or a design contractor.  When we work together through the PDRI session, we have an opportunity to highlight any poorly defined areas or gaps in scope definition in an objective manner.
  3. All of our efforts in this session help to identify risks and feed into the project’s risk assessment process.

PDRI sessions are held at multiple points in the front end planning processes.  The first session, or PDRI-1, is typically held at the end of feasibility, prior to a gate review.  The second session, or PDRI-2 is held at the end of the concept stage.  In large projects, a PDRI 2-i, meaning an intermediate session, can be conducted as part way through detailed scope.  And finally, a PDRI-3 session is conducted at the end of detailed scope and immediately prior to your gate review to proceed into execution.


Not all organizations use all four-application points.  In practice, organizations that successfully implement PDRI as a stage gate deliverable generally conduct a minimum of two sessions for each project.

PDRI provides a comprehensive scope definition review spanning the basis of project decision, the basis of design, and the execution approach – effectively determining how well you have defined the Why, Who, What and How of the project:

Why – why are we doing this particular project? Are there better places for us to spend our time and capital?

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Who – have we got the right people involved? Are there human resource gaps that will prevent success?

What – what will it look like? What equipment, regulatory, environmental, site and technical design elements need to be evaluated?

How – how will we build it?


PDRI provides a comprehensive scope definition review spanning the basis of project decision, the basis of design, and the execution approach.  Each of these three sections is broken down further into categories and elements.  The Infrastructure template that we see above includes 68 elements.  As shown in our pie chart, the basis of project decision represents almost half of the total risk we’ll evaluate for each industrial project.

There are three versions of PDRI that are available:


  • Industrial projects.  This includes a broad range of capital projects that typically have extensive piping and mechanical equipment considerations. This includes power plants, chemical plants, refineries, water and waste treatment, and manufacturing just to name a few.
  • Building projects.  This template is tailored specifically to commercial building projects, such as offices, medical facilities, institutional buildings and government facilities.
  • Infrastructure projects. This includestransportation, pipelines, transmission and distribution just to name a few.  These projects typically cover a large geographic area with many stakeholder groups, right of way and environment considerations.

No one will argue with the fact that wise capital expenditure is critical to the success of any business, yet history is riddled with projects going well over budget, well past schedule, and failing to meet operational objectives. Most companies have recognized the need for proper front end planning to ensure successful project execution, but getting there seems almost unattainable. Improving the success rate of your capital projects, even by a few percentage points can turn you from a project zero to a project hero. PDRI is here to help.

By Sandra MacGillivray
Managing Director
Valency Inc.

Capturing The Right Data Needed To Manage AEC Projects. Part 2

Cost Management.  Those are responsible for managing the project cost is mainly interested in successfully achieving two important objectives. The first is how to ensure that actual project spending is aligned with the baseline spending plan or what is known for many the time-phased budget or budget cost of work scheduled (BCWS or PV). The second objective is to ensure that the actual project cost (AC) does not exceed the approved project budget at completion (BAC).

Achieving those two objectives require having a number of document templates to build the data to report on those two objectives. The fist document template is the Project Cost Estimate which will capture the cost details of the different project elements which are usually aligned with the WBS. The content of this template could differ depending on the level of details that the company wants to capture. It is also very common to have multiple revisions of the cost estimate template as the company will prepare different cost estimates depending on the available project scope level of details.


The second document template is the Project Budget which will be used to develop the project time-phased budget. This document will be generated from the Project Cost Estimate document template as it will provide the basis for determining the budget cost for each WBS level. The project budget will also include additional cost elements that the cost estimate might not have such as project contingency, funding cost, overhead and profit among others. The time-phased budget requires having a start and finish date for each budget item which can be linked to the project schedule activities. Similar to the Project Cost Estimate, It is common to have multiple revisions of the Project Budget template as the company will have different project budgets depending on the available project scope level of details.

The third document template is the Project Budget Request which will be used to capture all changes and adjustments to the approved Project Budget. Budget revisions are needed when there is either a change for the baseline project scope or there is a need to transfer funds from one center or WBS level to another. This document template should explain the reason for this change and cost centers as well as the amounts for those adjustments.

The above three document templates mainly have to do with establishing and formalizing the project target cost for which the cost of executing the project scope should not exceed. On the other hand, there are other document templates that will be needed to capture the data associated with the project actual cost. The first of those is what is known the Commitment Contract. This document template will be used to capture what is known as the selling price for the selected project scope of work. One a single project, it is very common to have more than one commitment contract as the project delivery will usually involved more than one entity. This document template will also capture the contract terms such as retention percentage, payment against material on site, advance payment recovery, taxes among others.

The commitment contract template needs to capture data that relate to the scope of work that will be delivered through the contract which can be best described by selecting the associated WBS levels. For each WBS level, the agreed selling price must be provided. For some projects, the selling price for a WBS level could have different currency than other WBS levels in the commitment contract. In addition, it is very common to capture the start and finish date for each WBS level to provide what is known as the Cost Loaded Schedule or Anticipated Cost. This will help in ensuring that the anticipated project spending is aligned with the planned baseline spending.  This will help in supporting the first objective and that is how to ensure that actual project spending is aligned with the baseline spending plan or what is known for many the time-phased budget or budget cost of work scheduled (BCWS or PV).


As it is rarely one will have a project without changes, managing a project requires using a number of document templates that will be used to manage those changes. Some of the common document templates include Potential Change Order, Change Order Request, Proposed Change Order, Change Order and Variation Order among many others. The common data fields in those documents in addition to the project and commitment contract details is the WBS levels that will be affected by the change, associated cost for the change, time extension associated with the change, whether the change is considered to in-scope or out-of-scope and the details of the entities and individuals who are responsible for reviewing and approving the change. The document template will also detail the current revised contract value and completion date.

Another important cost management documented is the Progress Invoice which is used to capture the details of the value of approved completed work that needs to be paid for the company performing the work. This document template will capture the approved percent complete for each progressed WBS level to determine the amount that the project owner needs to pay. This amount is the Actual Cost (ACWP or AC) that the project owner is paying for completed work. When the same approved WBS completion percentage is applied to the approved budget, the project owner can determine the Earned Value (EV or BCWP) for the work performed.

The Progress Invoice and similar to other cost management documents should have built-in formulas to do the calculation associated with those documents. For example, in the Progress Invoice, the document template should calculate the cumulative amount of approved work to date, retention amount and other adjustments needed to comply with the contract terms and conditions. Similar to change management documents, the Progress Invoice will also detail the entities and individuals who are responsible for reviewing and approving the amount to be invoiced and eventually paid.

Of course there are other cost management document templates that could be needed to manage a project depending on what the company wants to achieve. For example, the company could decide on having Fund Authorization, Fund Spending, Fund Changes and Revenue Contract among many others.

To be continued.

About the Author

Capturing The Right Data Needed To Manage AEC Projects. Part 1

Like any other profession or industry, the engineering and construction industry has identified over the years what data must be captured during the project life cycle stages to enable the project team to successfully manage their projects and eventually have the insight to make better and faster decisions. The captured data also plays an important role to fulfill and govern the contractual obligations between the project parties. This data is usually captured using document templates that although the layout could differ from one project to the other, nevertheless they all almost have the same core content. Document templates are also used to enforce the formal communication that is part of every project.

For an organization to have better document templates when it comes to managing their engineering and construction projects, the following is recommended:BLOGPOST21

  1. Document Templates need to be aligned with Project Management Best Practices like those developed by the Project Management Institute (PMI) and other professional bodies.
  2. Document Templates need to be aligned with engineering and construction best practices like those of the Construction Specification Institute (CSI), American Institute of Architects (AIA), Construction Industry Institute (CII) among others.
  3. Document Templates need to be aligned with the engineering and construction contracts used on projects like those of FIDIC, NEC3, AIA among others.
  4. Document Templates need to be aligned with the local regulations and authorities requirements where the project is being executed which might affect the language used in the document template.
  5. Document Templates need to be aligned with the company’s knowledge and best practices accumulated over the years in delivering engineering and construction projects.

The list below provides recommendations on what to consider when an organization wants to develop the document templates to be used during the project life cycle stages as well as some of the document templates that are needed to capture project data. Those recommendations are aligned with the PMI’s Project Management Body of Knowledge (PMBOK) which provides an integrated and comprehensive platform for managing projects.

Project Life Cycle Stages. It is important to understand what will be the project stages that the company will be responsible to manage as the document templates needed for each stage could differ. For example, managing the pre-project approval stage requires having documents on the project’s return on investment, strategic alignment, and stakeholder’s requirements among others.

It is also highly recommended to have document templates to capture the Stage Gate Approval. Those document templates will usually identify the deliverables of each stage, who approved them and when. In most projects, the formal approval of Stage Gate is a must before allowing the project to proceed to the next stage.

Today, it is very common to have a Project Phase field in project document templates to identify which phase the document template belongs. This is very much needed for document templates that are common to all phases such as meeting minutes, progress reports among others. The RFI example shown below shows the Phase field labeled as “Phase” which will pick the relevant value from the predefined dictionary.


Scope Management.  In addition to the need to have document templates to capture the original project scope and changes to the approved scope, all document templates should be aligned with the Work Breakdown Structure (WBS). Similar to the need of have a reference number, date, issuer and recipient name, document type and status, it is a must to have a field that will capture the WBS level that the document relate to. The RFI example shown below shows the WBS field labeled as “WBS” which will pick the relevant value from the WBS data imported from the project schedule which could be from Oracle Primavera P6, MS Project among others.

For scope management, one of the important document templates that would needed to capture data that relate to project scope is what is known as the WBS Dictionary. This template is used to identify the included and excluded scope of work for each WBS level. The template is also used to capture the planned start and finish dates for the WBS scope, account manager among others.

Time Management. Document templates are used to drive actions on part of the recipient to avoid delays to the project.  Those actions need to be aligned with the approved project schedule which also has a lot of important data needed to manage the project. Therefore it is highly recommended to have the approval “Required Date” clearly stated on the document template to determine the needed approval date to avoid project delays. Should the document template have an impact on the project schedule, then it is highly recommended to have a field to capture the activity that could be impacted by if there is delay in approving this document.  The RFI example shown below shows the required approval field labeled as “Required Date” and the “WBS” field which will pick the relevant value from the WBS data imported from the project schedule.


In addition, it is very common nowadays to have a document template that will capture the details of all delay events that could impact the project schedule. This template, Delay Event, will capture the delay event type, responsibility, start and end date, activities affected, contract clauses relevant to the delay among many others. This will help the team to do a comprehensive delay analysis and use this information in their Extension of Time claims.

To be continued.

About the Author

The Fatal Syndromes of Ineffective Projects Performance Communication

No one can deny that having the insight to make better and faster project related decisions depends to a large extent on the knowledge that one has on the current project’s performance and health status and how could this impact the desired project objectives. This knowledge would largely depends on the extent of information that has been extracted and analyzed from the data captured from the different project team members regardless what role they play on delivering the project. This Data should be captured from the different formal and informal communications that take place during the project life cycle stages.

Project Centric Organizations

Project centric organizations that do not have a formal system to capture, analyze, share and visualize their projects performance data are usually faced with at least the following three fatal syndromes; Watermelon Dashboard Reporting, The Elephant with Seven Blind Men and The Chinese Whisper. The negative impact of those syndromes could drastically increase their risk of encountering the high cost of project failure. On average, organizations risk $109 million for every $1 billion spent on delivering projects due to failed projects (PMI’s Pulse of the Profession PMI_Pulse_2014.pdf (27 downloads )

Watermelon Slices

Watermelon Dashboard Reporting. Performance dashboards that are not linked to the data source have the high chance of being manipulated to reflect performance results that do not reflect the real project’s status. Data could be manipulated intentionally or unintentionally either to avoid reporting project issues, unavailability of actual data or mistakes in data entry. In a way, the reported Key Performance Indicators (KPI) could be all green while the actual project’s performance is all red. Another issue that faces organizations who continue to depend on Watermelon Dashboard Reporting is the delay in sharing the project’s performance status from the time it’s captured to when it becomes available to be visualized.

The Elephant with Seven Blind Men

The Elephant with Seven Blind Men. Project’s performance depends on capturing data that is generated by different team members thus increasing the risk of having data silos. For example, a project could end having different data silos for schedule, risk, cost, quality, contract administration among others. This gets more complicated when the project delivery involves multiple parties to execute and manage the project. Each one of those entities could be using their own systems to capture and report their relevant project information. This will make it impossible for a decision maker to have the understanding of the overall project performance as well as the impact of decisions on other aspects of a project.

The Chinese Whisper

The Chinese Whisper. Decision makers who depend on intermediaries to communicate project’s performance data face the high risk of data quality deterioration and manipulation in addition to the speed of having this information. This syndrome gets even worse in the Middle East region where the projects delivery involve team members from different nationalities and cultuers where project information could be affected by the subjective views and feelings of those involved in communicating project’s performance status and health as well as when translating the performance status from one language to another.

Therefore, for those decision makers who are keen on having the insight to make better and faster decisions on their projects need to change and adopt today’s best practices in managing their projects data. Those decision makers should be the one to decide what questions they need to get answers for in a timely, objective and true format.


About the Author