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.

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.

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.

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.

Since Project Management is a set of (somehow) standardized best practices to manage a project, then the short answer should be “yes”: a Project Manager with an experience anywhere can work anywhere else. Nevertheless, there are a few factors that will highly influence the survivability of the Project Manager overseas.

Cultural Differences

Cultural differences should be taken into consideration by the Project Manager. Cultural differences affecting the project are many, including:

• In North America, the vacation days (per year) vary between 10 and 15 days, and resources have to secure the approval of management (which may or may not happen) before taking any vacation. Additionally, most employees do not take all these days at once (normally they take only 5 working days in a row). Project Managers usually are very careful when approving overlapping vacations by two or more resources and they are able to disapprove vacations that may hinder the progress of the project. In Europe, on the other hand, employees are entitled to a month every year. Employees just inform management of their vacation date (they seldom ask for approval, as it’s taken for granted) and length. Not only that, most employees take a whole month in one shot, and they don’t care if the project is struggling and/or other employees are taking their vacation that very same month (which is often the case. For example, most people in Europe take their vacation in August, just before their kids start school, as spending time with the kids is quite important in Europe). This practice of course can stagnate the whole project (especially when multiple resources take the vacation at the same time), and the Project Manager can do nothing about it, even when the project is desperate for resources. The best thing the Project Manager can do is to always account for the “long vacation” factor in the project plan.
• In developed countries, leniency and fault-tolerance is expected and appreciated by the resources, and viewed as a management best practice. In developing countries where firmness is the norm, adopting those same principles may be perceived as a weakness. This of course can make it hard for the Project Manager to enforce his authority over the resources.
• In developed countries, micromanagement (for most resources) is a big no-no. In fact resources in these countries resent this practice (some find it even insulting), and can be easily demotivated, ultimately reducing their work output. On the other hand, micromanagement in developing countries is, in most cases, a must. Resources will feel lost and become frustrated if they don’t constantly feel that someone is watching over them and guiding them even when it comes to the smallest of tasks.
• Gold plating as well as huge padding when estimating tasks (as opposed to the over-optimistim when it comes to task estimation in developed countries), are practices that are usually adopted by project team members in developing countries. Some team members are even unable to give any estimate for their tasks. The Project Manager is expected to do the job of the team members and estimate the tasks himself (hence it is important for the Project Manager to have a technical background when managing projects overseas).
• Last but not least, office politics can be a completely different play overseas, and this is where most Project Managers fail. Office politics is usually much tougher than at home, and this is caused by 2 things:
  1. Most people working overseas are materialistic people that are there just for the money (and sometimes lots of money), so they wouldn’t mind stepping on other people to reach what they want (this is especially true in a company where management consists of expatriates).
  2. In developing countries, country politics may have a direct effect on the inner politics of the company. For example, there might very well be some senior executives advocating for a certain politician, party, etc… In some countries, religion and ethnicity also comes into play in office politics.

  Navigating office politics in a foreign country can be hazardous, and, if not done right, may lead to either the firing or the resignation of the Project Manager. Studying the company and the country very well, understanding who’s who, and who belongs to who, can really help in this case.

Language Difference

A different language can be a huge obstacle when managing projects overseas. It may lead to the following undesirable outcomes:

• Miscommunication: Assume the Project Manager is talking in English to resources whose first language is not English. The Project Manager may say something that will be interpreted differently or misunderstood by the resources, who are then shy to admit that they didn’t understand what the Project Manager really wanted. It is the duty of the Project Manager to make sure that what he’s communicating to his project team is crystal clear, usually by asking the resources to repeat for him what he already asked them to do (this is the most basic yet most efficient method).
• Conflicts: Language misunderstandings that are left unresolved may easily grow into conflicts. It is very important for the Project Manager to immediately address any misunderstanding (resulting from the language difference) in order to avoid unnecessary conflicts. However, sometimes it is very hard to know if a conflict is festering due to something the Project Manager unintentionally said. This is because some resources do not immediately express that they were offended by something, instead adopting a passive-aggressive behavior.

Procurement Challenges

In developed countries, procurement is probably the easiest part of managing a project, especially when the company has contracted a vendor to procure all the necessary equipment/material. In developing countries, procurement can be a problem, as sometimes it becomes very hard to locate some basic equipment, even after contacting many vendors. In order to solve this problem, the Project Manager has 2 options:

1. Contact the most prominent vendor in the country, and ask that vendor to import goods on the company’s behalf.
2. Completely take the local vendor out of the equation and import the goods directly.

Both options have pros and cons, and the second option may be better especially if the company is large enough to handle the procurement by itself. Supporting and maintaining the imported goods is a problem in either case. Unfortunately, there is no silver bullet for procurement overseas.

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

Why Work Overseas?

