Comments (0)

What Are the Limitations of Project Management?

Filed in Other Project Management Topics, April 18, 2010, 1:57 pm , ,

After discussing the disadvantages of Project Management, a logical follow-up on the topic would be the limitations of Project Management.

Before starting, we need to define the meaning of limitation in this context. A limitation is a restriction imposed by the application of (mostly traditional) Project Management. Limitations differ from disadvantages as the latter are undesired results stemming from the adoption/application of Project Management, while limitations are boundaries artificially created by Project Management. The absence of these boundaries results in a better management of projects as well as a superior quality in the delivered product/service.

There are several limitations to Project Management, mainly:

  • Inability to “stick” with the project scope: Project Management, by definition, is unable to commit to the original project scope due to constant change requests. Project Management acknowledges this with the formal integration of Change Management. This limitation causes a lot of problems, and is the reason why so many projects end up way over budget and many months/years late, sometimes even canceled or killed.
  • Inability to fully align the project objectives with the business/organizational strategy: By definition, Project Managers manage projects, not their organization. Although projects are usually initiated by stakeholders/executives with a clear relation and full alignment with the overall corporate strategy, Project Managers are incapable, by themselves, to make sure that their projects are kept aligned with the company’s strategy. In order to solve this limitation in Project Management, Program Management was introduced as a higher layer of managerial control to guarantee and sustain alignment.
  • Inability to manage projects with unspecified budget and/or schedule: This is probably the biggest limitation in the traditional incarnation of Project Management. Imagine if, thousands of years ago, pyramid building was restricted to a budget and a schedule. Would the pyramids have lasted so long? Would they have been considered as marvelous wonders? Project Management imposes a budget and a deadline on any project and thus creates a major problem: All projects finishing on time and on schedule (and they are very rare) have their quality compromised (when was the last time you saw perfection in any project?). Resources are not allowed to give their best, gold plating is considered a bad practice, and resources finishing on time, regardless of the delivered quality, are considered heroes.
  • Dependence on functional management: Traditional (non-agile) Project Management is clear about the authority of the Project Manager over the resources: he has none. It is the functional managers who own the resources: they have their loyalty (resources are loyal to their functional managers as they’re the ones who report quarterly on their performance), they have their gratitude (most resources are hired directly by their functional managers), and they have their respect. The dependence on functional management is a major limitation in Project Management, as Project Managers are constantly at the mercy of both the functional managers and the resources (indirectly, for example, an excellent resource resenting the presence of the Project Manager might disobey him, while still being supported and endorsed by his functional manager), and they have to compromise, or “offer something” in return, just to get things done. Note that this limitation is almost negligible in highly projectized organizations.
  • Following an exclusive methodology Project Management forces the Project Manager to choose and follow a methodology, be it the traditional (waterfall) methodology, or a newer methodology such as Agile. In Project Management, a project can only be managed using one methodology, and, in almost all cases, is not switched from one methodology to the other (usually methodology switching is not per project and is a decision made at the organization level), even when the other methodology is proven to be highly successful for that type of project. Being restrited by an exclusive, non-changeable methodology, either at the project level or the organizational level undermines and limits the potential of the project as well as the resources.

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

Comments (1)

What Are the Disadvantages of Project Management?

Filed in Other Project Management Topics, April 13, 2010, 7:37 pm ,

A lot has been written and said about the advantages of Project Management, but almost nothing about its disadvantages. So, does Project Management have any disadvantages? And if yes, what are they?

To answer the above question, yes, Project Management has some disadvantages, but, in most cases its advantages far outweighs its disadvantages.

The disadvantages of Project Management can be grouped into 3 main categories: overhead, obsession, and non-creativity.

Overhead

Project Management presents 3 types of overhead: cost overhead, communication overhead, and time overhead.

  • Cost overhead: Project Management costs money. Hiring Project Managers, training Project Managers, hiring Program Managers to make sure that projects are kept aligned with the overall business strategy, creating a PMO to control the different projects, changing the organization to adopt and adapt to Project Management, etc… are all actions that can cost a substantial amount of money. In the case of small companies, even paying for just one Project Manager is huge overhead, as Project Managers are rarely paid below the $70k mark. Not to mention that small companies view Project Managers as (redundant) employees who do not produce tangible work.
  • Communication overhead: Project Management introduces another layer of communication between management and team members. Instead of having the information flow directly from functional managers down to the team members and back up, it’s all funneled through the Project Manager.
  • Time Overhead: The communication overhead stated above is one cause of time overhead. For example, consider some wrong requirements that the Project Manager mistakenly gathered and passed to the team members for implementation. Once the requirements are discovered to be false, the team members have to scrap the implemented part based on the wrong requirements, the Project Manager has to re-gather the requirements, and finally pass them again to team members for implementation. Additionally, Parkinson’s Law is a nearly unavoidable problem in Project Management, as Project Managers can never accurately assess the length of any task, and pad their estimates so that they won’t wind up with a late project.

