What Are the Advantages and Disadvantages of Microsoft Project?

Microsoft Project is still one of the most used Project Management software (tool) out there. Project Managers, when evaluating Project Management tools, often wonder what are the advantages and disadvantages of using Microsoft Project.

Advantages of Using Microsoft Project

  • Maturity: Microsoft Project is a very mature Project Management tool. MS Project was first released in 1984 and over the next 26 years, Microsoft has listened to the increasing number of Project Managers adopting this tool, and added/enhanced a lot of features that are now vital for managing projects. Almost any chart the Project Manager can think of is now available in MS Project. (At the time of writing this article, the current version is MS Project 2007).
  • Support and Reliability: Contrary to the myriad of the other Project Management tools available on the market, Microsoft Project is developed by the largest and most reputable software company in the world, which offers reliable support of this product. Additionally, the success of MS Project has spurred the growth of third party support and training services offered for this product.
  • Easy Integration with other Microsoft Products: MS Project offers integration with other MS Products that are highly popular, such as MS Word, MS Excel, and MS Outlook.
  • Desktop Application: MS Project is a desktop application, which means the Project Manager can work on the project schedule even if there is no Internet connection.

Disadvantages of Microsoft Project

  • Steep Learning Curve: MS Project is a software that needs some considerable training and experience to get know how to use it. This is a significant setback for the product as there are lots of Project Managers out there who are not technical, and may experience a hard time trying to learn MS Project.
  • Generic Focus: MS Project does not focus on any particular industry (though some say it’s slightly more inclined to Software Project Management), this results in Project Managers using a tool that is not tailored to their needs.
  • No collaboration: This is a major drawback in MS Project because of the importance of communication in Project Management. Online collaboration nowadays is indispensable for easy and accessible updates by the team members/the Project Manager/the stakeholders on the project. The complete absence of real collaboration in MS Project makes it outdated by the standards of today’s connected world. To make things worse, MS Project does not even offer integration with third party collaboration tools, which leaves Project Managers with no choice then to use a separate collaboration platform to ease the communication flow on the project. This adds an unecessary overhead to the workload of the Project Manager.
  • Desktop, Offline Application: Although this one was mentioned as an advantage, it is also a huge disadvantage. Using a desktop application means that the project data file (usually the one with the .mpp extension) is stored locally. This leaves the ever-busy Project Manager with the responsibility of backing up this file always (not doing so may risk losing all the project plan in the blink of an eye in case the Project Manager’s PC fails). Additionally, quite often multiple people (e.g. the Project Manager, some team members, and some stakeholders) will have different copies of the MS Project file which are not in sync, leading to inconsistency issues (MS Excel has also the same issue when used as a Project Management tool). The Project Manager will be forced to email the project file to everyone involved every time a change is made.
  • Compatibility Issues: MS Project files are saved in a proprietary format, meaning they won’t run on any other PC unless that PC has also (usually the same or a later version of) MS Project installed. This makes the life of the Project Manager harder as he has to make sure that everyone (including the stakeholders, the client, and the team members) receiving a copy of the .mpp has to have MS Project installed on his PC. An alternative way is to send the Project Plan as an image or a pdf file, but of course, both of these options are not as good as sending the real project plan.


MS Project is a mature, respected, and robust Project Management software, but the steep learning curve and the complete lack of collaboration may hinder future adoption of MS Project. It Microsoft doesn’t acknowledge the importance of implementing easy collaboration in this tool as well as addressing the other problems mentioned above, then MS Project may become obsolete in a few years.

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

Is It Easy for a Project Manager to Manage a Project Overseas?

Now that we’ve explained how to negotiate a Project Management job overseas, the immediate question would be: is it easy for a Project Manager to manage a project overseas with his experience? Or is the Project Manager’s experience transferable to other countries?

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.

How to Negotiate a Project Management Package Overseas?

Project Management jobs are available all over the world, and are currently abundant and lucrative in emerging economies. So how can a Project Manager get and negotiate a package overseas?

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.

Should I Add PMP As a Title in My Business Card?

Newly PMP certified Project Managers wonder whether they should append “PMP” as a title in their business card or not.

In order to determine the right answer to this question, we need to examine three things: titles, business cards, and the history of the PMP accreditation.


Titles are suffixes or prefixes appended to the name of the person originally used to highlight a certain career position (for example “MD”), a level of education (“Ph.D.”, “MBA”), a rank in the government (“MP”), etc…. Recently, titles have been used to highlight prominent accreditations issued by either commercial or self-proclaimed not-for-profit organizations, such as “MCSC” (issued by Microsoft) or “CCNA” (issued by Cisco).

Business Cards

Business cards are essentially given to one’s acquaintances to promote himself or his business. Business cards usually include the career position and/or the level of education. However, since business cards are all about promotion, then adding any title (including a prominent accreditation title) promoting the person is considered acceptable.

History of the PMP Accreditation

The PMP accreditation was initiated in 1984 by PMI which is, as of 2010, a 40 year old (self-proclaimed) not-for-profit organization, aiming at enhancing the status of Project Management worldwide, and promoting it as a profession, while at the same time, defining Project Management standards. The PMP accreditation was launched as a response to the increasing number of projects worldwide, to give companies the ability to test the knowledge of their Project Managers, in order to make sure that these Project Managers are fully capable of managing projects efficiently.

