One of our peers asked a question today about the key elements for standing up a PMO. Here is what I told him.
My opinion is that you'll need to show value to the SBUs. They've been executing their operations and change initiatives to this point on their own so your team will need to always ask yourselves the question "What can we do for the business?". A couple of things to start with:
What are your thoughts on the PMO? How do we serve and deliver value in the 21st century? How should be evolve to continue to do so?
As we all know, leadership is one of the key areas of PDUs in the PM talent triangle (PMI, 2019). We all are called to lead in our role as PM's, and we all lead in different ways. It seems that the world today is polarized in many ways. There are methodologies that seemingly keep us on one side of a continuum, and it seems like we need to make a choice regarding what type of leader we need to be. Should I be extremely detail-oriented or should I delegate that function to someone else? Waterfall or Agile? Collaborative or Directive? etc.
I would argue that in this polarized world there is a third way. We all have to find our third way in between the poles. When you think of our planet, it is very difficult to live at the poles. The temperature extremes and harsh conditions are brutal. Also, there are long periods of light and darkness that are difficult to endure. I've never lived in the arctic or antarctic regions, and I don't want to. However, I have tried living at these "poles" of leadership, and I've found that they can be just as harsh, but in different ways. Living between the poles in a more temperate region is much more pleasant, and I would argue produces better project success results. So what are some of the tenets of temperance?
1. The Third Way
In his book "How to Lead When You're Not in Charge", Clay Scroggins explains that there is a third way to lead. He explains that the two extremes can be
- waiting until you are in charge and blaming others that you are not--passivity
- Fully embracing your ambition and bowling over others to meet your goals--aggression
His third way is simply to serve people where they are, and to help them achieve their goals. I tried the first two ways (the poles) and was not very successful. The third way has been much more effective for me. Plus, it's just more fun! A friend of mine asked me recently how my projects were going, and after a pause I said:
"I helped other people work toward their personal and group goals today, and that also helped the project". That leads me to the second tenet of temperance.
2. Align team and individual goals
It's not always possible, but you look for opportunities within the teams you lead to lift others up. Give somebody an opportunity to lead a portion of the project that he/she is passionate/skilled at executing. Most of us can recognize talent when we see it, but sometimes that talent needs to be developed. I work in a matrix organization (like most of us), and when I can work with a resource manager to help one of their team members work on a specific skill or competence--I embrace the opportunity to do so. Often that skill or new way of conducting a portion of the project can be assimilated into best practices. I'm not saying to be reckless in our approach to running projects, but continuous improvement through the empowerment of others can be powerful indeed.
3. Mentor without being asked
My title is Senior PM. That's not important, however, what is important is the fiduciary responsibility that I have to my team. The PMO Director pulled me aside recently and thanked me for my work with my peers. She mentioned that sometimes I can say things in a way that resonate differently than they do from her as the boss. These private conversations can be tailored directly to a specific person's learning style and situation. When you can develop a safe space to pass on some knowledge in private, the benefits can be greater than they are in public or more formal situations. I endeavor to help other PMs within my organization become the best leaders that they can be, and to help them see that it's cold and dark at the poles sometimes.
4. Be a generative leader
Generative Leadership is a style that produces new thought or processes on how to accomplish a task and run a project. The types of leaders that embody this philosophy are proactive, positive and see opportunities where others see problems. These leaders create and shape change rather than just responding to it, and are conscientious in their efforts for continuous improvement (Disch, 2009). The new approaches theses leaders are using include finding new answers to seemingly conflicting priorities, looking for commonalities and inclusion versus differences and exclusive behaviors, and the re-framing of situations to expand options in seemingly constrictive environments to generate multiple solutions (Disch, 2009).
True leadership is often a thankless job, but are we really doing it for the accolades anyway? Following these 4 tenets over the last couple of years have really helped me to live with joy and find satisfaction in my job. After all, it's a pretty lonely place at the poles. I lived there for awhile, and I'd rather live in the temperate zone. Best wishes for your leadership journey.
Disch, J. (2009). Generative leadership. Creative Nursing, 15(4), 172-177.
Scroggins, C (2017). How to lead when you're not in charge, Grand Rapids, MI, Zondervan Press
I'm managing an interesting project. It is a new business line that we are bringing up out of the ground. Therefore there are some predictive elements (i.e. construction, development, testing, fielding of systems), and there are some iterative elements (mobile development, enterprise data warehouse integration). These projects are rolling up into a really cool program. When you combine this with a maturing PMO concept, there is alot of change going on at once. An additional change was that the business analyst on our team was out for two months. Guess who that job fell to in his absence? If you could see me right now I'm in my chair leaning back with two thumbs pointing right at me!
I quickly had to understand the need for business analysis, the interface with the customer, the accounting department and the HR department as well as stakeholders in IT. Whereas before I just need to worry about the "what" to do regarding the deliverables, the tasks and the milestones, now I had to be concerned with the "why" as well. Here is a perfect example of a seam--I'm well versed and experienced with process maps to determine the major muscle movements about what needs to happen in business processes. However, without the BA I needed to delve down deeper into behavior designed development (BDD) frameworks so that we would be ready for detailed testing of our solution. I didn't understand until now how important it was for every possible interaction a user of a system could accomplish that there needed to be a specifically designed business outcome to assign to that action. I see this as a potential area for further collaboration and knowledge creation between the BA and PM communities.
What do you think?
In 2002 during my first year of service as an Air Force officer, I invested $100/month in the GI bill. That $1,200 investment has paid big dividends in my life. Ultimately, it funded my living expenses and 100% tuition of my Doctoral Degree as a Doctor of Business Administration (Project Management Emphasis) in 2016. The ROI on the initial $1,200 funded over $75,000 in education benefits not to mention the other qualitative benefits I've received as a result. One of those is the great honor of writing this blog. In 2002, my budget was tight, and the GI Bill wasn't something I was originally planning to do. It was a bit "out of scope" of my current thinking.
I want to ask you all a question today. The concept of scope is generally understood in predictive environments, and in agile/iterative/dynamic environments it is pretty much understood how we deal with changes. However, what if an issue becomes so severe that it impacts the life of the project, and nobody is managing it? Or, like the GI Bill, the opportunity has such a great upside that we need to embrace it.
Does that by definition become part of your scope? The choice is either to absorb the responsibility or the project will be at severe risk. Yes there may be an initial bump in resources and effort spent, but in the "long run" of the program it will save TONS of those resources and effort. More succinctly stated: an small investment at the front end will pay HUGE dividends at the back end.
I welcome your thoughts. What have your experiences been in this area?
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