An Interesting week ahead

Next week looks to be very interesting. I've not written much in the last month because I really haven't done much PMO work. I've been writing Plan documents, so you can imagine how much I want to come home and write more. One of the reasons I'm falling behind on the Accord project - more on that later.

So, next week we are going to begin our installation of Project Server 2007. We have some consultants coming in to help us with the setup and some training. I've got a little experience, but not enough to want to jump off that ledge alone. I have been reading up - bought a book and pulled some papers down from the MS site. We have been slowly building a schedule (I use that term loosely).

Our schedule (which everyone calls a plan of course) is running about 2000 lines right now. Probably somewhere on the order of 250 resources. I know that's too big, so we have to figure out how to manage at the level of detail we must (per the contract no tasks >80 hours) and still be able to give some meaningful management information. We have a couple of really interesting challenges ahead:

Size/complexity of the project: This really just a technical challenge, but one that will be with us throughout the entire project. The solution right now for this is a full time scheduler.

Politics: I am not really sure that everyone has bought in to the 80 hours deal, so there may be some work there trying to get the right informaiton into the schedule.

Earned Value: Another contract promise - yikes! MSProject has a the tools, it's collecting the information that is going to be a challenge. Right now, I'm struggling to figure out "value." Is it the value assigned by the client or the value assigned by the contractor? We have a fixed price contract so to the contractor value = bid - cost (or profit). If it costs more to produce something that was bid, that's a problem. But the client has a whole different value proposition based on rate of return, net present value, payback, etc.

Scope: This is tied with the politics too - what isn't. How much of MS Project Server do we want to implement - it's a pretty robust tool - what's enough and what is too much. I'm a minimalist and so is my counterpart, so I think we will go with as little as possible. I just hope that is enough.

Off to read more, check a few blogs, etc.

2 New projects

I've been overwhelmed lately with life things - new job, new house, moving, packing, packing, packing, moving - resting from about killing myself since I am clearly not 20-years old any longer - or even 30 0r - oh well you get the idea.

So, my two new great projects are: Building a PMO - yes again - I love this - this one is for a public sector multi-million / multi-year program and subsequently the software organization that results from this!!

The other one is with the PMOSIG. We are working on a PMO Accord that will document lessons learned and best practices from PMO SIG members. This will be fantastic as it will be a collection of the knowledge from those who have walked the walk. No theory, just tried and true experience. Also there will be multiple perspectives on the same topics, maybe even some healthy disagreement. My job on this is part editor, part contributor and part coordinator / project manager.

So stay tuned. I'll be updating the blog on the progress of both of these!

Derry

Quick thoughts on a PMI research paper on PMOs

I just finished my first reading of a great study titled: The Multi-Project PMO: A Global Analysis of the Current State of Practice. I recommend that you take the time to look this over. There are a lot of interesting findings. It will take a while to fully understand them all (at least for me). However, I did see two points that I think are vital. I am glad to see a study that reinforces them to some extent.

It’s about people. I know I harp on this – I think it is vital to a PMO. The study talks about 50% of PMOs being “questioned.” One key finding relates to the performance of a PMO and the expertise of the PMO staff (practitioners) – not the project managers, the PMO people. While not exactly an epiphany, the finding is “Expertise is critical to PMO performance.” If performance is being questioned, it follows that the greater the expertise – the greater the performance and then the less questioning.

It is about YOUR PMO. One thing that the study repeats throughout is the variability of the findings. There is not a lot of correlation between the variables (company size, number of projects, PMO organization…). There is some, and that’s important to look at. The lack of correlation tells us that what you do with your PMO in your company is really what matters the most. Don’t try to implement a cookie cutter PMO. Know your stakeholders – all of them. Understand what their pain points are. Know where they need help and attack that. If you fully customize your solution you can succeed.

Maybe we will get to the point where PMOs are implemented by the book. Where there is a checklist that everyone fills out and that determines how a PMO is built and run. I guess it is our job to move us there. (Personally, when we get there, I’ll be somewhere else.) Until that time, we can think of ourselves as craftsmen (craftspersons). We have tools and materials, but the work that we do for this one PMO, this one time, is what matters.

Week 27 - Change

This week I inherited the responsibility of rolling up all of the IT status reports into IT release level reports – which then in turn go into the Program level report (along with the Business status). Now, I have been doing the program level reports, and not sure how I got the IT ones – probably no one else wanted these – I think that I got them because (as any consultant will know) consultants are the “catch all” when a real employee doesn’t want to do something.

Anyway, the reports were a mess. I am getting 23 separate weekly reports in about 10 different formats. Some in word, some in excel. My job then is to cut and paste these babies into 4 different release level reports. Sound like fun???

Being the lazy, avoid-work-at-all-costs type of person that I am, I tried to find a better/easier way (after shamelessly trying to beg out). Well obviously, this would be a lot easier if everyone used the same format right? Well, why weren’t we doing that in the first place? Here is where it gets interesting – the answer I got when I posed that question to my predecessor was that they had tried to get everyone to use the same format, but they wouldn’t. AH HA – change resistance.

I have to admit a bit of disappointment that the only method attempted was to give the team leaders a template and ask them to use it. The follow up was to ask them several more times. When I asked what else, I was told that my predecessor did not have the authority to get them to change. Hence nothing was done. Another AH HA – responsibility without authority !

Given that I was in the same boat, needing people to change, but not having any authority to change them I had an idea. What was it that people didn’t want to change? Not the process, they were handing in weekly reports on schedule. So it was actually the format of the report – that seems like a small item, so why resist. Then it hit me – because it meant a good bit of upfront work, and these guys have “better things to do.”

So these busy people did not want to change because they were busy, and frankly the format of a report is not that big a deal – unless you are dealing with 23 of them a week. So – in essence, the problem and pain was mine, not theirs. Since I could not force them to make the change, I took a different route. I eliminated the work.

I simply took each of the 23 status reports and copied all the information into 23 new status reports under the new and consistent format. I then mailed these out asking that they start with these as the base. So far, everyone has been either accepting or thankful. I’ve gotten no resistance or complaints.

My lesson learned here is that by doing the initial change and creating a situation that is no more difficult for the person, we can speed change. Most of the time the hard part of changing is just that the change itself, after that we develop new routines that are usually less work than the original ones – that’s one reason for change – less work.

