Login access is only available to associates and administrative staff.

The Fundamentals of Project Management in a Technical Environment

  • By: pcadmin on 15 Aug 2013

Guest post by Mr. Robert Mattia, A.Sc.T.

In today’s world of ever increasing speed, complexity and competitiveness we as Technicians and Managers find ourselves with the overwhelming need to achieve absolute efficiency. This need forces us to organize and direct our energies in more creative manners. As we surpass one goal, another sets the bar even higher requiring additional improvements. This efficiency is generally a result of taking our experiences and lessons learned and converting it into an improved method or product at the most competitive cost.

Project Management helps bring efficiency to our technical challenges. Originating in the days of pyramids and castles, Project Management has advanced through NASA and the Space Program onto modern construction processes and into the worlds of IT and manufacturing. PM is achieving a maturity in virtually every industry requiring products or deliverables. In many organizational environments the term Program Management is used to define the management and prioritizing of a multiple of projects, not to be confused with Project Management.

At some point in our careers we have all been involved with, been made aware of, or practiced the principles of Project Management. It is largely defined as the process whereby you are called upon at the inception of a project or deliverable, to plan, co- ordinate and control all the resources required to complete the project or deliverable through to operation within an allotted time, an agreed budget and to a specific level of quality and safety, at a minimum of risk.

In the early stages of our careers or as specialists, many of us play a role in the overall Project Management process. A project team may have participants exhibiting planning skills; other members of the team may have more technical or quality skills. Generally one individual acts as the Project Manager overseeing the entire process and holding ultimate responsibility and authority. It is human nature to appoint a leader. This position is usually achieved after years of playing several roles in the PM process gaining knowledge and experience or through formal education. Occasionally a Project Manager is assigned this duty at a premature stage in his career development which can produce less than acceptable project results. It can also leave the Project Manager disillusioned and wrongfully perceived as an underperformer when in fact a lack of skill sets was the true culprit.

There are countless volumes of literature available to help detail and define the need and application of Project Management techniques and methods. Many organizations have adopted PM principles and created Procedures for their own unique circumstances.

In these short pages we wish only to highlight the basics of PM and how it relates to our daily work assignments as participants of a project team.

Why use Project Management?

As with any task, it makes good sense to create and follow a well thought out game plan. PM helps create that plan. It helps you focus on your objectives by documenting your requirements and building your deliverable on paper before committing expensive and scarce resources to it. PM produces information which increases your level of confidence and communicates the expectations. It forces you to plan your resources, and then use them efficiently and productively.

The Project Management Institute founded in 1969 is the custodian of A Guide to the Project Management Body of Knowledge (PMBOK Guide®)[i]. This document represents years of effort and standardization in the Profession of Project Management. Through education and practice one can achieve the recognized designation of Project Management Professional (PMP®)[ii].

Projects can range in size and scope from a new product such as a pipe fitting to a major industrial construction project such as a nuclear plant. Each deliverable has its own unique set of circumstances. They can be standard products with multiple quantities or as in many cases a custom application. Regardless of how unique the project is, in general all undertakings require some form of control and organization.

Project Management is made up of many organizational competencies, however, we will deal with the following six main controls, once mastered will deliver a high incidence of success. These are not in order of importance or significance. Each unique project will have a set of circumstances that will dictate what priority this list should follow.

  1. Scope
  2. Time
  3. Cost
  4. Quality
  5. Resources
  6. Safety


1. Scope

A scope of work defines what it is you want in detail through written documents or an electronic data base. It further serves to avoid interpretations. A well defined scope provides clear instructions understood to mean the same thing by all who are affected by it. The Product Scope is the “What” and the Project scope is the “How”. A scope can also help to define the work breakdown. The work breakdown reduces the scope or project to easily definable and manageable parts that can be resourced and scheduled. The scope of work or a work breakdown is specific, measurable, attainable, realistic and constructible. Tender documents generally begin with the scope of work. It should address all the major aspects of a project such as time, cost, quality and safety. Generally the more detail found in the scope of work the more efficient the cost and time will be in executing it.

