by Dave Wakeman
I recently came across some of management guru Peter Drucker’s thoughts on project management.
As often happens with Drucker’s writing, the lessons he wrote about many years ago are still applicable today.
In his thinking about project management, Drucker came up with the idea that it really came down to three ideas: objectives, measurements and results.
Let’s take each of these areas and think about how we should approach them today.
Objectives: Many projects get stuck before they even begin, due to a poor framing of the project’s objectives. We should be undertaking our projects only when we have moved through the project-planning phase to such an extent that we have a strong grasp of what we are hoping to achieve.
These objectives shouldn’t be fuzzy or wishy-washy. They should be solid and rooted in the overall strategy of the organization you are performing the project for.
This means you have to ask the question: “Does this project move us toward our goals?”
If the answer is “yes,” it’s likely a project that should be launched.
If the answer is “no,” it’s likely a project that needs to be fleshed out more, rethought or not undertaken at all.
Measurements: Drucker is famous for this adage: What gets measured gets managed.
In thinking about project management, measurements aren’t just about being able to improve project delivery. They’re also essential to ensure the project is headed in the right direction.
To effectively measure our projects, we need to have laid out key measurements alongside the project’s objectives.
The measurements should be specific, with expected outputs and completion dates, so you can affirm whether you are on schedule, behind schedule or ahead of schedule.
At the same time, the measurements should inform you of your progress as it compares to your strategic goals.
Results: Ultimately, projects are about results.
To paraphrase another great thinker, Nick Saban: If you focus on doing your job right on each play, you’ll put yourself in a position to be successful at achieving your goals.
Saban coaches U.S. football, but this works just as well for all of us in project management.
If we are focusing our energy on tying our projects to our organization’s strategy, through this strategy we focus our project efforts on the correct objectives in line with our strategy. Then we use those objectives to measure our progress against the strategy. We should be putting ourselves in a position to get the results that we need from our projects.
These results should be measured as positive outcomes. In Saban’s case, that’s wins. In your case, it might be a new technology solution, a successful new ad campaign or a profitable fundraising effort.
To me, reviewing Drucker’s thoughts on project management is a reminder: Even though there is a constant pull of new technologies, never-ending demands on our attention and a world where change feels accelerated, sometimes the best course of action is to step back, slow down and get back to the basics.
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.