The mid 90’s was a turning point for the PMP certification, namely because:

  • Its reputation and popularity increased dramatically.
  • Companies started seeking PMP certified Project Managers to fill in Project Management jobs.
  • Companies started paying higher salaries for PMP certified Project Managers.

The above reasons created a rush (that still exists) to get become PMP certified. Project Managers (and sometimes persons with no Project Management experience) started seeking this certification on an individual basis in order to increase their salary and their job prospects.

Ever since, the demand for the PMP certification has skyrocketed, and it’s fast becoming a requirement for Project Managers (with the exception of countries where the PRINCE2 certification is much more prominent), and no longer a “nice-to-have” certification.

It is worthy to note that in the whole history of the accreditation (and so far), it was never easy to become PMP certified, even if the applicant is an experienced Project Manager. The current PMP pass rate is 80% (according to the PMI) and almost every applicant studies hard for the PMP test. This means that not just everyone can get this certification. Worldwide, the current number of PMP certified people is around 360,000.

Is It Appropriate to Add PMP to the Project Manager’s Business Card?

By examining the history of the PMP accreditation, one can easily determine that is has the following 2 characteristics:

  • It has now become a prominent and a reputable accreditation.
  • It definitely adds value to the Project Manager.

Since PMP is now a prominent accreditation, it has now a “title status”, and since it adds value to the Project Managers, it is a good promotion to the individual and can definitely be added to the business card of the Project Manager.

Quick Note: Some Project Managers append “PMP” to their name while posting in various Project Management forums and commenting on Project Management posts/articles. While, as we stated, PMP is considered a title, your are discouraged to mention it extensively in front of other Project Managers that may very well be much more experienced than you (and often not holding any kind of Project Management accreditation). Doing so might be considered “boasting”.

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

What Is Gold-Plating in Project Management?

Gold-Plating in Project Management is the act of giving the customer more than what he originally asked for. Gold plating is common in software projects, and is usually done by team members either on an individual or a collaborative basis, most of the times without the knowledge of the Project Manager.

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.

What Is the Difference Between Construction Project Management and Software Project Management?

Although Project Management is essentially the same concept across the board, it must be fluid enough to accommodate all industries, resulting in quite a few differences in its application from one sector to the other. Here are the differences between Construction Project Management and Software Project Management:

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

Why Is Project Management 90% Communication?

One of the first things an aspiring Project Manager will hear from a Project Management mentor or in a Project Management class is that Project Management is 90% communication. The immediate (and often unasked) question is Why?.

In order to analyze the claim, first let’s consider the very main responsibilities of the Project Manager:

  • Initiating the project
  • Developing the project plan
  • Managing the project communication
  • Managing the project resources
  • Managing the project stakeholders
  • Managing the project risks
  • Managing the project conflicts
  • Updating people on the status of the project
  • Closing the project

Of course the list above is not comprehensive, but it lists the most important tasks taking almost all of the Project Manager’s time. Now let’s examine each of the above responsibilities individually:

Initiating the project

When initiating the project, the stakeholders have to communicate with the designated Project Manager all the information they currently have on the Project. Additionally, the Project Manager has to meet extensively with the stakeholders to develop the SOW (Statement Of Work).

Developing the project plan

Project Managers do not develop plans from thin air; the project plan is developed based on the input of the team members and the internal/external stakeholders. Developing the Project Plan is essentially gathering all this input and formulating it into one document that will govern the management of the project until its closure.

Managing the project communication

The Project Manager manages the communication at the project level by defining the RACI matrix, defining formal communication in the project, setting intervals for status updates, and calling for meetings when necessary.

Managing the project resources

Managing the project resources is essentially monitoring the resources’ progress, see if they’re facing obstacles, train them if necessary. Naturally, the Project Manager has to communicate with the project resources in order to get the necessary input to assess their performance and see that everything’s on track.

Managing the project stakeholders

The main thing about managing stakeholders is to keep them satisfied and supportive of the project, while reducing, as much as possible, their negative effects on the project (which may result from hidden agendas). In order to do that, the Project Manager has to keep a constant stream of communication between him and the project stakeholders. The Project Manager also needs to report the status of the project constantly to the stakeholders, as well as major obstacles and issues. Additionally, the Project Manager needs to receive feedback from the stakeholders, and formulate this feedback into the project, whether it’s about change requests, cutting funds, etc…

Managing the project risks

Risks nearly always arise in any project. Be it a new government regulation, a union strike, a delayed shipment, a couple of resources quitting, etc…, risks can have detrimental effects on any project. The Project Manager becomes aware of these risks through his communication with the stakeholders and/or the team members. Once aware of the risk, the Project Manager will then have to assess and reduce the impact of these risks, and then report back to the stakeholders on about the risks and how they were handled.

Managing the project conflicts

Inter-team conflicts are common in any project. The Project Manager has to acknowledge those conflicts, and manage them properly through constructive communication with the involved team members. If a team member is consistently hindering the project in one way or the other, then the Project Manager needs to remove him off the project after communicating the issue to the resource’s direct manager.

