Tag: Stakeholder


Lean and Project Sustainability

On July 18th, 2008, SPIEGEL quoted the Dutch architect Rem Koolhaas on how sustainability is seen and understood by various people. Rem Koolhaas allegedly said that “sustainability is such a political category that it’s getting more and more difficult to think about it in a serious way”. The issue raised by Rem is that sustainability is a complex concept, difficult to think about. It is therefore difficult to implement and control a concept that doesn’t come out clearly in our minds.

The former German Chancellor Angela Merkel, quoted by the financial times on March 28th, 2009, commented on sustainability from the lean management viewpoint and opined that the 2007-2009 Great Recession “did not come about because we issued too little money but because we created economic growth with too much money, and it was not sustainable growth.”

The issue raised by Merkel is that monetary and related instruments leave out key lean principles, especially on eliminating waste, namely (i) identifying and specifying value from the customer’s perspective, (ii) mapping the value stream, (iii)creating continuous flow, and (iv) establishing pull system. Eliminating waste is a major aspect of quality management. With the USA’s Great Recession case at hand, this article discusses lean as a tool for sustainability.


Eliminating waste to maximize sustainability

Generally, there are two types of work: value-adding and non-value-adding work. The non-value-adding work is also known as waste. A major aspect of sustainability thinking is the efficient and effective management of resources. In lean management, there are 7 categories of waste that need to be considered for sustainability’s sake.

They include (i) overproduction, (ii) over processing, (iii) waiting, (iv) transport, (v) inventory or stock, (vi) motion and (vii) defects.

Sustainability-oriented project teams will strive to eliminate these wastes to make sure project results “meet the needs of the current generation without compromising the ability of future generations”. By eliminating the above-listed wastes, project teams increase the chances for project results to survive the closure phase.


Voice of the customer (VOC) as the foundation for sustainability

The Brundtland Commission report underscores three dimensions of sustainability namely environment, society, and economy. The social dimension of sustainability requires that beneficiaries of any given intervention are heard and participate in the decision-making process. It is this participation in the decision-making that guarantees the ownership of beneficiaries. Not only the lack of this ownership does shorten the lifecycle of the project results but also erodes the capacity of beneficiaries for resilience and adaptation.  Needless to mention that resilience and adaptation are key features of a sustainable intervention.

Applied to project management, the lean methodology uses VOC to collect information on how customers or stakeholders feel about the project and their expectations.  For instance, customers interviews, live chat, focus group discussions, emails, social media, feedback forms or even special events such as customer dinner or brown-bag lunch are organized to collect data on how customers, at their respective chain levels, feel about the business, the products and understand their preferences.




Mistake-proofing the sustainability-related processes

Mistake-proofing, also known as poka-yoke, is a declaration of systematic war against errors to make it impossible for an error to happen or if it occurs it doesn’t reach customers. The majority of poka-yoke in manufacturing use automatic devices or other technological tactics to filter out errors.

It is advisable that, in all industries, whenever possible, the project team and other stakeholders use poka-yoke to prevent the occurrence of errors throughout the project life cycle. For instance, during the formulation or reviews of the projects, checklists can be automated using drop-down lists with links to critical features of sustainability.

If certain sustainability requirements are not met, the next step will be put on hold until everything is right. Advanced technologies will also include digital documents and pictures (both baseline and targets). The use of GIS and GPS in mistake-proofing helps to prevent environment-related mistakes. Simply put, there are many ways project sustainability can be assured using the poka-yoke technique.


Two Muda that threaten sustainability: the USA great recession case

 What if chancellor Merkel’s complaint was about overproduction or over processing?  From her argument, we learn that the traditional belief that monetary policies and related instruments designed and implemented by central banks and other monetary institutions are not necessarily demand-driven. When Chancellor Merkel argued that “too much money” was supplied in the market, she warns us against the Muda of overproduction of money that doesn’t match with sustainable growth.

Assuming that Merkel was right, it is logical to warn against a new Muda of overproduction probably worse than the 2007-2009 great recession, as it would be exacerbated by the solution brought by the federal reserve. In fact, as a response to the crisis, the Federal Reserve, along with massive government spending, reduced the interest rate to zero and bought financial assets to add more money into the economy.

