The Right Way to Implement Portfolio Management: Baby Steps
| By Wanda Curlee Why do organizations implement portfolio management? There is no right or wrong answer. However, there is a right and wrong way to implement it. Sometimes organizations become so excited by the possibilities of portfolio management, they take the big bang approach. In other words, they implement everything at one time. This is definitely the wrong approach for almost all organizations. A more desirable approach is what I like to call baby steps. With baby steps, there’s less to lose if something needs to be abandoned or tweaked to better meet the demands of the company. The first step of this approach is to develop the portfolio management methodology the company wants to eventually adopt. This helps leadership see the full value and builds buy-in. For some, determining what to adopt first is very painful. My suggestion for deciding what aspects of portfolio management to implement first has to do with resources. Today, organizations usually lack all the resources needed to deliver everything desired. So start with your most in-demand resource—the type that gives you the most trouble—whether it’s human, capital, hardware or something else. Then take all your projects and programs and decide the order in which you’d like to deliver them. This is your portfolio roadmap. Are the in-demand resources in collision? In other words, would a scarcity of resources cause bottlenecks in project or program execution? Most likely the answer is yes. Next, you might want to roughly determine the cost of each component (e.g., a project or program), the highest two risks on each one, and the perceived value of delivery. Cost is normally quantitative, but perceived value and risks may be qualitative. That’s okay. Just try to have four or five factors for each and assign a numeric value for low, medium and high. This makes it easier to come to consensus. For each component, have concentric circles with value at the center, cost surrounding the value and finally a red circle to describe risk. For example:
The first set of circles has a relatively small value, but large cost and risk. For the amount of benefit received from this component, it might make sense to cancel. The second set of circles shows a large value, a smaller cost and a large risk. Since the value is so large compared to the cost, it might be worthwhile to see if the risks can be reduced. Finally, the last set of circles has a moderate value, a large cost and a fairly low risk. This may be a good one to keep, especially if the costs can be negotiated down. Once each component has three circles, then the portfolio roadmap can be looked at again with each of these concentric circles. Does it match what you had before? Probably not. Based on the circles, you will probably make changes to the portfolio roadmap. Some portfolio components may be canceled and others will change priorities. Yes, the resource that causes bottlenecks or collisions still needs to be evaluated, because most likely there are still some issues. However, you may have more resources because some components were canceled or delayed. With a better handle on what components can and should be executed when, you’re on your way to a successful rollout of portfolio management at your organization. Have you ever done this kind of resource audit and prioritizing at your organization? If so, has it helped?
|
Aligning Stakeholder Engagement to the Big Picture
| By Lynda Bourne Stakeholder engagement is an essential part of project management. Chances are your organization focuses on stakeholder engagement but uses another name for the activity. From an organizational perspective, stakeholder engagement is a means to achieving outcomes increasingly seen as necessary to comply with various rules and regulations or meet customer or community expectations. Here are some terms you’ve probably heard that have stakeholder engagement at their core. Corporate Social Responsibility (CSR) Stakeholders increasingly have expectations about the behavior and responsibilities of organizations that go beyond the provision of jobs and products or services. CSR is generally defined as the continuing commitment by an organization to improve the quality of life of the workforce and their families as well as of the community and society at large. The social responsibilities of organizations arise in the context of stakeholder relationships. No two organizations are likely to have the exact same set of responsibilities, because each organization has different products, services and strategies and therefore different combinations of stakeholders and stakeholder interests and issues. Sustainability Sustainability in an organizational context goes beyond environmental issues to include every dimension of how a business operates in the social, cultural and economic environment. It is a business approach that creates long-term consumer and employee value and directly contributes to the sustainability of the organization itself. The Triple Bottom Line (TBL) TBL is an accounting framework with three parts: social, environmental and financial. These three divisions are also called the three Ps: people, planet and profit, or the "three pillars of sustainability." Many corporations are required to report in the TBL framework as part of their exchange listing rules.
(The International Organization for Standardization’s ISO 26000:2010: Guidance on social responsibility, and the Global Reporting Initiative’s closely aligned guidelines set out the framework for social responsibility and guidelines for reporting, respectively.) What This Means for Project Managers As project managers, we don’t always have input to organizational policies, but we are at the cutting edge of organizational change. Many projects have a significant impact on stakeholders outside of the organization. Therefore if your organization’s executives are using any of the terms detailed above and are “walking the talk,” you need to make sure your project activities support the organization’s overall stakeholder engagement philosophy. Project failures such as the tailings dam disaster in Brazil last month can undo decades of work by an organization to establish a reputation as a good corporate citizen. Building such a reputation is not purely altruistic! ISO 26000 suggests organizations that practice CSR and sustainability and focus on the TBL have a distinct competitive advantage that includes:
In summary: Project managers cannot create corporate policy. But if the organization is focused on its TBL, the wise project manager will make sure his or her project plan includes proactive stakeholder engagement, and view that engagement as part of a much larger picture. How much focus does your organization place on stakeholder engagement? How much does it care about CSR, sustainability and the TBL? |
Are You Managing For The Right Outcomes?
|
by Dave Wakeman Last month I wrote about measuring your project’s ROI. Part of that discussion included the idea that in the end, your projects need to be measured according to the outcomes they produce and not the actions that are taken. So I wanted to take a few minutes to go back over the concept of outcomes and how outcomes, execution and strategy play together to deliver successful projects. 1. Outcomes are all that matter: Every project has deliverables and actions that are meant to drive the project forward and give stakeholders an understanding of where things are and what is happening. The fact is, things like schedules, a work breakdown structure and risk assessments are just tactics that are meant to move your project closer to its end goal: the outcome! In every project the only relevant measurements of success are the outcomes. Outcomes mean things like a fully functioning product or service, a project delivered on time and schedule, and one that meets the goals of the client and stakeholders. So try to frame your project conversations in terms of the outcomes and the tasks important to those outcomes. Instead of an activity, think about how these activities play into timelines and budgets or into the overall success of the project. 2. Outcomes aren’t always obvious to everyone: It can be very easy to take a black-and-white view on outcomes. But the truth is that depending on where you are in a project and the role you play, the outcomes may not always be obvious to you. Why? It’s pretty simple, really. In any situation, we spend an inordinate amount of time focusing on the actions and activities that are most important to us. So when we look at projects, it can be easy to just think about the tasks we need to do to clear out our schedule or to move onto the next task on our checklist. Most of this isn’t intentional, so you may have to spend some time relating to team members how activities play into the desired outcomes or even spending time communicating the vision of how the project will play out in the organization. 3. Always be prepared to change: We spend a lot of time talking about risks and change in projects, but I think that in many instances these two skills aren’t applied with as much success and consistency as desired. But the process of implementing your strategy and optimizing execution comes with the basic jumping-off point of needing to understand, prepare for and embrace change as a constant within all projects. To better prepare yourself for change, develop this mindset: you are going to communicate consistently with your stakeholders and proactively manage where your project stays within the marketplace, the desired outcomes that the project will produce, and changes in the circumstances of resources and other internal factors. The simplest way to think about a project is as a set of activities that can be checked off on the way to completion. In fact, a lot of projects are managed that way. But to be the best project manager and a partner to your organization’s success, you have to make the effort to keep strategy top of mind while executing for the right outcomes. I think these three tips will get you started. What do you think? By the way, I write a weekly newsletter that focuses on strategy, value, and performance. If you enjoyed this piece, you will really enjoy the weekly newsletter. Make sure you never miss it! Sign up here or send me an email at [email protected]! |
Why Some Projects Succeed and Others Fail
|
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. |
Is Managing Risk a Negative Way to Work?
Categories:
Risk Management
Categories: Risk Management
|
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? |