2. Time Control

Schedules are created to plan, monitor and control that precious commodity, time. The scope of work is usually accompanied by a time restriction. This can be in a macro form or a more detailed micro form. Several forms of time control exist. The worst form of time control being memory or as many of us veterans recall, on the back of a cigarette pack or napkin. More effective methods include lists with dates, day-timers and notes. Modern software now allows us to utilize time scaled charts, specialized computer applications and risk analysis programs.

In essence time control involves establishing a timeframe or duration and applying it to an item of work breakdown or activity. It should be measurable so that at specific intervals progress can be determined against the base or original plan. These durations are assigned by the use of actual data from previous results or from estimated results. These activities are then linked to other activities via dependencies. These dependencies are called relationships. Activities can be linear or in series or they can be in parallel with one another. By creating this network of interdependencies a critical set of activities emerges which helps to determine priorities. With accurate input of actual progress the schedule acts as a tool to determine current status and predict future results.

3. Cost Control

Similar to time control, cost control assigns value to the scope of work. Individual items within the scope can be valued and then summarized to a work breakdown item or cost code. Ideally, time control and cost control should support the same basic work breakdown structure thus providing a basis for measure. This basis serves as the initial cost plan. The value or cost of an item of work can be determined by using historical data, estimated results or through research analysis. Cost is generally broken down into labour and material with possible contingencies where they apply.

Controlling costs involves careful procurement and assignment of resources and materials within the scope budget or estimate. Any deviation from the scope or changes in work is a major source of cost overruns. Change management becomes a key function in controlling these unplanned costs. Comprehensive documentation is the basis of a well managed cost and change control program.

4. Quality

Quality can be defined as the ability of features and characteristics of a product or service to satisfy stated and implied needs.
This takes on a more technical approach to the management of work and the level of expectations in product or process. A good quality program starts with a well defined need through clear and concise scope documents, specifications and drawings. It includes such factors as material specifications, dimensioning, tolerances, welding procedures, codes and regulations. In the case of personnel it involves levels of skill, expertise or, certification and professional designation. Quality programs should be recognized and uniform. Many organizations have adopted recognized international standards of quality control such as ISO. Quality involves inspections and the documentation of results which are compared to the specified needs, which may in turn lead to non conformance and corrective actions. Needless to say the fewer non conformances encountered the more successful the project in terms of cost and time.

5. Resources

Resources include all the elements required to execute or deliver the project such as labour, material, money, equipment, tools and time. It involves procuring and assigning these resources at the point of need in the project in order to avoid waste or delay. Resources introduced too early, too late or inadequately become inefficient or non productive thus driving cost and time beyond the plan or budget. The key to efficient use of resources is to determine the optimum quantity and applying them at the optimum time. Procurement of resources, managing, human and labour relations also become key functions in a project in order to ensure adherence to quality, time and cost. Resources too can be planned in the same manner as cost and time applied to items on the schedule. By applying resources to the schedule, histograms and cumulative curves are generated providing early resource management capabilities.

6. Safety

As a mature, industrialized economy and society we have developed safe guards to ensure that people can work at their vocation with a level of confidence in their personal safety. Today, unfortunately there continues to exist economies which lag behind in basic worker safety practices. Eventually education will help to create a global minimum safe work standard.
The goal of a safe project is to perform and complete the Scope of work within a specified time, cost and quality without injury or incident. This begins with a complete safety policy and procedure. The policy and procedure adheres to or exceeds Government regulated standards of safety. These policies and procedures must be communicated to all the project participants via several media methods. These include orientation, training, regular reminders, visual and audio awareness techniques. Safety records and reporting are an integral part of a good safety program which generates statistics and lessons learned thus injury avoidance. Safety audits to ensure compliance are a must as complacency can easily result in an injury to a worker. Another widely used safety technique is the Task plan which documents the task process and highlights the potential dangers and the techniques used to avoid or reduce the risk of injury. Each participant in the task reviews the documented plan and acknowledges his understanding prior to the work. This communication helps to unify the group’s responsibilities and identifies the expectations.

