A Checklist for Shared Outcomes
Education and Training,
Human Aspects of PM,
Categories: Benefits Realization, Best Practices, Career Help, Change Management, Communication, Communication, Complexity, Education and Training, Ethics, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Leadership, Leadership, Lessons Learned, Mentoring, PMOs, Portfolio Management, Procurement, Program Management, Project Delivery, Project Failure, Project Planning, Roundtable, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
I was recently assigned to transform a procurement team into one that managed outsourcing partnerships. I realized the team was very disengaged, leaving the strategy up to me to define. There was no buy-in. The team and the partnerships were sure to fail.
But I was determined to make the team successful. For me, this meant it would be accountable for managing thriving partnerships and delivering superior outcomes.
To get things back on track, I had to first get alignment on goals. Setting shared goals can help to shape collaborative and accountable teams that produce desired outcomes.
Establishing goal alignment can be a difficult leadership challenge; however, leaders must gather the needs of all stakeholders and analyze their importance to achieve the desired organization outcome.
I often use this checklist to tackle this challenge:
I used this checklist during the procurement team project and it helped to reset and reinvigorate the team. Once we aligned around shared goals, team collaboration increased and the organization started to achieve the targeted business benefits.
If you’ve used a checklist like this before, where have you stumbled and how did you turn it around?
By Ramiro Rodrigues
When outsourcing a job to consultants and service providers, I’ve often found that achieving "agreement" with a client that a project is finalized is one of the most delicate times.
This is usually due to the fact that by closing the project the client knows that:
Scope verification—the process of formalizing the approval of a project scope—recommends progressive approvals are made as partial deliveries of the scope take place. This process, if well planned and applied, helps to minimize the weight of the final approval term.
The strategy I developed over many years of consulting work is something I call “ground preparation.” This strategy has four simple stages that need to be well distributed in the time near the project closure to increase your chances of a non-traumatic closure.
Let's review them:
1st Stage: As you move close to the end of the project, start the conversation, preferably face-to-face, with the stakeholder responsible for accepting the project.
2nd Stage: Send that same stakeholder a draft version of the project acceptance document that is as close as possible to the final version.
3rd Stage: After giving the stakeholder time to digest the draft, follow up to discuss any questions or concerns. Also, this is a good time to let them know when they can expect the final acceptance document.
4th Stage: Send the final version of the acceptance document and suggest that you collect it with, if applicable, some sort of closing event.
Of course, we are talking about a project that has successfully achieved its goals. But even projects that have had to be aborted or projects with a low degree of success at the end must be formally shut down. A lot of this strategy can be replicated whenever the end is imminent.
What are your strategies for closing down a project?
In my next post, I will review the characteristics of the acceptance term for internal customers.
By Marian Haus, PMP
The SWOT framework is a very useful analytical tool for identifying risks and opportunities. It can be used across industries and in a range of scenarios, from project planning and risk management to strategic business and corporate planning.
When used in project management, SWOT can help capture internal project aspects (strengths and weaknesses), as well as the external aspects (opportunities and threats) that can positively or negatively influence the project.
Here are four steps for preparing and moderating a two-hour SWOT session:
1. WHAT: Explain what SWOT is, elucidating each of the four terms and giving some examples of each. For instance:
It’s important to highlight that strengths and weaknesses are characteristics internal to the project, while opportunities and threats are external.
From the very beginning, it’s equally important to define what goal you’ll be assessing under the SWOT framework. This will narrow the focus from generic to articulated obstacles and prospects that can hinder or support reaching your goal.
For this part, allocate a time-box of 15 minutes from the total two-hour session.
2. HOW: Now that everyone knows what SWOT is, explain how the analysis will be conducted.
You’ll need to prepare in advance. First, get a whiteboard and draw a simple SWOT matrix, with a quadrant for each attribute (S, W, O and T). Highlight that “S” and “W” are internal factors, while “O” and “T” are external.
Next, make sure you have sufficient Post-its for capturing the SWOT information. I recommend using separate colors for each attribute—this will improve the visualization of the SWOT matrix.
Allocate a time-box of five minutes for this part of the session.
3. CONDUCT: Conducting the SWOT analysis is the easiest part. Now that everyone understands the approach, engage the participants in capturing the strengths, weaknesses, opportunities and threats on the colored Post-its.
For a team of 10 people, allocate 10 minutes for capturing and 30 to 50 minutes for presenting and posting the results on the SWOT board. Each contributor should individually capture the SWOT and present the results.
4. STRATEGIZE: Now that you know the strengths, weaknesses, opportunities and threats of your project, it’s time to do something about them. There are different strategies and approaches for dealing with the SWOT outcome.
One strategy is to apply a risk management approach: Qualify the captured information by urgency and impact, and define responses for risks and exploits for opportunities.
Another strategy is to convert weaknesses and threats into strengths and opportunities.
Or you can apply the simple USED approach, by addressing the following questions:
For this important part of the process, you should allocate up to 50 to 60 minutes of the session.
The SWOT analysis is a subjective assessment because the level of knowledge and state of information might vary among the attendees. Nevertheless, the outcome could help to prevent issues or exploit opportunities during your project journey.
What tips do you have for moderating a SWOT analysis?
By Linda Agyapong
During lunch one day, project managers Jim, Mary and Alex got into an argument over who was best adhering to their industry’s project success criteria. They all had sound arguments. The problem was, however, an “industry standard” did not appear to exist.
Jim argued that he follows the good old “triple constraints” or “iron triangle” concept (i.e., time, cost and scope). Mary sharply retorted that she follows the “quadruple constraints” concept (i.e., time, cost, scope and quality), where the “quality” minimized bugs or defects. Alex quickly asserted that he is the best project manager because in addition to what both Jim and Mary did, he reduces risk, meets stakeholder expectations, and his projects generally add value to the organization in extra areas.
Before we jump into crowning who we think should be project manager of the year, let’s take a trip down some project manager memory lane based on recent research I performed.
Although PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) makes certain recommendations, the subject of project success criteria has been evolving for more than five decades.
In her report, Kate Davis summed up the different success criteria throughout the years:
1970s: Project success was centered on the “operations side, tools and techniques (‘iron triangle’).”
1980s: The technical components of the project and its relationship with the project team and project manager.
1990s: The “critical success factor” framework, and its subsequent dependence on both external and internal stakeholders.
21st century: The focus has primarily been on the stakeholder.
Davis isn’t the only one pointing out the changing criteria. Many academics and authors have noted the differences, including:
1980s: Jeffrey K. Pinto and Dennis P. Slevin expressed their frustration in a Project Management Journal article by asking, “How can we truly assess the outcome of a project when we (in the project management field) cannot fully agree on how project “success” should be determined?”
Late 1990s: David Baccarini from the Curtin University of Technology recounted in a Project Management Journal article that “a review of the project management literature provides no consistent interpretation of the term ‘project success.’”
2008: Graeme Thomas and Walter Fernández said that “although IT project failure is considered widespread, there is no commonly agreed definition of success and failure.” They described project success as being “a difficult and elusive concept, with many different meanings,” and hence called it protean (likening it to the Greek sea-god Proteus), based on its ability to continually change its “form to avoid capture.”
The current decade: Hans Georg Gemünden criticized the triple constraints for failing to consider other factors, such as stakeholder impact, since “value lies in the eye of the beholder.” He recommended project success criteria be based on its “targeted outcome and impact” to the organization’s business case.
Standish Group’s 2015 CHAOS Report redefined a successful project from one being “on time, on budget and on target,” to one being “on time, on budget and with a satisfactory result.” This redefinition was to ensure project deliverables met stakeholder expectations and also added value to the organization.
So based on the above, which of our three project managers (Jim, Mary or Alex) should be crowned project manager of the year?
The Problem With Paradox
Categories: Decision Making
by Lynda Bourne
The dictionary defines a paradox as a statement or group of statements that, despite sound reasoning from acceptable premises, leads to a conclusion that seems to defy logic or intuition. An example of a paradox is: “This statement is false”—if it is, it is not; and if it isn’t, it is.
A well-known project management example is Cobb’s Paradox: “We know why projects fail; we know how to prevent their failure—so why do they still fail?” The apparently true statement is that we know how to prevent project failure, but do we really know how to make projects successful? And if we do, the illogical element is, why do we let them fail?
This concept extends into the realm of project management. Virtually every management system generates a range of contradictions that can be removed by better design. It also creates a series of paradoxes that can’t be removed because both factors that create the paradox are important, but at the same time contradict each other.
This type of management paradox is defined as “a persistent contradiction between interdependent elements that resist a simple binary choice between the elements.”
Some of the more common paradoxes found in most organizations include:
The persistent nature of every paradox means the decision maker has to get used to living with contradictions. Dealing with the paradox requires intuitive judgment to decide on the best balance to strike between the competing elements in the current situation.
Group decision making, diversity, and consensus can help achieve the best judgment call. But there will always be viable alternatives—and any change in the situation will usually require the judgment to be adjusted. The problem with any intuitive judgment is that different people will arrive at different conclusions because they apply a different frame of reference to the problem.
The final element that makes paradox hard to live with is hindsight. Regardless of the decision made, balancing the competing elements in a paradox involves a compromise and different people will have differing opinions of the optimum balance point.
When circumstances at a later date show there was a better balance point, criticizing the original decision (and the decision maker) is very easy. The 20/20 vision afforded by hindsight rarely matches the uncertain fog that surrounded the possible futures confronting the decision maker.
Math does not help either; binary decisions have a 50/50 chance of being correct and these odds can be improved by the application of good decision-making processes. A paradox presents a continuum of choice. That means there is an almost unlimited array of possible options and the one chosen is highly unlikely to be the best in hindsight—the best outcome one can hope for is one that is reasonably close to the optimum.
This type of decision presents a real challenge to trained engineers and technical managers who expect to find the right solution for every problem.
Generally, at the technical level, there are correct solutions. But, if not, in most cases you know a decision is needed and can choose the lesser of two evils.
Good managers decide—lucky ones get it right (and you can usually correct wrong decisions).
The further up the organizational ladder you move, the more you will be exposed to paradox. Every decision you make to balance the competing elements in a paradox will be open to criticism.
It’s a tough place to be. How would you deal with a paradox in your environment?