Obsession

Obsession is a growing problem in any Project Management environment. It stems from the minds of Project Managers and can be one or more of the following: methodology obsession, process obsession, and stakeholder obsession.

  • Methodology obsession: In case you’re new to Project Management, here’s a short introduction to the whole subject. Project Management has existed for thousands of years (pyramids, for example, were a project). A few decades ago, the “Waterfall” term has been introduced to describe the then linear process of Project Management. Waterfall was applied to all kinds of projects (construction, engineering, etc…), including software projects. Nearly a decade ago (in 2001 to be exact), a group of software professionals introduced a certain methodology (it is debatable on whether it qualifies for a methodology or not) called Agile, claiming that it’s much better for managing software projects due to its iterative approach. Some people converted to Agile and became Agilists in the view of Waterfallists. Moving back to the current day, each camp claims obsessively that their methodology is much better, and one can never finish a project with the other methodology. Instead of just “getting the project done”, which is the whole point of Project Management, some Project Managers have become so focused and so obsessed about the methodology that the latter has grown to be the “end” rather than the “mean to the end”. This jeopardizes the delivery of the project and causes missed opportunities as Project Managers become so closed and so protective their own methodology that they refuse to experiment with another one that might be faster and better for their current project.
  • Process obsession: Quite a few Project Managers hinder the progress of the project with their obsession for sticking to the process. For example, they require all the paperwork to be in perfect order before processing anything, be it a new project, a major change request, a minor change request (e.g. changing the font color), the addition of a new resource, etc… Unfortunately, rigidly following the process is encouraged by most references on Project Management as well as by experienced Project Managers. The reason why most Project Managers consider process obsession a good practice is because of the following:
    • Insecurity: The vast majority of Project Managers are insecure, they’re afraid that if they don’t have a proof of who approved what, they will be scapegoated if something goes wrong.
    • Fear of loss of control: Most Project Managers think that if they don’t enforce a process, then they will no longer be in control of the project (this, to a certain extent, is probably true).
  • Stakeholder obsession: The term stakeholder management, for quite a few Project Managers, means “ensuring stakeholder satisfaction”. Instead of managing the stakeholders’ expectations, requests, and interference, and focusing on getting their support, these Project Managers try their best to accommodate the stakeholders. This accommodation, which often manifests itself in gold plating, is costly and needless. Unfortunately, stakeholder obsession is here to stay, as, in most cases, this is a win-win situation: stakeholders love to be pampered, and Project Managers (for selfish, provincial reasons that have nothing to do with the project) love to pamper their stakeholders.

Non-creativity

Some organizations, when adopting Project Management, suffer from non-creativity. Non-creativity can be either technical or managerial.

  • Technical non-creativity: Project Management imposes deadlines on resources, who have to work as fast as they can to finish their tasks on time. By nature, people like to be creative, especially at work. For example, designers like to come up with the perfect design, programmers like to write elegant, smart, and scalable code, but when there’s a Project Manager breathing down their necks all the time, their primary goal is just to finish on time; they don’t care anymore about unleashing their creativity. This demotivates the resources and adversely affects the quality of the end product.
  • Managerial non-creativity: Faithfully trusting and following a routine process is not the dream of any manager (at any level, whether lower, middle, or upper management). Project Management, by nature, enforces that routine process. Managers, usually leading humans, become lead by a process. Their managerial skills weaken, as there’s no need to sharpen them anymore: the process is clear and it should be followed. Likewise, managers (especially functional managers) become demotivated.

As stated by many, nothing in life is free, and everything comes at an expense. If you’re thinking about implementing Project Management in your company/organization, weigh the expense for making that move, and then weigh the benefits, and finally make your informed decision.

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

Comments (0)

What Is the Difference Between Project Audit and Project Review?

