by Lynda Bourne
Project managers and processes go hand in hand. But are the processes of the past the right ones to guide future projects? And if project management is evolving beyond today’s generally accepted 40 or 50 processes, what should the next version of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) look like?
The Evolution of Process as a Concept
To consider these questions, let’s start by looking at the way processes have evolved. The concept of describing the process needed to accomplish a task emerged as part of the development of scientific management in the early 20th century. Scientific study and careful analysis defined the “one best way” of doing the work and the time it needed. Shortly after, the application of learned experience entered into the equation as a way to improve the current “best method.”
By the 1950s the concept of a process with defined inputs, transformed by the application of defined tools and techniques to produce outputs, was firmly established in quality control and management. Process improvement was central to the rapid development of post-war industry.
During the development of the 1996 version of the PMBOK® Guide, PMI adopted processes as the best way to organize and explain the complex flow of information through the life of a typical project. The PMBOK® Guide came to embody “generally accepted good practices that apply to most projects, most of the time.” Over the years, the 37 processes in the 1996 version of the PMBOK® Guide expanded to 49 in the Sixth Edition (released in 2017). Through the editions, PMI has progressively increased the emphasis on the need to customize and tailor processes to meet the needs of each individual project. But is this enough?
The questions I want to ask in this post are:
In the past, processes were developed around the concept of transforming specific inputs in a defined way to create consistent outputs. Business processes define how the how work is done within an organization, to meet the needs of its customers. PMI’s approach to generalizing processes across a management discipline adapted this basic concept.
The idea was powerfully successful when most projects, most of the time, had similar characteristics. They were approved, planned, built and closed. The same approach was used in construction, engineering and most other industries that did projects in the 1990s—and the concept remained largely true for the next 20 years or so.
However, does this generality still apply in the current environment, where some projects still follow the traditional approach (e.g., construction/engineering), others use various iterative approaches, while others take a fully adaptive and agile approach?
Some core objectives are consistent across of all of these approaches. For example, they all use some form of schedule management to get the right people into the right place at the right time, adequately resourced to do the right work. However, the processes applied to accomplish this objective have very little in common. For example, resources are allocated to logically constrained activities by the planner in traditional critical path method scheduling, in agile resources choose which activities to include in their next “sprint.” Similar challenges exist across most, if not all, of the knowledge areas. Has creating processes that can work across all of the different delivery strategies become impossible?
Focusing on the next edition
This brings me to the second question. What should the next edition of the PMBOK® Guide look like?
As our profession rapidly changes and diversifies, it remains central to the development of the world’s economy. So how do you think the PMBOK® Guide can best evolve to maintain its preeminent position as the global reference defining the management of projects?
Your answers will help inform my next post looking at managing the accelerating rate of change in our profession.
By Marian Haus, PMP
Trust is defined as a “firm belief in the reliability, truth, ability or strength of someone or something.”
Isn’t that what we all want in our professional and private lives?
Imagine a project with little or no trust between the project manager, team members and stakeholders. In such an environment, communication is opaque and piecemeal, and what’s communicated to you depends on your position in the organization. Silos are built to protect individuals, positions and knowledge. As for assignments, they’re meticulously planned and controlled, and work is delegated and rigorously followed up on.
I could go on and on.
Without trust, companies won’t survive for long in today’s world of VUCA (volatility, uncertainty, complexity and ambiguity). Without trust, for example, how can you as a project manager quickly respond to constantly changing customer expectations and environmental conditions?
The absence of trust is at the basis of the pyramid of The Five Dysfunctions of a Team by business consultant and speaker Patrick Lencioni. According to this model, conflicts cannot be solved creatively without trust. The lack of trust erodes people’s commitment, engagement and accountability—and therefore makes it difficult to attain goals and results.
I believe the evolution of project management over the past two decades is due in large part to the way trust is now valued in projects and in business. It’s an enabler for individual and organizational success. People are more empowered than ever to work independently (i.e., with no micromanagement) and to collaborate in trustworthy environments.
Companies that understand this have trust as a core value of their corporate culture and part of their corporate DNA. Leaders, project managers and employees of these organizations are not struggling to gain the trust of their peers. They are benefitting from and supporting the implementation of cultural changes based on trust, openness and fair collaboration.
How can project managers lead by example and work to create a trustworthy project environment? Here are some tips:
By behaving in a trustworthy manner and leading by example, you’ll gain your team’s confidence. People will rely and count on you in any circumstance.
How do you drive trust in your projects and organization?
The Traps of Textbook Scrum
By Christian Bisson, PMP, PSM
The Agile methodology is quickly becoming the standard for IT projects. More specifically, most organizations are using the Scrum framework to bring their software development to the next level.
But it’s implementation often remains a challenge and that’s because Scrum is not one-size-fits-all, and if you follow the manifesto too rigidly you can fall into a few traps.
Here’s a look at two:
1. Lack of Team Experience
If you’re coaching a team new on Scrum, take baby steps. Imagine if you’re teaching someone to play basketball for the first time. You will most likely teach them how to dribble before you teach them how to dunk a ball.
It’s the same with Scrum. If you throw everything in the Agile Manifesto or Scrum Guide at your team at once, chances are the results will be poor, the team will be confused and ultimately they will not enjoy the methodology.
For example, when assigning complexity, start with T-shirt sizes (small, medium, large) instead of the Fibonacci scale. When the team grasps this concept well, adapt accordingly.
2. Potential Waste of Effort
An active sprint is considered sacred for a team. Its scope must not be modified, and any new requests/requirements should be factored into future sprints.
Be that as it may, sometimes there are extreme circumstances where the sprint must be stopped or modified due to new requirements.
For instance, say an amazing opportunity presents itself three days into the sprint, making the current scope of the sprint obsolete. Fixating on the fact that a sprint cannot change and having the team work for the remainder of the sprint on something confirmed to be useless would be a waste.
If this sudden change creates downtime for the team while the new requirements are written and refined, the team could focus on testing new technologies, or working on a proof of concept that could help with the new requirements.
Or sometimes a project faces issues and due to the importance of the client, those issues must be prioritized. People may be pulled out from one team to help another. That will mean that an active sprint’s committed scope may have to be reduced, which is when you have to put aside the textbook for the sake of the organization, and to help out colleagues in need.
Have you ever had to steer away from initial expectations for a project or team’s benefit? Share your story!
By Ramiro Rodrigues
Is risk management just an exercise in paranoia?
That’s the question I’m often asked. I like to respond by saying there are both negative and positive risks.
A risk is a situation in which it cannot be certain whether a specific result will happen. That potential cannot be discounted. Thus, any risk hypothesis—whether for small or large risks—is subject to some sort of management strategy. While we often think of negative risks, positive risks present opportunities for organizational or project gains.
Risk management strategies can be applied to our daily lives. Take, for example, my own experience.
A few years ago, I was invited to hold a workshop on project management best practices for a service company. Concerned about the event, I decided to invite a colleague whom I trust to share the work (strategy: share) and increase the chances of the workshop being successful (strategy: improve). When checking his schedule, my colleague realized that he would be returning from a trip at 6 a.m. on the day of the workshop, which was scheduled to start at 9 a.m. Even knowing that flight delays are more common than we would like, we decided to take the risk (strategy: accept).
In the weeks leading up to the event the preparation flowed well. We met with the client and tested the presentation dozens of times (strategy: explore), but the possible flight delay did not leave my mind. For this reason, I studied not only my part of the presentation, but also that of my colleague (strategy: eliminate).
When the day arrived, I woke at 6 a.m. to find two messages from my colleague on my phone. The first one said, "I've landed?” This gave me a sigh of relief. The second said, "I'm really ill. I'm going to a hospital.” I called my colleague and verified the illness.
What a great irony! All my fears arising from my colleague's risk of a delayed flight were realized, but not because of that event.
Some changes were necessary. First, I had to substitute the car journey with a taxi (strategy: transfer). Second, I had to remove specific parts from the presentation to reduce the impact of my colleague’s absence (strategy: mitigate). Even without doing so through a documented plan, I had used all of the recognized risk response strategies.
For me, it became clear that the great gain from risk management is in the exercise of thinking beforehand and being able to choose the best options available.
The outcome of the workshop? I imagine it would have been better if my colleague had been able to attend. But judging from the applause and words of praise, I believe that it was a success.
Keep These 3 Priorities In Focus
by Dave Wakeman
In today’s project environment, it can be difficult for project managers to know where they should—or shouldn’t—focus their time and energy. Stakeholders, team members, and sponsors, all with their own agendas, pull project managers in different directions.
That said, I think all project managers can gain a great deal by focusing on the following:
1. Opportunities within the project. I’ve never seen a project that’s set in stone. In truth, almost every project I’ve worked on has changed so much throughout the course of its existence that it often becomes unidentifiable with the initial scope.
This can be frustrating, but to maximize your success as a project manager, you should embrace the change process because it allows you to search for and capture opportunities that will enable you to have the highest impact.
Think about this simplified example: Let’s say you are working on a web project. The scope of the project calls for you to build a responsive website that can handle a certain amount of traffic, and you have three months to do it. That’s pretty clear-cut, right?
It is. And, you could definitely go right through the project and deliver. But what if you discovered a more cost-effective way to host the site with a better load speed? Wouldn’t that be identifying an opportunity and creating a better outcome for you, your team and your client?
2. Development of your team. One challenge we often face is resource uncertainty. Essentially, will our human capital sufficiently meet the project’s demands?
This is an ongoing challenge in many organizations. Staff members are often overburdened, and they’re not always up to speed on the newest ideas, techniques, and tools.
To maximize your impact, it pays to spend time thinking about and developing your team. Consider ways you can help build up your team’s skills in a way that will make your life as the project manager easier. It may be as simple as identifying a skill crucial to your project and providing some type of consistent coaching, information or feedback each week that helps improve that specific area.
3. Testing as you work your way through a project. Does this part work the way it should? Did that segment of the project produce the outcome we needed? Are people reacting the way we thought they would or should?
Pay attention to each step in the project and spend time testing your assumptions and your results against the work produced. It’ll pay off in the end.
In some cases, things will work out exactly how you thought they would. But in the cases where that doesn’t happen, testing can be the difference between the success and failure of your project.
Is there anything else you consistently remain focused on during your projects?