I learned a long time ago (the hard way) that there is only one thing any of us has the power to change – ourselves. By reframing my view (changing from the view of my predecessor) I changed and made it easier for others to do so. I think that whenever we find ourselves involved in helping someone else change, the first question should be “what can I do differently to make it easier for them to change?”

Often the answer will be that we have to do a little work that “is not our job” or falls outside of the box, but if PMOs are to be centers of change, shouldn’t we lead the way by changing ourselves rather than expecting it of others?

Week 25 (Building a PMO) - Lessons Learned? - Process

In project management, we generally group our processes under the heading of “methodology.” For some reason, I think methodology brings a more formal connotation than process. Either way you slice it, the way we do our work is what those of us in the profession are all about. The PMO is the corporate manifestation of the need to improve the way we work. So, what did we learn about how to work together on this particular project? I think five of the top 10 lessons were process related. The list and discussion follow.

1. We left management and planning unattended for too long.
Bet you never heard that one before! Without going into a rant, essentially we began the project with a boilerplate project schedule and methodology that was designed for small projects of this type. The schedule called for a 16 week step by step implementation. That went down the drain almost immediately and now 17 months later – TA DA! We go live. If you are going to plan – do it! Do it right, do it often, and don’t let convenience dictate how long you are going to plan. On my other project, we have a two-day planning session coming up this week. Guess how long we are going to plan? Not until we have a good plan, not until we have a shared understanding – two days – that is it for a 12 month multi-million dollar project the entire leadership team is getting together for exactly two days to plan! Boy, are we good! ---- ooops I’m ranting – suffice to say, my opinion is that planning may not always be perfect, but I’ve never been on a project where I didn’t see a lesson learned like the one above – and I’ve never even heard of a project where people said that they wish they hadn’t spent as much time planning.

2. We had the most success when we were all informed.
Communications! There is an interesting story here, and while it is not the only communication situation that helped us, it is one worth telling. Since about mid-December, the project has been hanging on by a thread with looming deadlines and a lot of nail-biting. We gave one of our weekly reports to the board, and someone suggested that we might benefit from a daily call – touch point, stand-up, type of thing. Well, that went over like you might expect – “I’m too busy to take time out every day for a call”, or “I know what I need to do” “That would just slow me down” and so on. We decided to adopt a method that I think I stole from scrum. First we scheduled the call for 15 minutes. During the call we went through the roster and each person said what they did yesterday, what they planned for today and any situation that might be keeping them from accomplishing their work. For the first week or two we had abysmal attendance, of about 15 invitees we were lucky to get 5. We persisted and elevated to the board asking that they “encourage” their team members to attend. That ultimately worked and for January and February we had great attendance. Some times the calls went long, some times we were less disciplined that we would have liked, but the #1 positive feedback I got for lessons learned was on how much the daily call helped. Almost every participant in the call mentioned it as one of the 3 things they would do again. It was really rewarding to see that popping up so often as I got the responses.

3. Once engaged and informed, management responded quickly and helpfully.
Yes, “once engaged and informed” are the key words here. We had a real problem being succinct and persistent about our needs. Of course without a schedule or a good understanding of the work, that was hard. However, every time we were able to say what we needed, for how long and when, we experienced great responsiveness. This then is the key. Don’t raise vague complaints – the team was working long hours and making little progress, but they were unable to clearly express the need. Once we sat down, thought about it and gave a clear definition - we needed an Access expert who had some product knowledge for about 3 – 4 weeks at least 50% of the time. The executives fell all over themselves getting the right person, and while it was a bit more than 4 weeks and quite a bit more than 50% of the time, everyone hung on and we got through it. Moral – know what you need before you ask.

4. We did things right, wrong, and mostly late
This is typical of every project. We made a lot of mistakes in how we approached the work, in how we solved some of the problems, but I think these were all exasperated by our lack of clear objectives. We did not have critical success factors or a good schedule initially, so we were not able to keep the project on target. Everyone had a sense that things were going bad, but we often waited or delayed either through optimism or ignorance. Then when it got really bad, it was too late to recover by any normal means and we had to call in the cavalry. Only long hours and additional people allowed us to pull though – the sign of bad planning and waiting too long to acknowledge (recognize?) a problem. There was a lot of good work late in the schedule that if done earlier would have been higher quality and easier on everyone.

5. A great customer relationship got us through many challenges
There are a lot of ways of looking at this. My favorite metaphor is the “open kimono” one. Doing business with full transparency in my book is the only way to go. That doesn’t mean giving up the company secrets, but it does mean keeping the customer informed and if at all possible making them a functioning part of the team. Too many managers try to censor the information that goes to the customer so that they are giving the customer a specific contrived view of the project. Everyone sees through this and it does little more than cause distrust. You may be able to control the information flow, but the customer will know that something is being held back. How they react to that differs among customers and people, but it is rarely a good reaction. In our case, we had weekly meetings and discussed any level of detail that the customer wanted. We discussed our process and schedule, and when we were late, we talked about that too. The customer knew that we has their best interests in mind and they trusted us – not blindly, but because we were open and honest. The customer team was exactly the same sharing their challenges – all this lead to better understanding. When we hit a rough spot we hit it together, and that is a partnership – no hype or glad-handing, mutual respect and trust.

There you go, only one left for next week – tools – maybe I’ll cover it now. We didn’t have the skills and tools needed. Make sure these are lined up and immediately available, or you will be left scrambling. My father in-law is a wonderful mechanic, electrician, plumber, you name it, and he ALWAYS has the right tools – and that makes all the difference. When you can’t seem to get things to work right, find an expert and ask – they will have the right tools – which reminds me that my new hand-built computer still refuses to power up – time to have granddaddy over to visit the grandkids and maybe take a look at my project :-)

Week 24 (Building a PMO) - Lessons Learned?

If I take the lessons learned from last week and look at them, I think we can logically divide them into 3 categories – People, Processes, and Tools. These are the building blocks of every organization or project. There is a lot of overlap in these lessons and some fall into all three categories, but the division works for my purposes here.

People: The people lessons were:

• The people we had were great; there just weren’t enough of them.
• Unclear roles and responsibilities led to confusion and loss of precious time.
• We were slowed by constant competition for resources.
• We did not have a clear understanding of the work when we estimated.
  

These issues paint a clear picture of our project and our main people-related challenges. We were consistently understaffed, competing for resources and often confused about who should do what. What is not mentioned here is that there were effectively 4 project managers for this one project and no one had full authority – so there’s the answer to the confusion problems.