To achieve a competitive edge it is necessary to take an organized approach when embarking on a project. Project management can help to achieve that success by providing techniques and guidance through each stage of a project’s development. Each of the above controls does not act alone. They each relate to one another in a project. If one of the controls is not managed adequately it will manifest itself on some other control item. For instance a badly defined scope will increase costs and duration due to excessive contingency allowances. A poorly executed safety program can result in serious injury which produces emotional and tragic results but also causes resource inefficiencies and increased costs or time delay. Conversely poor quality or product can force a project into reworking non conformances utilizing additional unplanned resources.

In conclusion it makes good sense to consider the Fundamentals of Project management in your assignment. When a project is small in nature a Project Manager may be on their own to perform all the major functions of control. On larger projects the function of the Project Manager may be leader and coach guiding a team of experts. Utilization of Project Management does not guarantee perfect results in all cases. If applied and executed properly, Project Management will reduce the risk of failure and increase the rate of success as you gain confidence and experience from project to project.

TCS/The State Group Inc.


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, 2013.

[ii] PMP is a registered mark of the Project Management Institute, Inc.

Integrated Change Control

  • By: pcadmin on 14 Aug 2013

Understanding change control is critical for the PMP exam and your career as a project manager.

Below is a simple flowchart of a basic change control process.

Tips and tricks:

  • A change request is usually initiated by a project sponsor, client, project manager, project team member or less often by any other stakeholder.
  • Change request is the output of:
    • All Monitor & Control processes in all Knowledge areas
    • Perform Quality Assurance
    • Manage Project Team
    • Plan Procurement Management
    • Conduct Procurement Management
    • Manage Stakeholder Engagement
  • Approved change requests are inputs to Control Quality and Control Procurements and are implemented through Execute and Manage Project Work.
  • While preparing for the PMP, students are often confused about the process, some preparation guides suggest to do an impact analysis and then issue and submit a change request to the Change Control Board (CCB) while other say to issue a change request and then do impact analysis and submit to CCB. Both are correct! Change Control is a process and is usually defined in the Change Management Plan (part of Project Management Plan), depending on the project and/or organization, there will be infinite process variations on how change will be managed and controlled.
  • One thing to remember is that if a change request is issued internally (by the project manager or a team member), in most cases the impact analysis would have already been done even before issuing a change request and logging in the change log. You wouldn’t want to issue multiple change requests when a simple impact analysis will show the impact of the change will be unacceptable by the client or CCB. Once the change request is issued, the project manager will follow the same process and submit the existing impact analysis (with any updates or edits) to the CCB.
  • For change requests issued by the client, sponsor, or any stakeholder, the first step will usually be a change request is issued and recorded in the change log and followed by impact analysis and so on.
  • Approved changes can require revision to schedule and cost baselines, activity sequencing, resource requirements, and risk reassessment. Any changes to scope or product specifications should be managed through configuration control. Review the post on Configuration Management and Change Control vs Configuration Control if you are not clear on this topic. 



Configuration Control vs. Change Control

  • By: pcadmin on 09 Aug 2013

This is the fourth in a series of posts on commonly confused terms for the PMP exam.

Configuration Management’s focus, in the context of a project, is on controlling changes to the project’s product’s functional and physical specifications (also called configuration items) as well as project baselines. Review the post on Configuration Management for a more thorough discussion on the topic.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines:

Configuration Control is focused on the specification of both the deliverables and the processes.

Change Control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines.

As the above definition states, the focus of configuration control is on the specifications of both the project’s product (deliverables) as well the process baselines (scope, cost, time, etc.). While change control is much more focused on the “process” part of that change.

