by Christian Bisson, PMP
A scrum master is an essential part of an agile team. However, it seems their role is often underestimated or misunderstood. In this article I’m hoping I can shed some light on the value they bring.
How People See Them
Here’s what I’ve heard over time:
Elves of happiness
Since scrum masters want teams to perform well, they want to make sure team members are happy. That sometimes makes others think that all scrum masters are trying to do is to make everyone happy without an actual purpose behind it.
Since scrum masters often talk to the team and gather information about the status of a project, they are often mistaken for coordinators—people tasked with giving a status report to the product owner or taking notes during meetings.
Some people simply have no clue what scrum masters do, thinking they are an overhead that could be removed without any impact because they don’t actually “produce” anything.
What They Actually Do
Help teams grow
One of the scrum master’s main tasks is to educate the team with agile principles, but also to help the team become self-sufficient. In a way, their main duty is to actually become useless as the team becomes more mature.
Scrum masters can do so by sharing agile knowledge and by coaching teams as they go through retrospectives where the team is motivated to talk about how they can improve.
There are so many different roadblocks that can reduce a team’s efficiency—whether it’s poorly defined requirements, inefficient meetings, lack of documentation or communication, or conflicts. A scrum master can help tackle anything that might slow down the team.
Keep the focus on the right place
Not being hands-on in projects allows scrum masters to have a different point of view that allows them to re-focus teams when needed. Whether it’s toward the developers and their commitment to the sprint, or product owners and their focus on a product’s vision, scrum masters make sure to remind everyone where their effort should go.
It can be hard to quantify a scrum master’s usefulness since they do not actually produce deliverables. But having experienced an agile project both with and without a scrum master, I can vouch for their role. They bring so much on a day-to-day basis to the teams they work with, which in turn brings quality products to clients.
Have you experienced working with scrum masters? What do you think is most important about their roles?
By Ramiro Rodrigues
In my last post, I shared tips for closing external projects. Now it’s time to tackle internal efforts.
As part of this discussion, it’s worth remembering that PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not differentiate between the origin of the customer (internal or external) for the scope verification process.
So even if a project is internal, project managers should obtain acceptance and have at least one approval by the customer in order for the project to be formally closed.
A crucial question to consider: What does your organization's project methodology say? Are you required to get a form signed to show formal acceptance at the end of the project? If so, the good news is you’re closing process is outlined for you.
It gets complicated when you’re not required to sign a formal document or there is no defined methodology for closing an internal project. It creates a great organizational trap for project leaders as projects that are not formally completed tend to repeat the phoenix fable: a project is resurrected over and over again with new work requirements because there is no record of a signed agreement signalling the completion of the work.
Imagine having to re-run a project months—or even years—later when there are no more resources, schedule or budget available to execute the remnants that emerged? On top of this, you’re probably already involved in other assignments, and you may not even remember the full context of that project.
The most effective strategy for not falling into this trap is to produce an informal document of acceptance—a simple text that describes the macro deliveries of the project scope and send your customer a hard copy or email copy. But be careful to include a text that makes it clear that the parties (you and the customer) agree that the deliveries quoted have been made to the desired quality.
And make sure you receive acknowledgement—even a simple “okay” response will be sufficient to file the document and to protect it from unwanted resurrection.
How do you ensure internal projects don’t come back to haunt you in your organization?
By Jen Skrabak, PMP, PfMP
There’s great news for the profession: According to PMI’s latest Job Growth and Talent Gap report, there will be a need to fill 2.2 million jobs globally each year until 2027, growing to a total of 88 million project management jobs in all. Moreover, much of the growth is outside the United States—in places such as China, India, Brazil and Japan.
Project-related job growth is expected to be 33 percent overall, with health care (17 percent), manufacturing/construction (10 percent) and information services/publishing (6 percent) representing the top three industries.
How can you position yourself to take advantage of these trends? Here are three things to work on.
1. Get a Certification
Although certification by itself doesn’t guarantee that you will be hired, it does mean that you have demonstrated knowledge and experience in project, program or portfolio management. There aren’t many PMI Portfolio Management Professional (PfMP)® credential holders out there, so obtaining this certification will help set you apart.
But, instead of viewing the PfMP certification as the goal, plan to take it as a journey. If you find that you don’t have the requisite experience, how can you position yourself by taking volunteer roles to gain the experience?
Career development should be a joint responsibility between you and your manager. You should express the desire and develop the knowledge to grow your experience in certain areas, and your manager can work to open up opportunities to help you practice your knowledge.
Work on delivering strategic initiatives, driving change and providing innovation consistently and reliably. It’s not experimenting, but actually delivering—first on a smaller scale, then on a larger scale.
For portfolio managers, for example, you may start by managing the portfolio of a department or product, then move to an entire business unit, segment or product line, and finally on to an enterprise level.
There are three key areas to grow the depth and breadth of your experience:
1. Strategic alignment: Go beyond understanding the strategy and proactively work to translate that strategy into specific initiatives. This can be done by defining the business cases, developing multi-year roadmaps or translating high-level concepts into specific projects that will deliver the result, benefit or transformation promised.
2. Benefits realization: This starts with validating the business case and ownership of the benefits, and is typically realized three to six months after the project/program delivery via operational budget savings, reductions or reallocations. Few organizations realize the benefits because they are often too optimistic in the upfront business case and fail to follow through by ensuring that operational budgets reflect the promised savings or headcount efficiencies.
3. Project/program delivery: The foundation of portfolio management is good project and program execution to deliver the product, service or result on time, on budget and per the scope. It doesn’t matter if it’s agile, waterfall or hybrid. Although the portfolio manager may not be responsible for the delivery, the delivery affects the portfolio value. Ensuring that the portfolio value is realized means ensuring the project or program was delivered effectively and efficiently regardless of the methodology.
3. Communicate Effectively
Working on the portfolio level means that you’re communicating a vast amount of information—anywhere from 15 to 50 projects and programs—in an actionable way to executives. I’ve had executives tell me, “Don’t tell me what’s going right, tell me what’s going wrong and how to fix it.” Your role is to remember the four “C”s—clear, concise, compelling and credible. Be to the point, tell the story and build trust with a clear plan of action to fix any potential issues proactively.
By Linda Agyapong, PMP
I received a lot of interesting feedback on my last post, “What Defines Project Success,” which has necessitated a follow up.
For those who missed the discussion, Aaron Shenhar et al. summarized it perfectly by saying there is no one-size-fits-all definition for project success. Instead, it’s based on the philosophy of “how different dimensions mean different things to different stakeholders at different times and for different projects.”
Every project is different and hence could have different success criteria. These were the exact same sentiments that folks shared in the discussion on my last post. This time we’ll dissect the concept of project success by breaking down some of the buzzwords surrounding it.
Project managers Jim, Mary and Alex (the same characters from our prior discussion), entered into a high profile kick-off meeting with some Fortune 500 clients regarding an upcoming million-dollar project. When the floor was opened for the clients to ask questions, they unanimously said that nearly 50 percent of the discussion went over their heads because all they could hear were buzzwords.
These buzzwords were “project success” vs. “project management success” and “project success factors” vs. “project success criteria.” The clients could not figure out if they meant the same or not. Let’s help Jim, Mary and Alex break down these buzzwords to their clients based on recent research I performed.
Project Success vs. Project Management Success
Terry Cooke-Davies embarked on an empirical study to identify the factors that are critical in obtaining successful projects after stakeholders had been disappointed with the project results that were being obtained. His study was to address the following three broad concerns:
· The factors that make project management successful
· The factors that make projects successful
· The factors that make projects successful on a consistent basis
Although his three concerns may appear to be intertwined, Anton de Wit provided a distinction: Project success identifies factors that help to attain the overall objectives of the project, whereas project management success focuses on addressing some of the project’s constraints (including time, cost and quality) within the project.
Based on this understanding, Mr. Cooke-Davies concluded that there is a cycle of individual success (such as an individual’s leadership style), which leads to corporate success that later transforms into corporate best practices. As such, once these best practices are consistently applied, it could lead to making projects successful on a consistent basis.
Project Success Factors vs. Project Success Criteria
In their research, Ralf Müller and Kam Jugdev argued that project success factors identify the specific elements within the project “which, when inﬂuenced, increase the likelihood of success.” They added that these are the independent variables that enhance the success of the project. And Mr. de Wit described them as “those inputs to the management system that” directly or indirectly lead to the project’s success. (Can you name some specific examples?)
Conversely, Dr. Müller and Dr. Jugdev explained that project success criteria are the measures (or acceptance criteria) by which the final outcome of the project will be judged, i.e., whether the project is successful, challenged or a failure. They added that the project’s success is measured by these dependent variables. (Can you name some examples?)
So there you have it! Are you enjoying this ride so far?
In my next post I’ll tie this concept of project success to the stakeholder. Until then, I’m interested to get your perspective on this topic.
Understanding Expert Judgment
By Lynda Bourne
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) uses the concept of “expert judgment” in most of its processes, but only has a relatively brief description of the concept. It describes expert judgment as “judgment based on expertise appropriate for the activity being performed” and advises, “such expertise may be provided by any group or person with specialized education, knowledge, skills, experience or training.”
This description leaves three questions:
Obtaining the expertise necessary to arrive at a wise judgment is not the exclusive responsibility of the project manager—you do not have to be the expert! However, the project manager is undoubtedly responsible for the consequences of any judgments that are made.
Instead, project managers should focus on knowing how to obtain the necessary expert advice and how to use that advice to arrive at the best project decision.
Finding an Expert
The first challenge in applying expert judgment is identifying the right people with the right expertise to provide advice.
By definition, an expert is a person whose opinion—by virtue of education, training, certification, skills or experience—is recognized as holding authoritative knowledge. But this definition is subjective and different experts will frequently have very different opinions around the same question or set of facts.
Also, as the Dunning-Kruger effect explains, people with limited knowledge are often absolutely certain about the facts.
Experts, however, being more cognizant of what they don’t know and having the knowledge to appreciate the complexity and depth of a problem, will frequently only provide a probabilistic answer, such as, “I would suggest this option, but….”
The decision-maker must ensure that the information brought into the judgment process is the best information—not the information that is advocated most loudly.
The organization needs to make information available to its managers about the sources and types of expertise available, and the location of useful experts. This information needs to be updated on a regular basis and be accessible.
In the context of expert judgment, judgment is an action verb—it is the ability to make considered decisions or come to sensible conclusions based on information and knowledge derived from the application of expertise. Consequently, while the project manager can, and frequently should, seek expert advice to help inform his or her judgment, ultimately the considered decision that comes out of the judgment process is the responsibility of the project manager.
The defining competence of every good manager, project managers included, is their ability to make effective and timely decisions. The challenge is balancing the decision’s importance, the timeframe in which the decision is required, the cost (including opportunity costs) accrued in reaching the decision and the availability of the resources used in the decision-making process.
The key elements of effective judgment are:
The judgment portion of expert judgment is part of the individual manager’s skill set. Their innate abilities should be supported with training and a culture that rewards a proactive approach to deciding.
Making an Expert Judgment
Bringing expertise and decision-making skills together to form an expert judgment works best in a structured process. PMI’s publication, Expert Judgment in Project Management: Narrowing the Theory-Practice Gap, outlines the framework:
When significant decisions are needed on a regular basis within the organization, standard operating processes should be defined to reinforce the practice of obtaining an expert judgment using the organizations knowledge resources.
How do you go about making expert judgments?