From another analytical angle and in line with Merkel’s opinion, since the federal reserve injected much money into the economy, it can be inferred that a second Muda of over processing is ongoing. For complex processes, unless mistake-proofing is used, over processing can only be known when products are out and customers don’t take them.



With scarce resources and increasing demand by the current generation, it is urgent to think about how to assure the quality and quantity of what the current generation will leave for the future one.

This said, we need to first figure out what will be the needs of future generations and then, as advised by the Lean Methodology, establish a pull system to serve those needs. The above-discussed great recession would not have happened if there were a poka-yoke to prevent it. The fundamental question is why the Federal Reserve didn’t think of mistake-proofing in the financial system to prevent the crisis.

Is it because this kind of poka-yoke is impossible? Is it because, as Rem tries to convince us, sustainability is just a fashionable political category?


Exceeding Expectations is a Quality Killer

Do you remember a time when you were hungry, and once your favorite food was brought, you couldn’t help but consume only part of it? Why didn’t you eat it all, given it is your favorite food? The answer is very easy. As you eat, hunger starts to disappear and immediate interest in the favorite food starts to reduce until it disappears. At the time you feel satisfied with already eaten food, swallowing an extra unit will be harmful. How would you feel if a friend of yours insist that you should eat that extra quantity of that delicious food?

The project management profession is full of similar stories. In the project management profession, stakeholder engagement is paramount to the project’s success. The purpose of fully engaging stakeholders is to ensure their satisfaction.

Why do stakeholders’ expectations matter?

Project management is one of the few jobs that are likely to suffer less from robotization. This is because the project management job involves interacting with people to understand their needs to serve them better. The business case at the origin of a project ensures the business bottom line is at the service of key stakeholders essentially customers, end-users, suppliers, and the sponsor. Consistency in project management consists of regularly testing the correspondence between the business case and stakeholders’ expectations. This test helps ensure that the project implementation serves the needs and wants of stakeholders since a project, regardless of the industry, should be pro-people. By trying to develop a new product, service, or result, a project exists to serve the needs or expectations of key stakeholders mainly customers and end users.

Benefits realization: the total utility for stakeholders

As rightly put in the previous section, a project exists to serve the needs of key stakeholders. Customers and end-users invest their capital into a project expecting that the ultimate result will make them better off or happier. When a project manager or a project team member strives to meet stakeholders’ expectations, she/he assumes that by doing so the beneficiary stakeholders will get more enjoyment or happiness from the project results. Microeconomics teaches us that this satisfaction, or happiness felt by the consumer, or the stakeholder in the project management language, is also known as utility in the disciple of Economics. Utility function has been largely studied by microeconomics scholars and they postulate that the consumer will seek to maximize the utility derived from consumer goods and services.  If project team members stop here, they will spare no effort to find how they can exceed customers’ expectations. However, Microeconomics arrived at a conclusion that for a single good or service (project result in this case), consumers maximize the enjoyment or total utility when marginal utility becomes zero, as its curve reaches the flexion angle. At this point, the total utility starts to decline, and the extra unit of goods consumed starts harming the consumer as illustrated in the following graph. Remember the old saying that “too much is always bad”.






Navigating the project complexity to meet stakeholders’ expectations

In light of the above discussions, the work entrusted to the project manager is not straightforward. It is full of changing individual and organizational behaviors, a dynamic system behavior resulting from connectedness and interdependency of project elements that interact to bring about change as well as ambiguity stemming from unclear cause-and-effect relationships, emergent issues, and situations that can be interpreted differently.