Change Control, as defined in the Change Management Plan, will outline a generic process to identify, document, and process any kind of change. This is the intent of Integrated Change Control process. On the other hand, Configuration Control will ensure control of the specifications (product or the process), identifying configuration items to be controlled, evaluating the impact of a change on the whole configuration, as well as control after the change is processed through Change Control. In order words, as (Gladstone, 2008) states, “Three main aspects of configuration management are – version control, change control, and reports (audits).” Change Control is part of configuration management and is “process” focused while Configuration Control is specification focussed for controlling the whole confirmation.

Let’s look at an example (Wikipedia, 2013):

Virtual Case File (or VCF) was a software application developed by the United States Federal Bureau of Investigation (FBI) between 2000 and 2005. The project was officially abandoned in January 2005, while still in development stage and cost the federal government nearly $170 million. The primary reasons for the failure of the project were repeated changes in specifications, and repeated turnover of management, which contributed to the specification problem.

As a specific example, Sept 11 attacks highlighted the Bureau’s information sharing problems and increased pressure for the Bureau to modernize. In December 2001, the scope of VCF was changed with the goal being complete replacement of all previous applications and migration of the existing data into an Oracle database. Additionally, the project’s deadline was pushed up to December 2003.

The change to scope and specifications of the software would have been processed through a Change Control process as defined in the Change Management Plan. Configuration Control would have ensured correct impact analysis while changing the product specifications and ensuring any changes to the scope and specifications are documented and a new design baseline is established. The new project schedule would have been the result of impact analysis and taking into account the new configuration of the software.


Project Management Institute (PMI). (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th ed.). Newtown Square, PA: Project Management Institute.

Gladstone, Kent (2008), Virtual Configuration Management, PMI Virtual Library

Wikipedia (2013), Virtual Case File. Retrieved July, 2013 from http://en.wikipedia.org/wiki/Virtual_Case_File .

Components of Configuration Management

  • By: pcadmin on 19 Jul 2013

The four basic processes of configuration management are:

  • Configuration Management Planning (not included in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
  • Configuration Identification
  • Configuration status accounting
  • Configuration verification and audit

Configuration management planning, like most other plans, requires planning ahead of time to provide guidance and direction on how configuration management will be accomplished throughout the project or product lifecycles. It involves establishing what configuration items need to be controlled, typically the level at which to control the configuration for both hardware and software; when to control configuration, normally once a baseline is established; how to change configuration through configuration control process; and the level of resources required for configuration management efforts.

Configuration Identification

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)  definition – “Identification and selection of a configuration item to provide the basis for which the product configuration is defined and verified, products and documents are labeled, changes are managed and accountability is maintained.”

The main purpose of this process is the identification and selection of a configuration item (CI). “A configuration item (CI) is any part of the development and/or deliverable system (whether software, hardware, firmware, drawings, inventories and/or documentation) which needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained.  CIs differ widely in complexity and may contain other CIs in a hierarchy.” (Kelly, 2005)

Each CI should have a unique identifier and a version number. Configuration management plan will help determine the level at which configuration items should be defined for both software and hardware components. For example, design of a new smartphone will have hardware and software as primary specifications which can further include configuration items:

Hardware – radio system, camera, casing, keyboard, etc

Software – radio system software, camera software, user interface software, etc.

Configuration status accounting

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) definition – “Information is recorded and reported as to when appropriate data about the configuration item should be provided. This information includes a listing of approved configuration identification, status of proposed changes, and implementation status of approved changes.”

This process is mainly concerned with keeping track of all configuration items, all pending changes, and all approved changes to configuration items. The status accounting process is mostly one of reporting on what progress the project team has made in completing configuration items and in incorporating approved changes into configuration items.  But, although the configuration status accounting process may seem trivial, there is one important function that it plays.  It provides a very useful metric on the quality of specific configuration items. (Mitretek, 2002)

