A small claim on a résumé can create a large breach of trust.

By László J. Kremmer, MBA, CLC, CSM®, CSPO®, PMP® | Member, PMI Ethics Advisory Team (EAT)

“Could you verify your PMP® status before tomorrow’s interview?”

The recruiter expected a quick “Of course.” Instead, there was a long pause. Then came the reply: “I completed the training, and I plan to take the exam next month. I thought it was close enough.”

The names and details are changed, but the pattern comes from real ethics cases. A professional adds a credential to a résumé or social profile before earning it. In another version, an applicant pays a proxy to complete part of the certification process or creates a second account to bypass controls. The shortcut may look small. Its impact is not.

A professional credential is not a hopeful statement. It is a factual claim others rely on. A hiring manager may use it to shortlist candidates. A client may use it to decide who is trusted with a complex project. Another applicant, who invested the time and effort to earn the credential, may lose a fair opportunity.

The PMI Code of Ethics and Professional Conduct connects this issue to both responsibility and honesty. We accept work that matches our actual background, skills, and qualifications. We also avoid misleading statements and dishonest conduct intended for personal gain. When we attach “PMP®” to our name, we promise something earned and verifiable.

Sometimes the defence is, “Everyone improves their résumé a little.” Yet project decisions are built on information. One false line can distort a recruitment process, weaken confidence in certification, and expose an employer or client to avoidable risk. If the claim helps us gain access, influence, or money, it is not harmless decoration.

Leaders can make verification fair and routine. Check the credentials of every final candidate, not only those who “look suspicious.” A consistent process protects qualified professionals, reduces bias, and makes verification feel like normal governance rather than public humiliation.

Keep the promise.

• Use only credentials that have been formally awarded to you, and present their status accurately.
• Review your résumé, biography, email signature, and social profiles whenever your status changes.
• Never share identities, accounts, exam content, or application work with a proxy service.
• When you discover an error, correct it everywhere, promptly, and notify people who may have relied on it.

In one real-world pattern, an inaccurate credential claim was compounded by hostility when a recruiter asked for proof. That second choice mattered. A calm correction and sincere apology do not erase the first error, but they show responsibility. Defensiveness, threats, or more falsehoods turn a repairable mistake into a deeper breach of trust.

Before publishing any credential, ask three simple questions: Can I prove this today? Would an independent verifier understand the claim exactly as I intend? Am I creating an impression that I have not earned?

A credential takes effort to gain. Its value survives only when all of us protect what it means.

Over to you

1. Have you seen credential wording that was technically clever but ethically misleading?
2. What controls does your organisation use to verify professional credentials consistently?
3. How should a leader respond when someone corrects an honest mistake quickly?

By: Laszlo J. Kremmer MBA, CLC, CSM®, CSPO®, PMP® - Member of PMI Ethics Advisory Team

Several specific problems characterised the project.

1.One problem was weak continuity in key areas of support and decision-making. When an ERP implementation is still in its early stages, the need for subject matter expertise is especially high. Business processes are being clarified, requirements are still stabilising, and local operational realities need to be surfaced before they become design issues. When expertise becomes inconsistent or unavailable during that phase, the quality of decision-making suffers. People start making assumptions where confirmed knowledge is needed. Open questions remain unresolved because the right voices are absent. Over time, that weakens confidence in both the plan and the team.

2.A second problem was insufficient recognition of location-based complexity. Two locations may sound straightforward compared with a multinational rollout, but even two sites can introduce meaningful differences in process, culture, staffing, readiness, and operational constraints. If those local differences are not actively managed, the project can fall into the trap of assuming consistency where none exists. Ethical leadership requires paying attention to those differences because the consequences of a poor assumption are borne by the end users, not by the plan itself.

3.A third problem was the erosion of visible accountability once the project hit delays. When a project is healthy, roles often appear clear. When the project struggles, that clarity is tested. The question is not whether accountability exists on an organisational chart, but whether it is being lived in practice. On this project, a difficult truth was that pressure did not always produce clearer ownership. In some instances, it produced less. That is precisely the point at which delivery risk becomes ethical risk, because stakeholders and users continue to depend on a structure that no longer functions as intended.