As I look back, it is possible we did not get the people we needed due to political skill, combined with the lack of a single project manager. Let’s face it, obtaining needed resources within most organizations today has more to do with how good you are at asking than how much you need them. In our case, I think we might have allowed ourselves to be victims. When we did not have what we needed, we often rolled up our sleeves and gave it our best shot while half-heartedly asking for help. This tendency towards action meant that we tried first and then ended up pleading for people only after we had gone down the wrong road. Better to get the right people in the first place, or manage this as a risk with contingency and mitigation plans (longer timeframes, training classes).

The roles and responsibilities problems started from the beginning. The project initiated as if it was a typical, small installation project. These projects generally take 16 weeks; ours ended up at 17 months. This miss-categorization set unreasonable expectations and incorrect staffing. The roles assigned “project manager”, or “business analyst” have a completely different meaning for a 16 week boiler plate project than they do for a 17 month implementation. It took us a while to discover this, understand and adapt. Even as we end this, no one person speaks for the project, fortunately we all speak with one voice – more or less.

Lastly, competition for resources was a constant problem. Only one person was full time on the project up until about 3 months ago when the full-time staff doubled to two people! This excludes IT development staff who were often full time for short periods according to the development schedule. In most cases, we would get a statement of general support without specific date and effort commitments. Then, when needed the people were able to only dedicate a portion of their time, extending the deliverables. Fact is we did not account for that. Maybe that is more the problem than the unavailability. Seems we did not learn from this and plan accordingly. We didn’t do that. We didn’t because it was too hard to get everyone together and we were too busy “doing” the work to take time to plan it. OK – we knew that was wrong, but we accepted it as better than nothing. The error was that we did not add this as a risk and raise awareness to the “powers that be.” I’m starting to feel pretty stupid; I seem to have mistaken some progress for good progress. Isn’t any progress good? Isn’t there a quote that says something like: good is the enemy of great? I’m not feeling so great right now.

Week 23 (Building a PMO) - Lessons Learned?

Well, one of the major deliverables for one of our customers has arrived – we are going live on 3/1! As of this writing, it really looks like we will make it, and with quite a few reasons to be proud. We will be implementing a considerable part of what we planned, and in some cases, a little extra. Of course since we had no real success criteria, the idea of a successful implementation is not applicable. How can you succeed if you don’t know what success is? I’ll get to that another time… Today – lessons learned.

First, I am an advocate of learning lessons at all times during the project and recording them as they occur, something that I did with this one. My reasoning is that we tend to forget over time, so waiting until the end of the project may result in lost lessons. Also, after a project is completed, we all have a tendency to paint a slightly rosier than real picture of what happened. The aura of success (or even just getting the darn thing over with) can create a euphoria that makes things look - not so bad.

The reason I added the question mark to the title is reflective of my skepticism that we are actually learning here. I propose that a well-run project will have lessons learned that relate ONLY to the parts of the project that were new. The other parts, I expect we would have learned from already. Now, that is not to say that continuous improvement is not possible, but rather that the “lessons” from continuous improvement are a different order of magnitude than those from the newer parts of the project. That is – if you have been learning in the first place! I think we are learning a little, but not as well as we could. One of the jobs of a PMO is codify or ingrain these lessons into the culture and processes of the organization. This way we can collectively and consistently learn these lessons rather than learning them individually and unpredictably.

So here are some lessons learned form the most recent project in our current program – how many of these do you already know?

1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.
5. Once engaged and informed, management responded quickly and helpfully.
6. We did things right, wrong, and mostly late.
7. We were slowed by constant competition for resources.
8. A great customer relationship got us through many challenges
9. We often did not have the tools and skills needed to do the best job.
10. We did not have a clear understanding of the work when we estimated.

I am sure every one of you can relate to these lessons. These were not all the lessons, but these are the ones I think we already knew. Yet somehow we did not learn from them in the past. Why? I think I will break these down a little over the next few weeks and look at them – surely there is a reason, or reasons. Hmmmm.

Week 22 (Building a PMO) - POWER!!

Power – yes, power, it brings up all sorts of negative references – “Absolute power corrupts absolutely” being the most famous. Well power exists and it is used and misused every day, mostly misused or abused. I’ve recently been able to observe and better understand the workings of power. I’ve seen manipulation, abuse and absence. I want to talk about the absence of power as my current assignment has taught me a lot about that.

First, let me talk about the difference between power and influence. Influence is absolutely necessary and vital to everything we do. When you can use influence do so, use power only as a last resort. No matter what position you have, working jointly with someone and using your mutual respectful relationship to come to a decision is infinitely preferable to using power – EXCEPT – when you can’t agree, or there is not a relationship of mutual respect.

So therein lays the benefits (even necessity) of power. As hard as it is to believe, not every working relationship is one of mutual respect and cooperation – no news flash there! Now, I think the first job of all of us is to create that kind of relationship. Everyone benefits when these relationships exist, including the company and the stockholders. Therefore, it is inherent in your job as a manager to build and maintain these relationships and influence. But sometimes, things just have to get done. That is when power can be adeptly applied towards success. Where there is no power, there are problems.

Consultants have a unique perspective on power. We are ultimately powerless. Any perceived power is simply a very strong and widespread influence. Being the only expert in the room often gives the illusion of power but, as we have all seen, power trumps influence. Being powerless is a great motivator to learning about power – trust me on this one! One thing I am learning is that when power is not defined and understood by all, there is a level of chaos that is expensive and detrimental.

A project without ONE single project manager is a project at risk. The more project managers the more risk. This seems so obvious that you might wonder why I am saying this. Power and politics often create situations where there are multiple project managers. In my current assignment there are at least 3 projects managers on the two major projects. One could argue that there are as many as five on one of them. The organization started simply enough and the story goes something like this:

We have a project that will involve many different areas of the company – it’s important to all of us, so we want each area to assign one of their best people to the project (and part-time only, but that’s a later blog). Of course this usually means managers get assigned and usually some wrangling goes on where these people all end up being at the same organizational level (i.e. pay grade). So now we have 3 to 5 managers all with separate areas of control as the “appointed leaders” of their area. Here is where organizational culture comes in.

In most organizations territory is closely guarded, so each appointee has some mandate from their management to protect the interests of their group. There is also some tacit or actual agreement that each appointee will have “final say” or power over anything that impacts that area. See the problem? Makes you want to scream right. Believe it or not al this seems very logical from the point of view of those making these decisions. Well to my eyes, here is the 800 pound gorilla. THIS IS A PROJECT !!

