By Giampaolo Marucci – PMBOK® Guide – Seventh Edition Development Team Member
In some languages there is no direct translation of the English word “accountable.” For example, in Italy we translate it as “responsible.” That is, in Italy, we translate “accountable” and “responsible” with the same word: “responsible.” But we know, also in Italy, that “accountable” and “responsible” have different meanings.
In Italian, we interpret responsibility as the act of taking charge of the execution of work that someone asks for. Accountability is the awareness of paying someone for damage caused by wrong decisions or getting the reward for good decisions. Accountability requires that the accountable people respond to any of the activities delegated to responsible people. Responsibility does not include accountability, while accountability can include responsibility. In both cases, someone is responsible or accountable to someone else.
Historically, accountability for a project has been assigned to a single person inside a context. For example, a project manager is usually accountable to the Sponsor for the success (or lack of success) of the project. While the project manager may delegate responsibility to members of the project team, the project manager maintains accountability. But, looking at how some organizations have been structured during the last couple of decades, in some cases, accountability in a project, product, or service to customers or the public, has been assigned to more than one person. In the Team Performance Domain in the PMBOK® Guide–Seventh Edition we refer to this as shared ownership. That is, there are contexts in which the outcomes from the work are assigned to the more than one person, or the team as a whole.
This can be the case with a high performing team that is stable, empowered, and self-organized. Ownership for the outcomes from the project are shared by the team as a whole. Stable teams move from formation and grow into a high-performing team by passing through four stages: Forming, Norming, Storming, Performing. The length of time for the team to grow into the performing stage can vary based many variables. (You can refer the Tuckman “Team development model” for detail on this. The PMBOK® Guide refers to it in the section “Models, Methods, and Artifacts” of the PMBOK® Guide - Seventh Edition.) Following, you can see some of the characteristics that are usually present in high performing teams where ownership can be shared:
Having such a performing team, an organization can assign them a project and let them self-organize to decide their way of working, choose and evolve their processes and practices to adopt inside the project, and configure processes and practices based on the organization’s policy. The organization can give to the team, as a whole, rewards or penalties for success (or lack of success) of the project.
In other words, the organization can let the team not only be responsible for the work but also own the outcomes to the organization. High performing teams with shared ownership is described inside the Team Performance Domain in the PMBOK® Guide–Seventh Edition.
by: Jesse Fewell, PMBOK® Guide–Seventh Edition Development Team member
In our previous post, The Latest Evolution of the PM Role, Part 1, we explored how the project manager role has become vastly more sophisticated than when the profession first defined it decades ago. In particular, we revealed that the upcoming PMBOK® Guide –Seventh Edition will challenge project managers to leverage the broader project team in their practice, more than they ever have before.
In this post, we answer the next obvious question: Fair enough, but what does that look like, and what do I do? To find that answer, we begin by zooming out to a bigger perspective.
It’s official: Project Management is now a team sport.
In the 20th century, projects were closer to the post-industrial and information ages; they were more likely to be categorized into certain business functions, departments, and vendors. However, more recently the complexity of our projects are increasing. As such, project complexity has more frequently become larger than any single mind to capture and contain. To overcome these challenges, Project managers across the world are more and more leveraging project team members in the practice of project management activities. This allows project managers to scale their impact and effectiveness by expanding beyond the physical limits of their own personal capacity.
More than just a sub team. For years, we’ve discussed a similar idea with the concept of a Project Management Team, as “The members of the project team who are directly involved in project management activities.” However, the last two decades have gradually eroded the distinction between the overall Project Team and a more specialized inner circle “Project Management Team.”
In fact, the PMBOK® Guide has reflected this evolution. The document’s mention of the term “Project Management Team” has decreased from an average of 27% of the pages (3rd Edition), to 14% (4th Edition) to 9% (5th Edition) to 5% (6th Edition). Today, there is no longer a discernible distinction on most projects, most of the time, as to who does and does not perform project management skills and activities.
When you think about today’s workplace, it starts to make sense: A tech writer may be the one who coordinates interviews for a new user manual. A senior graphic artist may be collecting the estimates from junior colleagues. A junior chemist may be the one to record meeting minutes, since she’s the one who best understands what is signal versus what is noise.
So then, what does a project manager do uniquely and distinctly?
Functions, Not Roles. The draft of The Standard for Project Management now elaborates the project manager as “The person assigned by the performing organization to lead the project team that is responsible for achieving he project objectives.” That emphasis on leadership sounds to be a much more strategic description than the traditional expectation of being the one ultimately and singularly responsible for getting work done.
The draft Standard goes on to say that leadership is manifested by performing a variety of “functions.” The functions include things like Oversight & Coordination, Facilitate & Support, or Provide Resource & Direction. But it also says, “Functions related to the project can be fulfilled by one person, by a group of people, or combined into defined roles.”
That is, it doesn’t have to be you. Rather than limit a project managers’ potential impact to a single role description, the standard now reflects the sheer diversity of projects in the world today. The draft Standard goes on to say, “The needs of the project, organization, and environment influence which functions are used on a project and how those functions are carried out.”
Context is king. As long as you ensure good management is being performed, your context will determine what you alone, as the project manager, should do or not do.
The Bottom Line
So, what’s the bottom line here? Today’s project world is more complex and dynamic than ever before. That has led to a permanent change in the state of who does what in the world of project management. No longer can we say that a project manager does X on most projects, most of the time. Instead, you have the opportunity to have more impact on more people, by inviting them to the project management table.
by: Jesse Fewell, PMBOK® Guide–Seventh Edition Development Team member
Over the last few decades the world of work has changed. The COVID-19 pandemic was not a cause of this disruption, but a reflection of it. It revealed just how interconnected and fast changing we now find our global economies, societies, and, yes, our projects.
In response to these changes, project management has also evolved. Recently, members and staff of the Project Management Institute (PMI) traveled across the world asking project practitioners how they have responded to these new challenges. Those investigations are reflected in the upcoming PMBOK® Guide–Seventh Edition and include some interesting patterns of modern project management practice. This post digs into one of those recurring dynamics: The “Who” of project management.
The Project Manager role has become more sophisticated
First, we became established. As the 20th century came to a close, the discipline of project management was formalized as a noble profession, with the Project Manager as the archetypal practitioner of the profession. We had established our associations (e.g. PMI®, IPMA®), our standards (e.g. The Standard for Project Management, Prince2®, ISO21500:2012), and certifications of practice.
Indeed, our sense of ownership and professional pride are reflected in the 2004 definition of the Project Manager as “The person assigned by the performing organization to achieve the project objectives” (PMBOK® Guide–Third Edition glossary). We project managers were the center of gravity. We had our act together. We were becoming pivotal to any initiative’s success.
Then, we became more curious. In 2009, PMI launched its virtual communities program. This new technology platform helped streamline knowledge sharing among its members where webinars, blogs, articles, etc. were easily shared, especially across different industries from banking to healthcare. Moreover, the newly flexible community charter process allowed several formal groups to self-organize around project management topics like agile methods, social media, learning & development, and innovation. To overcome modern challenges, project managers were becoming even more continuous learners.
Soon, we became more versatile. In 2013, the newly published PMBOK® Guide–Fifth Edition formalized the expectation that “Effective project managers require a balance of ethical, interpersonal, and conceptual skills.” It also introduced a checklist of eleven such interpersonal skills. But the changes didn’t stop there. Just a couple of years later, PMI introduced the Talent Triangle, a framework that required PMI credential holders to grow in project management skills AND interpersonal skills AND strategic business skills. While the Guide formalized this emerging expectation, the Talent Triangle operationalized it: To overcome modern challenges, project managers had to become more than just calculators of critical path or coordinators of resources. We were becoming practitioners of diverse leadership skillsets.
Today, we have become role models. The upcoming PMBOK® Guide –Seventh Edition reflects a new trend in the project manager’s quest to overcome modern challenges: we are leveraging other people, departments, vendors, and stakeholders in the broader project ecosystem. This concept is captured as a “system for value delivery” in The Standard for Project Management. It challenges us to think of a project as more than just unilaterally getting work done; it is the interconnection of several pieces of a larger whole. Those vendors, stakeholders, executives, sponsors, line managers all need us to show them the way, without getting in the way. The new standard goes on to say, “Regardless of how projects are coordinated, the collective effort of the project team delivers the outcomes, benefits, and value.” That means we can be the ones to show how each stakeholder’s part fits within and contributes to the larger whole.
So, what do we do?
Hopefully you can see the trend: The role of project manager has become vastly more sophisticated than when the profession first defined it decades ago, and it still continues to evolve. But that leaves a key question: Okay, so if we are supposed to leverage the broader, extended Project Team, what does that look like? We’ll explore that in part 2, posted next week.
by: Klaus Nielsen, PMBOK® Guide-Seventh Edition Development Team member
Tailoring the project development approach is a bit like tailoring clothes based on individual measurements—we plan and execute projects according to individual project objectives and the characteristics of the project. Since each project is unique, it is important to understand that project management processes will likely need to be adjusted to ensure the project’s success. Project customizations consider that project management processes are not “one size fits all,” which means that there will be many times where processes need to be adjusted to ensure project success.
In many ways tailoring is reminiscent of the work of a tailor, which requires dexterity, color sense and a good form perception. There are other project management competencies; but, like the tailor, there is also the need to help the client / project choose the right model and fabric. We project managers take project objectives and work out a pattern that needs to be cut, stitched and worked on. A tailor’s customers also have measurements other than standard sizes, where a sample model may need to be sewn in canvas and customized before it is cut into the right, expensive fabric. Most projects are not “standard off the shelf.” As a project manager, you also do preparatory work, perhaps conducting an analysis or Proof of Concept. A tailor sews in both thin and thick materials —primarily using sewing machines but also by hand if needed. As project managers we work with traditional and agile project development models, or a combination (hybrid). No clients or projects have completely standard measurements (objectives) and none of them are exactly alike. They are unique, which require project manager’s and the tailor’s best choices and customizations.
When we tailor, it is because what we must do is different from what we have just made (i.e., the scope or amount of what the project should contain is quite different). One project may be a metro building in the capital, while another is an office building in a housing district. Yes, these are both buildings, so a large part of the same toolbox can be used, but these are two vastly different projects, so they must be tackled in different ways. It is not much different than a tailor’s customers: one wants a whole winter wardrobe, the other just a small black dress for a big family party.
The development approach must be individually tailored based on the context, but we also need to get the best result and, in the process, eliminate time spent on unnecessary tasks. The scope of the task affects the resources we need to solve the task, how we approach the task, and the uncertainties associated with the work and ultimately the cost and result for the customer.
As a public contractor, I may want to run an EU tender to buy an IT system, which includes a number of processes, but then I have to implement the IT system in the organization and ensure that every stakeholder derives benefit from the IT system, which leads to tailoring even more processes. In this case, the complexity changes from one tender and implementation to another, which has far higher complexity, including other competencies that need to be used.
A tailor may need to do cutting, alignment, sewing and design, while the project manager’s processes are about initiating, planning, execution and closure, but the message is the same. Regardless of which task is to be solved, it is often advantageous to tailor processes to only what is needed.
Tailoring is difficult to outsource. It requires testing and adjustments along the way before delivering the finished product. Back to our tailor example, if a dress was a dress and all women had the same size, taste, finances and the like, then perhaps it doesn’t matter who does the tailoring or if tailoring is done at all. But these personal attributes are not fixed, and each individual is unique. The same goes for projects. Projects have different funding models, varying time demands, multiple expectations from stakeholders and uncertainties associated with the work processes. Therefore, it is important to customize the development approach based on the context. Tailoring the development approach based on the context is important to enable the project to meet expected outcomes. The following are just a few of the considerations when tailoring the development approach based on context. Remember, no two projects are not the same, but tailoring:
By Giampaolo Marucci – PMBOK® Guide–Seventh Edition Development Team member
Activities executed inside a project are about project management: planning, estimating, measuring, realizing, communicating, integrating, coaching, motivating, tailoring, etc. These activities are guided by the principles in The Standard for Project Management. Principles can provide a cultural framework of behaviors that lead to a common mindset useful for performing the work inside the context of the project.
Principles guide behavior within the Project Performance Domains of the seventh edition of the PMBOK® Guide. Performance domains describe the collection of activities or functions that influence project performance. They provide guidance for decision making with a focus on enabling desired project outcomes. Together, the principles and performance domains serve all of the people involved in project activities.
The project team, one of the critical stakeholder groups in a project, executes the work of the project tailoring the development approach and the selection of models and methods.
In the past, it has been common thinking that project management knowledge needed to be owned by project management practitioners. But who is a project management practitioner inside a project? We could say that a project management practitioner is anyone who executes some project management activity and who has some responsibility for some result of the project. From this point of view, any team member of a project performs some portion of the project management activities.
The type of project management activities, and the level of details of those activities, that any team member can do depends on several factors, such as the framework of project management practices selected; the organization’s policies, requirements, and processes; or regulatory requirements. For example:
Therefore, project management activities can be executed by different people in different organizational roles, including members of the project team.
In projects where the project team can be much more self-organized and empowered, people in the project team need to know what models, methods, processes, and practices can be considered, to which project performance domain they are related, and how the team can be effective in delivering project outputs that enable realization of intended outcomes. On the other hand, in a project where the project team needs to be guided in the details of the work, the project team members need to know why they are following the indicated models, methods, practices, and processes, and have a common vision upon which to tailor the work across all of the performance domains. In all of this, the principles of project management enable a common mindset that guides behavior and decisions.
For these reasons, independent of role titles, organizational structure, or a particular project development approach, the project management principles serve all people in a project as a foundation upon which the work of the project proceeds. The Project Performance Domains serve all people in a project as a structured system for areas of focus for the work of the project, decisions, and actions guided by the overarching principles. So, it is important that the members of the project team are coached or trained on the Project Management Principles and Project Performance Domains. I believe these Principles and Performance Domains can serve as the foundation for all members of the project team and can lead to improved project outcomes.