By: Cynthia Dionisio, Co-leader PMBOK® Guide–Seventh Edition Development Team
In past blogs, various members of the PMBOK® Guide–Seventh Edition development team and community have talked about the evolution of The Standard for Project Management and you have heard from team members about some of the thoughts around the principles that comprise the concepts for the Standard. Recently, Maria Cristina Barbero, Standards Member Advisory Group member, discussed the concept of a Body of Knowledge. One of the sections in the Guide to the Project Management Body of Knowledge is Project Management Performance Domains. This is a new approach in the PMBOK® Guide. Past editions of the PMBOK® Guide used Process Groups and Knowledge Areas as the organizing concept. In the Seventh Edition we are shifting the focus to Performance Domains.
If you are a bit of a Standards geek like I am, you may have noticed that The Standard for Program Management and The Standard for Portfolio Management are comprised of performance domains, so this is not a new thing in PMI’s standards. As we communicate about this shift, I have been asked several times, what is a performance domain? I admit, the term is a bit vague. I struggled with this myself for a while. Here is what The Standard for Program Management says:
Program Management Performance Domains are complementary groupings of related areas of activity or function that uniquely characterize and differentiate the activities found in one performance domain from the others within the full scope of program management work.
If that doesn’t quite resonate with you, let me share how I think of domains. I think of them as broad areas of focus for project delivery. Think about when you work on a project. You spend time focusing on the outcome or deliverable that the project was undertaken to develop. You spend time focusing on the team. You spend time focusing on stakeholders. These are areas of focus that interrelate and interact with each other within your project. There are times when a situation arises with a stakeholder that you need to address immediately. That situation involves a stakeholder but it also impacts planning, delivery, navigating uncertainty, project performance measurement and other aspects of project work. So instead of thinking about engaging with the stakeholder in isolation of everything else, you think about the stakeholder, the situation and their impacts across the various project work domains.
Domains run concurrently throughout the phases of a project life cycle, regardless of how you deliver value (frequently, periodically, or at the end). If we use the examples above, your focus on the deliverables has to include thoughts about your stakeholders, and your team. But the activities associated with creating those deliverables are different activities than those you undertake in working with your team members. The activities interrelate, but they are different. They are interdependent, and they overlap in different ways throughout the project. However, you can’t work on a project without focusing on deliverables, stakeholders and team members.
There is another aspect of performance domains – they are outcomes focused. Notice that outcomes are different from outputs. As you are likely aware, in previous editions of the PMBOK® Guide the processes culminated in an output, such as a scope statement, risk management plan, stakeholder register, etc. Outputs are fine, but they are not the same as outcomes. Outputs enable outcomes. For example, if we have a performance domain around effective interaction with stakeholders, I would want to know the outcomes associated with that. For example, one outcome might be satisfied stakeholders. I can measure that with surveys, observing relationships and interactions, etc. Each performance domain has measurable outcomes, and the outcomes are different from an output. I might use an output, such as a stakeholder register to enable the outcome, but the stakeholder register is not the most important thing, stakeholder satisfaction is what’s important.
This is a big shift in how we think about delivering projects, so let me summarize it for you:
In forthcoming blogs, you will hear from team members who will share their thoughts on possible performance domains for project management. I hope you enjoy the upcoming series. There is much more to come, so check back frequently.
Busting Standards Myths
Over the past few months, members of PMI’s Standards Member Advisory Group (MAG) and PMBOK® Guide–Seventh Edition Development Team have blogged on the standards transformation journey at PMI and, in particular, observations and thinking around the next edition of the PMBOK® Guide. There is much more to come as the work continues. However, as this work has progressed, we have heard a few observations and rumors. Take a minute (well actually 10 minutes) to watch this video as we bust a few myths. Enjoy!
By Maria Cristina Barbero, PMI Standards Member Advisory Group
The Black Monks, so called in reference to the color of their religious tunics, are monks of the monastic Catholic religious order who follow the Rule of Saint Benedict. This Rule provides some guidelines for monastic life where reading is one of the compulsory activities built into a monk’s very regimented schedule. In the 6th century one of them, Cassiodorus, pushed the practice of copying texts of all kinds over just reading them. Copying texts became an important part of life in monasteries.
So, in the Middle Ages monasteries and monks were hubs of culture. Monks were sharing a seat and desk with other monks in “scriptoria” (open spaces for writing activities) where they were dedicated to conserve the biblical knowledge over a world of wars, famine, and epidemics simply through copying texts. To be honest, it was not just about biblical texts but also grammar and later encyclopedias that constituted the body of knowledge these monks wanted to conserve with their work. And, again, it was not just copying. It was also about adding or integrating these texts with something new they could capture during other monks’ travels. The final aim was to transfer this knowledge to posterity as well as have a base for training young pupils, usually sons of princes, kings, and other nobles.
Let’s focus on how the bodies of knowledge were growing, transforming, and adapting to new discoveries. In medieval Christianity all that was known was represented as a static pyramid having few possibilities of evolution (for example, the Great Chain of Being is a hierarchical structure of all matter and life, derived from Plato and Aristotle, and thought to have been decreed by God). Later, the most common representation of knowledge changed to a tree—the pyramid had been rotated. The tree can expand and evolve. You can add branches and leaves. Seeds generate new trees.
Nowadays a body of knowledge is intended to be a complete set of concepts, terms, and activities that make up a professional practice, as defined by the relevant learned society or professional association. These bodies of knowledge in general evolve in accordance with the “tree model.” The body of knowledge of project management (PMBOK® Guide) is defined by PMI “as a term that describes the knowledge within the profession of project management.” PMI recognizes that the body of knowledge of project management has no definable limits and that “no single book could contain the entire PMBOK.” Therefore, PMI developed and published the PMBOK® Guide which is intended to be a guide to this vast body of knowledge.
The PMBOK® Guide has been for years perceived and used by trainers, consultants, and project managers worldwide as a “golden box” where the knowledge of project management was maintained. Since 1996, like other bodies of knowledge, it is a tree that continuously evolves. More content is added periodically to the constellation of knowledge elements that a project manager should know and use (practices, tools, techniques, skills).
The “tree model” survived for centuries. It is just in the last thirty years that things dramatically accelerated the demand for a new model of representing knowledge and bodies of knowledge. Change enablers include the web, user media and devices, micro-computing, 3rd party platforms, Internet of Things, availability of large volumes of data, communications strengthening, and overall the willingness of humanity to share their own experiences and contribute directly to the growth of knowledge in most sectors and industries.
Several new contents are available and today each single body of knowledge potentially collides with other bodies of knowledge and requires a representation that is a web where new branches of the original tree draw over branches of other trees.
Therefore, the evolution of the PMBOK® Guide had to be rethought and that’s what PMI and volunteers did over the last couple of years. My colleagues already introduced areas of change in the PMBOK® Guide and in The Standard for Project Management.
What I want to remark on here is my thoughts on the intrinsic why of this big shift that is not a whim but, more than ever, a need. PMI cannot evolve the body of knowledge following a “tree model” simply adding branches and leaves to the body of knowledge, but must open it to future evolutions in a modern multidisciplinary and digitized context. The structure has to support the evolution of knowledge while at the same time providing a framework that better represents the interaction of a system of systems that influences project performance.
I think this approach to the evolution of the PMBOK® Guide will enable the reasoned and appropriate maintenance of the evolving knowledge and practice of project management.
by Maria Isabel Specht, PMBOK® Guide-Seventh Edition Development Team member
When I retired from the petroleum industry after 31 years as a researcher and project manager in Venezuela’s hyper-inflated economic conditions, it would have been easy for me to accept my son’s offer to support me and stay at home. Instead, I took on the new phase of my life with a curiosity that has left me continuing to develop as a project manager, an educator, and even a mom and a grandma. That journey, and the growth I’ve experienced, have inspired me to develop a new project management mantra: projects are led by people, done by people, and made for people.
I entered my retirement with an intellectual curiosity that led me to pursue education in neuro-linguistics programming (NLP). I realized that I could still improve the way that I communicate, even after a full career in a competitive industry. I learned to develop active listening skills that allowed me to do something I call “designing my conversations.” This means I work to listen and respond in my interactions, and to understand the unique circumstances of the people I communicate with. It also means I focus on achieving specific goals through my conversations. My colleagues at NLP School noticed my interest and recommended I consider additional training as an ontology coach. I began to have a realization: communication and project delivery are deeply related.
I began applying more of my communication tools in project environments. With the help of two philosopher mentors, I envisioned projects as a net of conversations. In these conversations, people are bringing their own backgrounds, their emotions, their fears and their personal goals. By understanding the people’s motivations, I am able to listen and understand better–and this has led me to better project outcomes. When project leaders view their projects as nets, they can coordinate efforts and understand impacts across the project. They become more effective.
On the other hand, when I looked into projects that showed no success, I considered that there must be something we were not considering. I asked myself, “What if we are not considering that a main focus of projects is people?” The success of projects is based on people–and people can be successful if they have empowering conversations.
As project leaders, we need to endorse our team members by actively listening to them and valuing them. We have an opportunity to create this environment on our teams, which will increase the team’s effectiveness and lead to better outcomes. Even though we are in a hostile economic environment in Venezuela, we are still having fun on our project teams because we have a sense of community, we are working in collaboration, and we deserve it.
I see messages about the communication processes – emitters and receivers, but what about the emotions? I propose that a fundamental principle of project management is to nurture a project environment that values individual commitment, collaboration, and communication.
Now, I work at the university level as a “divergent teacher”—I do not deliver a master class of lectures to my students. I teach my students, aspiring mechanical engineers, through projects. And as I teach them, I encourage them to apply active listening techniques and to design their conversations. Sometimes, they apply these skills on our in-class project teams. Other times, they take these skills into their personal lives and report out on communications with their others. I joke with my students that even my son is one of my stakeholders. The next generation of project leaders will be more impactful—and better off—if they are able to navigate in the complex web of project communications using active listening and designed conversations. This leads to the coordination of actions for making decisions, building relationships, evaluating new possibilities, and creating new realities.
By: Maricarmen Suarez, PMBOK® Guide–Seventh Edition Development Team member
Is project management a science or an art? While we could debate this fun question for decades, I think we can all agree that there are elements of both. Our profession continues to evolve with a focus on quality, globalization of reach, and the velocity of change—we have seen it all. But first things first, at the center of it all, we see one thing in common—people. I genuinely believe that it is those human interactions that help us deliver value through project management. Consequently, a fundamental principle of project management seems to be stakeholder engagement.
Anyone that is impacted by changes can be considered a stakeholder. It is critical to define who our stakeholders are, acknowledge their motives and define their engagement, as well as understand their level of involvement and sphere of influence. As a practitioner who is continuously assessing the stakeholder pool, I ask myself daily that old question: “where should I spend my time and energy? With the optimists? The naysayers? Or the ones sitting on the fence?” I’m not sure there is a right answer to that, but my experience has taught me that the best solution is “all of the above.”
The optimist will always have a positive, can-do attitude. They help you move your initiative forward and, depending on their level, they can prove to be an invaluable resource to influence others.
As for the naysayers, it is essential to understand their drivers, i.e., what motivates them? Why are they against the project? What would it take to get them to a middle ground? Is there an unidentified risk, either opportunity or threat, that may have been overlooked? By no means, am I suggesting that everyone can or should be converted to the “right” side of an initiative; but as a project leader, my role is to ensure that everyone has a voice and that needs are met. I guarantee that while the naysayers may never be cheerleaders beaming with support, they have enough to be able to compromise and not derail or stop our initiatives.
That leaves the ones on the fence—those on the middle ground that can go either way but are choosing to stay on the sidelines to see what happens next. These stakeholders are the ones I find myself spending more time and energy with. Simply because I consider them sponges. The fence-sitters feed off of other stakeholders. While I can’t control every channel and every interaction of these stakeholders, I can ensure they have the right amount of information to make an informed decision.
Some best practices I use to proactively engage stakeholders include:
I consider stakeholder engagement a pivotal principle—projects are undertaken by people, for people. As practitioners, we have a unique opportunity to engage and serve stakeholders proactively. As they say in the flight safety briefings, always put your own oxygen mask on first, before helping others.