4.A fourth problem was the gap between formal progress and lived readiness. ERP projects can create the illusion of progress because plans can still be updated, meetings can still occur, and milestones can still be discussed. But actual readiness depends on something deeper: aligned decisions, engaged experts, trained users, and confidence that the system and the organisation are moving toward the same outcome. When those elements begin to separate, the project may continue administratively while becoming weaker operationally. That disconnect is dangerous because it can mask the project's true condition until much later.

The lessons learned from this experience have stayed with me throughout my career.

1.The first lesson is that a small or early-career project can still carry major ethical significance. At the time, I might have thought of this as a relatively contained ERP implementation: 25 named users, two locations, limited scale compared with enterprise-wide transformation programs. But for the people involved, it was not small. It affected their work directly. That taught me that project ethics is not reserved for the largest or most visible initiatives. It applies anywhere project decisions affect people, trust, and outcomes.

2.The second lesson is that accountability must become more visible when a project struggles. If a project begins to slip, the right response is not reduced presence. It is stronger ownership, more direct communication, and clearer escalation. Difficulty is when leadership matters most.

3.The third lesson is that subject matter expertise is not a support function to be consulted when convenient. In an ERP implementation, it is an essential infrastructure for responsible decision-making. When that expertise is absent, ignored, or inconsistently available, the project becomes vulnerable not only to design errors but also to ethical failure, because decisions are made without adequate grounding.

4.The fourth lesson is that honesty is a protective discipline. Clear language about risk, readiness, and unresolved issues can feel uncomfortable, especially early in a PM career when authority may feel limited. But honest communication protects the project and the people affected by it. It allows for earlier intervention, resetting expectations, and preserving trust even when progress is slower than planned.

5.The fifth lesson is that ethics often becomes visible through behaviour under pressure, not through formal statements of intent. Most teams can align around principles at kick-off. The real test comes later, when timelines tighten, participation fluctuates, and the project becomes less predictable. That is when responsibility, respect, fairness, and honesty become observable.

What stays with me most from this project is not only what went wrong, but what it taught me about the kind of project professional I wanted to become. Early-career experiences often shape our instincts. This one taught me that when a project begins to struggle, the work is not just to recover the schedule. It is also to protect integrity. That means staying present, naming risks clearly, respecting the people affected, and refusing to let silence replace ownership.

An ERP implementation may be judged by whether the system eventually goes live, but that is not the only measure that matters. It should also be judged by whether the process was led responsibly, whether users were treated with respect, whether burdens were shared fairly, and whether the truth about the project was communicated honestly. Those are not secondary concerns. They are part of what professional project management requires.

To open discussion, these questions may help start a thoughtful conversation:

1.When an ERP project begins to slip, what are the clearest signs that a delivery problem is becoming an ethical problem?

2.How should project managers respond when key contributors or subject matter experts become less available at the exact point their engagement is most needed?

3.Early in a project management career, how can a PM raise concerns honestly and constructively when accountability appears to be weakening around them?

By: Laszlo J. Kremmer MBA, CLC, CSM®, CSPO®, PMP® - Member of PMI Ethics Advisory Team

Early in my project management career, I worked on an ERP implementation project that shaped my thinking about leadership, accountability, and ethics to this day. It was not the largest project I would ever see, but it was large enough to matter deeply to the people involved and complex enough to expose weaknesses in both delivery and conduct. The project involved 25 named users across two locations, each of whom would be directly affected by the implementation. It also required coordination across multiple functions, managing competing priorities, and a level of change readiness that, in retrospect, we did not fully appreciate.

At the outset, the project appeared manageable. The scope was defined, the users were known, and the organisational footprint was limited to two sites. From a planning perspective, it seemed like a project that could be structured, tracked, and delivered through disciplined execution. But what I learned very quickly was that the visible scope of a project does not always reveal the full ethical and operational challenge underneath it.

