There are several differences between project audits and project reviews, mainly:

• Project reviews are usually held at the end of each project phase. In most cases, the project review is conducted at the end of the whole project (and in this case it is often referred to as “project post-mortem”). Project audits, on the other hand, can be held at any time during the course of the project, or even after the project is finished (though naturally, performing a post-project audit has no benefits for the project, but may be helpful for future projects).
• The aim of the project review is to make sure that the project is on time, on schedule, on scope, and on budget, as well as highlighting key issues the project is facing (note that in the case of a project post-mortem, the aim is just to highlight key issues the project has faced, in order to improve the process for next projects). In short, the project review can be labeled as a “project health check”. The project audit is not about the health of the project, but it’s about seeing if the project is being managed properly according to the organization’s standards and guidelines and that the project plan is being followed. The aim of the project audit is to identify any project management errors that may have occurred during the project.
• Project reviews are performed by the project review board (or PRB). Although there are no defined standards about the constituents of the project review board, it usually includes one or more of the following: project sponsors, program managers, clients, and other project stakeholders. Project audits are performed by the PMO, by internally trained auditors (usually with a Project Management background), or by external auditors provided by specialized Project Management firms.
• The outcome of the project review is a written document assessing the health of the project, highlighting key situations affecting the deliverables, the budget, and the schedule. This document is sent to the Project Manager, the team members, and other involved stakeholders. The outcome of the project audit is the project audit report, which is sent to both the stakeholders and the Project Manager. The project audit report captures all the project management issues found by the auditor, assigns each a severity (usually from 1 to 10), and suggests a corrective action. Here’s a project audit template (note that this is a Microsoft Excel version, a PDF version is available as well).

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

• Project Management in project-driven organizations is mature and respected. On the other hand, in non-project-driven organizations, Project Management is still in its infancy, and is often looked at with skepticism.
• Project-driven organizations make the lion’s share of their income through projects, non-project-driven organizations mainly make their income through production.
• The Project Manager is responsible of the profitability and loss in project-driven organizations. In non-project-driven organizations, the responsibility for profitability and loss is ambiguous.
• Project-driven organizations adopt either fully projectized or matrix organizational structures. Non-project-driven organizations usually adopt a functional organizational structure.
• Project-driven organizations have flexible career paths, where one can ascend quickly to higher positions. Non-project-driven organizations have traditional career paths, where moving upwards in the company ladder is very difficult. Quite often, one has to wait for his manager to get fired/resign/retire/die to ascend the company’s ladder and assume a better position.

Examples of industries where project-driven organizations are predominant include:

• Construction
• Aerospace
• Research

Examples of industries where non-project-driven organizations are predominant include:

• Manufacturing
• Services
• Farming
• Natural resources

IT (Information Technology) organizations (that fall under the services industry) are considered to be hybrid, where parts of such organizations are considered to be project-driven (such as the development of a new software), while other parts are considered to be non-project-driven (for example supporting applications).

In order to answer this question, let us examine the following:

• The PMBOK, considered by many as the final word when it comes to defining Project Management and its terms, is also divided on the subject. In the PMBOK version 3, task and activity do not mean the same thing. However, in the PMBOK version 4, the term task is not defined. Activity is defined as a work package (the lowest level WBS activity).
• As stated earlier, some Project Managers believe that a task is a work package, and may comprise (or may decomposed into) one or more activities. Their supporting argument is that a task clearly has a starting date and an ending date by definition, while an activity is vague from that perspective.
• It is unknown why there’s another group of Project Managers thinking that an activity is a work package that can be split into more tasks. This definition is the weakest as it has no logical grounds.

What Should I Do?

As one can see from the above, there are 3 different opinions and there’s definitely no consensus. However it seems that the PMI (who, again, has a huge say when it comes to Project Management) has moved towards unifying the meaning (again, from a Project Management perspective) by solely using activity to denote a work package. Having said that, it is important to note that it’s not a case of who’s right and wrong, and the best thing a Project Manager can do is to follow the standards of his company for the for the proper usage of Project Management terms, and if there are no standards set, then he can set his own. In that case, probably a good idea would be to use these terms interchangeably, along with job and operation, which also mean the same thing.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

More Details