Updating people on the status of the project

The current status of the project has to be communicated constantly to the team members and the stakeholders. Status updates may be done at regular intervals, or when the needs arise (such as a major risk or a conflict). Status updates may be communicated in an email or during a meeting. In case of a Project Management 2.0 environment, stakeholders can check status updates by themselves (without the need of the Project Manager to send this information).

Closing the project

When closing the project, the Project Manager has to verify the scope by making sure that the project satisfies the needs of the customer (this is usually done by getting feedback from the customer using a questionnaire), he will then have to communicate the release of the team members to their respective managers to ensure their availability for the next projects. The Project Manager will then have to gather the lessons learned essentially by collecting feedback from the project team members as well as stakeholders. Finally the Project Manager has to create a final report assessing the project and then communicate that report to the stakeholders.

When examining the above responsibilities of the Project Manager, we can clearly determine that almost everything the Project Manager does has to do with communication, and when he’s not communicating, he’s formulating some gathered information into documents to be later communicated. Hence, it is safe to say that Project Management is indeed 90% communication, the other 10% are spent preparing for communication.

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

What Is Project Management 2.0?

A lot of Project Managers hear about it, but not a lot know what it is about. So what is Project Management 2.0?

Project Management 2.0 – sometimes referred to as Social Project Management – is a term that was coined in 2006 (maybe earlier, there is no exact date, but that’s when the term started emerging) by an unknown Project Manager. The term highlights the influence of the new social media (built on the so-called Web 2.0 technology, this is how we probably ended up with the name Project Management 2.0) on Project Management. The term has currently no standard definition, there are literally dozens of views and articles written about Project Management 2.0, all of them are subjective and reflect the author’s own view on the term.

Having said that, most of the people who have written or spoken about the subject agree on one thing: Collaboration is at the heart of Project Management 2.0. Such collaboration is made possible using the (paid or free) online collaboration tools.

What Project Management 2.0 Is and Is Not

It is important to note that Project Management 2.0 is not a framework, is not a methodology, is not “the next big thing” in Project Management (as falsely hyped by so many companies building online tools), and does not make a Project Manager a better Project Manager. Project Management 2.0 is simply a style of work, for example, instead of using emails to update the stakeholders on the project status, stakeholders can login to the collaboration tool online and see the actual progress themselves. Another example is instead of a resource sending an email to the Project Manager about a challenge/issue in a certain task, he can simply update him (and the involved team members) via the web tool. When seeing this update by their workmate, other team members may be also interested in replying, or giving advices on the task, etc…

Advantages of Project Management 2.0

There are several advantages to Project Management 2.0, including:

  • Efficient and simplified communication between the Project Manager and the team members (and amongst team members as well). This is the most important point, as Project Management is 90% communication.
  • Immediate and up-to-date reporting on the status of the project available to all stakeholders.
  • Reducing the redundant and routine work of the Project Manager (e.g. compiling the reports, remembering to followup on emails sent to team members and or stakeholders, etc…)
  • Ability to accurately assess the real output of the team members.
  • Seamless creation of a knowledge-base that may be used for the current project and for next projects.
  • No more little issues falling through the crack anymore.

Disadvantages of Project Management 2.0

Project Management 2.0, in its current incarnation, has several disadvantages including (note that the disadvantages below can also be viewed as concerns):

  • Unless the organization hosts its own collaboration tool, privacy and security are an issue. The organization will be storing some potentially classified information on a 3rd party server, which may be in a far away continent. Although almost all companies claim that privacy and security are there utmost concerns, one has to be careful.
  • Reliability and availability are very important. The data has to be backed up constantly (on another server), and the server has to have a very high availability (nearing 100%). Compromising these 2 factors might result in a total data loss (of potentially all the company’s projects) that is unrecoverable or simply the inability to do any work (as the Project Manager will not be able to update the team members about their tasks and vice versa).
  • Misleading marketing techniques devised by companies building collaboration tools hyping the concept as the future of Project Management, while these tools are merely about organizing and streamlining communication. Project Managers, betrayed by this false promise, may blame the “tools” for the failure of their project.

Adoption of Project Management 2.0

Small companies are the largest adopters of Project Management 2.0. As companies grow larger, they become hesitant (politics, maturity, etc…) to adopt new technologies at the organizational level to manage their projects’ communication. Still, even in this case, some Project Managers may elect to individually adopt Project Management 2.0 and consequently, make their team adopt it as well.

Internet companies are by far the largest adopters of Project Management 2.0, followed by software companies. The reason for this large adoption in these 2 sectors is the highly Internet skilled personnel as well as the relatively young age of these companies.

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

What Is the Difference Between Good Project Managers and Bad Project Managers?

Project Managers only come in 2 flavors: either good or bad. So how can someone differentiate between Good and Bad Project Managers?

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

What Is a Hidden Agenda in Project Management?

Generally, a hidden agenda is a secret plan (or thought) serving an individual (or a group of individuals) own interests, regardless of the (usually negative) outcome that might affect others. A hidden agenda usually dictate one’s decisions and actions.

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.