Filed in Other Project Management Topics, April 9, 2010, 11:18 am , , , ,

Most beginners in Project Management confuse the terms “project audit” and “project review”, and think they are the same, although they’re not. So what is the difference between a project audit and a project review?

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.

Comments (0)

Who Is the Project Quality Manager?

Filed in Project Quality Management, April 6, 2010, 3:41 pm , , ,

Typically, in large projects, you can find individuals holding a “Project Quality Manager” title. So who is the Project Quality Manager, when and why was his position created, and more importantly, what does he do?

Primary Role

The primary role of the Project Quality Manager is to devise, implement, and maintain the Quality Management Plan (also known as QMP) as well as to enforce on the technical level and through policies and guidelines on the business/managerial level.

History and Creation of the Role

The role of the Project Quality Manager was initially assumed by the Project Manager for all projects. As project management started taking over bigger organizations and Project Managers were assigned to larger projects, the varied responsibilities of the Project Manager were just too much to handle for only one person. Different roles were forked from the Project Manager responsibilities, including the Project Quality Manager (also referred to as the Quality Manager), the Project Risk Manager (also referred to as the Risk Manager), the Project Scheduler (also referred to as the Project Schedule Manager), etc… The Project Quality Manager, as well as all the other forked roles, report to the Project Manager, and, in some cases, report directly to the stakeholders, under the supervision of the Project Manager.

Note that in small projects and/or small companies the Project Manager role still embodies all the above mentioned roles, which probably explains why Project Managers in smaller companies are usually much more overwhelmed than their peers in bigger companies.

Responsibilities

The main responsibilities of the Project Quality Manager are:

  • Developing the Quality Management Plan: The Project Quality Manager develops the Quality Management Plan after consulting with the project manager and the stakeholders. Note that the former has to approve the final QMP.
  • Maintaining the Quality Management Plan: The Project Quality Manager usually adjusts/modifies the initial Quality Management Plan as the project advances. Medium to major changes must be approved by the Project Manager.
  • Ensuring conformance to the Quality Management Plan: The Project Quality Manager ensures throughout the project that the product/service to be delivered will meet the requirements in the Quality Management Plan. This often means that the Project Quality Manager has to do/manage technical tasks such as testing code. Additionally, the Project Quality Manager makes sure that the policies and processes (pertaining to quality) described in the QMP are respected.
  • Reporting: The Project Quality Manager prepares technical reports (e.g. bug listing) that are used by team members to enhance the project, as well as non-technical reports that are elevated to management describing the current status of the project from a quality perspective.
  • Escalating discrepancies: The Project Quality Manager escalates any (non-minor) non-conformance to the QMP to the Project Manager.

By looking at his list of responsibilities, we are able to conclude that the ideal Project Quality Manager is someone with a technical background, as well as moderate managerial skills.

Some Examples on What Can Be Included in the Quality Management Plan

The Quality Management Plan specifies the policies and the guidelines relating to the Quality Assurance/Quality Control (see the difference between QA and QC) of the project. Here are some examples of the requirements specified in the QMP:

  • Adhering to international quality standards
  • Complying with local as well as international laws and regulations
  • Ensuring only high quality concrete is used (in the case of construction projects)
  • etc…

Current Job Market for Project Quality Managers

Salaries of Project Quality Managers (in 2010) range between $60,000 to $80,000 per year. These numbers are taken from the US job market. In most cases, Project Quality Managers are promoted (or assigned) into this position from within the company, usually on the advice of the Project Manager. Hence the prospects for those seeking jobs as Project Quality Managers are not high.

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

Comments (0)

How to Share PDUs Between Multiple Credentials?

Filed in PgMP,PMP, April 4, 2010, 8:28 am , , , ,

Sometimes, a Project Manager might possess two or more certifications issued by PMI that need to be maintained by PDUs, this mostly happens when a PMP certified Project Manager earns a PgMP certification. So can PDUs be shared between multiple PMI credentials?. And, if the answer is yes, then how?