In this day and age, Project Management jobs paying 6 figure salaries (and often tax-free) can be easily found overseas, in emerging economies. Some “unfortunate at home” Project Managers are able to easily find a good Project Management job on the Internet in a very distant country. These jobs tend to be attractive and a much better option compared to what the Project Manager has (or does not have) at home.

How to Get a Project Management Job Overseas?

This is the easiest part in case the Project Manager has the necessary experience. Simply searching and applying for a job on some of the better Project Management job websites can do the trick. If the qualifications of the Project Manager meet the requirements of the job, then one of the following may happen:

• The Project Manager will be flown overseas for a job interview.
• The Project Manager will have a job interview locally before assuming his role overseas.

As with all the other job interviews, if the Project Manager does well, then the company will offer him a job, and he’s now prepared to negotiate his contract.

How to Negotiate a Job Contract that Is Overseas?

Negotiating a contract overseas differs greatly from negotiating a contract at home, as the perks and the salary ranges are completely different (usually much higher). There are 3 factors that play a huge role in this negotiation (and listed in the order of importance):

1. The country where the Project Manager is relocating to.
2. The nationality of the Project Manager (in other words, the nationality of his passport, and not his country of origin). Note that this point is of the highest importance in some countries (where the Project Manager can get 3 times as much money because of his passport), but can be irrelevant in other countries.
3. The position to be assumed by the Project Manager, as well as the industry he’ll be working in.

Researching the country the Project Manager is going to (as a rule, the riskier the country the higher the salary), studying the status of the citizens of his country in that country (is it favorable or not), as well as the salary range for a person with his position (taking into consideration the industry) are the starting point to a smart negotiation about the salary. Additionally, working overseas often comes with the following perks that should be negotiated, such as (listed in order of importance):

1. Free return business class tickets for the Project Manager, his wife, and his children. Some companies even offer 2 return business fare tickets for the whole family per year.
2. Free housing
3. Free schooling for the Project Manager’s children
4. Free international insurance
5. Free company car (gas is paid by the company)
6. Free phone lines (landline and mobile)
7. etc…

The first item on the list above is a given as the Project Manager has to travel home at least once a year, with his whole family. The second and the third items on the list are the most important (the rest of the list is trivial) as they may cost a substantial amount of money (housing can easily cost more than $30,000/year and good schooling may cost up to $17,000/year/child). It is essential that the Project Manager negotiates these 2 items into the package as perks (e.g. the company handles the housing and schooling directly), and not accept to have a monetary compensation instead. Going with the latter option will expose the Project Manager to the following risks:

• Inability to find decent housing/schooling within the budget set by the company, which may force the Project Manager to tap into his base salary to offset the difference.
• Even if the company is giving more than enough money to cover those expenses, the Project Manager might have logistical problems to get adequate housing and schooling.

In short, the best thing a Project Manager can do is to negotiate a contract where the basic salary is independent from the perks, and all the perks are paid directly by the company to the respective service owner (such as the company paying the rent directly to the landlord). Additionally, usually companies (thanks to their operational experience within the country) pick decent areas for housing, as well as reputable schools for the children.

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

Why Gold Plate?

Gold plating is giving the customer something that he did not ask for, something that wasn’t scoped, and often something that the he may not want. So why do it?

There are several reasons for gold plating:

1. Some team members thinking that a certain functionality would be “cool” to have in the end product, and so they add it.
2. Some team members falsely determining that a certain functionality is a pre-requisite to another one (but is absent in the scope), or a necessity in the end product. Note that in some cases, this might be true, but the process is wrong. Team members should follow formal procedures by reporting this to the Project Manager, who makes the ultimate decision (after consulting with key stakeholders, in the case of a big functionality).
3. Team members wanting to prove their abilities to the Project Manager and/or their direct managers.
4. Team members with a lot of slack trying fill in their time by adding “bells and whistles” to the end product.
5. The Project Manager wanting to shine in front of the customer (there might be a hidden agenda behind this, such as the Project Manager is seeking to be ultimately employed for the customer).
6. The Project Manager and/or the team members wanting to divert attention from (sometimes serious) defects in the final product.

By examining the above reasons, we notice that gold plating is mostly done with good intentions, but then again, even the road to hell is paved with good intentions. Note that the first 4 reasons above imply that the Project Manager is not properly managing and controlling his resources.

Consequences of Gold Plating

There are many potential (mostly negative) consequences of gold plating, including:

• Increasing the cost of the project. Gold plating takes precious time, and is usually done by top resources. Of course, the customer will not be paying for those extra hours.
• Scope Inflation. Sometimes gold plating may result in changing some of the underlying infrastructure that was originally defined and agreed upon just to accommodate the features that the client did not ask for. Again, such changes are usually done by top resources.
• Increasing risks. On average there are 20 errors for every 1000 lines of codes. Gold plating is mostly about adding code, and consequently, bugs.
• Raising the expectations of the over-satisfied customer. Customers with a gold plated product will grow accustomed to getting more than what they originally bargained for, for free. The next time the same company delivers a project to this customer, there’d better be gold plating…
• Customer backlash. As stated above, gold plating is giving the customer something that he may not want. Sometimes the customer will be ungrateful (as viewed from the team’s perspective) and will request to remove all the bells and the whistles that were added without his approval. This will cost the company time and money.

Who Benefits from Gold Plating?

On the short run, (almost) everybody. On the long run, nobody. On the short run (and ideally), team members will shine in front of their managers (while doing something they like), the Project Manager and the company will have a satisfied customer, and the customer will be getting more than what he paid for. On the long run, team members will be stressed to add extra (unpaid) features (no longer fun), the Project Manager will not be able to manage the customer’s expectations properly, the project will cost the company more time and money, and the customer will certainly be not as happy as the first time.

How to Avoid Gold Plating?

Avoiding gold plating is easier than what some might think, all the Project Manager has to do is to enforce a policy not to add any functionality (no matter how small or big it is) that is outside the original scope of the project without consulting with him first (and then formalizing the request). The Project Manager should be firm and he should punish gold-platers instead of rewarding them. Setting a harsh example with one of the team members might be a bit overkill, but will deter other team members from doing the same. Finally, the Project Manager should never give his team members complete autonomy, while not falling into the trap of micro-management.

Of course, if the Project Manager is the person who’s behind the gold plating, then all of the recommendations above are practically worthless. In this case, the stakeholders should interfere if this practice is jeopardizing the project.

© 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.

Hidden agendas in Project Management are common among stakeholders, and they have negative effects including:

• Hindering the progress of the project: Hidden agendas are not there to serve the project, they are there to serve narrow and selfish interests. Many times hidden agendas conflict with parts or the whole project, ensuing delays, cost overruns, etc…
• Lowering team morale: Project Managers usually get frustrated by unjustified decisions made by stakeholders with hidden agendas, this frustration is passed to the team, whose morale diminishes. The team will be demotivated, confused, and its productivity will decrease.

Why do we have hidden agendas?

The main reason why stakeholders adopt hidden agendas in Project Management is selfish interests. A stakeholder might go as far as secretly working towards the failure of a project to serve his own interests (A failed project, for example, would result in the allocation of future funds to one of that stakeholder’s own projects). Stakeholders more likely to have hidden agendas are those who hold executive positions in multiple companies and/or those who are corrupt (e.g. taking bribes from external organizations to either force or block a decision). Projects more likely to suffer from hidden agendas are public projects because of the sheer amount of government and company politics involved. Projects with lots of stakeholders (where each stakeholder is serving on multiple projects) are exposed to this problem as well.

Examples of hidden agendas

• A stakeholder refusing to go on board for a release of funds for an urgent project. Hidden Agenda: Maybe the stakeholder is aware of the limited cash flow in the organization and does not want to affect his own “pet” project?
• A stakeholder pushing very hard to finish a public project (even with a reduced scope and quality) before the elections. Hidden Agenda: Maybe the stakeholder is supporting a politician who’s taking credit for this project?
• A stakeholder fiercely vouching for a specific vendor although prices from other vendors are much cheaper. The stakeholder cites “reliability” as a basis for his decision while the quality is almost the same. Hidden Agenda: Maybe the stakeholder has an under-the-table deal with the vendor?)

How Can a Project Manager Detect a Hidden Agenda?

There are a couple of clear signs of hidden agendas:

• “Because I think it’s best for the company not to do it” (or vice versa): A stakeholder opposing (or supporting) a project or a project functionality cannot clearly and objectively justify his decision.
• Never-ending delaying of feedback/decision: A stakeholder does not get back to the Project Manager on a key issue that requires a decision or feedback, even after being approached several times by the Project Manager.

How to deal with hidden agendas?

As stated in the previous section, hidden agendas are not that hard to uncover, on the other hand, they are very hard to address. The problem is that the people with hidden agendas causing a lot of harm to the project are usually key stakeholders from upper management. The Project Manager does not have any authority over them nor can he simply accuse them of having “hidden agendas” without suffering very negative consequences at the career level. The best thing a Project Manager can do is to accept hidden agendas as part of his project, and hoping he doesn’t end up being the scapegoat of a failed project. The worst thing a Project Manager can do is “joining the dance”, e.g. adopting a stakeholder’s hidden agenda himself, this will never work as the Project Manager will soon find himself facing major conflicts with other stakeholders, not to mention that any hidden agenda can change at any time, leaving the Project Manager vulnerable after adopting an agenda that nobody is supporting anymore.

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