Author: Andrew Lavinsky

Andrew Lavinsky, PMP, MVP, is a manager in the program management practice of a Big 4 consultancy, where he focuses on enabling organizational performance improvement through enhanced project and portfolio management. As a professional trainer and consultant, Andrew has a diverse background providing services in such industries as oil and gas, healthcare, finance and IT. Andrew has lectured extensively on project and IT operations management topics within the United States and abroad. A graduate of the George Washington University, he has been an active volunteer with PMI, ITSMf and a number of other professional and educational organizations. In the mid-1990s Andrew was involved in the creation of one of the first official nongovernmental organizations in Mainland China. Later in that decade he served as a Peace Corps Volunteer in rural Mongolia, moving on to manage project delivery for Fortune 500 companies in the Chinese market. Contact Andrew at

How to Accelerate the ROI of Your PPM Investment

What if I told you that I know how to shortcut the payback period on a typical project and portfolio management (PPM) maturity initiative? What if I could tell you how to abbreviate the growing pains and go straight to the results? Getting to a solid return on investment on your PPM investment takes a while. Take it from me. I’ve been working with organizations for decades on this (sometimes even the same organization). I’m not saying there isn’t a quick ROI on investing in PPM maturity. Rather, I’m saying that many of the organizations I work with could get better and faster ROI if they just followed a few simple principles. The first principle is to truly understand how PPM can provide value within the organization. Once we understand the real value proposition, we can make a beeline for that goal… knock it out of the park, and then turn around to focus on the less critical things. Think of PPM maturity similar to how I played Capture the Flag with my kids at a paintball park recently. When the referee kicks it off with the whistle, you sprint to the back of the compound, grab the opponents’ flag, and then turn around to begin mopping up the remnants of their force. So what’s the underlying goal in any PPM maturity exercise? Resource metrics? Operational excellence? Risk avoidance? Predictability? No, I would argue all of these are secondary goals. They’re necessary at some point, but not sufficient. No, the main goal of a PPM maturity undertaking is almost always to align project execution with the strategy of the company. Period. The challenge is that many times these endeavors are chartered at the wrong level, for example, as an investment in project delivery by the PMO organization. When that’s the case, the journey takes on the characteristic of a salmon swimming upstream. We have to start at the bottom and keep working our way upwards until we can get to the point where the project portfolio may be aligned with the fundamental needs of the organization. This approach may be ostensibly risk averse, but it greatly slows the realization of the ROI on the PPM initiative. So how do we address this principle? Start at the top. Imagine that you’re starting with a white sheet of paper. Understanding the organization and its goals as you do, how do you design the perfect mechanism to execute on strategy? That becomes the end goal of the PPM maturity exercise, to build the processes, tools and behavior required to support the execution of organizational goals. Don’t stop there, however. If you start at the top and never take it down to the execution layer, you end up with some fantastic reports and slide decks — depicting a fantasy world that will never get realized. Start at the top and follow through all the way down to the project execution processes. The second principle is to truly understand the importance of change management as an enabler of PPM maturity ROI. Without the behavioral change, nothing happens. How do we get that behavioral change? There are a number of ways and frameworks to accomplish this, but the main way I’ve seen to succeed in this space is to focus on inclusive involvement and a solid consensus as to the underlying goals of the initiative. This means allowing the folks at the execution end of the portfolio to participate in discussions on how the portfolio links back to organizational goals. Change management in PPM maturity endeavors is most often subverted by two things: An overriding focus on the technology required to enable PPM processes; and/or The cognitive dissonance caused by acknowledging the underlying issues driving lack of organizational performance and then capitulating to immediate needs by focusing on the wrong issues. What happens when organizations ignore these principles? Ignoring these principles makes the road to PPM ROI even longer and more winding. Many organizations give up in the middle — or get stuck in endless loops trying and failing different things, like iterating through execution maturity to find just the right fit of methodology to map to the organization. This is a great discussion — but it tends to distract us from where we’re trying to get to: portfolio alignment. Similarly, I find the resource management discussion tends to distract us from our true aims — and by distract, I mean put everything on pause for six to eight months while we focus on something tangentially related to our goals — which then fails to achieve our actual goals, resulting in ever increasing cultural resistance to the overall PPM story. Curious what the path to PPM maturity looks like for many organizations? The main reason most PPM investments fail is that they’re too limited in scope. It’s an investment in strategic execution, and we almost always begin with operational excellence. This is certainly not without value, but the sequence should be reversed if we want to push the needle meaningfully. It’s not about executing better, but about aligning better. Hence my tips to accelerate the ROI of your PPM investment: 1. Start with the strategy. 2. Design the organization to execute the strategy. (In other words, don’t stop at strategy, but carry the discussion forward.) 3. Involve the organizational execution folks in the discussions. 4. Wrap it all with analytics. The major return on the PPM investment lies in getting important things done faster and in not wasting time on things nobody particularly cares about. Follow these principles, and while you may not have the results you need in a couple of months, you’ll certainly have them faster than you would following a more traditional path. Have your own thoughts? Share them in comments below. A version of this article first appeared on Andrew Lavinsky’s blog, “Project Epistemology.” Image Source

When Deterministic Scheduling Meets Kanban