This project must be impacting multiple organizations or we would not have involved them, so there will be many decisions that impact every organization involved and some of those will have to favor one over another. Since we now have a group of equals who are first dedicated to their organization, they will fight for the decision that is in their interest. This can lead to a plethora of wasteful activities. Imaging if these people are not working from a position of mutual respect and trust! That means a struggle at almost every decision – and projects have a lot of decisions!

One of the ideas of projects is to create something that is greater than the sum of its parts. With shared (and I use that term loosely) responsibility, each leader is looking out for their area and the picture of the project to them consists of “mine” and “not mine.” This creates several problems. Not everyone’s definitions of mine/not mine agree, so you have areas that several people feel they own (mine, mine); and those areas that no one owns (not mine, not mine). The only place where there is harmony is when something thinks they own something and everyone else considers that thing “not mine.”

Conflict arises when the views of the appointees do not agree. Obviously, if several of us think something is ours, a direct conflict over ownership and the power to decide ensues. If everyone thinks something is “not mine”, then we might all just drop it, or even better one of us might decide that that something is “yours” and YOU need to do something about it. Ah what fun that is! Try to get someone to work on something for which they have no sense of ownership! So begins the joyous practice of finger pointing and CYA that we all enjoy.

What a load of crap – all this because some people were more interested in having some power than in getting the work done for the company. Here a single, responsible person with power can save huge amounts of money and time and achieve success for everyone. Seems too many of us would rather lead in hell than be part of a winning team which I guess explains a lot of the working environments out there today.

I need to think of some way of creating a scenario or game that shows how ineffective this is … hmm.

Week 21 (Building a PMO) - Reporting part 2

So, last week I talked about Just in time reporting – getting the information to the right people while it’s “hot.” This week, I want to talk about getting the right information there. This can be tricky! There are some serious pitfalls. There are problems with giving useless information, presenting the information incorrectly, giving too much, too little and so on. Let’s start with the quantity of information.

You will rarely hear your stakeholders ask that you give them less information; because of this it is your job to start with a little as possible without giving so little as to be meaningless. Ha – that was easy to say! It has been my experience that every time I present information I get good comments about how the information can be used, and am asked if I could include “a breakdown by month”, or “a list of projects over $1million”, or…. This means that if you start with a lot, you will end up with too much information and the associated excess of work. So what is enough?

Let’s look at it this way; you are usually producing reports for some level of management. So what do they want to know? In my experience both as a provider and recipient of these reports, the primary questions are: How are my resources being spent (time, people, money)? Will we do what we said we would do? What can I do / what do you need of me? Although these are all closely linked, let me address them individually.

How are my resources being spent? Any project is an investment by your stakeholders and they want to know how their investment is doing. Did they spend the right amount? Are the resources the right ones? Will the investment pay off? In order to answer these questions, you will focus on the past and the present. These metrics or measures are often seen in dashboards. So some examples would be milestones, earned value, budget, time spent, adherence to schedule, utilization and other similar measures. The purpose here is to say – you (the stakeholder) have invested this (money, people, and time) in the project and we have created this (value, product, service).

Will we do what we said we would do? This relates to commitment and promises. Each project is a promise to meet a need or want of a stakeholder. Those who are receiving the end result of the project want assurances that they will get what they want. While those contributing to the project want assurances that their investments will produce the desired results. This information will focus more on the scope of the project than on the cost / time aspects. Measures here might be number of requirements met or forecasted to be met. Change control information, quality measures, achievements and deliverables demonstrate that the project will achieve what is expected.

Finally, management wants to understand what is needed of them. Everyone wants to contribute to the success of the project, but it is not always obvious how this can be done. Most of those reading your reports do not have intimate knowledge of the projects and do not know immediately what is needed. It is then your responsibility to simply ask for help as needed. Do not assume that any fool seeing this report would know to do such and such, simply ask for the help and explain what is needed and why. If you need more time, money, resources ask. If you are stalled because of a particular problem, call in the big guns. That is what they are there for.
Well, that’s all well and good, but what does a “just enough” report look like. Here is my criteria:

1. KEEP IT TO ONE PAGE LONG AND NO LONGER !!!!!!!! (I can not stress this enough) – if you can’t say it in one page then don’t expect anyone to listen and it is YOUR FAULT – management does not have time to read excruciating details about everything they are involved in or responsible for. That’s why they hired you! Give it to them short, accurate and ON ONE PAGE!!

2. Use illustrations and diagrams whenever possible. This is not because words and numbers are too complicated for pointy haired managers, it is because pictures communicate more information in less time and with greater accuracy. If you haven’t studied work by Edward Tufte then do so. The expression of information is vital in our work for so many reasons.

3. Answer the three questions above. If you don’t, you will be asked these questions every time. Take care of this up front.

4. Tell a story. Make your report more that a point in time snapshot, show the past and predict the future. Some models are good at this – EVA has a lot of potential. One that I use is to show simply actual expenses against budgeted. I use a graph with a line showing actual expenditures up to the current date with a colored in area showing past and future budgets. Bind the past, present and future together in a consistent flow that tells a story of your project(s).

5. Keep the format consistent – same things at the same place on the page every time. Do not make the recipients of the report search for the information every time.

6. KEEP IT TO ONE PAGE – oh – you get the idea – really if they want more they’ll ask. Trust me – you don’t get to Senior management by being shy – keep it to one page, everyone’s life will be better for it – and you will rise to the challenge of presenting just enough information just in time!

Week 20 - (Building a PMO) Reporting

I’ve been thinking about reporting a good bit lately. What makes good reports? What type of reporting is the PMO responsible for? When? What? To whom? And so on. I have been working recently on streamlining the reporting we are doing on the project and yet providing more information in a more useful and timely manner.

I am a minimalist at heart. I believe in one-page. From a reporting perspective, there may be a need for more than one, but I think that the PMO that provide management with a one-page comprehensive status report has found the Holy Grail of reporting. My quest is probably equally romantic and impossible, but I think there is a lot of room for improvement out there.

Let me start with two components that I have been struggling with lately – I call them the “Justs.” They are Just enough information and Just in Time. I’ll start with the latter as that is the more familiar.

Just in Time started as an inventory management practice and Dell showed the world how effective and profitable this can be. Just in Time reporting refers to the freshness of the information. We have all walked into a meeting with management to review the reports we sent out yesterday knowing that some (perhaps many) pieces of information were no longer accurate. Face it, by their nature, projects change quickly and frequently and they have a terrible habit of being unpredictable. Part of the problem is the ever popular hierarchical reporting methods.