Stakeholders’ expectations are embedded in individual and organizational behaviors, which, as mentioned above, are changing. The changing nature of stakeholders’ expectations makes it difficult to identify them. Targeting to exceed stakeholders’ expectations will bring more complexity as, to be safer, it would be built on assumptions of increasing marginal utility which is a very rare situation. Proponents of the postulate of exceeding stakeholders’ expectations base their view on the assumption that the expectations in question are less than the maximum total utility or benefit that can be obtained from the project.  However, this is not always true, given that history is full of examples of overambitious stakeholders. In addition, this assumption of a sober and realistic stakeholder tends to forget other aspects that make project management complex namely the limited resources, emerging issues, stakeholders’ changing behavior, and most importantly the diminishing marginal utility of most of the project results as well as their opportunity cost.

To solve this problem, the adaptive approach in project management proposes to regularly check stakeholders’ expectations and adjust targets to a desired, justifiable, and affordable level. By adjusting project targets, the project team will hence deliver to newly identified stakeholders’ expectations rather than exceeding them. The adaptive approach will embrace the continuous improvement practice in which the regular assessment of stakeholders’ expectations will be the mandatory entry point.

Ethics and exceeding stakeholders’ expectations

In most situations, the project team members work as agents on behalf of the sponsor who is the principal. They receive the project implementation mandate from the sponsor or the customer. The project team is selected based on its skills, experience, exposure, and network, assumably required for successful project implementation. As they carry out their duties, team members obtain specific information on the project. Ethics requires the project team to share specific information with relevant stakeholders to ensure informed decision-making. Before delivering beyond expectations, a team member that behaves ethically will check with the concerned stakeholders if doing so will be beneficial for them. If the stakeholder confirms his interest, then the project team will be delivering on revised stakeholders’ expectations rather than beyond expectations.

If on the contrary, the project team goes ahead and delivers the unilaterally revised targets without confirmation from concerned stakeholders, this will sound unethical because one would ask why hiding good things, and the moral hazard can easily slip in this behavior.


As a continuous improvement practice, it is recommended to regularly check stakeholders’ expectations to deliver just on it. It goes without recalling that “too much is always bad”.


When is a Decision Final?

This article addresses the question, when can a decision no longer be changed?

Everything we do results from a conscious or unconscious decision. When it comes to anything important, it is better to make firm conscious decisions.

In projects, changing decisions about objectives, requirements, designs, staffing, and vendor selection is disruptive and costly. Not changing them may also be disruptive and costly.


When is a Decision Final?

A decision is final when it can no longer be changed. It can no longer be changed when the decision has been completely implemented or when authority, rules, and regulations say the decision cannot be changed.

We can’t revoke a decision to build a house once the house is built. It is physically impossible (in the absence of time travel) to go back and not build it. While it is physically possible to change a decision that has been deemed final by authority, there are political ramifications.


Models, Beliefs, and Relationships

Models and beliefs about sticking to decisions influence the decision-making process. Relationships among stakeholders are affected. Some expect that once a decision has been made the decision-making ends. They believe that going back to reassess a decision is a sign of poor decision making – being sloppy, wishy-washy or indecisive.

Consider the relationship between executives, clients, requirements analysts, and implementers.

  • Clients and executives love decisiveness and hate ‘analysis paralysis’ – they want to ‘get on with the work’
  • Clients often change their minds
  • Requirements analysts are charged with avoiding the need for changes and communicating changes to the implementers
  • Implementers are often ‘annoyed’ by the changes, thinking that the clients are indecisive and oblivious of the impact of their changes and the analysts are not doing a good enough job when eliciting requirements
  • Analysts feel that they are not given sufficient time and do not have sufficient access to decision makers.

We value both firm decisions and the flexibility to change them.


Expect Change

Change is inevitable. Consider a conscious decision-making process:

“1) Define values, goals, objectives and specifications underlying the issue or question

2) Define the decision making and target environments

3) Agree upon decision criteria

4) Identify solution options

5) Analyze and compare solution options vis-à-vis the decision criteria

6) Decide

7) Implement the decision

8) Monitor and adjust

9) Reflect on the process for lessons learned.”[1]

We see that step seven, Implement the decision, is not the finish line. We acknowledge the need for adjusting decisions whenever conditions change.




Decision Making and Change Management

This question of when a decision is final links decision making and project change management.

The heart of change management is deciding whether to change previously made decisions.

