Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: PMO
Project Managers Resistance to New Project Office Implemention
Hi. I am a Project Office Manager working for an important IT Programme in Scotland.
While implementing my PO, I have found a lot of resistace from the PMs, not only related to the new processes being implemented but also to the mentoring and training that we want to provided to them to improve their PM knowledge, specially for the juniors. The attitude is "we are here because we know what to do".
1.Do you think this is a cultural issue? These training plans have work in other countries.
2.Do you think it has to do with the fact that I am a foreing woman?
3. Do you think it as to do with the fact that there are to many changes going on at the same time?
4. Any good advise on how to haddle the situation? Continue? Back off for a while?
Sort By:
Page: 1 2 3 next>
Change nearly always meets with resistance. It sounds to me that they are feeling put upon and have no attachment to the new ways being implemented. In essence, they were not properly conditioned for the change. Were they part of the planning process to create the PO? Were they given a voice in the processes that are being changed? Are there measurable objectives that clearly identify the value-gap between the way projects are managed now and how they should be managed? If these things were not done then you will have a hard climb ahead of you.

I suggest you put yourself in their shoes and see the changes as they see them. Then I suggest you hear them out and be willing to calibrate the PO concept in a way that will allow them to attach to it.

Couple of suggestions:

First, you need to look at whether or not the company is ready for change. If it isn't ready, change will happen very slowly. Many times senior executives can be very useful helping get a company ready for change. If the sr. execs started a project office because they weren't getting something from PMs, now would be the time for them to start asking for it. Sr execs can start the change.

Second, be sure everyone knows what the Project Office is trying to accomplish. Be sure they know what the PM process is trying to accomplish. People like to see where things are going.

Third, any time you have significant change, and a project office qualifies usually, you will get three groups of people, those that love you, those that hate you, and those that aren't sure which way to go. Work with those that love you. Prove your value and create your credibility. If you do these two things with just a few, some that are sitting the fence will begin to follow. Once you have the two groups on your side, you kow have critical mass and those that opposed are in a minority.

Fourth, management mindset breaks into 3 groups, sr execs, middle managers, and front line managers. If you don't have at least one sr exec on your side (I assume that someone wanted the Project Office), you will have a difficult path. Once you have proven your value (see step three), the line managers will begin to ask for help. However, you must convince the middle group that you have value and that you are not after their job. Show them how they can be better managers with the correct data in their hands. They can look like they are in control (because they are). Help them understand what they should be getting from their project managers and have them ask their project managers to provide it to them. You can act as the coach for the project managers to help them provide this information. It will be very difficult for you to be both a policeman and a coach. Choose coach. Their manager should be the policeman.

Fifth, don't underestimate the power of marketing and communications. Good work does NOT always speak for itself. Get sr execs to speak for you. Get them acting supportive. Create presentations for them to use while they speak. Find any little success and celebrate it (don't brag or gloat, but celebrate). Get sr execs to recognize, in public, the behavior you want to see. Find out how you are perceived. Either ask them, periodically in a survey, interview, or some other way. Get someone else to ask them for you. Human Resources, Sales and Marketing, sr execs, etc can play this role. Prepare the information for them. Don't be disappointed if you are well received at first. Look for changes in reception, as you repeat the surveys.

Six, do not underestimate the amount of communication, training, etc. that must occur in order for PMs and others to understand what you are after. Also, don't underestimate how long it will take. You are creating cultural change. It takes time for people to get it.

Seven, staff your project office very carefully. Choose people who know what they are doing, who can communicate what they are doing, and can develop influence and power without being overbearing or pretentious. These people should be able to carry on persuasive conversations with sr busines people and entry level code cutters. One hiring mistake here can negate months of good work and progress.

Summary, you are an internal consulting group and you are asking people to change from practices, at which they have been successful. You have to gain trust, show value, build credibility, demonstrate sr level support, and show progress. It may take you a year to a year and a half to get a fully implemented Project Office. Develop a thick skin and don't take any of it too personally.

Good luck.
Many of the things you said are right and are the real cause of what is happening within my Project Office. The problem for me has been that this is not a permanent corporate PO but rather a temporary one that will remain in operation only until the Programme closeout.

The Programme had a previous phase and controls were not the best. This first phase ended 5 months ago and the previous team still hasn't been able to finish the financial closeout. Applying lessons learned, the Programme Manager wanted to put in place a PO for the second phase of the project in one month, and with new everything. He contracted me to do the job.

Another major issue for me is that all personnel working in the programme are contractors from a few different IT companies. The only staff person is de Programme Manager. I am a contractor myself, and many of the Project Managers from other companies resist the PO trying to chance the way they have always worked in they own companies for a long time.

This has been quite a challenge, really !!
Its almost impossible to effect meaningful change when everyone is just passing through.
In the situation you have described, there are many specific deliverables of the total project being accomplished by specific contracted firms whose PM is on site. You have a true Project/Program environment. I would suggest selling the idea of the PO stand-up as an office whose purpose is to effect coordination amongst the various contractor’s PMs and provide a single point from which the total program status is reported from the specific project status reports. The PO is more of a general contractor coordinating the timing of the major deliverables that make up the final overall program development. Hold to a minimum the requirements for the individual PM’s to follow a set program of common procedures for they may be performing in accordance with their own company’s policies. I would not think it would be unreasonable to prescribe a standard media that would show the overall PM status and fiscal state of each project being worked on.
I have managed to implement a simple web tool that shows the status of the programme up to date for all the different deliverables and different projects. It uses a "traffic light" approach for time and cost. It also generates the Highlight Reports automatically using the information contained in the database. The PMs like it and they are using it as a main tool to track and have visibility of progress. The site will be available for clients too. The success factor here, using Jim's advice, has been simplicity and to keep requirements to a minimum at all times.

Getting there ...
International -- (interesting name, by the way) -- What is the basis you use for determining red-yellow-green? I recently saw a presentation on a similar system in which the color was essentially a subjective assessment by the PM.

In the Critical Chain world, we use Buffer Management to provide objective OK-Concern-Trouble assessments, primarily for schedule, but also for budget.

Hi Frank. The approach I use in my tool is a 0% 100% complete approach for every deliverable in the project, so there is no way to be subjective. You have either completed it or you haven't.
For a single deliverable, if you miss your baseline date, the light will change into amber the next day and it will stay like that for one week (it is like a warning for the PM). After one week, if you still haven't completed your deliverable and entered an actual completion date into the database, it will change to red. As soon as you complete your deliverable, the light will change to green again. This is just the tolerance we have defined for our projects, but you might define another type of tolerance depending on your needs.
For the light that shows the overall progress of the project, the tool shows a green if you have complete 90% or more of what was expected, an amber if you have completed 75% or more of what was expected, and a red if you have completed less than 75% of what was expected. For the progress on cost information it behaves in the same manner for underrunning as well as for overrunning. Instead of shown a light, we show arrows pointing up or down.
I hope you find this information useful.
Regarding the traffic lights - have you considered using the same in reference to resource expenditure, unforeseen risks, requested changes, and client relations? I worked for a firm that used the lights as part of the one-page executive status updates. It was quick and the comments addressed the current situation as the light indicated.
International -- I'm curious as to how the 90% or 75% of expectation is derived. If you are basing deliverable completion on a basis of 100% or 0% complete or not, how does that translate to being 90% or 75% complete with a project. Are we talking about percents of milestones, percents of scheduled effort, percents of lines of code, or what?
Page: 1 2 3 next>  

Please login or join to reply

Content ID:

"Bad artists copy. Good artists steal."

- Pablo Picasso