To use my current situation as an example, I have a weekly board meeting every Wednesday morning. At this meeting we discuss the current issues, action items, and status for the two programs we are managing. These programs consist of multiple projects from multiple departments. One of those departments is IT. I get the final set of IT information on Monday afternoon for presentation on Wednesday morning. Let’s look at how that information gets to the board.

Working backwards – On Monday the consolidated IT reports are reviewed by IT management and approved for general release. These reports are created on the previous Friday afternoon from a collection of status reports by each project. These individual project reports are due by end of day Thursday. Each project team puts their report together in the day or two preceding Thursday. In this case the IT information that the board reads on Wednesday morning is a week old. A lot can change in a week. Unfortunately this means that we often report tasks as incomplete and behind schedule when they were actually completed on time.

We take a different approach on the business side. Here, there is a full program meeting on Tuesday morning. At this meeting, each project leader and team member reports their status as of that moment. The project manager updates the schedule, issues and action items right there. The program level report is published immediately after the meeting. Since the PMO is present in these meetings, we are able to produce the business components of the weekly status right after the meeting as well. This means that on Wednesday morning the board is hearing about information that is less than 24 hours old.

There are two circumstances that influence the difference. First, the business organization is less hierarchical and less formal than IT. This allows much quicker communication. My observation is that IT is oriented around structure, process, exactness and consistency – all of which contribute to some excellent, stable and reliable systems. Unfortunately, this means that non-emergency information has a long way to go to be seen.

Secondly, the PMO is directly present in the lowest level of the business meetings while we are not present in the lowest level IT meetings. This means that we get the unvarnished “raw” information straight from the people who know it the best. This enables us to better understand the information and to weigh its importance and urgency. This is not the case with IT.

I think the solution is two fold. First, set up a system and process that has the shortest amount of time between the collecting the information and reporting it. Second, eliminate every step possible between the collection and reporting. The fastest this can be done is obviously to have the person collecting the information turn right around and report it. Even better have the recipients of the information hear it first hand. Of course, it is rarely possible to get today’s busy executives to spend that much time listening to details. Don’t forget, your value-add in the reporting cycle is to aggregate, summarize, separate useful from useless, and elevate the important.

To parallel this to Just In Time supply management, getting information from the business is like going to the orchard to pick the oranges while the information from IT has to be obtained by driving to their grocery store and waiting until it is stocked on the shelves. Go to the orchard, pick the best fruit and get that to your board right away.

PMO Reporting

Reporting is often viewed as a less-than-glamorous responsibility of the PMO. I think that reporting is probably one of the most visible methods that a PMO can show value. The PMO reports go to management and those managers and executives make decisions based on your reports. By providing accurate and timely information in those reports, you – the PMO – are ensuring that the foundations of corporate decision-making are solid and built on the best information available.

With that as your mission, there are several different types of reports that the PMO may be responsible for: department reporting, project reporting, portfolio reporting and PMO reporting. Let’s take a quick look:

Department reporting takes several different forms; one common form is resource management and projections. These focus of these reports is to give information on a department or group.

Project reporting is probably the most familiar, this can take the form of your red/green/yellow status reports, buffer reports (for those using CCM), or earned value. These reports give information on a project or projects.

Portfolio Reporting gives information about a collection of projects, some common reports are the pipeline report which shows where each project is as it moves thorough the project lifecycle. Other reports include a project priority list, resource and cost projections, and possible other more sophisticated sets of information. While project reports are more tactical in nature, portfolio reports are used more for strategic decision-making.

Lastly we have PMO reporting – This is simply reports that tell how the PMO is doing. Some examples are budget reports, balanced scorecards, staffing and others.

Each of these reports offers you a great opportunity to demonstrate your PMOs independence, neutrality, honesty and consistency. They are also a great marketing tool.

Marketing your PMO

Yes, Marketing your PMO. Good, bad or otherwise, this is one of the primary jobs of the PMO Director. If the leader of the PMO is not doing this, then who will be? You want your organization to grow in knowledge and capability and you want to share how Project Management can help your customers better achieve their goals. There is nothing that helps you communicate this more effectively than the practices of Marketing.

If you’re like me, you’ve seen that vague smile and zombie-like glaze that comes over your loved ones when you start talking excitedly about how you were able to streamline the change management process by reducing the number of steps, modifying the forms and blah blah blah.... – Now imagine if the people you were talking to didn’t love you?

There is a lot to learn in Marketing and I won’t pretend to be an expert, but let me suggest three simple steps - I think you will find these effective, I have.

First - Find out how you can give value to your customer through project management.
Second – Give them that value with no strings attached.
Third – Talk to them about how you were able to achieve what you did.

I can’t tell you what your customers will value, but they can. Talk to them and begin your marketing campaign.

Week 19 (Building a PMO)

Distributed v Centralized PMOs

Yeah, I’ve skipped a few weeks. My official excuse is that those were the holidays and not much was happening. Since you all know it’s because it was the holidays and I got lazy, let’s just pretend.

A comment I got a few weeks ago about staffing has had me thinking about PMO models. There are a lot, but the two extremes that come to mind are the highly-centralized versus the distributed. Let me just set my definitions of these two and then talk about where I see the problems and possible solutions.

Centralized PMO – this PMO would contain almost all the project management work, knowledge and oversight for a single group or organization. Within this department would be all the project managers, PM trainers, methodology and tool experts, mentors, and PM specialists. If you want project management, this is where you come.

Distributed PMO – in this model, the PMO is very small and probably contains no more than a few people who have primary responsibility for the tools, methodology and maybe reporting. The PMs and specialists are distributed in the teams, and PM training would be part of corporate training.

There are a lot of advantages and disadvantages to these models. I still hold that the centralized model is more effective to the larger organization overall, but that is not the point of this post. What I have been thinking about is how to use the best of these models in a more effective manner, so here are my thoughts on a hybrid model.

First we start with the model of a centralized PMO, but we limit the involvement of PMs from this area to only certain types of projects (strategic, cross-department, high profile…). Or – and I think this is one of the key benefits of a centralized PMO – these PMs would be available to help departments that do not have their own PM. All other projects are handled at different levels of the organization by “imbedded” PMs. This removes some of the staffing and inequality issues related to a central model.