A change management process decides whether to allow change to earlier, frozen, decisions. Changes are costly. Changing a requirements or design decision before it is implemented costs far less than changing it afterwards. Changing a decision that has been baked into a contract can require legal proceedings. Changing a screen design in a website less costly than changing the design of a physical product, like a bridge or building once construction is started.


A Middle Way

Enable and minimize change.

We want to be flexible, open to changing our minds, and we want to avoid wasting time and effort caused by having to unnecessarily revisit decisions.

Let’s look at a case. A design team decided on the use of a certain type of handheld device. Based on that decision a procurement process was started. A couple of weeks into the procurement process for the devices, the design team changed its mind. They decided that a handheld device would not work. They changed the design to use work stations instead. This wasted the time and effort of the procurement team and the vendors they reached out to for bids.

Was the change warranted? Yes, it was recognized that use of handheld devices made operational costs excessive.

Could the design change have been avoided? Maybe. If the team avoided unnecessary changes by spending more time and effective effort to better understand the decision factors – objectives, work environment, criteria – using checklists, and making sure people speak up with ideas, comments and criticisms.



In this case, the design team became aware that they had not consider the operational issue of the loss, damage, and ‘shrinkage’ of the devices when a member spoke up to bring the operational issue to light.

Why hadn’t he/she/they spoken up earlier? Maybe the idea just dawned, or out of fear to speak up during the design sessions. Either way, it was a good thing the issue was raised and that the design team and leadership accepted the change, even though it disrupted schedules and wasted effort. The up front loss was miniscule compared to the expenses saved.

Imagine if design team leadership didn’t support the change, saying that it was too late or too politically dangerous to question the earlier decision. Not only would there have been an inferior outcome, but some members of the design team would also be demotivated, thinking that their leadership was unprofessional and cowardly.

If this kind of thing happened frequently it would be a sign that the design team’s process needed some improvement.



Adapt an approach that dynamically balances enabling and avoiding changes.

Any project decision can be changed until the decision has been completely implemented. Minds change when information regarding decision factors change. While you may never be perfect, make sure your decision-making process addresses all the factors that influence the decision. Take the time to get it as right as possible the first time.

Consider how often stakeholders change their mind after having decided, and how many decisions end up being poor ones.

Do you need to devote more time and focused effort to the decision process? Do you need more formal facilitation, brainstorming, checklists, and input from experts regarding objectives, decision criteria, environmental considerations, and options?

[1] https://www.projecttimes.com/articles/the-power-of-decision-criteria/

Project Stakeholder Register and Organizational Chart: Useful tools for project stakeholder management

Projects come in all sizes, and in most cases larger projects come with more potential complications.  This is also true when projects involve multiple individuals and organizations.  Successfully managing a project often means dealing with stakeholders beyond your immediate project team.  Stakeholders are key to the success of any project, so identifying and managing stakeholders is a critical element of project management (Kissflow Project, 2021).


Project Stakeholders

Projects frequently involve different groups, individuals, and organizations who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.  These are known as project stakeholders (Project Management Institute, 2021). Project stakeholders can be broadly classified into two categories: Internal Stakeholders and External Stakeholders

Internal stakeholders generally include anyone within the organization conducting a project.  It starts with the internal members of the project team, the project manager, and the project sponsor.  The concept can also be expanded to include other individuals and within the organization or company, such as other teams and departments.  Internal stakeholders are usually the easiest to identify because they are immediately known and often familiar.

External stakeholders include anyone affected by the project, its processes, or deliverables and outside of the organization conducting the project. These include external project clients, end-users of product outputs, suppliers, contractors, the government, and sometimes even members of the community where the project is taking place.  The complete list of external stakeholders can be more challenging to identify as they can be new to each and every project.  And of course, no complete list of stakeholders or stakeholder groups exists for each project!


Stakeholders, both internal and external, need to be identified.  A project team should have access to information regarding their roles, responsibilities, and capabilities regarding the project. Stakeholder contact information is also essential to coordinate communication throughout the project and therefore it needs to be available to the core project team.

