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.

Week 14 (Building a Program Management Office)

Week 14 – Change Control, Capacity and Budget

As I look at our projects, we have about 15 months between now and final implementation. We also have all our requirements completed, defined and ready for programming. All this is great, but I’ve been thinking a lot about our ability to make changes (mostly scope) over the remaining time.

In looking at this, the first question is: What is our capacity for change? I think this has to be determined based on resources, schedules, lead times, budgets and the like. We may actually have the capacity to make a 180 degree change, or a series of changes that add up to that. In any case, I think each project must have some “change limit” – this being the amount of change that can be absorbed within the time and budget available.

The first existing method that comes to mind for managing change is the management reserve budget. The intention of this is primarily to deal with risks, but something similar might be arranged for change. Maybe a change reserve budget. This would then define the capacity for change up front and allow us to track against that capacity. I think that we could then add something called a “change rate” to allow us to better allocate that capacity across the project.

The rate of change would naturally (I think) have to decrease over the course of the project. So that while we might have the capacity to make say $100,000 worth of changes, we could not reasonably make all of those changes at once, nor would it be possible to make them all at the last minute.

I think that the rate would have to continually decrease across the duration of the project, and at some point (depending on methodology, flexibility, resources, etc) the project would not be able to sustain any changes - we used to call this “the freeze.” I think then that our change model would look something like that below:


I have not figured out how to determine a good rate, but the idea here is that we pace ourselves with our changes, and that if we try to make too many at any one point, we end up overloading the project- impacting dates, etc.
I know that the traditional model of change control is that we always assess the impact and elevate that to the “powers that be” for a decision on whether we can do the change or not. But experience has shown that we often end up making certain changes and not changing any dates. How many times have you heard “it’s only a week, can’t you absorb that in your 10 month project?” Well yeah, I did absorb the first 12 one-week changes, but this is lucky 13. Now with a “rate” or speed limit, you can schedule the changes, or push back if there is too much at any given time. One way might be to say that we can only accept X amount of changes for the next cycle / month / period.

I think that the concern I am looking to address is the tendency to use up our entire change budget at the beginning of a project and get ½ way through with nothing left. If we use the rate as a limit, then we can actually have the ability to make changes later in the project when they’re needed.

Another idea I hear was about prioritizing changes, I worry about this for the simple reasons that if you only have one change, then it is top priority. Then after you put that in the next change that comes up will be top priority. The priority system is useful when you have all the information in front of you, but with change, you don’t know what is over the horizon. If you did, you would have planned for it and it wouldn’t be a change and you wouldn’t need to prioritize it.

So I think the answer is to pace yourself. Whether you are running a marathon or a sprint, if you use up all your energy too early, you’re in for a hard time. If we use the change rate, then we know we will have the ability to handle at least some part of what is coming.

Of course, I have no idea how to determine a change rate, and as I think more, I realize that this will create a backlog of changes – which we can then prioritize! Hmmm

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.

PMO Support Function (short)

Support PMO services are often referred to as administrative functions, and may be considered “menial” or “trivial”. Nothing could be further from the truth.

A PMO provides support services to assist with the management of a project. The key differentiator between support and project management is that support is not a managerial role. A supporting team member will often update the schedule, run meetings, follow up on open issues and other similar tasks, but they will not have the responsibility or authority to make project level decisions. Supporting on a project is often a good role for junior PMs, showing them the processes and placing them with a more seasoned PM for mentoring.

Support is the hard part of project management and it is what often meets the most resistance. Team members do not want to take minutes, track issues and action items, produce reports and so on. As with all clouds, this one has a sliver lining and becomes one of the keys gaining project management acceptance.

If you – the PMO – perform the support function, your stakeholders can realize the value of project management without incurring the cost. This will open a lot of doors and minds. Providing exceptional project support then is one of the first steps in building a great PMO.

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 12 (Building a Program Management Office)