Next we need to address the tendency of distributed models to move toward entropy with the PMO becoming ineffective methodology police. I have a real personal bias towards this, because I did not get into this career to run around telling others that they needed to run a phase-gate review using forms 21 – 36 before they could go on with their project. I believe that this creates an atmosphere of compliance and that is not what we are about.

So, how to move from compliance to integration where all PMs regardless of location use the same practices and procedures because they are the right ones, not because they are the only ones? I don’t have a full answer, but I think there are several steps in the right direction.

1. Project Manager Rotation. This can be pretty tricky, but I think we should look at having this as part of a PM’s career path. The project manager would serve a certain period of time in the PMO (as a mentor, trainer, strategic PM, portfolio manager…) and another period as an imbedded PM. In fact moving from group to group would also work well. With the addition of timeframes such as no less than 6 months and no more than 2 years, we can keep up the circulation without constantly upsetting workflow.

Cross pollination of team members will create a group of project managers who have worked in multiple areas of the company. They have shared their knowledge, and learned about the business. This is consistent with the value of integrating project management within the organization. This also creates a cadre of professionals who have a wide understanding of the business and of management – not bad for any organization.

2. A simple, flexible methodology. I know I harp on this a lot, but complicated methodologies are difficult to sustain, manage and follow. The truly useful and efficient methodology will be very simple, flexible and will not change often. Maybe methodology is the wrong term, maybe better a set of guidelines, practices, values and a framework. Trying to integrate a methodology with hundreds of forms and process steps is irrational in almost all cases.

Some other ideas come to mind, more on those later. I have to go move a refrigerator.

Week 15 (Building a Program Management Office)

Week 15 – The price of Trust

Pretty amazing thought, but I’ve been noticing just how valuable trust is and how expensive distrust is.

Think about how much easier it is to work and interact with those you trust versus those whom you either distrust or who you just don’t trust as much. I think in the working environment, this can be greatly influenced by the management team. I was fortunate to work in a company where trust was an integral part of the culture and in others where CYA was the norm. I got a lot more work done in the former than the latter.

Trust impacts a lot of areas of your work life. The biggest and most obvious I think is communication. There is a completely different level of communication with those you trust and those you do not trust. Communication with those you trust is often less formal and overall richer in content. You are more likely to have a face to face with those you trust (you probably like them more). Face to face is the richest form of communication; you convey much more than just the words. You can communicate greater range of meaning and emotion.

On the other hand, those you do not trust are more likely than not to get an email. Probably one that has a few cc’s – just in case. The email is likely to be very factual and directive – “I need such and such by Tuesday.” You’re unlikely to convey emotions (emoticons not withstanding) or any richer channels – you probably even avoid verbal communications.

OK, yes I am talking about myself as well. I find that distrust leads to more distrust and avoidance and thus non-communication and ultimately ineffectiveness which hurts everyone and your project. Therefore, I conclude that it is counter-productive to distrust someone – regardless of their prior behavior. So, I can’t remember who said it, but the motto goes “trust, but verify.”

I’m going to work on adopting that. It is unprofessional for me not to verify and ensure that what is committed is done, but at the same time it is unprofessional (and unproductive) for me to go on the assumption that it will not be done, or not done well. I think I will save a lot of time and heartache personally.

Let me suggest then that trust is not earned it is given, and that we should give it freely and constantly to those we work with. Yes, just like Charlie Brown always going for the field goal with Lucy holding the ball. If you are in an un-trusting work relationship, it is time to take the first step – just like I will on Monday.

PMO Staffing (short)

Many PMOs today are made up of teams of professional, dedicated Project Managers who are assigned to projects throughout their organizations. One job of the PMO is to put the right PM with the right project at the right time. Because of the nature of projects, this can be VERY tricky. Even the best resource management can be inadequate when a project gets into trouble, or when several projects get behind schedule.

Staffing is also prime target of politics. Without a project prioritization system, the assignment of project managers can (and often will) be viewed as arbitrary, unfair, or biased. One way to counter this perception is to be scrupulously independent in everything you do. It will not help all the time, but being know as fair and unbiased in the little things will serve you well when it comes time for the big decisions.

Another staffing political pitfall is more subtle. In these situations, one group starts requesting a specific PM. If Joe did well for Accounting in the last project, then they will probably be asking for Joe again. They will hit you with pleas like “he already knows everyone here”, or “he’s familiar with the way we work”, and more. It sounds immanently logical and that’s the trap. Going down this path will turn Joe into “the Accounting PM.” And if Accounting has their very own PM why can’t everyone else? And why isn’t Accounting paying for him? And finally, why doesn’t he just report to accounting and we’ll get rid of the PMO?

So be careful how you staff your projects and keep the long view in mind – someone has to.

Week 13 (Building a Program Management Office)

Well full week back after the Thanksgiving break. This was another travel week as we installed a PM at one of the project locations. The PMO has now doubled in size to two!! I think the new PM will work out great as she is working in the location where all the business teams are located and those are the people who have to live with what we implement.

This week did once again cause me to think about roles and identities. What is the PMO? What is a project manager? It’s easy to say “it depends”, but when there are people and projects involved, we need to have a clear definition. I have already learned that if there is more than one boss, there is more than one definition of your role. This is doubly true for consultants.

In bringing on the new PM, I am concerned that she is being under (used/appreciated?). In this case, the PM is certainly capable of managing a large part of the project and she could certainly provide some very useful advice and counsel to the leadership team. Because of the perceptions, this is just not likely. The perception is that the PM is there to do the support work, and that’s it. I brought the new PM to the board meeting and I was asked by the business lead why I brought her –as in “she is not this level so she doesn’t need to be here.” This pretty much defined at least our starting point.

Again, it comes down to people and I have a real problem here. Clearly, we (the PMO) were brought on because of our knowledge and experience, yet this is rarely sought and often unwanted. Why would anyone seek a particular set of expertise and then ignore it or leave it on the shelf. It is like buying a high-powered computer and doing nothing but web surfing. Strange, what does this mean? Well I have a theory.

I think that the problem is one of comfort and understanding. Using the high-powered computer example, if all you know is web surfing, then that is what you’ll do. They see the computer as just able to web surf faster and better, and do not see that they can produce multi-media presentations or do their taxes or run a small business – or even better – play the latest graphics-intensive games. So the challenge there is to raise awareness. The second challenge is to make them comfortable with the tools and techniques of project management. So how do I go about that???

