When I started as a project manager, the focus of my attention was on the mechanics of project management. This involved becoming very involved in work plans, risk/issue trackers, status reports, progress metrics and all those artifacts that form the means by which one manages a project.
What I realized after a number of years (as well as after a few hard learning experiences) was that while the mechanics of project management are important, they are merely enablers for the core activities that truly create a successful project.
I needed to think more about the successful direct and indirect business outcomes that could be created from a project. The attainment of successful business outcomes was what my stakeholders were really looking for, not necessarily the most impressive work plan or status report. This shift in focus become one of the turning points in my project management career.
So how does a project manager, in particular one early in his or her career, make the transition from executing the linear mechanics of project management to producing desired business outcomes? Well, they need to acquire the skills and behaviors that enable business success from projects— hopefully without harmful learning experiences along the way.
Here are four tips for making this transition.
1. Don’t Be Afraid of Business Processes
When I was a relatively new project manager, I spent a lot of time at my desk. This desk time was occupied with working on project management artifacts that if created perfectly would, in my mind, automatically lead to a successful project.
A senior project manager noticed this and encouraged me to spend a fixed amount of time creating project management artifacts, with the remainder of my workweek interacting with stakeholders in the business areas. In fact, this senior project manager arranged for me to work for a few days with some of the employees that were actually executing the business processes that were to be impacted by my project. Those few days of immersion were a great learning experience that it completely changed my outlook on how to run the project.
Today, I still employ the same technique for both myself as well as fellow project managers and team members. Whether it’s working in a retail outlet helping to stock shelves, processing billing exceptions in a call center or spending time in an airliner simulator, the immersion experience is essential to understanding what makes for successful business outcomes from projects.
2. Define Business Success Criteria
Very early in my career, I took what my stakeholders initially shared with me as business success criteria without any subsequent qualification. No surprise that some of the success criteria entailed—“just make it easy to use,” “finish testing by the end of the year” or “do whatever the senior vice president says”—didn’t really indicate a clear path to business success.
As I grew as a project manager, I began to spend more time in the beginning of projects articulating in detail with stakeholders clear criteria for business success. This involved not only understanding current processes by immersion, but also challenging stakeholders on the methods we would use to objectively measure business success. If something cannot be objectively measured, it would be difficult to determine the success of the project.
I also allocated time in the project to build and execute the processes to measure success. By doing so, I had the capacity to create evidence of how the project benefited the business.
3. Understand Your Industry
In my first few years as a project manager at an insurance company, I took every course on project management I could find (this pre-dated the creation of PMP certification). While I became adept at the mechanics of project management, I had no real foundation of business knowledge for the projects I was leading.
On a recommendation of a senior project manager, I took a course on the principles of the insurance business. This course covered the terminology, core business processes and emerging industry trends. I left the course wondering how all of this was going to apply to running projects.
Within two weeks of taking this course, my supervisor passed along a compliment from my stakeholders how much more effective and efficient I was in running their project. This newfound productivity came from the ability to more easily understand the challenges that the project was intended to address. Little did I know that the industry training was a form of business process immersion.
4. Get Comfortable With ‘Design Thinking’
The concept of “design thinking” originated with companies finding out that while project managers thought they were achieving the desired delivery success criteria of being on time and budget, they were not really producing the desired level of business success from projects. These companies began to explore ways of changing the approach in determining business success for a project.
Design thinking gives project managers several approaches to fully qualify the path to business success by techniques such as charting a customer journey, business process brainstorming, business case creation and creative reframing.
All of this opened my mind to going beyond the traditional boundaries of a project to ensure I was going to both define and execute to true business success.
I sometimes long for the days when I ran smaller, simpler and shorter projects whose goal was typically to finish on time and budget. I could afford to relax a bit and strive to achieve a high professional standard in the mechanics of running a project.
But as our projects become larger, more complex and longer in duration, we as project managers have to delegate some of these activities to other people, so we can get on with the business at hand of producing successful business results from projects.
These four things helped me make the transition to achieving business results on projects. What are some of the things that allow you to do the same?
By Marian Haus, PMP
There is obviously a high interest in the project management community and literature about what drives project success. For example, searching online for “why projects succeed” will return you five times more web pages than “why projects fail.” Similarly, there are four times more pages about “project success factors” than “project failure factors.”
This is no coincidence! The overwhelming interest in project success insights is driven by the struggle of many organizations and project managers to understand what drives success.
But before answering the question of why projects succeed, let’s first try to define project success.
The most common definition of success is delivering the project on time, on budget and in scope. PMI’s PMBOK Guide® says a project is successful if the following parameters are met: product and project quality, timeliness, budget compliance and customer satisfaction.
Others define project success by measuring the project ROI (or business case) over a certain period of time. If the ROI is positive, the project is declared successful, regardless of its deviations along the way.
I have my own definition: A project is successful if it meets its given goals, within acceptable variance boundaries (e.g., in terms of scope, time or budget). This is a relative definition and relies on the fact that the world is not perfect. Hence even a successful project will rarely be a 100 percent success.
A civil construction project might be declared successful if it meets its scope and quality. Acceptable time or budget deviations might not be seen as failure. Similarly, an IT project might be declared successful if it meets its scope on time, with acceptable deviations from quality or budget.
A project’s success is relative: it depends on how the success criteria and metrics are defined from the very beginnings of the project, along with who will measure them.
OK, there are clearly many definitions of project success. Similarly, there are also many views and studies on why projects succeed.
Let’s take a look at a few studies and try to find a common denominator.
According to PMI’s 2015 Pulse of the Profession®: Capturing the Value of Project Management, over the last three years the number of projects meeting their goals—hence being successful—has remained steady at about two-thirds of projects. This success is the result of organizations supporting project excellence by focusing on fundamental aspects of culture, talent and process.
But size matters, too. A Gartner study from 2012 shows that small IT projects (below US$350,000) are more likely to succeed than big projects (budgets over US$1 million).
Other studies reveal that project success is tightly linked to clear project objectives and requirements that are fully understood and supported by actively engaged stakeholders.
My view on the common denominator that leads to project success is simple: the main drivers of project success are rarely of a technical nature. Instead, the drivers are the basics of the project management culture and discipline within the project organization.
In other words, fix the project management basics, and your chances of reaching project success will increase.
By Christian Bisson
Risk management is often overlooked. Most people think it’s simply additional costs; others think it’s secondary and can be put aside to prioritize everything else. Some simply don’t understand it at all.
Regardless, project managers should always push the team to do it, even if at first it seems like it’s more about educating than any actual risk management.
While doing just that recently, though, I stumbled onto a new point of view I didn’t see coming: Risk management is “negative.” The rationale behind this view seemed to be that it makes us focus on what could go wrong, when we should be managing the project without thinking about potential problems.
I can’t deny that being positive is important for every aspect of one’s life. But I couldn’t disagree more that thinking about what could go wrong is negative. If anything, risk management is a positive way to work to make sure the negative stays far away from your projects.
Risk management is also about focusing on the positive risks and how to embrace those opportunities, although that part of risk management is often overlooked, unfortunately.
Have you come across similar point of views around risk management?
Have you been in situations where it seems that only shouting generates results? Or has your team been pressured to complete tasks that don’t appear to benefit your project? Maybe as the project manager, you have been in the middle of confusion and agitation that seem to undermine your project management abilities.
Could it be that many of the scenarios you encounter have their roots in conflicting stakeholder requests and misunderstandings? Well, it’s possible to avoid these types of predicaments. Consider utilizing the following three tools that allow you to have better control of your project and your project team:
1) Communications Plan. Outline a plan with names, contact information, and details on when and what messages need to be delivered to and from you. This tool allows you to know the frequency of message exchanges and the media required for specific contacts.
It also lets you know what level of detail the message should have, i.e., if it is going to a senior manager vs. a member of the supporting team.
2) Stakeholder Analysis. Prepare an analysis of your stakeholders to understand what their roles are and what area of your project is impacted by their involvement. This tool can help you with the department that has the biggest impact all the way down to the departments that have even a small effect.
Additionally, this tool can show how those who are directly or indirectly connected to your project may have an influence that can be detrimental.
3) Project Plan. Develop a plan with the focus on your project objectives and what the project will entail. Organize the plan for what needs to be done and when. The tool should show ownership and timings that you can share with stakeholders to also make them aware of the potential influence of their requests.
Sometimes, we get can get distracted when trying so hard to make sure our projects meet every need. There are many voices, conflicts, risks and events that affect the success of our project. Leaning on these tools may make your stakeholder management process smoother.
By Conrado Morlan
When I was a portfolio manager, I attended many portfolio status meetings where projects were reviewed and assessed based on their status color. The status color—green, yellow or red—was usually determined by a combination of specific metrics defined by the organization's project management office.
Green meant the portfolio was on track, yellow meant the portfolio could be in danger of not meeting its goals, and red meant the portfolio was in serious danger.
Attendees’ behavior during these review meetings was always the same. To me, it revealed how simplistic or misleading the tri-color status system can be. Portfolios with a green status received no questions from the audience, even when a portfolio manager conducting the presentation specifically asked if anyone had questions.
On the other hand, yellow and red status portfolios produced expressions of surprise and/or contempt. The audience bombarded the portfolio manager with questions and asked for contingency plans to bring back those portfolios to green status.
At times I felt those portfolio managers were being punished for doing their job well. And I always wonder if people had dug deeper into the portfolios with green status, would they still have been so surprised or contemptuous of the other portfolios?
A portfolios status turns yellow or red because a risk turned into a problem or because of internal dependencies like other portfolios or external dependencies like new government regulations. When portfolios are aligned with the organization's strategy, portfolio managers must know all the risks identified in the strategy and assess how those risks will impact the project portfolio.
That’s their job. Furthermore, portfolio managers who create awareness among the portfolio steering committee about risks or external dependencies are being smart. They’re gathering input to decide which projects in the portfolio may need to be postponed, which may need to have their scope changed based on risk and/or internal or external dependencies, and which may need budget cuts or increases.
In other words, a yellow or red status can indicate a portfolio manager’s competence and sophistication, rather than incompetence and stupidity.
As a portfolio manager, how do you avoid surprise and contempt among your stakeholders?