I have to laugh at myself sometimes. Not only does it help me not take the world too seriously, but it lets me reflect on what is important to me. It seems I can't get concepts such as efficient execution and quality out of my head. These concepts are permeating into everything that I do. I can't help it--I just notice stuff. My car has a trip computer that I use every day on my drive to and from work. The dashboard of indicators is designed to give you real time data on how your drive is going. I've completed this same drive, same amount of lights, same amount of turns at different times in the morning to figure out what is the optimum execution method for getting to work. Here are the dashboard metrics that the trip computer records.
1. Start time
2. Duration (elapsed time)
3. Mileage completed
4. Average speed
5. Miles per gallon
Now, trip computer only works when I'm in "Eco mode", which means that I place the car in a mode in which it is designed to perform with maximum fuel efficiency. One sacrifices performance for efficiency, but gone are the days where this 40 something year old needs to show all those other drivers what's up ;)
I haven't tracked my performance on these metrics empirically (they're not in a data warehouse or a spreadsheet waiting for analysis). However, over the last 90 days I have some "targets" in my mind that I try to hit. Those targets are
1. Start time--6:15
2. Duration (elapsed time)--35 minutes
3. Mileage completed--25 miles
4. Average speed--41 mph
5. Miles per gallon--34 mpg
Sometimes I get there sometimes I don't, and sometimes it's not my fault
It's just like project quality. The PMBOK 6th edition says that "Project Quality Management includes the processes for incorporating the organization's quality policy regarding planning, managing, and controlling project and product quality requirements in order to meet stakeholders' objectives. Project Quality Management also supports continuous process improvement activities as undertaken on behalf of the performing organization." (Project Management Institute, 2017, p. 271).
Said another way (and more simply) what we want to do here is to make sure that we are managing the project the most efficiently as we can. How do we do this? With quality metrics that are understood up front, easily measurable at key stages throughout the project and ones that are able to be compared to benchmarks so we know what "good" is. Let's apply these quality principles to my drive.
Start time: 6:15
It's simply good business to start projects when we say we are going to start them. Our organizations have allocated time, money and people to enter into a project that is designed to deliver benefits to the organization in some fashion. My drive enables my organization to benefit from my presence at work by 7:00. If I start my drive after 6:15 I will need to figure out how to deal with that. I can drive faster which will affect some of the other metrics that I mentioned above, but sometimes due to traffic that is impossible (a project constraint that is out of my control). Note that 6:15 + 35 minutes is 6:50. There is some strategic reserve of 10 minutes there to ensure that I get to work by 7:00.
- Start the project on time
- Build in a strategic reserve in case the risks and project constraints you identify cause delays/problems
How do I know that my target time is 35 minutes? Well I've found that if I start my drive at 6:15, the past data garnered have shown that 35 minutes is a reasonable time for project execution. However, if I start my drive at 7:00 the data has shown that it will take me 70 minutes to get to work. Therefore, the start time and the duration are sometimes correlated. This is the same with projects. We must consider the project constraints, other projects "in-flight" in the program simultaneously and the people/resources available to complete the effort. If I left at 7:00 there are exponentially more projects (drivers) on the road trying to complete their drives.
- Try to execute projects at the optimum time
- If that is not possible then we must consider resource allocation and adjust our quality metrics accordingly
There isn't much we can do about reducing mileage on some projects. Work just simply needs to get done. However, if you discover that there is a new route that may be longer, but also shorter in duration then that is a point of discussion when your PMO gets together. The trade space between level of effort and delivery time should be analyzed. Additionally, if there are some roadblocks or construction (project issues) that pop-up, a different route must be considered (what-if scenarios/fast-tracking).
- We must have a fundamental understanding of the level of effort and duration for each milestone/task/project so that we can make intelligent changes in execution as issues arise
- Sometimes the "route" (schedule) that seems longer can actually save you time
Average speed--41 mph
There are times on my drive where I am creeping along at 20 miles/hour and then there are times where I can operate the vehicle at 75 mph. Note that both of these extremes are within the project constraints of no more than 5 miles over the speed limit. This limits my exposure to risk (speeding ticket/accident). This is the same with projects at work. Sometimes the team needs to work slowly through a task due to the nature of the work and other projects in flight. Sometimes the road is clear and team members can fly through it only to hit another part of the project where they have to slow down again. However, after the project is over we can calculate the planned work versus actual work to determine schedule and cost variances (SV and CV). This comparison is vital when looking at process improvement. Every day I try to maximize my mpg and minimize my duration by riding in the correct lane and using the correct amount of acceleration to maintain my instantaneous miles per gallon. At work I'm managing a program with 10 projects that are very similar in scope. We are in the middle of establishing our metrics to determine how we are executing on each project and how we will record lessons learned to get better.
- If you have a repeatable process, understand the velocity of the team at key points and try to maintain that velocity
- Recalculate the level of effort and duration at different milestones during lessons learned sessions to facilitate periodic achievement of benchmark metrics.
It costs money and opportunity cost to execute a project or series of projects. In my organization we budget a certain amount for projects/programs every year. Ultimately, we are going to spend that. We have a fiduciary responsibility to be good stewards of that budget. If we put a certain amount of gas in the car (PMO budget) then we need to endeavor to get the most out of it as possible. I want to get the most trips (projects) completed between fill ups that I can. The way that I drive (the execution methods/best practices) has an incremental effect upon the efficiency of my execution. It is the same with projects. A standardized method for communicating, executing quality and storing/analyzing KPIs goes a long way with respect to efficiency.
- Streamline your project execution procedures to make the most of funding
- Employ a continuous improvement mindset to include your MPG (this loosely equates to Earned Value Management)
You can only determine if you are doing well with project quality if you identify and communicate the metrics to all the stakeholders in advance. The continuous improvement focused PM who complains about sub-par execution really doesn't have a soapbox to stand on if he/she doesn't first tell the team what "good" means. In other words. Figure out what time you want to start the project, how long it should take you to get to the finish line, how fast you are willing to go and how much effort you are willing to expel to get there at that time. Ultimately, we need to arrive at our destination without any damage to ourselves or the other projects in flight. This is a tall order, but can be achieved with a bit of foresight and planning.
Drive safely--our teams will thank us :)
Project Management Institute (2017). Guide to the project management body of
Communicating between teams, stakeholders and individuals is vital for project success. This is especially true when requirements are constantly emerging and shifting in the agile and hybrid project environments in which we find ourselves today (Mastrogiacomo, Missonier & Bonazzi, 2014). Therefore, our communicating methods must accommodate this dynamism and agility.
Here are 3 methods of communicating that have been effective for me over the years.
1. Get out of your office and talk to people--especially when you don't need anything
I have found myself at times in the past as the "room grenade". It's an uncomfortable feeling that you get when people scatter (either physically or emotionally) because they feel like every time you come to talk to them you are going to ask them for something or to follow up on a task that is due. Chances are that they know what they have to do, and they are used to PM's telling them that they either did it wrong or that they haven't done it on time. Rather than waiting to develop a relationship during this stressful time, why not stop by someone's office on your team just to say hello, or to thank them for their work during the last phase or to complement someone on their team. With all of the electronic methods of communication we have today there still is no better way to communicate your entire message and build a relationship than a face to face interaction.
2. Remain consistent with your approach--unless it isn't working
I've had leaders and PMO's direct me to communicate a certain way, and I kept it up even though the results we wanted weren't coming. I've been in project meetings in which people claim not to know what is going on even though I've sent out dozens of progress reports on tasks, milestones and overall project status. Yes, it is up to other professionals to read emails, notifications or reports, but it's also up to us to communicate with people in the method that works for them. How do we mitigate this risk of a message not received? Ask people during the initiation phase "how would you like me to pass you project information?" You may be surprised what you get as an answer to that question. One of the engineers I work with told me "don't send me an email, I won't read it! Either do a "drive-by" my desk or Skype me with something important."
3. Don't wait until the progress report goes out to communicate!
Ultimately, we can know everything about our project--the percent complete, the CV, SV, SPI, CPI, key risks/issues--but if nobody else knows about the information or if they have a partial picture then we are failing our project teams. Project success can be achieved even with poor communication, but it's easier to be successful with stellar communication.
Mastrogiacomo, S. Missonier, S., & Bonazzi, R. (2014). Talk before it's too late: Reconsidering the role of conversation in information systems project management, Journal of Management Information Systems, 31(1), 44-78. doi: 10.2753/MIS0742-1222310103
How many of us have been in PMO meetings where the topic of risk is discussed, and there is an uncomfortable pause in the room? I believe that this pause is because we all are relatively adept at identifying risk, but after that identification we are uncertain of how to handle it. Sometimes the plan is either only partially completed or can be executed only with extreme difficulty. We tend to have trouble regarding the next steps to accomplish and grasping what it means regarding those risks/opportunities.
- Who do we talk to about them?
- At what interval do we discuss them?
- Who is responsible?
- How long should we keep them on the register? our risk matrix?...our minds?
A Matter of Perspective
Before we can talk about uncertainty management (risks and opportunities) let's review some definitions and frameworks.
Individual uncertainty in a project or program is "a specific event or condition that might have an effect on project objectives" (Standard for Risk Management, 2009, p.10)
Overall project uncertainty "represents the effect on the project as a whole." It is "more than just the sum of individual uncertainties on a project, and "represents the exposure of stakeholders to the implications of variations in project outcome(s)" (Standard for Risk Management, 2009, p.10)
In other words, each individual risk (or opportunity) is an entity for management that combine in a complex fashion to shape the overall uncertainty management framework for the project. "Framework" is also a key concept. I've studied and practiced one (or a combination of both) of these in my career.
1. Project Uncertainty Management Process (PUMP), (Chapman & Ward, 2011)
2. PMBOK Risk Management Knowledge area
The PUMP framework emphasizes an early identification of risks in the process, but what to do about them is deferred until later. During identification a tracking interval and series of metrics should be established so trends can be tracked for proper monitoring and impact analysis of risk.
The PUMP structure follows (Chapman & Ward, 2011).
The PMBOK risk management (Project Management Institute, 2017) procedure includes the following:
Pivoting from Theory to Practice
Now for the pivot--the flowchart below is a framework that has been working for me. Note that blue denotes what to KNOW and orange denotes what to DO.
1. Bring up uncertainty management at the very beginning of the process. Uncertainty should be part of the decision space during the project evaluation phase. If your organization has a steering committee or a portfolio management group consider bringing in high level risks during the decision process to pair with the schedule, cost, benefits realization and organizational change factors. This is where the first high level uncertainties should be recorded in your PMIS. These are individual elements (we call them cases) which will be continually monitored throughout the project (assuming it becomes a project). They can fruit into issues and maintain the pedigree of the original risk. We also attach these uncertainties to major tasks in the WBS. Our PMIS allows us to use "tags" for easy sorting and review so we tag them as #risk, #opp. This action makes it really handy to go back later and retrieve all the #risk and #opp across your programs/portfolios for lessons learned.
2. Perform a qualitative assessment of the uncertainties with the project team
Once the steering committee says "go" and your project is in the planning phase, it's time to involve others in the planning. During planning sessions encourage as many different people with disparate skill sets on the project team to "weigh in" on the uncertainties. Their perspectives regarding what the risk/opportunity will mean for scope, cost or schedule will be different than yours, and this will create a healthy debate among the team. This debate also enhances the chances that the entire team will take ownership of these cases and manage them proactively. Note: I believe that the PM should always maintain ownership of each uncertainty on the project, but there can be other contributors that bring subject matter expertise to the table to enrich the management of these uncertainties. After the team meets to discuss update the rankings according to probability and impact in your PMIS.
3. Complete a quantitative analysis on the top 3 - 5 uncertainty cases on the project
If you have a team dedicated to risk and that can devote the time, by all means flesh out all of the quantitative measures for each risk you can. However, our team is small, and we must be judicious regarding our time. I have found that the 80% rule of thumb works here too. Twenty percent of the uncertainties will consume eighty percent of your time. Therefore, make it count--work as a team to quantify the cost or schedule impact that the uncertainty will have on the project. Remember, opportunities will have a positive affect on cost/schedule. There are many templates that go over some ways to accomplish this.
4. Update and maintain uncertainties and try your best to keep them from fruiting into issues
Risks are items of interest that may happen in the future. An issue is a risk that has become reality. These must be dealt with now! Sometimes issues seem to "pop up". This happens to all of us, but that doesn't mean that the risk wasn't there--it just means that it went unrecognized and that the team didn't know how to or that they should prepare for the eventuality. I argue that the more we can standardize the uncertainty management framework, the less likely these unrecognized issues will arise.
I believe that as project professionals it is our job to manage uncertainty. Business opportunity is not without this uncertainty, and strategic leaders are aiming to make informed decisions regarding which new ventures, change initiatives, and markets in which to enter. With this framework both before and after project initiation, we can assist our organizations in this endeavor.
Thank you as always for reading and I welcome your comments around this topic.
Chapman, C. & Ward, S. (2011). Project risk management: Processes, insights and techniques (3rd ed.). West Sussex, UK: John Wiley & Sons Ltd.
Project Management Institute (2017). Guide to the Project Management Body of knowledge (PMBOK® Guide)—6th Edition. Newtown Square. PA. 2017. Retrieved from http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-Library-of-PMI-Global-Standards.aspx
Project Management Institute (2009). Practice standard for risk management. Newtown Square, PA 2009. Retrieved from https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-project-risk-management
I play chess with my kids. They are 8 and 9 years old, and then they play with each other. I like to think that they take the concepts that I teach and then practice them on their own. One of the concepts I review with them is the "pivot".
This is a two-fold concept.
First: There needs to be an understanding of what your opponent is trying to do in theory. Then you need to transfer that thought in the practice of what you're going to do about it.
Second: There has to be a shift from a defensive action when your opponent attacks you to deflecting that defensely and "counter-moving" to put your opponent in duress.
This is challenging for the grade school minds that are my pupils.
What does chess with kids have to do with Project Management? In our work lives few of us concentrate on a pivot as a way to put others in duress so let's concentrate on the first point above. Throughout my career there has been a concept that has been at least as equally challenging for me. The concept of a pivot from what "the book" (PMBOK 6th edition) and the practice of what will work in organizations is one of the concepts that I have found to be vital for success as a project manager. The PMBOK is a set of guidelines that are a framework which will apply to most projects most of the time. However, the application of that framework involves the following:
1. A sound change management strategy
2. Mastery of team dynamics--people make process work
3. An appeal to organizational constructs, limitations & organizational values
This series will be dedicated to how we can translate what we KNOW into helping others DO to accomplish project objectives, obtain success criteria and be fully engaged emotionally, intellectual and with a servant's heart with our project teams. Please let me know what you think and what topics may be of interest to you. I never thought I'd be doing this, but I guess I'm making a pivot myself.
Project Management Institute (2018). Guide to the project management body of