In addition to knowing who the project stakeholders are, a project team should know how they are organized and structured within the project environment.  This is why using a project stakeholder register and organizational chart right from the very start can help to get a clear picture of the project organization and to manage communications throughout the project lifecycle.


The Tools

While project stakeholder management is its own knowledge area and functional discipline, knowing how to use two stakeholder management tools will help to organize stakeholder management for projects of all sizes: the stakeholder register and the project organizational chart.



The Stakeholder Register

A stakeholder register is a document including the identification, assessment, and classification of project stakeholders (Project Management Institute, 2021). It is a list of the stakeholders involved in a project and the “need to know” information about them, kept accessible to members of the core project team.


The first step in creating a project stakeholder register is to identify the stakeholders involved in a project.  Start with the internal stakeholders, and then move on to the external stakeholders.  Think about who is involved with the project both directly and indirectly.  Who might be affected by the project, its execution, and its outcome?  What individuals or organizations have authority over different aspects of the project?

Next, determine what information is needed from each stakeholder and start collecting it.  This starts with each individual’s name, position, role in the project, and contact information.  For organizations and departments, it should include the individual contact person from that stakeholder group.  Finally, any other relevant information or details pertaining to that stakeholder or stakeholder group that might be relevant to the specific project at hand.

Finally, compile the register.  This can be done in any format the project team chooses to use.  A simple spread sheet can serve the purpose, or something more organized like a contact management function in Microsoft Outlook or Google Contacts.  Many project management software programs include a resources sheet just for this purpose with customizable fields to organize the details on each stakeholder based on their importance to the project.  The most important criteria for the selection of a system to use is that it is accessible to the core members of the project team as they need to use it.


Project Organizational Chart

A project organizational chart is a document that graphically depicts the project team members and their interrelationships for a specific project (Project Management Institute, 2021). It is a visual representation of the stakeholder register indicating how various stakeholders are positioned within the project.  A projects organization structure is usually fairly obvious for small projects, but the importance of knowing and understanding the structure becomes more significant as projects grow in size and number of stakeholders.  Understanding the organization of the project stakeholders helps in defining relationships, allocating responsibilities, authority, and tasks (San Cristóbal, 2018).


The project organizational chart can be as simple as a tree diagram or a bubble chart.  More important than its design is its function and purpose, which is to understand the relationships among and between project stakeholders and to communicate this information at a glance.


Best Practices

With the tools in place, following a few best practices in creating a stakeholder register and a project organizational chart will help in coordinating project stakeholder management.

  1. Consider Frequent Project Stakeholders
  2. Start Early
  3. Involve Others
  4. Stress Test


Consider Frequent Project Stakeholders

In many organizations, project work is the normal mode of operations.  If your organization frequently works with projects, then there is a good chance that many of the project stakeholders, both internal and external, will be the same across multiple projects.  Having a list of stakeholders and their contact details ready to go will save time in creating a project register for each project once stakeholders are identified.


Start Early

The process of identifying stakeholders ideally starts once an organization selects and approves a project.  By doing so, they can be kept involved,  contacted, and consulted as necessary throughout the following stages of project development (Kissflow Project, 2021).


Involve Others

When considering details about individual stakeholders roles, responsibilities, and capabilities, it can be valuable to involve the individual stakeholders themselves, where practical, in collecting these details.  This allows for a more complete collection of information and to gain a different perspective.


Stress Testing

Once the stakeholder register and project organizational chart are completed, share them as appropriate with other project stakeholders and members of your organization.  As with the process of involving others, it helps to gain a different perspective on the information compiled.  Additional feedback will help to improve the accuracy, and therefore the usability, of both tools.

Understanding the needs, structure, and expectations of project stakeholders can be a critically important aspect of achieving project success.  Knowing the basics of project stakeholder management, as well as how to create and use a stakeholder register and project organizational chart, will go a long way toward successful stakeholder management in all types of projects.


Get the Right Answers to Make the Right Decisions

“If I had an hour to solve a problem and my life depended on it, I would use the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.” – Albert Einstein