One of the fun things about my job is that often I find myself knitting together multiple disparate systems and scheduling philosophies. In this case, I’m working with a client on a field scheduling problem, and we’re identifying how the multiple constituencies within the organization can collaborate to deliver a high level of service to the customer base — while at the same time ensuring an appropriate level of cost. From a very macro level, we are now trying to solve an equation for two optima: 1) How do I deliver world-class service to a customer base that needs responsive, predictable performance, 2) while at the same time juggling crews and equipment such that I am ensuring maximum capital utilization? When we are solving for one or the other optimum, life is simple. I can simply get more resources than I need, have them sit idle and waiting for the work to pass through — in which case the work doesn’t get delayed. Or I can schedule the crews according to their optimal schedule — which may not respect commitments to my clients (the classic “cable man” or “appliance delivery” scenario). We see the same discussion in other domains. For example, from some of the discussions I’ve participated in within the last couple of weeks: In IT, I have a limited number of testing resources. I need to run all of my projects through this testing bottleneck; hence, I want to structure the project to reduce the time between design and release while also optimizing the use of my testing resources. From a more macro IT portfolio sense, managers struggle with committing resources to projects before the projects actually can demonstrate a need for resources. In drilling, we have a limited number of rigs that must run from well to well performing drilling activities. Meanwhile, each well requires a series of activities to get ready for the rig arrival. Bringing the rig in too early simply means that it sits idle. In oilfield maintenance scheduling, I’m working through a backlog of maintenance tickets and trying to ensure efficient crew utilization. (Ok, this is not a perfect comparison, as we lose a bit of the deterministic element, but it’s still in the rough ballpark of the discussion.) Theory of Constraints provides us some guidance here. In ToC we would identify the bottlenecked resources, such as the crews, and then ensure that the deterministic scheduling approach creates a backlog of work in front of them. In other words, the bottlenecked resources are always used. Schedule Challenges First, let’s look at how to approach this via scheduling. The basic gist is that the deterministic schedule only predicts an early readiness date for the construction crew to start their work and then identifies a window within which they will perform the work. The length of that window is then defined by the anticipated volatility and workload of the crew schedule. (Which would mean that the more work they have — or the more variables that would be expected, say, during a season where weather disruptions are to be expected — would mean we would want to lengthen that estimated window.) As the readiness date approaches, the deterministic schedule dates may be adjusted based on real-time field conditions. At a defined milestone, the readiness status is handed off to the construction team, who then slots the work into the schedule for the next planning period, i.e. two weeks or one month. This means a few things: We need to treat the construction date within our deterministic schedule as a target, but not a specific date on which work will be done. We need to identify a triggering task or condition prior to that date that indicates the work is ready to be scheduled within the construction scheduling queue. We need to have a separate scheduling queue for the constrained resource, such as a process to define when work is ready to enter the queue and how that queue interacts with the overall logic of the deterministic scheduling model. We need a way of assessing readiness for the work to be put into the construction scheduling queue. If the work isn’t ready, we don’t want to waste everyone’s time scheduling construction. Communication Challenges From a communication perspective, we need to ensure that the systems or groups communicate specific data between themselves. Using the model above, that would look something like this. (And feel free to substitute any relevant constituency for “Crew” in this picture: IT testing resources, drilling rigs, etc.) The key here is to recognize the respective value that both perspectives have on the fundamental problem — that we’re attempting to solve an equation for both speed and efficiency. Therefore, we need to build a system that includes people, process and technology and that can solve — and reconcile — for both.   A version of this article originally appeared on Andrew Lavinksy’s blog, Project Epistemology. Image courtesy of Rude Health via a Creative Commons ShareAlike 2.0 Generic (CC BY-SA 2.0) license.  

database planning, portfolio planning

Annual Planning, Mode 1 Management and Circular Logic

Gartner introduced an interesting concept earlier this year: Mode 1 and Mode 2 planning. Mode 1 planning, as they described it, is the traditional planning approach to projects. Each project is scoped out, estimated, a business case is built, and then approved in some sort of an organizational cadence. When performed annually, this process is called “annual planning.” The alternative to Mode 1 planning is Mode 2. Mode 2, as presented, is much more agile and responsive. As the request is identified, the project is approved, funding and resources allocated, and the project team is off to the races. The challenge, Gartner presented, is for IT organizations to move from the Mode 1 planning model to Mode 2. Or rather, it’s to determine when Mode 1 is appropriate and when Mode 2 is appropriate — and then shift back and forth as required by the organization. I theorize that the farther ahead of starting the project that the planning and the resource allocation takes place, the more complex are the systems required to support the planning. For example, if you have an annual planning process where all resources are planned, funded and resourced prior to the beginning of the fiscal year, you’ll need a system to support the resource modeling of all projects throughout the fiscal year — and to model the cascading impacts of delays in one project. Knowing that planning so far ahead requires increased management complexity, why do we plan so far ahead? That’s when it hit me. We plan so far ahead, because we believe that we need to take a Mode 1 approach to project management. Why do we take a Mode 1 approach to project management? Because we plan so far ahead, we need to take a Mode 1 approach to support the annual plan. It’s a tautology. How do we break that logical loop?  How do we short circuit the time spent between planning/approvals and actually kicking off the project, i.e. moving to a rolling wave portfolio planning approach? We switch to Mode 2 planning, i.e. moving towards an asset or program based allocation model. Of course, that may not work in all cases. There are certainly some projects that require extensive approvals and a Mode 1 planning approach. Off of the top of my head, I might identify the following criteria for these projects: The project will have significant impact on the future operational expenses of the organization, such as a large capital project to build a new facility or an IT project that will deploy a new application into production. The project belongs to the category of infrastructure and on-going maintenance that may be easily planned for far in advance; for example, the retirement of a given application or the upgrade or replacement of equipment within a specific facility. The project is so large and significant that it requires a major reshuffling of the overall funding allocations within the organization, for instance, diverting significant resources to this project. That’s my criteria for when annual planning makes sense at a specific project level. What are yours? This article first appeared on Andrew Lavinsky’s blog, Project Epistemology. Image courtesy of tec_estromberg — CC 2.0