Configuration verification and audit

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) definition – “Configuration verification and configuration audits endure the composition of a project’s configuration items is correct and that corresponding changes are registered, assed, approved, tracked and correctly implemented. This ensures the functional requirements defined in the configuration documentation have been met.”

Configuration audits is concerned with verifying consistency of configuration documentation against the product. There are two basic types of configuration audits: the Functional Configuration Audit (FCA), and the Physical Configuration Audit (PCA).  The Configuration Manager or his representative conducts a FCA to make sure that the configuration item performs as its design and specification indicate that it should perform.  A PCA is an inventory of the configuration items for the system (or any of its subsystems) and ensure that all of the items are actually in existence before the system (or subsystem) is accepted for testing or for production use. (Mitretek, 2002)


Kelly, Marion V. (1995), Configuration Management: The Changing Image. McGraw-Hill Companies, The.

Mitretek Systems, Inc. (2002, April), A Guide to Configuration Management for Intelligent Transportation Systems. Retrieved July 2013 from http://ntl.bts.gov/lib/jpodocs/repts_te/13622.html

A Project Stakeholder Story

  • By: pcadmin on 17 Jul 2013

Tata Motors designed the Nano, the cheapest car in the world, and needed a site to build their manufacturing plant. The Indian state of West Bengal, to encourage Tata to build in their state, acquired the land from numerous small-holding farmer landowners at Singur, and Tata built their plant. Then the farmers began prominently protesting against the “forced acquisition” of their land by the government. Tata first delayed the Nano launch and later decided to build the car in a different state, Gujarat, instead. They had to build a new plant and pay their many local suppliers to also move with them.

Tata was no doubt originally pleased that the farmer stakeholders were being completely handled by West Bengal state. In other words, they were assumed to be stakeholders of low interest and zero power, in the power/interest model of stakeholder analysis. But this shows that sometimes stakeholders of apparently low interest and power may change into stakeholders of enormous interest and power.

Why is Integration Management the First Knowledge Area?

  • By: pcadmin on 14 Jul 2013

Recently, a very interesting question was posted on LinkedIn:

“Why is Integration Management the first knowledge area ?

I am just wondering why PMBOK placed and described the Integration Management(IM) knowledge area at the very beginning of all knowledge areas? Don’t you think it should come at 9th place (PMBOK 4th Ed.) or 10th place(PMBOK 5th Ed.) since, IM integrates all the knowledge areas? If other knowledge areas are not planned or executed then how can we integrate those at first hand? Any thoughts?”

My response:

Putting integration at the end, the implication is that the plan is an output of all other knowledge areas. Two issues: it is “bottom up” thinking, and forgets that the PMBOK is about more than just planning.

Integration management is arguably the most important area of project management. On a large project, a project manager can assign each of the knowledge areas to a specialist, a scheduler, a cost manager, a quality manager, even a communications manager (although communications management is another discipline that is tough to assign completely to someone else as it is fundamental to good integration management), but the project manager cannot and should not transfer responsibility for integration management although she/he may share it with a specialist vendor.

Many project struggle and even fail due to the lack of integration management by the project manager (Denver airport baggage handling system was a classic example), and complex projects succeed due to the proper attention paid by the PM to this area (Pearson airport). Think of a large complex project with many subcontractors – who is responsible to ensure that all the pieces fit at the right time, that communication flow between subcontractors is happening, and that the whole fits in with the client environment.

It is not the end story – it is the beginning. First you develop strategy and plan, paying particular attention to integration, then you develop tactical plans and implementations, like the schedule, budget, quality, etc. Integration continues to lead in execution, monitoring and control and closing.

Leave us a comment or feedback on with your thoughts.

Configuration Management

  • By: pcadmin on 06 Jul 2013