Well, first thought is that I have to become more assertive and aggressive. I can’t play a passive and supporting role; I have to take an active and leadership role. And that will certainly piss someone off. I don’t seem to be having a lot of luck in the persuasion department, so I’m going to take some things on myself (more work, but hopefully more success) and I’m going to push for some other things. One of which will be to have full-blown planning session for one of the projects – that could be successful, but not if everyone comes in with a bad attitude – which they will if I do this wrong. Well, this is the time of year when everyone is supposedly in a good mood; maybe I can leverage some of that. Ho Ho Ho.

What's a PMO (short)

I’m sure that many of you have been asked this question and even pondered it yourself. If you are lucky enough to be building or managing a PMO, you’ve probably been struggling with the wealth of information and definitions that are available. Every PM pundit has their “anatomy of PMO” or ten essential components of a PMO. Well, you can relax; I’m not going to add another myopic pronouncement to the mix.

Instead, I’m going to suggest that this is the wrong question. The question is not “What is a PMO” but rather “What is YOUR PMO.” While PMOs certainly share common characteristics, those characteristics describe a PMO and do not define it. The only definition that matters is the one you and your stakeholders have created.

Your PMO will serve the needs of your community, your company, your management. Your PMO will be unique and effective within your environment and not a manifestation of some theoretical model out of a textbook. Next time someone asks “What’s a PMO” – tell them about YOUR PMO.

Week 7 (Building a Program Management Office)

Week 7

In spite of everything, we went into the meeting to present the requirements and it was a disaster. Everyone had a different agenda and opinion about the requirements. We discussed AGAIN things that I swore we had resolved. The program managers and I got together and did a quick lessons learned on the whole thing. We discovered what is probably obvious.

The meeting with everyone face-to-face was a great idea and worked well. Other things that we did well were to keep a single list of the requirements and work from that whenever we got together. The consensus was that the communication was good as well, and that everyone on the team was kept up to date on what we were doing and what was decided. And that is it for the good news.

On the lesson side many of the mistakes were mine. Communication to the board was not good or clear, and the board was well behind what the team was doing and needed to be brought up to date before we could give them the current status. I did not keep track of this and start from the last time we talked with the board and moved them to the decisions the team made.

The team did not have consensus going into the meeting and the communication was ad-hoc. We needed to clearly agree on who would talk about which requirements and what each of them would say – hopefully what we all agreed on! If we added an agenda (yes I did not put out an agenda – I could kick myself) with the appropriate information, then it would have been smoother.

I think my take from the whole thing is that I need to be much more formal and complete with any communications to the board. I hope the next one works, I’ve spent some time putting together a presentation for the next meeting – Tuesday’s monthly meeting. As I was doing that I realized we needed a lot better information about our projects. We really don’t have any metrics at all. We do use the red/yellow/green, but it is not as objectively determined as I would like so building metrics is my big goal over the next month.

What I am thinking is keeping it simple with schedule, compliance and goals. We do not really have good project goals. I mean basically we have the “get the job done” goal, but no real way to tell if we are making good progress towards the goal. We can tell that we are working hard, but not that it is on the most important things. I’m going to interview the board to get their goals, aggregate them and set up some criteria that we can check against.

Schedule will be kept simple – on schedule, off, etc. The problem here is that we do not have good schedules. That is what I’m working with the teams on during week 8. I expect that we will have something with milestones, deliverables, and good dates. I’m sure this will help everyone at least have a better picture. I am learning that project schedules are a lot more fiction than reality, but we are going to work on that.

Lastly I’m going to use compliance as a metric. The first metric will be the weekly reports then probably keeping the schedule up to date. Don’t know what else, but I’ll think on this. I normally hate these metrics since they look like tattle-tailing, but I think this is one of the only ways we are going to get the teams to do the work needed to produce the information for metrics. We’ll see wont we?

Soldiers

Sorry for being out, between contracts, vacation and my laptop being in the shop, things got a little hectic. I want to continue with the discussion of heroes and soldiers. I think we all agree we would like to have a hero around when we need one, but that a team of heroes can be a little – shall we say “sub-optimal.” On the other hand, a team of soldiers can really accomplish anything.

Soldiers

When I refer to soldiers, I am not talking about clones or mindless robots that follow orders to the letter and sacrifice themselves in droves at the whim of their commanders. No, the soldier I am talking about is the professional soldier. Think Roman Legionary or any of today’s highly trained military. With proper management, diversity and organization, a Project Management Office built with good soldiers will be very effective in changing and sustaining a culture of project management. That said, our soldier type has some characteristics that we want to be aware of.

• Soldiers are disciplined: This is one of the main differences between a soldier and a hero. A soldier can be expected to show restraint, paint within the lines and to follow company policies and norms. While a hero will often play “bull in a china shop”, your soldier is unlikely to leave a trail of broken dishes or irate coworkers.
  Soldiers are team players: Soldiers work well in units. There is a real synergy when a team of soldiers gets together to tackle a problem. Here is where you will really see the power of teamwork.
• Soldiers are Professional: Soldiers understand the company dress code. They understand and abide by corporate behavior norms. Soldiers approach their work as a craftsman would, seeking to do the best they can and with an effective combination of enthusiasm and thought.
• Soldiers are reliable: This probably sounds a little boring, but as a director, you understand the need for reliability. Soldiers help you provide a consistent level of quality in all things. When you send one to a customer site, you know how they will behave, you know they will not say or do anything outrageous, you know they will represent the Project Management Office faithfully. This is vital to creating a trustworthy image and perception of your PMO.
• Soldiers often Specialize: Many of your team will have an area that they are particularly good at. You may have a methodologist, or a trainer, or a mentor, each of us has different gifts and hopefully you will help your team develop those to everyone’s benefit. A specialized soldier working in their realm is about as good as anyone ever gets. This person is “in the zone.”
• Soldiers can be slow: As a rule, your soldiers will usually take a little more time to complete the work, or to address the problem than a hero would. If speed is your only criteria, calling up your soldier may not be the best option. Of course this is not true of all soldiers or all situations. A specialized soldier in her discipline can be as fast as or faster than any hero. Get the soldier out of their specialty, and things slow down a bit.
• Soldiers can be rigid: I am sure you have run into this. The team member knows how to do something, and does it just that way or they look at every problem the same way. To a hammer, everything looks like a nail right? This can be a real drawback when you are trying to institute widespread change. Inflexibility in your team does not set a good precedent or example for others to follow.
• Soldiers can be unimaginative: This goes hand in hand with rigid in some ways. Often soldiers are so good at working within the norms that they cannot see outside them. This gives a limited point of view with limited options. Many times these team members will talk about things in terms of “Right” and “Wrong” – with caps. Once that mind frame is set, it can be very difficult to break out to new ways of looking at things.

