Week 4 (Building a Program Management Office)

Thing really took off this week! We were able to do some real in-depth work on the requirements. While we did not solve everything, the team gained a better understanding and we were able to significantly whittle down the list. More work on that to go, but should be OK. We have a fixed budget and a hard delivery date, so there is not much choice about which of the triple constraints is going to give.

I did do some more analysis of the existing documents. What is it about some people and documents???? First, the company has several sets of documentation for projects – corporate PMO, the quality management group, and IT has its CMM documents. There are a few others out there, but those are the main ones. Each group has a very cohesive and useful set of documents and often associated procedures. But why are they so complicated?? Why is there so much information needed to do such simple things? I guess when you give people the job of putting together documentation templates and procedures, they just do not stop. Most of us can put together an action item spreadsheet in 10 minutes. Imagine if that was your job – yikes – 10 minutes of work and you’re on the street? No – why not add links and procedures and notes and more columns and and and…..

Sorry, that was a bit of a rant wasn’t it? I guess it is just so obvious to me why people baulk at Project Management when we walk up to them with a ream of paper and say “if you fill all these out, you’ll be a project manager.” Like that loan guy on the TV commercials with the stack of forms to fill out for loans. Except we will put up with that to buy a house, not to run a project! Funny though isn’t it – the last house I bought was about $125,000 and my project is around $10,000,000 but I’m more willing to fill out the forms for the house. Let’s play with that a moment. I spent about 10 hours over the course of several weeks filling out loan papers and the innumerable legal documents and signing my name about 100 times to buy my house. So if I am willing to spend 10 hours for $125,000 then I should be willing to spend 800 hours for $10,000,000 – yep almost six solid months of filling out forms ! Yet I’ll bet we spend no more than 2 weeks in most projects.

My challenge is to find the “right” amount of useful information that takes an appropriate amount of time and put it into the forms and procedures that everyone can use with the least amount of pain. I am also working on how to organize the reporting structure (not organization / hierarchy so much) in such a way as to spread the work out as much as possible so that each level does only what they need and that information is rolled up to the next level who add what is pertinent there and rolls up, etc. My PMO does not have the staff to handle much work (the PMO being me and one other part-time manager), so we have to spread the burden as much as possible to maximize the value and minimize the pain / cost.

I went back and looked into RACI (Responsibility, Accountability, Consultation, Information) method and I think that will play well here both in relation to forms and procedures. We seem to have a lot of challenges in the roles and responsibilities area so I think I’ll address that first through the reporting, then move to decision making.

Onward.

Week 3 (Building a Program Management Office)

Mostly travel this week. Why is it that all your flights are perfect on your way out, but when you’re heading home, the entire aviation infrastructure fails? Of course I ended up getting home, tired and somewhat more fragrant than when I left.

The biggest things this week were the requirements. The team did agree to get together in person (guess who is writing this from the airport) to work out the details. I’m very optimistic about the meeting and the outcome. I will get the chance to facilitate a larger meeting with team members from different sites, and I’ll get to introduce a few tools and techniques.

First one will be a forced-ranking system that I’ve used for a variety of purposes from ranking projects to employees. It is a simple paired-comparison process that you can do on a grid. The one I’ll do will be on an excel spreadsheet. Below is a short example of how this works.


The idea is that each alternative is compared once against every other alternative. Half the table is shaded since you are making only one comparison. You can either work down the columns or by rows. Working down the A column, you would ask at each cell - “which is more important A or B, A or C, A or D and so on.” Once you have done this for each row, simple add up the number of times each alternative occurs. The alternative that occurs the most is the most important and so on. In the event of a tie, look for the cell where the tying alternatives were compared – the one selected is the higher. This ends up in a forced ranking with some good indications of the relative importance and differences between the alternatives.

Another tool I’m going to use is a roles and responsibility grid. Pretty simple, but there really is not one for this program.

On the PMO side, I’ve got some work! We have several areas where documents are kept, but they generally are the documents needed by each team, and not a comprehensive set of project documents. There really is not a clear standard for program documentation – there are a lot of suggestions and formats. Our challenge is to set a standard and the appropriate procedures that work within the multiple organizations. I am confident we can do it. I think the roles and responsibilities is the place to start. Understand what is expected of each role, then we can move towards procedures.

Other challenges include Risk management, change management, issue management, and many of the other traditional PM stuff. More and more next week and on.

