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?
By Kevin Korterud
I experienced my first agile project nearly a decade ago. At the time, agile was still an emerging concept. I remember thinking there were all sorts of activities going on that I had never seen on any of my projects. People were standing up for meetings, marker boards were filled with things called “stories” and delivery moved forward under the framework of a “sprint.”
At the center of this whirl of frenetic activity was a person who the team called a “scrum master.” At first, I thought this person was a project manager. But they were doing things that were outside of the traditional project management realm.
Since that first experience, agile has matured and continued to grow in popularity. This trend prompted me to examine the evolving role of the scrum master in complex agile delivery environments. Here are my observations:
1. Agile Delivery is Becoming Mature
Agile delivery teams used to function within isolated pockets. But, as the use of agile—as well as the size and complexity of solutions being delivered—grew, new methods, such as SAFe®, were developed to help orchestrate agile delivery across an organization.
With agile becoming more common in organizations as a delivery method, the overall need for scrum masters’ general process advice diminishes. Agile teams over time—as well as with the support of enterprise framework methods—will become more self-sufficient, which reduces the need for some of the current activities performed by scrum masters.
2. Higher Engagement and Direct Accountability
One of the guiding principles for scrum masters is that they are not supposed to intervene with the team and are not responsible for delivery outcomes.
While a focus on process advice was essential during the early days of agile, today’s larger and more complex solutions demand that delivery quality issues be identified as soon as possible. In addition, there is also a need to ensure on a more frequent basis that the solution being created will yield the desired business outcomes.
Given its proximity to agile delivery teams, the scrum master role is positioned to leverage a higher level of engagement and accountability. In addition to traditional agile process advice, scrum masters should also serve as a durable checkpoint for both delivery quality and alignment to business outcomes.
These checkpoint activities would include reviewing user story quality, monitoring non-functional requirements and checking solution designs against business needs. As other roles in agile delivery possess some form of delivery accountability, the scrum master must also become more engaged and accountable in order to remain relevant.
3. Emerging Project Managers Becoming Scrum Masters
While scrum masters are not meant to be project managers, that notion is preventing project managers from becoming scrum masters, especially earlier in their career. Emerging project managers invariably have some form of solution delivery experience. They know what makes for sound requirements (especially non-functional), designs, testing, quality and implementation plans.
As the level of complexity and scale increases with agile delivery, so does the need for some form of delivery oversight at the agile team level. With the scrum master position in their repertoire, teams would have developed competencies and know-how for scaled agile delivery, release train engineer, program manager, etc.
Scrum masters have played an essential role in the growth and adoption of agile as a practical means of delivery. Their direct interactions with agile delivery teams create a unique opportunity to expand their influence in generating valuable outcomes for end-users, consumers, customers, employees or suppliers. To do so, they need to further extend themselves— both in terms of skills and engagement—to remain relevant in today’s complex delivery environment.
How do you feel the scrum master role has evolved? Are newly minted project managers the scrum masters of tomorrow?
Imagine this scenario: You are the project manager of a new, strategic project of your company. Excited, you prepare the necessary documents and schedule the project's kick-off meeting.
The kick-off meeting seem to be going well, until you start presenting the necessities and you notice resistance coming from functional managers in ceding their resources.
And it’s only then you realize your mistake: You should have invited the project sponsor to the kick-off.
Kick-off meetings, which should take place between the end of the planning stage and the beginning of implementation, are of paramount importance to the success (or failure) of a project. And you must prepare.
For the project manager, the kick off is a great opportunity to ensure that your stakeholders are identified, to demonstrate that there is a common gain in the success of the project, to map out the stakeholder predispositions and to ensure that their respective roles are understood.
Here are four things to keep in mind:
1. The Invite List: You must have the other relevant stakeholders in the room—functional managers, the customer of the project product and all those who can have an influence, either positively or negatively.
2. The Meeting Infrastructure: The size of the room, amenities, coffee break and everything else that make the environment appropriate.
3. The Presentation: The kick-off meeting will be your moment to demonstrate that the project is well planned with mapped risks. But, keep your audience in mind. For example, the sponsor, usually an executive with no time to see the details, will be present at this meeting. Make your presentation concise and objective by showing that you have a clear vision of where you want to go.
4. The Sponsor: The great benefit of the kick-off meeting is to get commitment to the development and success of the project. Without it, the project manager always runs the risk of having their needs not met. This is where the essential participation of the sponsor comes in. He or she typically has a politician's nature.
Even though it is up to the project manager to conduct the meeting, it is essential that, soon after the welcome is given, the project manager gives the floor to the sponsor. They can use their position within the organization to "suggest" to those involved to give their support, resources and conditions to the project manager on behalf of the expected results of the project. With the sponsor message given—even if he or she leaves right after they speak—there is a greater chance that everyone else will understand and support the project and that will make the rest of the meeting easier for you.
By Wanda Curlee
Recently, my doctor’s office was attacked with ransomware—potentially causing a major safety issue.
Think about it: What happens if you have a life-threatening illness? All the medical records, including any tests and results, are no longer available. How can the doctor treat or even advise patients without that information?
For instance, a relative of mine recently had blood clots. To diagnose the issue, doctors performed a special blood test with the results delivered to the doctor within an hour. Had the doctor’s office been hit with ransomware, the results would have been lost—and there would’ve been a high probability of death.
Artificial intelligence (AI) and the number of devices that are now connected to the Internet of Things (IoT) heighten the risk of hacking—and the potential devastating effects.
So, how does this affect project management professionals? Project managers must understand that hackers are a reality and they must ensure that their team has the necessary training.
Program managers should establish the security protocols for all projects in the program. Each project will determine the security within the bounds of the program’s processes.
At times, the program manager may have to determine if security needs to be linked between the various projects. The program manager would need to monitor all protocols and make sure that program-level personnel coordinate the activities between the projects.
How does this affect the portfolio manager?
The portfolio manager needs to understand the company’s industry, the strategy objectives and the project/program landscape. At times, the portfolio manager may even have to present safety precautions as it relates to the industry’s IoT and AI to senior executives. By presenting the information, senior executives may alter a strategy or advise the portfolio manager to include security for IoT and AI in business cases.
And remember: In the future, project management tools may include IoT and AI. Can you imagine if a hacker were able to adjust settings, wipe out projects or use ransomware to block all access to project information that’s stored in the cloud?
This could be devastating. Let’s face it—a company without projects is a dead or dying company!
How are you ensuring hackers don’t devastate your projects or those of your customers?