Configuration Management is a comprehensive topic in itself and its application extends to overall product management lifecycles, engineering design, quality assurance, records management, etc. The focus of this post is to help understand configuration management in the context of project management, especially as it relates to integrated change control. The discussion of this topic in A guide to the project management body of knowledge (PMBOK® guide) and several other PMP preparation guides is not comprehensive and many prospective exam takers often don’t understand configuration management and its relationship to change control.

Given the sheer volume of information available on the topic, this post is divided into three parts –

If you are only interested in a brief introduction to configuration management for the purposes of PMP preparation, the first post will be sufficient. For those brave souls willing to delve deeper into the world of configuration management, posts 2 and 3 will give you a good introductory knowledge and reference to study more should you choose to delve even deeper.

Configuration Management – Primer

The PMBOK® Guide defines a Configuration Management System as – “A subsystem of the overall project management system. It is a collection of formal documented procedures used to apply technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a product, result, service, or component; control any changes to such characteristics; record and report each change and its implementation status; and support audit of the products, results, or components to verify conformance to requirements. It includes changes, documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes.”

Not a very self-explanatory definition I assume!

Within the context of project management, we use configuration management to control changes to specifications (functional and physical) of the project’s product and maintain a central repository of the most updated design (the latest version), previous versions starting from the initial baseline design, and details of all changes that were implemented, under implementation, and those waiting a decision. In short, a configuration management system provides formal documented procedures to control changes to product specifications and ensures any change to one component is carried through to all dependent components, e.g. change to the diameter of a blind rivet used for aircraft construction may affect multiple design features.

PMI’s standard on Project Configuration Management recommends using configuration management to control process baselines as well (project management plan, schedule, cost, etc.).

Some key aspects of configuration management you need to know for the PMP exam are:

  • Configuration Management System is a sub set of Project Management Information System (PMIS) and Change Management System is a sub set of Configuration Management System.
  • Configuration Management is used to control the physical and functional specifications of the project’s product (deliverables) as well processes (schedule, time, cost, etc.). This is achieved through Configuration Control.
  • Change Control is focused on identifying, documenting, and approving or rejecting changes to project documents, deliverables, or baselines. A separate post discusses Change Control vs Configuration Control.
  • Configuration Management System (part of PMIS) serves as a central repository to maintain all project documents and project’s products specifications. Please note the difference between a Configuration Management System and Configuration Management, the system is part of Enterprise Environmental Factors (often automated tools) that helps achieve the latter which is a management approach with defined set of activities.
  • We maintain project documents, plans, artifacts as well as product specifications in the same configuration management system. You may encounter questions on the PMP exam testing where project baselines are stored and version controlled. The answer will be configuration management system which is a subset of PMIS.
  • Three main aspects of configuration management are – version control, change control, and reports (audits). (Gladstone, 2008)
  • The three configuration management activities outlined in the PMBOK are:
    • Configuration Identification – Identification and selection of specifications (configuration items) of a product that need to be controlled, and assigning them a unique identifier and version number for control and tracking purposes. For example, design of a new smartphone will have hardware and software as primary specifications which can further include configuration items: hardware – radio system, camera, casing, keyboard, etc; and, software – radio system software, camera software, user interface software, etc.
    • Configuration status accounting – Reporting on the status of configuration items, list of proposed changes, and implementation status of approved changes.
    • Configuration verification and audit – Verification and audit of the project’s product to confirm all changes to configuration are registered, assed, approved, tracked, and correctly implemented. It ensures product design provides agreed performance capabilities and all configuration items are in existence (nothing has been missed from the list of requirements). You will find similarities in this process with the Verification process under Control Quality.


Gladstone, Kent (2008), Virtual Configuration Management, PMI Virtual Library

Project Management Institute (PMI). (2013). A guide to the project management body of knowledge (PMBOK® guide) (5th ed.). Newtown Square, PA: Project Management Institute.

Assumption vs. Constraint

  • By: pcadmin on 30 Jun 2013

This is the second in a series of posts on commonly confused terms for PMP exam.

PMBOK® Guide 5th Edition defines:

Assumption – A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration.

Constraint – A limiting factor that affects the execution of a project, program, portfolio, or process.

Assumptions and constraints are first listed in the Project Charter and then analysed and expanded throughout the project. They form an important component of the project scope statement; their validity should be tested throughout the project.

As stated in the definition above, constraints define the boundaries imposed by the client/sponsor or by government regulations due to the nature of the work. Constraints can be business constraints imposed by the organisation, typically related to time, cost, schedule, resources, quality, or risk tolerances; or, technical constraints imposed by the design and architecture of the system, like hardware constraints in software development, strength of the materials for construction of a bridge, etc. Constraints are key inputs to the development of WBS, time and cost management processes, and risk management process.

Assumptions are factors that we believe to be true without any definite proof or analysis. Assumption analysis is a key input to the risk management process. We make assumptions every day in every aspect of our lives, assuming the traffic on the way to work will be same as last week, markets will recover the highs after a long bear run, milk will always be stocked and available at a 24 hr grocery store, people working for 7.5 hours will actually work effectively and efficiently for 7.5 hours, etc.

Another way to look at assumptions are factors that must occur for the project to succeed, with the probability of an assumption holding its weight between 0 (assumption turns to be completely false) and 1 (exactly as assumed). Using assumptions help to model a project for cost and time estimates. However, if the probability of an assumption turns out to be 0, the estimates and the whole project may be in jeopardy. That is the reason why assumptions are a critical input to risk management and setting up of contingency and management reserves.

Let’s look at an example:

You are a PM for a condo restoration project following a flood due to water main rupture. This is a major undertaking involving several stakeholders with competing requirements. Constrains imposed by the condo board and condo management company can include, all work on the condos should be accomplished by the year end and the budget for the project is limited to the insurance claim plus a percentage of the reserve fund as stipulated in the condo by laws. Another constraint could be that an inspection should be completed before the hallway walls can be insulated and dry walled. Some assumptions in this project can be – the next condo will become available as soon as the work on the last one is finished, no delays in the shipment and availability of materials, all the owners who renovated their units followed the condo by laws, etc.

Many times you may realize that constraints imposed on a project are also the result of assumptions made by sponsor/client/regulators.

An interesting word history on assumption from dictionary.reference.com (of course not required for PMP!):[1]

The word assumption is a great example of how a word can take on new dimensions of meaning over time, while staying true to some aspect of its original sense. Assumption has been in the language since the 13th century, and was initially confined to a specific ecclesiastical meaning in the Catholic Church. The Latin word on which it is based literally means “the action of being taken up or received,” and in English assumption referred to the taking up into heaven of the Virgin Mary. That meaning still exists today, and in all the meanings it has assumed since then, one can see the common thread running through them is the sense of taking.

One early sense meant “arrogance,” as in this 1814 quote from Sir Walter Scott: “his usual air of haughty assumption.” Arrogance is a taking upon oneself a conviction of self-importance. Later senses arose having to do with the taking on of power or other responsibilities, as in “the assumption of command.”

Probably the most common meaning of assumption in use today is for indicating a supposition, an estimate, a conjecture—that is, something taken for granted. And as any school kid knows, presuming to assume can be dangerous, leading us to make, as the saying goes, “an ASS of U and ME!”

Validation vs. Verification

  • By: pcadmin on 20 Jun 2013

This is the first in a series of posts on commonly confused terms for PMP exam.

PMBOK Guide 5th Edition defines:

Verification: The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process.

Validation: The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers.

More commonly used definitions for Validation and Verification used in software engineering systems are:

Validation: Are we building the right system?

Verification: Are we building the system right?[1]

Verified deliverables are outputs of the Control Quality process and tests for correctness of the deliverables. Correctness relates to specified product/service/result requirements and design specifications. While doing Verification we are concerned with whether the deliverable meets exact requirements specifications.