Happy Thanksgiving to those who celebrate the event. The holiday made it a short week for me and a welcome one at that. The big event this week was the November governance board meeting. This is a typical board meeting for a program, we start with a presentation and the board members ask questions about the information, we talk about current status, upcoming milestones, issues and the like. This month’s went very well and I contribute that to two factors. The first, I was prepared. I put together a good presentation, I reviewed all the information, I had all the raw data and reports and so on. One thing I am learning, at least in this particular program, preparation is key! The second reason I think things went well is that hardly anyone showed up – lots of people on Thanksgiving vacation – for which I am thankful!

The two hour meeting lasted about an hour and fifteen minutes. We had good conversations and discussions. Both projects have made marked improvements over the past two weeks and I think the teams are much more confident and optimistic. That is really half the battle sometimes. At this point, we have a fair handle on performance against milestones and schedule, change control, scope and issues. Not so hot yet on risks, resources, financial performance and a few other areas, but working on it. Since only one department even records time and cost to the project, we are not going to achieve more than a fairly low level of control and information in those areas.

The good news for this week is that we have a project manager starting in one of our locations to help with the project work. Our one office is doing a lot of the heavy lifting in terms of PM work, and it is not getting the attention that it needs. Our new PM will start off with some more administrative and analysis work, but I expect that they will have much more responsibility very quickly. I really look forward to this as I am hoping that it will free some of my time as well so that I can spend more on putting together a PMO guidelines that can be used for all projects of this time. If the company is going to get in this business, then having a method/standard of operations for implementation will be very useful!

Well off to run a few of those new found pounds off. I think 20 miles will do the trick – that would be…. Unlikely . There’s still some apple pie in the fridge…mmmmm

Week 11 (Building a Program Management Office)

Week 11 went well, if somewhat quiet. I think that a lot of people were worn out after last week. Big events were conversations with one customer and some good work on completing the project schedule for the other project.

Right now, one of the projects is working with our customer and the company that currently holds the contract to negotiate a live date. We had a change in scope and delivery and that caused all three companies to have to look again at the dates. Right now we are in a situation where we each have a date that works for us, so that makes three dates. I am sure after our discussions and negotiations we will come up with a date that is equally unpalatable for all of us. Such is compromise. I’m sure we have not heard the last on all this; it is going to be interesting.

On the other project, we really have a good workable project schedule. Now for the aficionados, no it is not leveled and based lined, with actual times and so on. That, frankly, is a little more than we can really expect based on quite a few things. The schedule does however clearly indicate milestones, major tasks and responsibilities. In other words, what needs to be done when and by whom. We have a bit more than completion dates; we do have durations and hence start dates. Right now, all of the tasks are 80 hours or less, and span two weeks or less, so we have a fine enough level of detail to be able to track the work carefully and elevate and or react as needed. I am not a stickler for the 8 – 80 rule or other such PM rules. If you read this blog much, you know that I oppose rules and forms and procedures that exist only to be complied with. If something doesn’t make life easier/better for the PM and the team then my vote is – forget it.

I had a presentation on Monday that gave me the chance to put together some of the project information in one consolidated format. We don’t have a standard presentation template. I have to confess that I enjoy presentations. I like the idea of putting together information in a format that in some ways can be artistic. If I have not said this before, I highly recommend Edward Tufte. He has some extraordinary examples of information presentation. His books and workshop are worth every penny! He talks about things like information density, sparklines (my favorite). He sums it up well as “simple design, intense content.” Not that my presentation would ever wind up in one of his books, but I am working on it.

Week 10 (Building a Program Management Office)

Week 10

I had another difficult week this week. We had 2 2-day sessions where we tried to get a better handle on the work for the two projects. We actually made a lot of progress, and I think at least one of the projects is on the right path. Granted the path will be very difficult and busy. We have a lot to do between now and the live date of 3/1/07. I think that the tone of the group is much better now than it has been and I honestly see them as a “team.” I honestly do not know why this group seems to be more of a team than the other project group. I think it is certainly something that I will look at more as the projects go on. The other project group is more a series of teams who are working together. I think that some of it has to do with the size/intensity of the project combined with the personalities and the overall organizational structure.