By the way – never never tempt or challenge the airline gods for they are a vengeful and capricious lot. My flight arrived 2 ½ hours late.

Week 2 (Building a Program Management Office)

Another great week. After a long and relaxing weekend, we got right back into the flow. The biggest thing this week was the discussion about the significant differences between what was estimated and what is needed. A common project issue, but this one was recognized early, and the team has taken steps to address this now rather than wait until it becomes a crisis. But that is "project" stuff. Program Management Stuff: The challenge of building a methodology and framework continue. I need to merge at least two well-developed methodologies together and customize them for this type of program. Both methodologies have a lot of SDLC (System Development Life Cycle) components and are obviously IT-centric. This poses some challenges since there will be a great deal of non-IT work to be done. I will probably get all the details on this in the coming week and have some specific items to dig in to and relate. In the area of documentation/deliverables/artifacts or whatever they are calling these today, there is a wide variety of quality and quantity. My thought here is to concentrate on what can be reused and what is unique to the program. In this area, the schedule figures prominently. With multiple projects feeding into six main programs, there are a lot of schedules out there. Well, that is not exactly true. There are some schedules out there, some spreadsheets, some word documents, some post-it notes and some good memories. My challenge is how do all of these inter-relate and how do we track this. There have got to be thousands of tasks being managed by 20 managers, how to get them all to feed information int a joint schedule? Well, honestly, I do not know yet and suspect that I am going to find out. My current plan is to work down from the key dates and deliverables. I think one "summary" or overall schedule will be used for communication with the sponsors, customers and ourside stakeholders. There will then be one schedule for each customer (2) that will be split into either 2 or 3 sub schedules each representing one of the key programs. Past that, I don't think the PMO will be involved in other than helping each of the program managers in organizing and collecting their schedule information. It is likely to be very different for each group. So far, this sounds pretty simple, so I am sure there is something I am missing. Basically mirroring the

Communication: As we all know this is and will continue to be a key. My thought here is that my first job is “seek to understand.” I do not see how I can provide team members with the information that they need without understanding the team members themselves. For this I am convinced that nothing other than personal contact will do the job. I think you may be able to like and work well with people that you know over the phone or email, but that we can’t build the level of trust necessary without a personal relationship.

For this my approach is to do some traveling, probably a lot of traveling over the course of the program. I expect that only by meeting and working directly with the team members will I understand what is important to them and their communication and behavior styles. There is a lot of work involved beyond the traveling. I hate classifying people; we (people) are too complex and too adaptable to be classified. This makes it impossible to me meet once or twice, pigeonhole someone and then stick to that for the length of the program. What I need to do is to “understand” the people I am working with, how they relate to me, the work, the environment, the company, etc.. To do this is going to require that I be very open and vulnerable. I plan to invest a lot of myself in this work, if I didn’t how could I expect anyone to trust me?

Communication is not effective without trust. Trust requires a lot more than a few visits and come handshakes.

Week 1 (Building a Program Management Office)

Well, I just started on a new assignment building a Program Management Office and I thought that I would give a weekly update on what I am doing and going through, thoughts, etc. First a little background. The program has been active for about a month or two, so I am coming in early, but not completely at the start.

The Program is a set of three other programs that each consist of many projects. I’m not sure exactly yet just how many projects there are all told. One of the challenges that I’ve been asked to help with is managing and coordinating all the work so that things do not get dropped “between the cracks” so to speak. There are 6 major separate units involved, 3 are internal (I’ll refer to these as “client” groups), two customers and one external vendor – who works for the customer and us.

One internal organization has a methodology and is following that fairly well. One customer has a methodology and set of documentation that they would like to see, but I have not seen that yet. The client corporation has a methodology that is based on the PMI framework, so it is pretty easy to understand. I am still not too sure if that methodology is in use by all the client organizations.

This week, I mostly just started getting my balance and understanding who is who and what is what. I did get immediately involved in facilitating some work on budget and requirements. As a result of this meeting, I started using Meeting Minutes and Action Items. These were not new to anyone, but I didn’t see any action items for the program initially. I used the client’s forms.

The lesson here I think is to start small and simple. We have one person in the PMO – me, and a methodology consisting of 2 forms. No one seemed overwhelmed or resistant.

Overall the week went well and I got to meet many of the principles. All of whom are very capable and professional people. Nice too, I am looking forward to working with all of them!