Viewing Posts by Marjorie Anderson
Nick Clemens, PMBOK® Guide–Seventh Edition Development Team member
As a project manager I find myself immersed in uncertainties and change. People roll on and off my program teams, my management chain changes frequently, and my customer base is in flux. I am a contractor for a larger US Federal Department and even within the US Federal bureaucracy change comes quick and often. I think for large bureaucracies the problem is not change, it’s here and must be dealt with. The problem is adaption and response.
The same is true for projects. Project leaders must adapt and overcome. Our response as project leaders must insure the on-time delivery of our products and services within project constraints. This is how we deliver benefits that create value for our customers and companies alike. And for those who like to deliver incrementally, I’m also talking to you. Implicit in the idea of a Minimal Viable Product (MVP) is the delivery of a benefit that creates inherent value for both the user and the supplying enterprise.
So how do we keep track of where we are going with everything changing around us? To paraphrase the Cheshire Cat in Lewis Carroll’s Alice’s Adventures in Wonderland, If you don't know where you're going, any road can take you there. The answer is to go back to basics. Basic project management principles provide us with a framework to guide us when our projects are troubled. The PMBOK® Guide–Seventh Edition development team is taking just that approach in updating The Standard for Project Management. We are looking at a better way to guide project leaders using a principles-based approach that will allow flexible responses to an environment fraught with change and uncertainty.
So, what’s a project management principle that could help us to navigate our complex environments and keep track of where we are going? It has to do with “systems thinking” and is related to a management principle from the risk area, “work to balance threats and opportunities.” The principle I am thinking of is around the idea of Think Holistically.
Holistic thinking tells us to get out of the weeds, to see the forest for the trees. In other words, as a project leader have a vision for your project. That vision should include your project’s purpose, value to be delivered, impact to the business environment, and its effect on the people involved. Holistic thinking also includes understanding the trade-off space to ensure the team delivers outputs that will drive outcomes. It allows self-organization of work but keeps the pieces integrated. Holistic thinking challenges assumptions and mental models to broaden the possible solution space.
Whether managing a group of work packages to a project plan or integrating a couple of scrum teams to deliver a MVP according to a release plan, the challenge to the project leader is the same—keeping on track to meet our customer’s vision and expectations and delivering outcomes, even if the precise end goal is not fully defined at present. I didn’t say it would be easy. In most cases the days of the practically perfect project plans went out with the departure of Mary Poppins, not in the most recent Disney sequel, but in the original 1964 movie! To say the least, a principles-based approach to project management has been a long time coming.
So, think holistically to keep the focus of your project 100% aligned with your customer’s vision and expectations. Remember as the project leader your job is to deliver and create value for your customers and company. Everything else is in the weeds. The key is to recognize, evaluate, and respond to the dynamic circumstances within and surrounding the project delivery systems as the systems interact and react with each other.
by: Klaus Nielsen, PMBOK® Guide-Seventh Edition Development Team member
Did you know that many organizations have unsuccessfully tried to implement an off-the-shelf, or ready-made, project management methodology and found that it was unsuitable for their projects, their organization, and their level of organizational project management maturity?
This often results in a lot of money, time and effort spent with little return and a decrease in staff morale. The one-size-fits-all approach is not working, because no two projects are the same. Different people, clients, vendors, technologies, cultures, approaches, sizes and such require extensive tailoring.
Designing the delivery approach based on the context of the project, its objectives, stakeholders, and the environment is much more difficult than it may sound. Designing the delivery approach requires tailoring. We use tailoring to our project management methodology with the hope of buy-in from team members. In some cases, a tailored approach produces a more customer-oriented focus, centers on best-for-project approach, and reflects a more efficient use of project resources. It also helps to ensure that when the team agrees to use specific processes, tools, or ceremonies, everyone is aligned, and use is consistent.
But who has not experienced the damage from tailoring not done correctly? I have! It’s when project team members are not using the methodology, independently modifying the methodology, or following the process for the sake of the process.
When we tailor, we have a wide range of options. I tend to look at the processes and see whether it would work or not. Often, I have been faced with too many processes of little value. In some cases, inputs, tools, and techniques may be omitted or changed to make them work within a specific context. Also, when tailoring I examine the level of documentation required, as it’s often a great chunk of work. I want to make sure all project artefacts, documents, and plans provide value — not just documentation for the sake of documentation. Thinking back, if you had to apply everything the same way to all your projects for the last 20 years, that would be a nightmare. Firstly, I rarely do the same kind of projects the same way twice. Secondarily, if I had to do it all over, I would make a lot of changes (hopeful that I have learned something along the way). Think of tailoring as your opportunity to apply lessons learned.
I think it’s difficult to talk about tailoring without touching upon efficiency and effectiveness. Now it becomes slightly trickier. I don’t see one without the other. I know some of you may have concerns about the connotations of these terms, so let me try to explain my view.
Effectiveness talks to providing our customers with value through product delivery and producing the intended or expected result. It is also associated with the results from the actions of the team members and the project manager.
On the other hand, efficiency talks to how we are performing or functioning in the best possible manner with the least waste of time and effort. It is also associated with how things are done.
Who has not heard the following statement: “The fundamental reason why projects are late is because of inefficient use of resources. My job as a project leader is to move our expertise around to tackle as much work as possible, and to do so seamlessly?” In this case, efficiency means getting more work done with the least loss of time, which is done by maximizing utilization. In this case, efficient IS effective. In my native language of Danish, we use the same term for these two concepts.
For others, efficiency is a poison. For them it also means maximizing utilization, which requires that we overcommit and confuse our staff, leaving them no slack to breathe or innovate. To them, efficient is the OPPOSITE of effective. However, that was not the intention.
Just to wrap it up: Design the delivery approach based on the context of the project, its objectives, stakeholders, and the environment. Maximize value, manage costs, develop flow and enhance speed by utilizing just enough process. I think there might be a principle or two in there.
By: Nader K. Rad, PMBOK® Guide-Seventh Edition Development Team member
Once Upon a Time!
There was a policy in one of the companies I used to work for about 20 years ago: “Every procurement activity should be done in the headquarters, rather than in projects’ construction sites”. They believed it was more cost-effective.
One day, I realized that in one of the attempts at cost-effectively purchasing material for covering the joints of concrete sections, the process was so prolonged that the critical concrete work was paused in one of the sites for four days. I was the project planner at that time and I immediately went to the project manager, who simply told me that organizational processes should be respected! I went to the procurement department and realized that we just didn’t speak the same language. So I went back to my desk, called the project site, and asked the technician responsible for that section whether they could buy the material locally. He said they could do it in one hour. The cost? Only about €250 for two weeks’ supply!
I sent them €250 from my own pocket to buy the material and resume work. The company reimbursed me but asked me not to do something like that again, and of course, I kept doing that.
I’m sure you’re thinking about many problems in this scenario: They needed a more proactive project manager, they needed to use “manage by exception”, etc.
One aspect of the problem was that they cared about money (which is fine), but not in the correct way. It’s not only about the money we spend, but also about the money we [can] gain. What we want to optimize is not the cost, but the “benefits ÷ cost” ratio – given that we consider all types of benefits, short-term and long-term, and direct and indirect (e.g., reputation, market reach, and knowledge).
This relatively subjective “benefits ÷ cost” ratio is what we usually call business value, or value for short. We can always ask ourselves whether our selected choice is the one that contributes most to the value of the project/product.
Do you consider value in your decisions?
The other problem is that they were not adaptive enough.
When we talk about adaptation, it’s usually about adapting the product of the project to the environment, which is what happens in adaptive (Agile) projects and is very important and interesting. However, that’s not the only type of adaptation; there’s another one that applies to every type of project: adaptation of our delivery and management approach to their environment.
In my example, those problems could have been prevented if proper planning and risk management were in place. However, for some reason, that level didn’t exist. In such a case, when we see that we can’t fix our planning and risk-management system in order to have the ideal procurement method, we need to change our procurement method to adapt to this situation and prevent bigger problems.
Do you stick to your ideal methods or adapt to the environment?
Another issue with concrete work in that project was that the concrete was going to be exposed in the final product, and therefore, we needed to do some extra work to make sure the surface was clean enough. One day, someone suggested a simpler way of doing that; according to experienced engineers, the quality was much lower, but it was a lot faster and less expensive. So we decided to experiment with something!
The project was for building a central library in a university, and we had access to thousands of end-users! We offered €30 to any student who wanted to join our experiment, and we picked the first 100 volunteers. We had two walls finished, one with each of the two methods, and we asked the students to tell us which one was better. In the end, we found no significant difference in the number of votes for the two methods, and we concluded that the new method was as good as the old one for our end-users, and so we decided to proceed with it.
It happens a lot: Either we spend too much money on an element of the product that doesn’t make any difference for the end-users, or we make it in a way that doesn’t satisfy them.
Isn’t it a good idea to focus on outcomes before outputs and activities?
It doesn’t matter what type of project we have; it seems like we can always ask these three questions in our activities and decision-making process:
If these have the potential to help us in all or most projects, then maybe we’re talking about principles for running projects! Perhaps those principles could be summarized as:
By Vanina Mangano, Standards Member Advisory Group
Back in January 2017, I attended an annual event hosted by PMI for its group of volunteers serving in a leadership capacity. On the very first day of that conference, PMI made an exciting announcement: it was transforming. I remember feeling excitement and curiosity buzzing through the large room of volunteers – no naysayers could be heard, just intent and curious listeners who wondered what changes would follow suit. Even before PMI kicked off its transformational efforts, some critical conversations were taking place behind the scenes that would drive some of the changes unfolding within the Standards community. These conversations would influence the move from process- to principle-based standards. Brian Grafsgaard and Mike Frenette blogged about these changes back in August, and I thought I would follow their posts with some additional commentary and insight regarding why these changes are taking place.
First, did you know that there are various types of standards? Mike already provided a fantastic summary of what a principle-based standard is in his August 28th post. If you missed it, I highly encourage you to read it – not only is it informative, but it was a fun and interesting read! There are three general approaches used to document standards:
Skimming through the three definitions above, mapping the PMBOK® Guide–Sixth Edition to the approach used is not that difficult: it follows the process-based approach. Brian noted in an August 2nd blog post that the standard in the Seventh Edition of the PMBOK® Guide will evolve from a process-based to principle-based standard. The Standard for Program Management first shifted in this direction in its Third Edition and the Standard for Portfolio Management recently followed in its latest Edition. PMI is not unique in going this route; the International Organization for Standardization (ISO) has long used this less prescriptive approach.
Those “behind the scenes” conversations I referred to at the start of this post have been occurring among Standards leadership over the past few years, largely driven by practitioner feedback – arguably the biggest driver for the changes. Specifically, practitioner feedback stressed that the standards must address the full value delivery landscape. The standard in the Seventh Edition of the PMBOK® Guide will aim to do this very thing – document the stable project management concepts that lead to successful outcomes across the full value delivery landscape. This will be achieved through a set of guiding principles that apply across the value delivery spectrum, including predictive, adaptive, and hybrid delivery approaches.
Shifting this direction doesn’t imply that the elements of the “how” fully go away. In reality, more tools, techniques, and approaches exist than can be incorporated in one book. These resources are better collected and delivered through an online tool, which I hear is also in development. PMI will shed more light on that later this year.
Personally, I’m thrilled at this new direction, and I can see alignment with PMI’s 2017 Strategic Plan that was first introduced in the 2017 January leadership conference. I’ve seen my fair share of practitioners misinterpret how to apply the project management processes, viewing the processes as Waterfall-based, to be applied in a literal and / or sequential fashion (to be fair, the concept of “tailoring” can sometimes be difficult to understand when digesting a process-based approach). Pivoting to a broader set of parameters within which we operate as project management practitioners will enable us to better leverage the knowledge and core practices that have made PMI effective for decades.
I hope the larger community of practitioners feels that their voices have been heard through the coming changes. As Brian noted earlier, the profession is evolving. The set of tools we need to be effective leaders must also evolve and transform.
Vanina Mangano, PMP
Written by Mike Griffiths
I have just returned from the first face-to-face meeting for volunteers working on the PMBOK® Guide–Seventh Edition development team. This is a personal reflection of the meeting, not an official account of what happened or planned next steps.
We met at the PMI headquarters in Philadelphia. I have visited the office before and was initially disappointed it did not look like Hogwarts or some ancient repository/font of knowledge. Instead it’s a normal, pleasant, but mostly non-descript, three-story building in a tree lined industrial estate.
The development team volunteers came from Latin America, North America, Europe, Asia, and Pacific regions. We had a mix of industries including construction, government, IT, materials science, and education. We also had a diverse mix of roles including practitioners, consultants, PMO staff, and academia.
The goal for our three days together was to identify and begin to define the principles and domains that will make up the Seventh Edition. Everyone had been tasked with homework to research and consider in advance what they believed these universal project principles should be and what common domains/elements/aspects are involved in the delivery of results.
While this was our first meeting, it is important to explain that research for the Seventh edition has been underway for over a year. PMI regularly surveys its members and partner organizations to determine how they work and what real-world guidance would be of most use to them. There have been several workshops at PMI conferences worldwide to gather information and ideas about what to include in the next edition of the guide.
The team reviewed other project management guides, standards, and frameworks to determine what principles might be inferred and commonalities across various publications. It is probably fair to say every popular, publicly available project management framework was examined and I was surprised at how just many there were – certainly more than I previously thought existed.
During our time together we distilled, combined and generally whittled down over 100 suggested principles to around a dozen. We likewise suggested, debated and wrestled with domain suggestions. Despite our diversity we were able to land on an initial set of principles and domains for further development. Once refined, these will go out to a similarly diverse Review team of almost 70 people.
If you have read this far you are probably interested enough to want to know what the new principles and domains will be. Those are still in development, but several team members will be sharing their thoughts on specific principle concepts over the next couple of months. What I can share now is that the next edition of the PMBOK® Guide will cover the entire delivery spectrum. It will be relevant for traditional, linear lifecycles and applicable to non-linear, incremental lifecycles such as Design Thinking, Lean Startup, agile, and Kanban.
I left Philadelphia excited and a little daunted by the work ahead of us all. Yet inspired by the new direction and confident in the strength of our team. The next edition will be quite different, and I am glad to see it evolve.
The profession of project management is changing quickly. All of PMI’s research and surveys have indicated people have great ideas for changes they would like to see incorporated. I am looking forward to working with the Development team, Review team, and wider project management community to help develop the next edition of the PMBOK® Guide. For updates, discussions and accounts of the journey going forward please check back.
Note: For those planning to attend PMI Global Conference in Philadelphia 5-7 October, I will be assisting with two workshops that will further explore principles of project delivery: PMBOK® Guide – The Next Generation: An Innovation Working Session (Saturday, 5 October) and Project Delivery: Evolution and Revolution (Sunday, 6 October). I hope to see you there.