Consider an example, you are in the process of developing a calculator mobile application for a mortgage broker for calculating monthly mortgage payments by their clients. The inputs in the calculator are cost of the property, down payment, interest rate, and amortization period.  While verifying the deliverable, you will typically test whether the application works as desired, the algorithm for calculating monthly payments gives the right results under different conditions, the flow of the application is easy to use, the branding for the broker is as per the approved design (through a previous Validation process!).

Validate Scope is a process of Project Scope Management knowledge area of the PMBOK 5th edition. The verified deliverables from Control Quality are reviewed with the customer or sponsor to ensure they have been completed satisfactorily and to receive formal acceptance. Validation is concerned with the acceptance of the deliverables.

How will a customer give formal acceptance of the deliverables? The client or sponsor will typically test the product/service/result against the requirements document (most importantly business requirements) and requirements traceability matrix. Most often than not, the client is much more concerned if the deliverable meets the stated need of the product/service/result than a list by list technical requirements. In the above example, while validating the mobile calculator application, the client will typically check for the correctness of results under different scenarios, branding, and most importantly whether the application actually serves the real need. The client may realize that in order for the application to be universal, instead of just having a fixed interest rate input, they want to include an option of entering variable interest rates (calculated by automatically downloading the latest prime rate from Bank of Canada).

Following Validation, the client may accept or request for a change (through Integrated Change Control) as a corrective action or defect repair.

Its common sense that Verification should be done before Validation, you won’t take an untested product to a client and bear the embarrassment if the product fails to function as expected; even though this happens all the time. Do remember that both Verification and Validation can also be performed in parallel. I’ll leave it to you imagination on how to accomplish this.

A good discussion of how NASA’s Independent Verification and Validation (IV&V) program defines Validation and Verification can be found here – http://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/

Which EAC Formula to Use?

  • By: pcadmin on 13 Jun 2013

Are you confused which EAC (Estimate at Completion) formula should you use in which situation?

Once you understand the logic behind each formula, you will no longer need to memorize the formulas.

Formula 1 –


This is the most commonly used formula if no other information is available. It assumes the present cost variance to continue for the remaining project. This cost variance could have been due to inaccurate estimation, changes in the external environment or prices, etc. and will remain going forward.

This is also referred to as a typical case.

Interpretation of the formula is very simple. Let’s assume CPI (cumulative) at 50% completion is 0.8. This basically means, our EV is 0.8 times AC, or we are only getting $0.8 worth of work completed from every $1 spent. If we continue getting the same worth (same CPI), the Estimate at Completion will be 25% more (1/0.8%).

Formula 2 –


This formula is used when the assumption is that the present cost variance was only a one-time event and our budgeted cost will be applicable for the remaining project. A one-time cost variance could be due to unexpected delays in shipment and no further shipments are required, or an unexpected event (a major flood or fire) caused the closure of the office building for a week, etc.

This is also referred to as an atypical case.

Again, the interpretation is very simple. Our EAC is simply the sum of costs incurred so far (AC) and the budgeted cost of the remaining work (BAC-EV).

Formula 3 – 

EAC = AC + [(BAC-EV)/ (CPIc*SPIc)]

This formula is used when not only the expected cost variance is typical (similar to Formula 1), but also there is no flexibility on the schedule, i.e. schedule cannot be compromised and the project has to finish as planned, e.g. a conference which has to begin on the advertised date, no questions asked.

As we can see, we estimate the cost at completion by adding the costs incurred so far (AC) and modifying the remaining budgeted cost (from Formula 2) to account for CPI and SPI.

Formula 4 –

EAC = AC + new ETC

This formula is considered the most accurate and no surprise, the most time consuming. We will typically use this formula when are estimates or assumptions are no longer relevant or while using a rolling wave planning.

The interpretation is straightforward, estimate at completion is simply actual costs incurred to date (AC) plus a new estimate of the remaining work.


Upcoming events

Latest Tweets

Sorry, twitter is currently unavailable.