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

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.

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.

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.

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.

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

The Project Champion is someone who:

• advocates for the project by constantly praising its benefits (strategic advantage, ROI, etc…) to the stakeholders,
• is a fierce supporter of the project,
• and provides (often moral) support for both the Project Manager and the Project Team by liaising with upper management to address their worries and/or obstacles in the project.

In short, the Project Champion is an informal role whose main goal is to make the project succeed by addressing different obstacles while making sure that the stakeholders are always satisfied with the project.

What the Project Champion Should Not Do

As stated earlier, the Project Champion is not the Project Sponsor (although sometimes the Project Sponsor can play a dual role), and not the Project Manager, for that matter. Hence the Project Champion is not responsible for any reporting or monitoring of the project. The Project Champion’s involvement in the project (other than moral support) is solely limited to receiving (note the word receiving, the Project Manager provides the Project Champion with feedback, it is not the responsibility of the Project Champion to ask for feedback) feedback from the Project Manager about the problems that the project and/or the project team is facing, and escalating the feedback to the stakeholders along with suggested solutions to ensure a smooth project.

Who Should be the Project Champion?

Anyone from middle or upper management is eligible to become the Project Champion, provided he has the following traits:

• Strong communication skills: Since the role of the Project Champion is communicating with the Project Manager and the stakeholders, he must be an excellent communicator.
• Admiration of the organization: The Project Champion should be someone admired and respected by the organization, someone with charisma, someone that others blindly trust, and someone whose suggestions are always taken into consideration.
• Expertise in company politics: It is a fact that most stakeholders don’t want to come up themselves with solutions to the project’s problems (they simply don’t have the time), instead, they want others to suggest solutions to choose from. Stakeholders usually select the solution that is in harmony (does not conflict) with their own agenda. The Project Champion’s role is to propose solutions taking into consideration every stakeholder’s individual agenda, e.g. the company’s overall politics.

Perhaps the perfect Project Champion is someone from upper management, with the above traits and some solid Project Management experience. It is important that in this case, the Project Champion should be careful not to get tempted and assume some of the responsibilities of the Project Manager (such as stakeholder management).

Is a Separate Project Champion Role Necessary?

In general, the need for a separate role is proportional to both the size of the organization and the project, though there are some who believe that the Project Champion’s role ties well into that of the Project Sponsor, and hence it makes logical sense to have both roles assumed by the same person in every project and every organization. It is important to note that the advantage of having a dedicated Project Champion is that the project, the Project Manager, and the project team will have more support, and that the project will be less likely to fail. A good Project Champion can be the reason why a project succeeds.

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

Many Project Managers wonder if it’s possible to become a PMP without Project Management experience. The short answer is “No”, PMI is very clear in its requirements for the PMP credential: the Project Manager has to gather at least 4,500 hours of real Project Management Experience.

Unfortunately, PMI only audits a small percentage of PMP applications, which allows some unethical applicants to fake the required Project Management experience (and sometimes the education) in hope that they will not get audited. Deceptive techniques used to faking the Project Management Experience include (but of course, are not restricted to, as unethical people are usually creative in finding ways to trick the process):

• Claiming fake Project Management experience either as an employee or as a contractor from disreputable companies/organizations that went bankrupt, ceased to exist, or are owned by a friend or a family member.
• Inflating the experience acquired with the current company/organization, many times even informing management about this deceptive technique, so that management is able to confirm the validity of the applicant’s claim in case of an audit.

Sadly, because of the very small percentage of applications being audited, quite a few people are able to become PMPs by using the above (again deceptive) techniques.

This, of course, has some negative consequences, including:

• An influx of bad “Project Managers” in the job market: Most companies assume that being a PMP (because of the traditional respect for this certification) equates being a Project Manager. While this is true in most cases, it certainly is not for anyone unethically becoming a PMP.
• Diminishing prestige of the PMP accreditation: Those landing a Project Management job after unethically acquiring the PMP accreditation through faking their experience will send the wrong message to companies about the real value of the PMP because of their clear incompetency.
• Reduced salary for PMP certified Project Managers: The diminishing prestige of the PMP as well as the abundance of (bad) Project Managers will have a direct and negative effect on the PMP salary.
• Less respect for Project Management in general: The reduced quality of those working in Project Management will send the wrong message about the worthiness of Project Management as a profession and as a process to get projects done. This will hinder the evolvement of Project Management and will push companies to seek alternatives for managing their projects.

What PMI Should Do

For better or for worse, PMI has a huge say in the Project Management world, and as we can see from the negative consequences above, the somehow lax standards of auditing PMP applicants for their experience can affect the profession of Project Management as a whole.

Here are some thoughts on what PMI should do to avoid this:

• Drop the random PMP audit mentality: PMI claims that it randomly audits applicants for their experience. This, of course, results in efforts being spent in the wrong place. Many times, it is very obvious to differentiate between someone with real Project Management experience and someone with no experience at all. What’s the point of “randomly” auditing the former and not auditing the second? It is better that PMI adopts a more targeted approach as stated in the next point below.
• Adopt targeted auditing: Candidates documenting Project Management experience from unknown companies/organizations or those applying immediately after acquiring the minimum required Project Management experience to be eligible (for example exactly 4,500 hours) should have their application looked at with scrutiny.
• Increase the percentage of the audits: According to PMI, only a small percentage of PMP applications gets audited. Most probably this is done because PMI is understaffed. Perhaps PMI should consider hiring more resources to perform audits. By hiring more auditors, audits can then be more proactive, such as contacting involved companies/individuals to verify that the Project Management experience is definitely “real”.
• Enforce a lifetime ban for those faking the Project Management experience: Anyone claiming a fake Project Management experience is clearly not doing it with “good faith”. Those doing so should be banned for life from taking any PMI certification. Of course, some people make genuine mistakes in their application and should be excluded from this punishment.

PMI has to assume its responsibility of protecting Project Management and its future as a profession from fraudsters posing themselves as Project Managers. Otherwise, as stated earlier, companies will seek an alternative, and Project Management, as we know it right now, will perish.

Note: To its credit, PMI reserves the right to audit applications even after the certification is bestowed, but this is rarely (if ever) done.

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

Origin of the Term

Most students tend to leave their homeworks/exam studies until the very last possible date to get the job (somehow) done, hence the origin and the relevance of “Student Syndrome”. The term was first coined by Eliyahu M. Goldratt in his book, The Critical Chain.

What Causes the Student Syndrome?

There are many reasons that may result in a project infected with the Student Syndrome, such reasons include:

• Poor Project Management: A bad, disorganized, and unaccountable Project Manager who doesn’t constantly communicate with the project team is usually the main reason behind the Student Syndrome. The project team, when left unattended, may “slack” a lot, which results in a very slow progress. This will remain the case until the Project Manager decides to get feedback on the current status from the project team to show the progress to the stakeholders. This is when when suddenly everyone is in panic mode and every task has to be finished in a record time.
• Unclear Project Requirements: Requirements that are not clearly defined as well as a hazy “big picture” of the project may result in frustrated resources trying to avoid unclear/difficult tasks that they do not understand.
• Multiple Concurrent Projects: Having the project team working on multiple projects at the same time may lead in prioritizing one project over the other, where the latter will be in “stagnation mode” until the very last moment.
• Human Nature: Last but not certainly not least, it is important to mention that humans, by default, are lazy. Procrastination is an innate habit in any person, this is the reason why success is only reserved for a few who conquer this habit.

Disadvantages of the Student Syndrome

Almost any project suffers occasionally from the Student Syndrome whether at the resource level, at the Project Manager level, and at the stakeholders level. This is normal. However, when the Student Syndmore is part of the overall project’s and/or the organization’s culture, there will be many disadvantages for the project, such as:

• Reduced quality: Since all the work is concentrated in a shorter period of time, quality is expected to be negatively affected.
• Reduced scope: When trying to finish tasks fast with very little time and no buffer, the Project Manager will be forced to reduce the original scope for the task in order deliver on time. Again, this will affect quality.
• Stressed team: A stressed team is bad news for any Project Manager. A stressed team cannot be pushed further and increasing the work hours will reduce (instead of increase) the productivity.
• Risking the Project Schedule: The Student Syndrome is tolerable for a few, non critical tasks. But when the number of critical tasks affected increases, then whole schedule will be at risk.
• Loss of Stakeholders Confidence: Any product or an important task, that is even delivered fast and cheap, but with a largely reduced quality and scope without the stakeholders’ consent may jeopardize the reputation of the Project Manager, and will probably result in the loss of the stakeholders’ confidence.

In a worst case scenario, the Student Syndrome can cause a project to be killed (or indefinitely on-hold).

How to Avoid the Student Syndrome?

There is no way to completely suppress the Student Syndrome from any project, because, as stated above, it is an innate human habit. However, the Project Manager can keep it in check by:

• Constantly communicating with the project team about their tasks, and giving feedback.
• Constantly communicating with the stakeholders about the progress of the project, and requesting a feedback.
• Keeping the slackers in the team under the radar, raising up concerns when too much time has gone by with too little work achieved.
• Breaking down tasks into smaller, more manageable tasks in the project schedule. The time taken to detect the Student Syndrome is usually equal or less than the size of a task. If the affected task is allocated 3 months in the project schedule, then it might take up to 3 months to discover the problem, however, when the task is only allocated a week, then the maximum time it takes to detect the problem is a week. Note that very short tasks can make the schedule less manageable, and can create more overhead on the Project Manager.

Proactive (as opposed to reactive) project management is key to keeping the Student Syndrome in check, and to reducing its effect to a tolerable level. Perhaps the best thing to for any Project Manager is to start by himself by conquering his innate habit of procrastination.

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