• Estimated Cost at Completion (EAC) is what the Project Manager expects for completing a specified objective, be it a task, an activity, or a project.
• The Actual Cost (AC) is the cost incurred so far for completing a specified objective, that cost is known and is ready to be charged to the project budget. The payment for the actual cost is either already cleared or pending clearance.
• The Actual Cost morphs into the Actual Cost of Work Performed (ACWP) once the objective is accomplished. The ACWP represents the total costs incurred at the completion of the objective.
• Subtracting the Actual Cost from the Estimated Cost at Completion will return the Estimate To Complete (ETC = EAC – AC). If the ETC is positive (e.g. bigger than 0) then this means that the task/activity/project has not yet exhausted the budget (a good sign), a negative result (ETC < 0) means that the task/activity/project is now over-budget. This can be extremely bad news especially if the objective is far away from being reached.

A Simple Example

The Project Manager has predicted the cost of finishing a construction project to be $4,000,000. 10 months into the project, the costs (such as material, labor, etc…) incurred so far were $3,000,000. This means that:

• Estimated Cost at Completion (EAC) is $4,000,000.
• Actual Cost (AC) is $3,000,000.
• Estimated cost for completing this project = Estimate To Complete = ETC = EAC – AC = $4,000,000 – $3,000,000 = $1,000,000.

Notes

• Some Project Managers mistakenly refer to the Estimated Cost at Completion as simply Estimated Cost, which is wrong, as the term has to stress that it’s an estimate for completing an objective.
• Some think that the Actual Cost can only be known at the completion of the objective (confusing AC with ACWP), again, this is wrong. The actual cost changes every time a cost is incurred towards completing that objective.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

• Construction Project Management is mature and predictable, and has been (mainly informally) practiced for thousands of years now. Software Project Management is at most 50 years old in its informal and then formal form. Software Project Management is still an immature and non-standardized practice (but it is predicted to reach a comfortable level of maturity in 20 years).
• Construction Project Management is taught at school to civil engineering students (usually the course is titled “Construction Engineering and Management” or “Construction Management”, among others). Such courses are standardized all over the world. On the other hand, there is no formal education for Software Project Management (formal education is restricted to certification). Recently, however, some schools are starting to offer courses in Project Management for software students, but the courses’ contents are still not standardized (e.g. they differ from one school to the other) and they essentially reflect the teacher’s own view of Software Project Management.
• Construction Project Management is usually only practiced by those holding engineering degrees, Software Project Management can be practiced by virtually anyone, provided he possesses the necessary experience to do the job.
• Construction Project Management defines some clear and static requirements in the planning phase, which makes the waterfall methodology perfectly suitable to manage a construction project. In Software Project Management, the requirements collected from the client during the planning phase are often either unclear or incomplete, which makes the fluidity and the adaptability of an agile approach very suitable to accommodate software projects. Negative consequences may ensue Should the Project Manager elect to adopt waterfall in case of a software project, such a flood of change requests in the execution phase (potentially leading to scope inflation), which may result in a project that is behind schedule and over budget.
• Since costs in Construction Project Management are hugely offset by tangible resources (such as concrete, iron, etc…), then costs overruns may be dramatic in case of a price increase in raw materials. In Software Project Management, there are usually no tangible resources to buy, hence this problem does not exist.
• In Software Project Management, Project Managers have the flexibility of outsourcing work, consequently reducing the cost of labor, and ultimately reducing the total cost of the project. In Construction Project Management, however, outsourcing is not an option, as nearly all the resources have to be physically on-site which makes reducing the cost of labor problematic (some countries/companies overcome this inconvenience by issuing work permits to laborers from neighboring countries to work on their construction projects).
• High level politics (sometimes country politics) play a major role in Construction Project Management, low level, company or departmental politics may shape the project in Software Project Management.
• Construction Project Management thrives in a traditional organizational structure (e.g. functional or matrix organization). Software Project Management thrives in a projectized environment.
• Communication in Construction Project Management is simple and straightforward. In Software Project Management, communication is complex and plays a major role in the project: online Project Management Software is nowadays a necessity to communicate with the project team and the stakeholders.
• Conflict Management in Software Project Management is a big issue, as the Project Manager has to constantly caress the programmers’ and the designers’ egos while making sure that all personal conflicts are resolved in a timely manner to maintain a high spirit among team members (in order so sustain high productivity). On the other hand, Conflict Management in Construction Project Management is almost non-existent, this is because of the following reasons:
  • The Project Manager owns the resources, and can be much more authoritative and firm when handling conflicts (scaring potential trouble-makers) .
  • Construction workers have much less ego than programmers or designers.

  Having said that, conflicts among workers do arise occasionally, and they often take the form of a physical (not mental) conflict. Additionally, Construction and Software Project Management both suffer from high level conflicts (e.g. with stakeholders’ conflicts), although the latter is more susceptible to such conflicts.