But first about this week; for the smaller project, I was assigned (volunteered?) to serve as facilitator. The goal was really to get a clear mutual understanding of the work needed to be done between now and the live date. My first step was to lead the team through a very high level breakdown of the project. Nothing really detailed, or down to the work package level. Instead we looked at the high level tasks and looked at the task to see how complex it was, how many dependencies there were, and how “independent” the task was. For most tasks, we did not go into a lot of detailed analysis. We did find one are of tasks that one member of our team nicknamed “the water-main” that represented the critical path and many associated important and highly dependent tasks. While we still have not done any critical path analysis, I am sure that most of these tasks will end up on the critical path, or the resource critical path.

To do the detailed analysis, we went low-tech. We started with the WBS created earlier and stated breaking down the tasks and sequencing them using sticky notes and a whiteboard. I recommend this since you can move the tasks around easily and draw the relationships using the whiteboard and whiteboard markers. Nothing is permanent; you can toss a sticky out if you don’t need it, and you can break it up into two or three sitickies if you need that. This method is very flexible and visual. I think that works for most people. By placing the information on the wall in front of the team, everyone in the room can look at any part of the diagram and any participant can take as much time as they want on any section. This gives each person a lot more freedom and usually a lot more involvement.

Some other conventions we followed for the meeting. We wrote the meeting goals on a poster-sized sticky and it was on the wall and visible the entire time. We had a “parking lot” – another poster-sized sticky where we kept items that we wanted to talk about, but just did not have enough time, or were not directly related to the goals of the meeting. We also had a poster up for risks – here we wrote down risks as they came up during the discussions. I like this method since risks always pop-up during these types of meetings, and if you collect them all and address them at the end, you often find that some of the risks are gone based on what you’ve done during the meeting, and often many can be addressed with the same mitigation plan. The last constant we had was a poster with “to do” or action items on it. This way, when something came up we wrote it down and moved on. At the end of the meeting we went over the to do list, assigned someone to each and a due date. It was a great way to wrap up.

The other 2-day meeting was somewhat similar. I am faced with a very difficult situation in that group where I have somehow earned the enmity of one of the team leads who is working very hard to have me marginalized and / or removed. This is a very difficult and sensitive situation for a consultant. I am not handling this well or badly, somewhere in between, but I am being deliberately cautious and non-confrontational. It is amazing how much different things are when you are on the outside looking in.

Regardless of all that, the meetings went well. That project is certainly in a more difficult situation, and the team members are not as open to compromise and innovation as the other team. The meeting saw a wide use of the “can’t” word and several “shoulds” and “musts.” I think this team could find some creative alternatives to the situations they are in, but the political environment encourages individual success over project success. I have seen this a lot in many different organizations. Simply put, the organization, company, and most importantly the compensation system encourages success within the organizational hierarchy over successes that span organizations. This is often one of the biggest risks that projects face, and one of the easiest to overcome.

There are a lot of ways to improve projects success chances by overcoming some of my thoughts on this are:

• Give someone specific responsibility for project success and give them the money to do this. Asking someone to succeed on a project over which they have no real authority is a huge risk. Make no mistake – money is authority. The person with the funding is the one running the project. The closer the money is to the project, the more likely it will be used for the project only.
• Create an extra-organizational structure (like…. say a PMO) to run the project. The less influenced this group is by the organizations involved, the better. I’ve written on impartiality of a PMO before. I was able to observe over the last few days how much easier it is for the PMO to facilitate a meeting than it is for one of the project teams to do so. In the meetings that I facilitated, the discussions were within the team and there was no thought that I was trying to push the meeting or group towards a solution. In the ones where a team member was leading, there was noticeable tension between team members and the facilitator, and a tendency of the facilitator to move the meeting in a slightly biased direction.
• Create dedicated project teams. I’ve seen this work time and again. Of course it needs to be a TEAM, and it needs to be DEDICATED. That does not mean a few part time people from different areas working together over the phone when they can make their schedules meet. Dedicated team work best when their members are solely dedicated to the project and they are as co-located as possible. If you can have 1 or 2 locations where the majority of the team are that’s a plus. I know this may sound contrary to flat world theory – of which I am an advocate. I still think that collaboration is best done face-to-face. The further apart your team is the less they will collaborate. Face it, to collaborate to the guy next to you often means leaning back in your chair, to do so with the team in India means scheduling a conference call, and trying to get 4 groups in 3 different time zones together is a major effort. It’s not as easy as standing up and yelling – “hey, I’ve got an idea, let’s get a coke and let me bounce it by you.”