As the project progressed, cracks began to show. Delays emerged. Some decisions took longer than expected. Some dependencies were not resolved when they should have been. And once the project encountered difficulties, a troubling pattern emerged. Key people became less available. Some project support weakened. Subject matter experts were harder to reach. Momentum slowed, but the need for ownership increased. Instead of the project receiving stronger engagement as risks became more visible, it often felt as though accountability became less clear, exactly when it was needed most.

At that stage in my career, I experienced this primarily as a delivery problem. Looking back now, I see that it was also an ethical one.

ERP implementations are rarely just technology projects. They reshape how people work, how data is managed, how decisions are made, and how operational control is exercised. Even with only 25 named users, this project had a significant impact because each user depended on the project team to make sound decisions, properly prepare the organisation, and communicate clearly across both locations. When that does not happen, the consequences are not abstract. They are felt directly by the people expected to adopt the new system and continue business operations through the change.

The PMI Code of Ethics and Professional Conduct provides a useful lens for reflecting on what happened. Its four core values, responsibility, respect, fairness, and honesty, offer more than a set of ideals. They provide a practical standard for assessing how project professionals behave when a project becomes difficult.

Responsibility was the value most visibly tested. In an ERP project, responsibility means more than maintaining a task list or reporting status. It means owning outcomes, actively managing risks, preserving continuity, and ensuring that unresolved issues do not simply become someone else's burden. On this project, one of the clearest problems was that when delays occurred, ownership did not always strengthen. In some areas, it became weaker. Questions remained open longer than they should have. Dependencies sat unresolved. Critical input was not always available when needed. The project still moved, but not with the level of accountable leadership that the situation required.

Respect was also at stake, though I understood that more clearly only in hindsight. The 25 named users across the two locations were not passive recipients of a system rollout. They were people whose work routines, confidence, and effectiveness would be directly affected by the implementation. Respect in that context meant giving them realistic timelines, complete preparation, clear communication, and confidence that the project team was present and engaged. It also meant respecting colleagues by not leaving them to manage ambiguity without adequate support. When key contributors become difficult to access during a challenging phase of delivery, the impact is not only operational. It signals a lack of respect for the people carrying the work forward and for the users who depend on a successful outcome.

Fairness appeared in a more subtle but equally important way. As often happens in struggling projects, the burden did not fall evenly. A smaller group of engaged people ended up carrying more of the work, more of the uncertainty, and more of the responsibility to keep progress moving. Others became less visible as the project became more difficult. That imbalance matters ethically. Fairness is not only about impartial decisions or equal treatment in formal terms. It is also about whether risk, workload, and accountability are being shared appropriately. When some people quietly disengage, and others compensate for that disengagement, the project may continue for a time, but it does so on an increasingly unfair foundation.

Honesty may have been the most important value of all. ERP projects can absorb setbacks if they are surfaced early and discussed honestly. What makes them dangerous is not delay alone, but the lack of candour that often surrounds delay. One of the central ethical lessons from this experience was the need to clearly state what is happening, what is at risk, and what the consequences may be if unresolved issues persist. Early in my career, I saw how easy it was for teams to use softer language than the situation warranted. A dependency becomes "in progress." A missing decision becomes "under discussion." A growing risk becomes "something we are watching." Sometimes that language protects relationships in the short term, but it can also obscure reality. Honesty requires more discipline than that. It requires naming the issue as it is and not as we hope it will become.

The PMI Ethics Framework is especially useful in situations like this because it encourages structured reflection before action. Looking back, several questions should have been asked more often and more directly. Who is affected if we continue without resolving this issue? Are we being transparent enough about readiness across both locations? Are we placing an unfair burden on a few reliable contributors? Are we making decisions based on evidence, or are we allowing optimism to replace judgment? These are not only project controls questions. They are ethical questions.

To be continued...

Do You Like to Pick and Choose Your Projects?

What the PMI Code of Ethics Says May Surprise You