It is a fact of project management life…every project starts off perfect, like a blank canvas ready for the masterpiece to unfold. As the PM, you are prepared to execute on a flawless plan, applying all the PM wisdom you have gained from experience, training, and a few good blogs. It’s a fresh start, and you are ready to go.
And yet, somewhere between adding the first task to your project schedule…and completing your project closure steps, things always seem to get off track. The project stumbles, and you find yourself back in that adrenaline-fueled organized chaos that is the reality of most major projects.
Before you know it, you are banging your head on your desk in a post-project lessons learned session because 90% of the things that are identified are not new to you. You KNOW there needs to be better cross-team communication…you KNOW the requirements for an item need to be nailed before you start design on that item…you KNOW that risks associated with critical milestone dates need to be identified earlier. The list goes on, and they are all good points…and you can’t quite figure out how these things happened again.
You want to know…when exactly did my project stumble? What was the turning point?
While you probably have a lot of documentation associated with your project, you don’t have an instant replay camera. You can’t rewind the tape, scanning for that exact moment in time when the project stumbled. And the reason is, in most cases…there is no exact moment. There is no single point in time where the train jumped the tracks.
Your project made its way from start to finish by way of hundreds or thousands of daily decisions and actions. And each one considered by itself does not appear to be a project-wrecker. At the moment in time any given action was taken, chances are people did not think it could cause major headaches down the road…until pretty soon you have a stack of actions/decisions with minimal individual impact, but major collective impact. And that is how you got to this lessons learned session you are in.
So, what can you do about it to lessen the chances of this happening again next time? Aside from getting an instant replay camera, consider these suggestions:
- Know your non-negotiable rules. A project manager’s job is to help utilize a toolbox full of processes, tools, templates, and techniques to ensure the project is executed successfully. And there will be times you may decide to relax a rule, or allow more flexibility, based on your situation. That is perfectly acceptable, and is why PM discretion is so important. But before you get to a cross-road decision, you should already know which project processes or rules are non-negotiable. And when the request comes to deviate from the stated process, you will be prepared to hold the line on the non-negotiable items, rather than wrongly assuming this small, isolated change won’t have a big impact.
- Check for lessons learned as you go. Don’t wait until the project is over to capture the lessons. Try doing lessons learned on a periodic basis, either based on some calendar interval, or based on finishing each phase of the project. It is far better to identify a bad behavior or poor decision during Planning than it is to note it at the end…after you have suffered the cumulative impact over the life of the project.
- Audit your project management plan. If you have defined in a project management plan, or other form of documentation, what your processes will be for issue and risk tracking, change requests/change control, status reporting, logging decisions, etc., don’t let the project kickoff be the only time you use that document. Pull it out for each phase gate review and audit yourself…have I made small deviations that I was not aware of? Have I slacked off the plan, and need to get back to what we said we would do? If you can identify it early, you can minimize the downstream impact.
- Apply the lessons learned. We all know this…capturing lessons learned at the end is a great way to help define things to do better next time. But I would bet it is a low percentage of PMs who start their new project off with a team review of the lessons learned from recently completed projects. Use that accumulated knowledge…make those lessons fresh reminders as you get started on a new one, and gain team commitment to avoid duplicating the mistakes again.
- Which leads me to the most important one on my list…make sure you are not the only one with the replay camera. It is impossible for the PM to be everywhere all the time. You need to leverage as many of the project resources as possible to keep an eye out for those small slips that add up to a major stumble. Share the concern with them, share your non-negotiable items, enlist them in the gate-review lessons learned…in short, spread the responsibility for preventing “the stumble” to all who are in key roles on the project.
You may have had a project that DID have that one major moment when everyone knew the project stumbled, but most of us don’t. We are always looking for the instant replay camera to try and spot the exact moment. Don’t get caught in that cycle again. The next time you have that blank canvas of a new project, think about how to address the hundreds of moments instead…and then see how differently your lessons learned session may go at the end.
© 2012 Steve Carter
A guest blog post I did for pmchat.net on 10/5/11.
©2011 Steve Carter
If you are reading this, you either have an interest in starting a PMO, or helping someone else start a PMO…or are just trying to figure out what a PMO is and does! Whatever the reason, I’m glad you are here, and I will do my best in a short blog entry to give you some useful information.
First of all, let’s clarify what a PMO is. For different companies, the P in PMO can stand for Project, Program, Portfolio, or any combination of those…and the MO stands for Management Office. Most companies use their PMO to oversee a group of projects and resources, which can be for a program or for your entire portfolio of projects. (Some will create a PMO specifically for a major complex project, but not keep it as an ongoing entity.)
There are three traditional primary functions or roles for the PMO. Most PMOs in existence are designed to cover one or more of these roles for the organization:
- Resource pool – the PMO can be the home of a centralized or shared set of trained and talented project managers and other project professionals. Often it is more efficient to centralize those resources and apply them to the various prioritized projects rather than have every team staff their own PM resources.
- Methodology/Governance stewards – the PMO can define and maintain the project methodology, tools, templates, and processes that all projects are expected to use, and can track and report on adherence to the methodology. The PMO as part of this role can also own/coordinate PM education and training to ensure all resources are capable of following the company project guidelines.
- Back-office support – the PMO maintains the project registration, prioritization, and ongoing tracking/reporting processes in support of the organization.
Some mature PMOs handle all three roles for the organization, and are the hub for all project-related activity, including the interface with key partner groups like risk management, finance, procurement, etc. It is much easier for the PMO to work with these groups on standard templates, process steps, compliance guidelines, etc. than to have the partner groups try to resolve that with PMs scattered about the organization.
Many organizations only have a PMO set up in their IT function, which is where most of their projects are sponsored or managed. I am a strong believer in business PMOs to address the broader organizational change and process work that surrounds most IT projects.
The most exciting change in PMO models these days is to add a fourth focus to the three mentioned above, and that is a focus on aligning the project portfolio to the overall business strategy. Mature PMOs can move beyond a narrow focus on consistent application of the methodology to the defined list of projects, and instead can play a real role in ensuring each project is aligned with and supporting the strategic goals of the company. PMI member and author Mark Price Perry has written a great book entitled “Business Driven PMO Setup” that goes into great detail about the expanded role the modern PMO can play.
If you are thinking of starting a PMO, I urge you to make sure you are clear on what your organizational need is, and don’t do it because you hear that other people have one…you need to know what void or need it can fill.
Here are my recommended 5 key steps to create a PMO:
1) Clearly define the business need. Identify the gap between your current state and what leadership wants it to be, and how the way you manage projects needs to change. You need to know that before you determine that a PMO is your solution.
2) Based on the problem you are trying to solve, identify the roles your PMO will play.
a) If you are having trouble sharing PMs across functional or department lines, and you need a better way to take limited resources and apply them to prioritized projects…then you may need to leverage the resource pool aspect of a PMO.
b) If you are struggling with multiple methodologies, and not having a consistent approach that meets the needs of IT, legal, finance, etc….or if you have major differences in the breadth and depth of your PM skillset, then you may need to leverage the methodology/governance and training aspect of a PMO.
c) If your leadership team or the broader organization is seeking more consistent approaches to project prioritization and initiation, and wants rolled up info on project statuses…then you may need to leverage the back-office aspect of a PMO.
d) If you find there is no clear link between the projects you initiate and the strategy your company has defined, then you may need a PMO that helps facilitate the project selection process in conjunction with your strategic planning process.
3) Work with an executive level sponsor to create a charter for your PMO. The charter needs to clearly define:
a) the future state you defined
b) the roles the PMO will play and the deliverables of the PMO
c) the key stakeholders of the PMO and what they stand to gain (see my additional note below on this one)
d) the authority the PMO will have
e) the measures of success
4) Gain CEO and leadership team buy-in. This is critical.
5) Clearly define your implementation plan, including PMO staffing plans and education/communication plans for managers, PMs, business process owners, key partners in other divisions/departments.
I want to underscore two points…
First, make sure you assess what you have now and what the organization needs to be successful. Blindly implementing a PMO without a defined organizational need can lead to poor adoption and a lack of necessary support.
And second, the PMO is most successful when it views itself as an internal provider for multiple sets of customers/stakeholders…the leadership team…the project management community…and the key stakeholder groups like finance, IT, risk management, etc. If you set your PMO up to be the customer and expect all of those groups to do something for YOU, then you are missing the point. The PMO should be a servant function that seeks to enhance the effectiveness of everyone else….when you give them what they need, they are far more likely to give the PMO what it needs.
A PMO can help improve the clarity of priorities and project approvals…it can improve the level of PM skillset across the company…it can provide more effective tracking and reporting that can help organizations recognize and respond to problems faster…and it can help save money through more efficient and effective use of resources.
I wish you much success in establishing a PMO and leveraging it to improve your current state!
It was a well-planned and well-attended fundraising event for cancer research, hosted by a close friend who has far too many family experiences with cancer for one family to deal with. And like most well-planned fundraisers, there were some very enticing silent auction items, and some beautiful raffle baskets. You know the kind…nice decorative baskets, each with a different theme, but stuffed full of things that we all want.
And so it was that night last year when my wife and I watched basket after basket of exciting gifts go to other well-deserving participants (darn!). And then it came down to one last basket that had been generating a lot of buzz…the Starbucks basket, complete with gift certificates, home-brew bags, coffee mugs, etc. And all of the crowd leaned forward expectantly as the MC called out the winning ticket number…and I won! And everyone gave me that look of raffle-basket-envy.
The only problem was that neither my wife nor I drink coffee! And we had been silently (okay, not so silently) saying “don’t call our number, don’t call our number…” Needless to say, that which was so sought after by others didn’t do much for us. So, I gave the basket to an over-worked, caffeine-deprived, friend who was standing next to us…and she was thrilled!
And that has been a great reminder for me as a leader and a project manager. Not everyone appreciates the same things, and not everyone is motivated by the same recognition. While all PMs and leaders need to utilize recognition, the best leaders take the time to understand what makes people tick…and they tailor their recognition to match.
One team member may crave public recognition, while the next may hate it. One may appreciate lunch with “the boss”, while the next considers it torture. Clearly, most of us are not able to provide expensive recognition gifts on a regular basis, but even small tokens of appreciation (thank you note, shout out on a conference call, a cup of coffee) can make a major difference for someone who is giving it their all for your project or team.
So, the next time you are able to provide some recognition, try to make it fit the recipient, and see how much further that recognition will go. Coffee anyone?
©2011 Steve Carter
I’m sure many of you have led or participated in a system/technology project that nailed everything in the WBS and was successfully implemented. But have you experienced projects where the technology solution was successfully implemented, while the overall business objectives were not achieved?
The telltale signs? The business process performance didn’t improve…the adoption rate by employees was not what it should be…or the changes we expected to see never materialized. Many times these and dozens of other issues are not captured because “the project” was completed, and the resources moved on. Whose fault is it? Not even worth the time to discuss it, because we all share the blame, and we can all influence the success of the next one.
Here are some thoughts on how to ensure the broader business objectives are met when a technology solution is defined as the project:
- Systems and technology are meant to support and enable business processes. You must start your analysis at the business process level. Don’t define a project as “implement a new xyz system” until you have defined what needs to change about the business process(es) that the xyz system would support. Too many of us focus on the technology, and then back-end the process work to conform to the system. It should be the other way around…do your homework on your process first, so you can ensure you have defined a system (and the requirements for that system) that will meet your process needs. Sounds simple, but so often lost in the rush.
- On a similar note, when you define success factors for your project, be sure to distinguish between the measurements that define a successful implementation and those that indicate you met your business objective. Implementing a new performance management system and having it operational by a certain date is a nice implementation goal. But the business should have decided to pursue that goal because it had a broader business objective…ensuring all employees have meaningful, documented performance goals and regular feedback sessions with their manager….or creating an integrated performance and development process that linked performance goals to compensation decisions and to development training opportunities. Most business objective metrics of success will need to be tracked long after the “system installation” is deemed a success to know whether the overall business objective has been met.
- Don’t forget that successful change management starts at the very beginning of a project, and is not something you address when you are ready to “roll it out” to the organization. Successful change management involves early identification of the knowledge, skills, and behaviors you need to change before, during, and after the implementation to ensure business success. While most of your project team is focused on the system that is the bulk of the project, you have to have resources working the other pieces. Who will be impacted by the process changes, and will they be engaged and trained? Who is leader or leaders who will need to reinforce new behaviors by managers or employees who will utilize the system, and how will they be prepared for their role? How large is the gap in the current and future state of your process, and how much communication/education do all stakeholders need?
These are only three items, and I know you can identify more. (Feel free to share them with others in a response to this blog!) But they are a reminder that even the biggest technology projects are a subset of some overall business process that is changing, and real success comes when we address the business process need holistically. What do you think?
©2011 Steve Carter
Who is the real customer of your PMO, and are you meeting their needs?
Granted, there are as many flavors of PMO as there are organizations that have one, so I know it is hard to make generalizations. I do think, however, that all PMOs have struggled with (or need to struggle with) the question of “who is your customer?” If you have not done your own customer/stakeholder analysis for your PMO with the same energy that you might for a major project, you are missing an opportunity to ensure greater PMO success.
Spend some time looking at your various customers, what their needs/expectations are of the PMO, and what you are doing to meet those needs. And if any appear to be in conflict, deal with those as quickly as you can. Here are some examples to consider:
- Senior leadership team – Most leadership teams look to their PMO for visibility into the portfolio of projects, status snapshots of the most important initiatives, updates on critical issues, and a “heads-up” on risks that lie ahead. Timely, accurate, and prioritized information is critical for this customer group, as is clarity on where you need their engagement or decisions. Are you meeting the needs of this customer?
- Project managers – Whether the PMs report into the PMO or not, the successful PMO views the PM community as another one of its important customer groups (and not the other way around.) PMs need clarity from the PMO on the methodology and tools they are expected to use, as well as easy access to any templates, resource guides, or collaboration technologies that are available. In addition, most PMOs can be the aggregator or provider of ongoing PM education. The PMO should also try hard to ensure status reporting and other compliance processes are as simple and unobtrusive as possible, while still meeting the needs of the organization. Are you meeting the needs of this customer?
- Sponsors – Good PMOs can also be a critical link for project sponsors, who may or may not be part of the senior leadership team. They need coaching on the role of the sponsor and an understanding of what the PM and the project teams will need to receive from them in that role. Sponsors also need to see how the statuses of their projects are stacking up against all others in the portfolio before those reports go to the senior leadership team. An educated and engaged sponsor is crucial for project success. Are you meeting the needs of this customer?
- Stakeholder teams – This group covers a lot of ground…from finance, legal, compliance, IT (if you are in the business unit), business unit (if you are in IT), HR, procurement, risk, etc. Each has its own specific need from the PMO. It may be general information about the portfolio of projects, info about specific projects, assistance in making sure their policies and practices are understood and followed by project teams, or assistance in resource allocations from their small staffs to the many project teams who need them. Don’t overlook the importance of these stakeholders to the success of your projects. Are you meeting the needs of this customer?
My list could go on, but you get the point. Don’t assume you have your customers covered just because you are providing the info the one vocal leader is seeking. Spend some time with your PMO team doing your own customer/stakeholder analysis, and see where you need to clarify expectations. And, commit to making that an annual process at a minimum to ensure your ongoing success as a PMO.
©2011 Steve Carter
They are the ultimate challenge for many PMs…project sponsors. Either they are too distant and failing to provide the direction, decisions, and leadership you need…or they are “too engaged”, micromanaging your every move, and at times acting as if they are the PM. Or your sponsor may fall somewhere in between these examples, and might even be exhibiting the perfect sponsor behaviors. Regardless of how your project sponsor shows up, your challenge is to meet them where they are.
While we all wish sponsors had read the sponsor handbook and would automatically know how to successfully play that role, most in fact are not as familiar with the role as you would expect, and far fewer have had the formal project management training that you have had.
So, do you spend your hours fighting against the way your sponsor shows up, or is there a better way. Here are my suggestions…let me know what you think.
1) Meet them where they are. Accept that your sponsor may not be ideal in how they approach the role, and make adjustments on your part to match up more effectively with them (more on that below). Don’t spend days and weeks fretting over this, and risk putting other aspects of your project off-track. Back up a step, understand who they are and how they are showing up, and meet them where they are.
2) Modify your approach with them. Maybe the last sponsor you had was ideal, and you didn’t need to provide them an update every day, but this one is asking for that. If you want to gain the trust and respect, and have any hope of modifying the sponsor behavior going forward, then start by meeting their requests. If that is for daily updates, do it….and in those meetings show how you have things under control. Identify the next few actions, talk out your plan with the sponsor, and gain their input on your plan. Then, as they are more comfortable with your approach, ask if they would be willing to meet after you complete a few of those steps, instead of meeting again tomorrow. Whatever the behavior that is less than ideal, try modifying your approach with them first, and then win them over to your more ideal approach.
3) Make sure they are getting the info they need. Often a sponsor has enormous pressure on them to deliver on the ultimate objective, and their reaction is to engage with the project in what may seem at times as inconsistent and erratic ways. Part of your responsibility is to make sure they are getting the info they need to make senior management happy, and to be able to feel confident in your ability to control the project.
4) Have the hard conversation. In the real world, you end up with sponsors who just won’t respond to those steps or your constant attention to their requests…or despite your efforts will not engage to the degree you need them. You are just the tip of the iceberg when it comes to impact of a poorly engaged sponsor. All project stakeholders feel the effects when a sponsor is not fulfilling their role effectively, and you owe it to all of the stakeholders to have the difficult conversation with the sponsor. Schedule a separate meeting to point out the behaviors, tactics, or procedures that are impacting the project…state how the project is being impacted…and ask the sponsor if they would be open to some changes. I know from experience that some sponsors are just blind to the impacts of their behaviors, and appreciate being told. Others are not as open to that conversation, and nothing will change. But you as PM owe it to the project team to have the conversation.
5) Follow the behavior to the ultimate cause. Often your conversations with the sponsor can uncover the true underlying issue that they are dealing with, and you may be able to suggest alternatives. For example, if too much micro-management is the problem, it may be because a prior project failed when they were more hands-off. Or if it is too little engagement, it may be that they are not bought into the ultimate goal or are unaware of the level of engagement you need. At the end of the day, there is usually a reason they are behaving the way they are.
On a final note, the sponsor/PM relationship is critical to the success of your project, and experienced PMs know that every new sponsor brings a new set of engagement challenges. My suggestion is to understand where your sponsor is coming from…meet them where they are for now…and then work with them to see if there are changes that can be made to improve things for the project. Sure beats sitting back and complaining.
©2011 Steve Carter
Whenever we began the process of interviewing and hiring a new Project Manager for our team, the same debate would ultimately surface…are we better off hiring the strongest PM we can find, even if they are lacking experience with the specific business or methodology we support, or are we better off finding someone with the business/industry knowledge who might need some mentoring as a PM.
My blog entry today is not an invitation to join that debate, (and for the record, I always felt finding the solid PM was the important task, and we could bring them up to speed on the business segment to the degree they needed to be successful.) My purpose in highlighting that debate is to comment on the importance of PM skills these days, and the struggle at times to find people who possess them.
My completely un-scientific research (interpret that as what I have personally seen over the years) indicates there are some people who seem to have the “PM gene”, and those who don’t. Those who do are natural planners and organizers. They are generally process-oriented, and need to think about the critical path of events, even if it is just for planning a trip to the grocery store, or thinking about cleaning out a room. These natural PMs may not have any formal training in the tools of the PM trade, but they have an internal drive to bring order to chaos, to identify the objectives, and to plan out the steps to reach a successful conclusion. If you think about the most talented PMs you know, I bet they share some of these “natural PM” traits, in addition to any skills they may have learned from the PMBOK.
Can we help develop more individuals with this natural orientation to project management? While some aspect of this may be hereditary (see my comment above on un-scientific!), I do think you and I can help develop the next generation of PMs. And it starts in elementary and middle school.
Schools are natural training grounds for project management skills….assignments given in advance of a deadline…multiple classes assigning homework at the same time…projects that need weeks to come together rather than the night before the due date. With the right influence from parents, teachers, and mentors who understand basic project management, we can help students break these assignments down into basic pieces, and lay out a plan that helps them get to the end goal. We can reinforce the value of the “critical path” by helping them see the need to complete some tasks well in advance of others, and we can underscore the negative impact of schedule slip (procrastination) on their success.
So, if you have these natural PM skills, make sure you are passing them on to your kids. Or if you have the time and ability, talk to a local school about how you might be able to spend some time there talking about project planning and execution. And see if you can help develop the future PMs our organizations need!
©2011 Steve Carter