And now that I am thirsty, I think I will take my own advice and get something to drink as I – yes, you guessed it – wait on my LATE flight home. Hey maybe that’s why I don’t believe in this dispersed group thing?

Week 9 (Building a Program Management Office)

Week 9

This week I got a lot more time to do some physical, document producing work. As I’ve mentioned, one of my responsibilities is to organize the work being done by the teams and to create templates and procedures that can be used in future projects that are like this one. I kind of like that part of the work since it is a form of legacy, something that I can leave behind and something that I have the opportunity to create. I’m somewhat challenged trying to spend the kind of time I would like on these activities. Of course, I recognized that this is only one part of the entire job, and that as much as I would like, I cannot loose myself in that, but rather have to continue with the relationships that will ultimately help make the projects successful.

There in lies my newest problem – people. Here is my lesson this week. No matter how innocent a situation appears, do not ever takes sides in an internal argument. No matter how obvious it is that one side or the other is right or justified or whatever, do not take sides. You can agree with someone, but that had better be because of your knowledge or experience and not because you share the opinion. Here is what I did in a nutshell.

I was in a meeting where one member of the meeting showed their frustration and somewhat directly implied that another member was deficient in their duties. So someone got mad and made sure everyone knew it. Nothing huge - I’ve been cursed at, walked out on, hung up on, screamed at .. you name it, and this was nothing of that level, just a clear statement of displeasure with a bit of “I don’t care who knows it.” After the meeting I was called in to comment. I sad that it was clear someone was frustrated and that the behavior was noticeable and antagonistic – and in my opinion it was. I had pretty much forgotten about it but when I was asked that’s what I said. Well that was when the you-know-what hit the fan.

The person I talked to reported my statements to the manager of the person who spoke out. That person called me and quizzed me, and clearly mentioned my comments to the original offender. Well that person has placed me at the top of their hit list. This person is not the type to forgive and forget, nor are they into “proportional response.” My action has caused an all out war against me where this person is probably expending far more effort trying to harm me than in doing the project. In fact that is the project – wonder if there’s a charter or a schedule? Probably not, since project management is unnecessary to hear this person talk.

So the lesson is, if this ever happens to me again, I will politely say that I do not wish to make any comments in relation to this issue. I will say that my personal opinion is not really needed to help the project succeed. I will not be impolite, but I will be insistent and mute. Once again, I learn that no matter how honestly people ask, they do not want to hear my opinion. I already have a rule that when someone asks me a question like “is there something I can improve” or “what do you think of my management style” I always avoid commenting, deflect the conversation or give some innocuous answer. When someone working for me asks for that kind of feedback, I always tell them to think about it and ask me again in 48 hours. Those who really want to know, ask again. This doesn’t mean I don’t give unsolicited feedback where it is warranted, it is solicited feedback that has invariably gotten me in trouble.

Anyway, the week pretty much went OK, I got to spend a lot of time putting together status reports, project schedules and other useful docs. I hope to get them into use the week after next. I also spent a lot of this week getting ready for the planning sessions next week. This is really my first big opportunity to show some of my skills. I think I can lead at least one of the project teams to a good resolution. The other one, well I’m not so sure, too many chiefs and too much politics and too many divergent goals. I’m sure we will get through all that, but it is so unnecessary and counter-productive. As an outsider, I have the opportunity to observe it and learn a great deal. I hope I’m learning how to put it aside in myself and focus on the job and the people.

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?