Decisions solve problems and are the forerunners of action. According to Oxford Language a decision is “a conclusion or resolution reached after consideration.” Decision making is “the action or process of deciding something or of resolving a question.”

Decision making is at the heart of effective performance. It is a complex process that relies on a combination of both external, interpersonal, and intrapersonal factors.


Stepping Back to Consider

Einstein’s estimate of how long it would take to solve the problem may be optimistic for those of us lacking the genius’ intellect, but the ability to step back and ask the right questions is critical to being an effective decision maker. The principle is true for individuals and teams alike.

The primary definition of decision says one is made after consideration of questions to uncover and narrow down alternatives, make sure that there is understanding of the problem, and to focus attention on critical issues.

“The affect of asking the right question is statistically profound. … we saw that asking the right question increased the odds of someone’s work having a positive affect on others by 4.1 times. It made the outcome 3.1 times more likely to be deemed important, 2.8 times more likely to create passion in the doer, and perhaps most significant to company leaders, 2.7 times more likely to make a positive impact on the organization’s bottom line.”


What to Consider?

What are the proper questions? For example the question “Why is it that when we want to call and talk to a person, we have to call a place?” asked by a Motorola project manager charged with creating the next generation of car radiotelephone led ultimately to the personal mobile phone rather than to a solution that focused on a location, whether at home, in office, or in a car.



There are seven questions that are widely accepted as the basics for getting the right information for making a decision – who, what, when, where, why, how, and how much. Of these, the why question, is the most controversial and often the most difficult to ask.

A brief internet search uncovers articles that insist on asking why and those that say not to ask why because it is too confrontative and often comes from being judgmental as opposed to being curious. Of course, it depends on the context and the reason for the question.

In the context of project management, “why?” is a critical question that helps to make effective decisions.


Do or Die

Imagine being a project manager who has been assigned a project that must deliver a specified result in six weeks. You ask, “Why that result and in that time frame?”  If the response is “Because the client wants it?” do you push back?

Or do you walk away ready to give your team the same answer you got from your boss or the customer contact person? Telling them “Ours is not to wonder why. Ours is just to do or die.”

Would the client be averse to the “why” question? If so, “Why? How about if the question were rephrased as, “We often find that there are several ways to achieve your business goals and some are often better than the solution we first think of. Can we explore the reason for your objective so that we might be able to better serve you?”

Note the possibilities here. The client might be completely closed to any other solutions and require that you “do or die.” Or, the client might be interested and open minded enough to identify the reasons for the objectives and be open to alternative solutions that would be less costly and more effective at achieving business objectives.

That is why wise project managers insist upon getting answers to the proper questions. Failure to do so not only makes for suboptimal solutions, but putsd the manager and team in a position to take the blame for it.


The Right/Proper Questions

Detectives ask questions to uncover means, motive and opportunity. Project managers may ask questions that take them “out of the box of conventional thinking, but they must ask questions that consider the situation at hand:

  • Are expectations rational?
  • What will happen if we don’t ask the right questions?
  • What are the business goals and project objectives?
  • Why are they the objectives?
  • Are there alternative objectives that would achieve the goals?
  • What are the criteria for success? Why? Who established them? Who will determine if they have been met?
  • What are the consequences of failure? Of success?
  • What are the risks  that might get in the way of success?  What are their likelihood and impact?
  • When will the project be performed and when is it expected to be completed?
  • What human and material resources are needed? Why? What quality characteristics must they have? Are there alternatives?
  • Are the resources available? When will they be needed? Why? How could they be made available?
  • What is the project environment like? Can it be made more “friendly” to project performance?
  • Who are the stakeholders and what are their roles and responsibilities?
  • Who will be impacted by the project’s performance and its results? How will they be impacted? How can impact be influenced to make it more positive?
  • What is the project history – e.g., was this or a similar project performed in the past? How can lessons learned be used to inform the current team?
  • What procedures and tools will be used? Why? Are there alternatives?


Courage and Patience

Often, everyone wants to just get on with the work, to “just do it.” It takes courage and patience to take the time and effort to step back and ask the proper questions, even in the face of resistance by key stakeholders to explore reasons and alternatives.