PMI is aware that getting 120 or more PDUs every 3 years to maintain 2 or more of their credentials is not an easy thing, even when someone can get PDUs for free. PMI has actually implemented a process specifically to handle this issue, where the Project Manager holding muliple certification is offered three choices:

  1. Aligning the Credentials with the Old Credential Cycle

    Let’s assume the Project Manager became a PMP on April 1st, 2008. The Project Manager then earned a PgMP certification on April 1st, 2010. All of the PDUs earned from April 1st are counted towards both certifications. On the flip side, the Project Manager has to renew both certifications on April 1st, 2010 (merely 1 year after acquiring the PgMP certification) as both CCR (Continuing Certification Requirements) cycles are now the same. This is a good option to take in case the Project Manager has collected a lot of PDUs in the previous 2 years.

  2. Aligning the Credentials with the New Credential Cycle

    Let’s look at the above example where the Project Manager became a PMP on April 1st of 2008 and a PgMP on April 1st, 2010. In this option, all of the PDUs earned in the 2 years preceding the PgMP certifications are not counted, on the other hand, the renewal date for both certifications will be on April 1st, 2013. This is a good option to take in case the Project Manager has collected very few PDUs in the previous 2 years.

  3. Not Aligning the Credentials

    The Project Manager might elect not to align his multiple credentials, so the renewal date for the PMP in the example mentioned in the first option will remain April 1st, 2011, and the renewal date for the PgMP certification will also remain April 1st, 2013. This is a cumbersome option, as the Project Manager has to track a different CCR cycle for his multiple credentials. However, it is worthy to note that a PDU reported for the PMP can also be reported for the PgMP certification in this case (similar to the previous options), provided the acquiring of the PDU occurs in the certification cycle for both accreditations.

Sharing PDUs with Specialty Credentials

The alignment of the credentials mentioned does not apply to specialty credentials such as the PMP-SP or the PMP-RMP. However, the Project Manager can still use the PDUs earned for his PMP-SP and/or his PMP-RMP towards maintaining his PMP/PgMP credential in the applicable credential cycle. For example, in case the Project Manager acquired his PMP certification on April 1st, 2008, then acquired his PMP-SP certification on April 1st, 2010, then any PMP-SP PDUs reported can be reported as well to maintain his PMP certification (and also his PgMP certification, in case he has one).

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

Comments (2)

What Is Burn Rate?

Filed in Project Cost Management, March 28, 2010, 4:30 am , , , ,

Burn Rate is a metric to assess the performance of a certain project with respect to the original budget. In short, burn rate is the rate at which the project is spending its original budget.

Origin of the Term

The term “Burn Rate” is originally a financial term, and it was first coined in the 90s during the “Internet Boom” to describe the rate at which new Internet Startups were spending their invested funds, while making no revenue. The term is highly relevant in a Project Management environment since most projects do not make any revenue and spend their initial capital in their execution phase. It is unknown when and by whom the term was introduced to Project Management.

How to Use the Burn Rate

As mentioned earlier, the burn rate is an indicator of the project performance with respect to the budget. A burn rate greater than 1 means that the project budget is exhausted faster than originally planned, which indicates that the project may be finished over-budget. A burn rate less than 1 means that the project budget is exhausted slower than originally planned, which indicates that the project may be finished under budget. A burn rate equals to 1 means that the project is exhausting the budget exactly as originally planned, and indicates that the project may be finished on budget. Note that the latter case is not uncommon at the beginning of the project, but is not maintainable through the rest of the project, as it is nearly impossible to capture a project budget with a 100% accuracy at the beginning of any project.

The burn rate is an excellent “early alarm” that the project may be over-budget. A burn rate bigger than 1 should be immediately reported to the stakeholders. Since the burn rate seldom goes down, it is extremely unwise to “hope for the better” and not to report this metric to the stakeholders.

How to Calculate the Burn Rate

The calculation of the burn rate is quite simple and straightforward. Here’s the formula:

Burn Rate = 1/CPI

Where CPI is the Cost Performance Index which is calculated the following way (from here):

CPI = EV / AC

Looking at the above formula of calculating CPI, a more direct formula for the burn rate would be:

Burn Rate = 1/CPI = 1/EV/AC = AC/EV

Where AC is the Actual Cost, and EV is the Earned Value.

Example of Calculating the Burn Rate

Assuming the Earned Value of a construction project so far is $3,000,000, and the Actual Cost is $3,500,000. Then:

Burn Rate = AC/EV = $3,500,000/$3,000,000 = 1.16

Since the burn rate is above 1, then the project is spending the budget faster than it should, and may finish over budget.

Comments (0)

What Is the Difference Between Project-driven And Non-project-driven Organizations?

Filed in Organizational Structures, March 23, 2010, 2:06 am , , , ,