• The types of risks differ completely between Construction and Software Project Management. Risks in the former are usually high-level, broad risks (such as new government policies affecting imports of raw materials), while risks in the latter are project-level risks such as an “unaccounted for” maternity leave for a key resource, a chosen technology that is unsuitable to build the product, etc…

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

• Good Project Managers communicate constantly with the stakeholders, the client, and the project team. Bad Project Managers isolate themselves in their office/cubicle and try to keep communication with anyone to the minimum, leaving the team confused, and the client and the stakeholders falsely reassured.
• Good Project Managers are proactive, they foresee risks and problems and they account for them. Bad Project Managers are reactive, they react to problems as-they-happen, adversely affecting the normal flow of the project.
• Good Project Managers focus mainly on the project success, and then, to a lower extent, they focus on the project management success, and they can tell the difference between the two. Bad Project Managers care only about the Project Management success (specifically the part about being on budget and on schedule), they don’t seem to care much about whether the project has delivered tangible value to its stakeholders or not. They don’t even know that Project success is not the same thing as Project Management success.
• Good Project Managers put low emphasis on the methodology used; they just follow a methodology (whatever it is) to get the job done. Bad Project Managers try to force an incompatible methodology on a project, just because “they’re used to it” or “everyone is now using it”.
• Good Project Managers are organized: they’re always able to immediately locate any document about any project. Bad Project Managers are always in complete disarray, and they never seem to locate any document about anything.
• Good Project Managers are punctual, they’re always on time (and usually ahead of time) when attending a meeting. Bad Project Managers are usually at least 10-15 minutes late, wasting valuable company time, and citing lame and overused excuses on why they’re late (traffic jam, had to drop kids at school, etc…).
• Good Project Managers call for a meeting when they feel the project needs a meeting. Bad Project Managers call for a meeting when they feel like having a meeting (which may be every day or every month).
• Good Project Managers pay attention to their resources, cater for their needs, make sure they have the moral and the logistical support to be able to work on their tasks. Bad Project Managers are disconnected from the project team, they don’t know (and they don’t care) what the team needs.
• Good Project Managers know when to say “No” to the stakeholders. Bad Project Managers always say “Yes” to the stakeholders, and commit themselves to unachievable deadlines and unrealistic budgets.
• Good Project Managers think that having their team work overtime (especially for an extended period of time) is a bad idea. Bad Project Managers think that having their team work constantly overtime is a good idea, and even better when they (the team members) are paid for it.
• Good Project Managers are able to balance their life and their work and have them completely separated. Bad Project Managers try to constantly juggle life and work, and never seem to get any of them right.
• Good Project Managers are doers. Bad Project Managers are procrastinators.
• Good Project Managers spend their spare time sharpening their Project Management skills (reading and blogging on Project Management). Bad Project Managers spend their work time playing games or using the social media for non-professional purposes.
• Good Project Managers work on their image within their organization so that one day, they can get the promotion they deserve. Bad Project Managers work on their CV for their potential interviews outside their organization.

© 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

• Negative risks are unwanted and potentially can cause serious problems and derail the project, positive risks, on the other hand, are opportunities and are desired by both the Project Manager and the stakeholders, and may positively affect the project, such as increasing the ROI or finishing the project ahead of time.
• Known negative risks have to be managed and accounted for in the risk management plan, this is the same for positive risks. However, positive risks are managed in order to take advantage of them and “tame them”.

Examples of Negative Risks

• The main programmer on the project quitting the job.
• Lack of construction material (such as concrete) because of political issues (such as hostile relations between 2 bordering countries) in case of a construction project.

Examples of Positive Risks