The Soldier Culture
In a corporation that has gone too far into the soldier culture tends to be very rigid and is all about following orders and procedures. These are by the book types of cultures to whom rules are paramount. As an example, I recently attended a convention for which I pre-registered. I went to the line to get my materials, and right next to me was someone handing out lanyards – I know I have millions of them, but she was handing out ones that had the convention name on them and all the packet had was the typical string ones. I asked her for one of the lanyards; she asked to see my badge; I showed it to her and she replied that the lanyards were only for the people who were registering onsite. I of course said – “you’re kidding right, it’s just a lanyard.” To which this obedient unimaginative soldier answered “no.” Mindy you she must have been holding 100 of these things. Her customer service ethic alone was abominable. But think from her perspective – she was told that she was to hand out lanyards to the people who registered for the convention on site. I didn’t so I did not get a lanyard. This is the kind of thinking that can pervade the typical soldier culture.
In these soldier cultures, the Project Management Office often becomes little more than forms police or methodology Nazis. While this may be comfortable for some, count me out. So what works?

The Warrior Culture
What is too frequent today is a conflict between the heroes and the soldiers. Soldiers call the heroes “loose cannons” or “cowboys” and heroes call the soldiers “pencil necks” or “suits.” They both see their way as the “right” way, so someone not working the “right” way is “wrong.” This fundamental assumption is the problem. I have a button that says “I’m right and you disagree so you must be wrong.” When this happens, any movement away from “right” is seen as compromise or worse. Guess what, there are a LOT of ways to do things. If there was a right way to build a car, there would be only one type of car, or house, or city, or family…. Take a look around, nature has the idea – diversity, synergy, cooperation.
The best (not right) organizations will have a good combination of heroes and soldiers along with the associated mindsets. You can have heroes that follow rules or soldiers that act independently in unfamiliar situations. Let’s call this the Warrior culture. The Warrior team is capable of organizing and attacking situations with the flexibility of heroes and the discipline of soldiers. Now that is where I want to work – challenge and stability, known and unknown, chaos and order.

Marketing Your PMO - Positioning Project Management

First a comment on some articles in the June 1, 2006 issue of CIO Magazine. The cover story “When Failure is Not an Option” is about how AG Edwards is making huge strides by improving their Project Management capabilities. Great stuff there for you, both in terms of practical advice on the how of getting this done. Too many people focus on the “what.” Also, showing your management that AgEdwards is doing this might give you some more ammunition in advancing PM in your organization. In the second article Sari Kalin talks about Portfolio Management. The article is short, easy to read and gives some excellent practical advice and spotlights Eastman Kodak’s work in Portfolio Management. This one is great for printing, circle a few key points and drop it off on your boss’ desk with a “thought you might be interested” comment.

With that as segue; I want to talk a little about the shameless promotion of the PMO and Project Management. Personally, I am not very good at this, but this is an essential part of your job as director. You are trying to institute a change in your company and the name of that change is Project Management. Even if you have a fairly fertile environment and a high maturity level, you still have to get out there and talk it up.

How many of you just said “yech?” Believe me I understand; Project Management is a good thing, that’s obvious right. All we should have to do is demonstrate success and everyone will see and want to implement Project Management immediately. As we internet geeks say – ROFL. For the most part, people will attribute your success to you, luck or some other factor. This is not to say that they do not appreciate it or harbor any ill-will to you.

We have been taught from the beginning that success is achieved through hard work, skill, perseverance and sometimes luck. When is the last time someone thanked a process for their success? OK, except for those infomercials that show you how to make millions in real-estate or surfing the internet. In our minds, success is a personal thing; even group successes are achieved through the personal contributions of the team members. We’ve grown up with great personal examples of success - heroes. This is another reason why the Hero Culture (see my July 3rd entry) is so prevalent. Admittedly, it’s not a bad thing for you to be associated with success, what you want to do is leverage the success to show people how Project Management can help them achieve success as well.

What you’re up against

Here is an example of the mental barriers you will face. Take a look at how computers are used. Today it is generally recognized that most workers can and do benefit from the use of computers. In particular, office workers get more work done with higher accuracy and in less time. (Of course we are now expected to do twice as much work in half the time). When mainframe computers and later personal computers came on the scene, they were widely resisted. There were still plenty of people doing their spreadsheets with calculators and typing memos on typewriters. Computers did not achieve success, they enable success. They were a lever that enabled people to do more, better, faster. Project Management is the same thing.

Position Project Management as an Enabler

When you talk about the successful completion of projects, spread the credit wide and excessively to every person involved. With this praise throw in phrases like “our PM processes enabled the team to identify and resolve issues before they became critical.” or “PM helped team members focus their efforts on the critical features that we delivered on-time on-budget.” And so on. If you can get any quotes from people – get them and publish them. Don’t force anything, you do not want false testimonials, you want something that the team members will repeat in 6 months without you around. The message here is that success does come from hard work AND Project Management gives you an advantage.

Position Project Management as a Tool

This is kind of an enabler too, but you will want to use the work tool, or toolkit. This model may work better for some people than the less tangible enabler model. In this case, you would rephrase the quotes above to something like: “Team members used the Critical Items log to ensure that they delivered the greatest value.” Not a great one, but you get the idea. An analogy here that I’ve use a lot is that you can hammer in a nail with a rock, a hammer, or a nail gun. We are tool users who are always seeking better tools, when you position PM as a tool, your message will resonate well.

Position Project Management as a Time-Saver

Personally, I like to position PM as a time-saver. My thought is that when you do a project, you will do the PM process one way or another. You will have to know what your issues are, you will have to know due dates, costs, resources, etc. You can either spend your time creating a method with each project, or you can use one that is proven to work, and change it as needed to meet your needs. So the quotes here are “the team saved significant time by prioritizing tasks using the Critical Items Log.”

Ultimately, you want to look for every opportunity to promote PM, but to promote different aspects and capabilities. You know your culture and the people you work with, some approaches will resonate, others will not. Part of your job will be to find this out and change your message to be meaningful. Don’t think that this ever ends, you will want to keep trying new avenues of communication and messages as things will constantly change and you will need to adapt – but you knew that!