There are several differences between project-driven and non-project-driven organizations, including:

  • 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).

Comments (0)

What Is the Difference Between Task and Activity in Project Management?

Filed in Project Scheduling, March 19, 2010, 10:52 pm , , , ,

From a Project Management perspective, a better title for this article would be: is there a difference between tasks and activities?. This is because Project Managers are divided on the subject: some say that a task is exactly the same thing as an activity, others say that a task is a work package that may include one or more activities, and finally, to make things more confusing, another group of Project Managers believes that the previous statement is only true when inverted: an activity is a work package that may include one ore more tasks. So who is right?

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.

Comments (0)

What Is the Difference Between Estimated Cost at Completion (EAC) and Actual Cost (AC)?

Filed in Project Cost Management, , 7:54 pm , , , ,

The main difference between the Estimated Cost at Completion (EAC) and the Actual Cost (AC) is that the former is a prediction of what the cost would be for accomplishing a certain objective (usually a project), while the latter is the costs that were incurred so far towards the completion of the objective. Both the EAC and the AC are used in earned value formulas.

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.

Comments (0)

What Is the Demand for Project Coordinators?

Filed in Other Project Management Topics, March 18, 2010, 10:21 am , , , ,

Since a Project Coordinator (also known as Project Management Coordinator) is one step away from becoming a Project Manager, some employees seeking a future career in Project Management want to know what is the demand for Project Coordinators.

In order to answer this question, we first need to examine the role of the Project Coordinator and its relationship to the current demand in Project Management.

What Is the Role of the Project Coordinator?

The main role of the Project Coordinator is simply alleviating some of the load off the Project Manager’s shoulder. The Project Manager usually gives the Project Coordinator some routine or simple tasks that he (the Project Manager) doesn’t have the time to do himself. One of the basic responsibilities of the Project Coordinator is to “coordinate” (hence the title “Project Coordinator”) tasks between the resources. The Project Coordinator also monitors the progress of different tasks at a lower level, and reports the progress to the Project Manager. In some cases, the Project Coordinator might be doing most of the Project Manager’s work (especially resource management and conflict management at the resource level), reducing the workload of the latter to simply verifying and forwarding the different reports (usually to upper management) received by the Project Coordinator. In this case, the Project Coordinator can be considered as a ghost Project Manager, where the former does all the work, but the latter gets all the credit. Nevertheless, the Project Management experience the Project Coordinator gets is priceless.

Do All Companies Have Openings for Project Coordinators?

Usually no. However, this is changing fast, as Project Managers are desperate for delegating routine tasks. Many Project Managers currently delegate such tasks to someone from the project team, which may have a negative effect on that team member’s productivity. This usually convinces Project Managers (who in turn convince HR) that they need dedicated Project Coordinators.

What Is the Current Demand for Project Managers?

For obvious reasons, the demand for Project Coordinators is directly related to that of the Project Managers, since you can’t have Project Coordinators without Project Managers (but not vice versa).

To answer the question, the demand for Project Managers (especially those with a PMP certification) is huge and increasing, and this increase can be described as exponential. Additionally, all the signs are pointing that the increase in demand for Project Managers is sustainable on the long run. This is due to several factors, including:

  • The change of culture in companies across the world, where traditional, functional environments are being replaced en masse by projectized environments
  • The adoption and appreciation of Project Management across different government bodies all over the world
  • The ever increasing number of projects worldwide, especially in developing countries

A prominent Project Management jobs website lists around 500,000 active jobs for Project Managers, and about 50,000 jobs for Project Coordinators. By looking at these numbers, we can roughly deduce that the demand for Project Coordinators is roughly 10% of that of the Project Managers. That percentage is increasing steadily, since as we stated above, Project Managers are realizing that they need Project Coordinators.

What Is the Average Salary for Project Coordinators?

Since people reading this article might also be interested at the Project Coordinator’s salary, here are some numbers:

  • The average salary of a Project Coordinator in the US is around $45,000, while that of the Project Manager is around $60,000.
  • The average salary of the Project Coordinator is around 75% of that of the Project Manager.
  • Salaries for Project Coordinators start at $30,000, while those for Project Managers start at $40,000 (both numbers are in the US).

Conclusion

The demand of Project Coordinators is increasing by the day, and this trend will continue, as the demand for Project Coordinators is directly related to that of Project Managers, which shows no sign of slowing, even during tough times.

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