• Receiving much more than the expected number of subscribers on the launch date of the service (for example a new telecommunications service).
• Finishing a part of the project way before schedule and creating a lot of slack, as other resources are not scheduled to work on the project until much later.

  Note that positive risks can easily create negative risks, for example, in the case above where the telecom service gets a lot of subscribers on its launch date, then negative risks may possibly ensue, such as the inability of the switches to handle the load, the inability of the billing system to process all the calls, the clogging of the text messaging system, etc… These negative risks combined, can cause the whole service to fail, as people will be completely dissatisfied with the service. In short, positive risks are good but need to be accounted for and taken seriously.

  © 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

  ]]> http://www.projectmanagementlearning.com/what-is-the-difference-between-positive-and-negative-risks.html/feed 0 http://www.projectmanagementlearning.com/what-is-the-difference-between-project-manager-and-project-leader.html http://www.projectmanagementlearning.com/what-is-the-difference-between-project-manager-and-project-leader.html#comments Sun, 03 Jan 2010 17:24:18 +0000 admin http://www.projectmanagementlearning.com/?p=193 Quite often, the terms Project Manager and Project Leader are confused, and are thought to refer to the Project Manager. In reality, there are some differences between the Project Manager and the Project Leader:
  • The Project Leader is heavily involved technically in the project by coaching the project team, the Project Manager is involved in the project at a higher level, by giving directions (assigning tasks….).
  • The Project Leader is usually only responsible for one project (hence the time for dedicated attention and technical focus), the Project Manager can be responsible for many.
  • The Project Leader usually reports to the Project Manager, the Project Manager reports to upper management.

  Note that in rare cases (e.g. very small companies) the Project Manager and the Project Leader can be the same person.

  © 2010 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

  ]]> http://www.projectmanagementlearning.com/what-is-the-difference-between-project-manager-and-project-leader.html/feed 0 http://www.projectmanagementlearning.com/what-is-the-difference-between-project-progress-and-project-schedule.html http://www.projectmanagementlearning.com/what-is-the-difference-between-project-progress-and-project-schedule.html#comments Thu, 03 Dec 2009 20:50:48 +0000 admin http://www.projectmanagementlearning.com/?p=158 The main difference between Project Progress and Project Schedule is that the former refers to the work actually done for a specific period, while Project Schedule refers to the planned dates for performing work (or activities). Project progress falls under reporting in Project Management, while Project Schedule falls under planning.

  An example of Project Progress would be: “The project is 72% as of today, December 3rd” (note that Project Progress refers to “Movement towards Completion”). An example of an activity in the Project Schedule would be “We will start the working on the interface on Monday, December 7th, and we will be finished by Thursday, December 17th.”

  © 2009 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

  ]]> http://www.projectmanagementlearning.com/what-is-the-difference-between-project-progress-and-project-schedule.html/feed 0 http://www.projectmanagementlearning.com/what-is-the-difference-between-pmp-and-pgmp.html http://www.projectmanagementlearning.com/what-is-the-difference-between-pmp-and-pgmp.html#comments Mon, 30 Nov 2009 04:59:54 +0000 admin http://www.projectmanagementlearning.com/?p=147 Although they’re both credentials issued by the PMI, there are many differences between the PMP and the PgMP, including:
  • The PMP stands for Project Management Professional, the PgMP stands for Program Management Professional.
  • The PMP is credential sought by Project Managers, the PgMP is a credential sought by Program Managers.
  • The eligibility for the PgMP are much steeper than the eligibility for the PMP (more than double the experience years and hours).
  • The PMP credential is about meeting the eligibility requirements and passing the PMP exam, while for the PgMP, it’s about meeting the eligibility requirements, passing the panel review (which is a verification process of your Program Management experience), passing the PgMP exam, and finally passing the Multi-rater Assessment (MRA), which is an online evaluation survey, that you and 12 of reference contacts (your references) have to take.
  • There are as many as 360,000 PMP practitioners, while there are only 400 PgMP practitioners.
  • The fees for the PgMP certificate are (on average) 4 times more than those of the PMP credential.

  As you can see from the above, the PgMP is a much more exclusive credential than the PMP, with so much less certified people, and a (much) more complicated process. It is way easier to become a PMP than to become a PgMP, yet the trouble for the latter is definitely worth it if you’re a Program Manager with the necessary experience seeking a career boost. In case we don’t have a change in PMI’s strategy, the PgMP will remain a credential sought by many and earned by only a select few, who really deserve to be called Program Managers.

  © 2009 Project Management Learning – Reproduction of this material is strictly prohibited without the written consent of Project Management Learning.

  ]]> http://www.projectmanagementlearning.com/what-is-the-difference-between-pmp-and-pgmp.html/feed 0