Planner Interaction with Project Managers 2

[cosmicchris]

I'm interested in methodologies and techniques applied in other organisations with a view to best practice. My role is that of a planner within the Projects & Services department of a multi-national organisation. I'm charged with planning for 12 project engineers only 4 of whom are based on the same site as me. The role is actually a new position created specifically to remove load from the project engineers. So far the role involves compiling MS Project programmes which are then "tossed over the fence" to the projects people who only return if they require a modified programme and can't handle it themselves. My aim is to make a far more interactive role of this position with greater input and into the projects thus removing more load from the project engineers. There appears to be a certain amount of resistance to this which I plan to overcome with innovative and practical solutions, hence the request for methodologies and techniques.

 

[PSE]

Where is the resistance coming from, the project engineers, management? Your methodology to overcome this reluctance will need to be selected accordingly.

Regards,

 

[cosmicchris]

It appears to be resistance to change and possibly a small amount of suspicion I'm going to snitch to the boss or the big boss. Their immediate manager and the project engineers who report to him (he's my boss too) are reluctant to rock the boat as long as the invoicing is steady. This why the changes I suggest and hopefully implement have to see short term and medium results. Thanks for replying so promptly.

 

[RDK]

You are offering a service, planning and scheduling, to a group pf project managers who either do not want your service or distrust you for some reason.

Don’t take it personally. You don’t give any history about the origin of the position but I get the feeling that this was senior management’s idea more than the PM’s idea.

Step back and look at it from their perspective. They see you as a threat to their autonomy and authority on the project. You have to start small and slowly prove yourself as someone who can be trusted and helpful.

There should be at least one PM who is willing to give you a chance. Work with that individual and let the other’s see the benefits of having a proper planning program in place and how helpful you can be,

Provide good planning functions. Make sure that the work breakdown structures used are realistic. Be fully professional in all your dealings with the PM’s.

NEVER be a source of information good or bad news on a project directly to senior management, let the PM’s deal with the senior management. If senior management wants direct reports from you try to get out of it and let the PM be responsible for the project. It might be difficult to avoid doing but explain to the senior manager that there is a trust issue between the planning function and the PM’s and you don’t want to be seen as a threat to their authority and autonomy. A good senior manager will understand this and respect the chain of authority.

It will take a long time to change attitudes and overcome the organizational inertia to accept the new position.

Good luck




Rick Kitson MBA P.Eng

Construction Project Management
From conception to completion

http://www.kitsonengineering.com

 

[cosmicchris]

To RDK. Your perceptive notes are likely to be very useful, if only to confirm my suspicions on certain issues i.e. it has reassured me. Thanks.
I'm still interested in methodologies and if anyone can indicate useful tools they employ, other than the usual Gantts etc.

 

[PSE]

It would appear that your biggest nut to crack is that of communication. Since you are working with people spread over different geographical locations, you need to make yourself accessible. Having a cell phone # and e-mail address available to the Project Engineers is a starting point. If you have suitable resources, try to set up a Intranet web page or simply a unique drive area on a server where the PM's can access project information and scheduling.

Be responsive. Since this is a newly created position, you need to (as RDK indicates), prove your worth to the Project Engineers. You may need to travel to get "face time" and become familiar with each personality you will be working with. Find out what their biggest systemic obstacles to getting work done are then do what you can to remove those obstacles. In this way you build value and rapport with the Project Engineers without appearing as a threat to their position.

Regards

 

[ColCol]

RDK brings up an excellent point about NOT becoming a conduit of information from the project to senior management. This is a no-win role to play.

However, I see the scheduling problem a little more globaly. I suspect that Mangement may be misguided in creating a cross-project planning service. The reason I say this is that planing is a core function of an effective Project Manager. In my theory, PM's don't need to be unloaded of planning, they need to be steeped in it. Planning, staffing, communications (360 degrees) are the hallmark of a good PM. Why separate him from planning?

Perhaps your organization is aking PM's to do the wrong things, such as technological tasks, data analysis, detailed design, arranging furniture, etc. PM's are often selected due to their technical skill, one of the most common organizational mistakes in the world. When PM's are selected and rewarded for technical skills, they continue to practice those skills at the expense of planning, staffing, and communications.

I know it is not normal to susect that your senior mangement is the root of the problem, but why not? Have they ever managed a project before? (By the way, have you?)

I have led projects where there has been a team member tasked with updating the MS Project schedule, but I have never relied on an outside service provider to handle this sensitive task. Within a team, schedule discussions are sacred, conducted behind closed doors, with the core of the project team, as these discussions and schedule scenerios are often used to predict the future, and the future can be very scary to outsiders who may not understand the level of uncertainty involved with predicting it.

What do you think, Rick? More or less scheduling for PM's?

 

[RDK]

I see no problem relieving the PM of a lot of the grunt work on planning.

This is not to say that the PM should be relieved of all planning issues, just the time consuming parts of it.

Management is all about planning, implementation, coordination and control. I am not using control in the American usage of the work where it is more like commanding but in the European sense where it is more in comparing actual results to planned results and making the necessary adjustments.

That is where I would concentrate in offering the planning services; make it easy for the PM to do the planning.

The PM’s real job is leadership. In order to lead you have to have a clear vision of where you are going and you have to communicate this vision to the troops. The plan is the road map on the way to this goal and the PM has to have the overall responsibility for the plan.

My style of leadership is to make sure that everyone knows where we are going, their role in getting us there and that they have the tools and resources to fulfill their role. Then I get out of their way by going forward. Usually they follow along, if only to see what I’ll do next.

Project management does not function well in a line-staff organization unless it is the line function that is stronger. I worked for the Canadian Military for several years and they have a much stronger staff function than the line function. This creates no end of problems because the staff wants reports, studies and more reports. This prevents the line function from doing its real job that of making things actually happen.

If the line is stronger then the staff can be told where to go if they get in the way or are not supportive.

The organization that cosmicchris describes is a line staff function. It appears that the line is the stronger and he is trying to make inroads in offering a service to the line managers that they do not se as valuable or that they do not want to give up control of themselves.

IMHO to be successful at giving this service he has to do it in a way that is non-threatening to the line managers. This is to take over the grunt work of scheduling. If the work in providing the inputs into his schedules becomes too time consuming the line managers will not use his services. Therefore he has to start small and take incremental steps as he proves the value to the line managers of his service.



Rick Kitson MBA P.Eng

Construction Project Management
From conception to completion

http://www.kitsonengineering.com

 

[ColCol]

Thanks for your insights RDK. I would point out that AMerican PM's are not all about commanding, we do understand the "leadership thing".

I have always had a different take on mangement structures. i.e. the permanent functions of the company are run by the "line" management, and executed mainly be "staff" functions. These two definitions are similar to the corresponding military roles. The "project" management, however, is different from both line and staff. The principle difference is the lack of permanance. From this temporary nature flows many other differences such as the absence of carear development within a project, the absence of substantial training, the absence of performance reviews, and a host of other behavioral differences. I don't know what the military analog to the project would be, perhaps a civilain contract?

I got the impression that the original poster was attempting to unload the planning function (or perhaps the paperwork part of planning) from the project manger. The new central planning function would necessarily report to some line manager outside the project team(s).

I still think that the answer to unloading a PM of the tedium of planning is better tools, and help inside the team, not necessarily an outsider's help.

 

[louis]

RDK is right on the money about not being a conduit of information to the project managers' supervisors. However, the planning tool itself may serve that function which leaves CosmicChris as the scapegoat. Where I worked before, the planning software was mandated by upper management to be used by the project managers to communicate the schedule to management. It took only nanoseconds for the PMs to pick up on it. As I was both a PM and on the team to implement the change, I tried to find a few wins. CosmicChris, I suspect you are consigned to a similar role. If the PM's normally use MS Project, the best idea I had was to create modules of certain processess such as contracting and publication. These modules then can be used as building blocks to assemble a new plan. The modules would include information such as lead time, staff time ranges, and skills. These modules may also be useful to the owners of the process if they wish to improve their process. The second idea was the one suggested before which is to become a resource to and a member of the PM's team.

If the project software is being dictated from above as a means to monitor the PM's, CosmicChris is in a rough position. I would suggest keeping one's eyes open for other opportunities and do not go down with the ship.

 

[cosmicchris]

Not all of the PM's use MS Project, in fact most of them did not use it and were resistant to the idea of it. One of my first tasks was to produce a programme for every project (no matter how small). The idea of modules of certain processes such as contracting and publication sounds interesting. If you get the time could you expand on this.
The modular approach is the one I've chosen but its hard work getting some of these chaps to buy into it (their PC skills are lacking in some cases).
The last comments struck an ominous chord and hopefully there won't be any need to abandon ship (yet!)

 

[louis]

While their PC skills may be lacking, do they use Gantt Charts or PERT Charts? If so, they may be of the old school where specialist prepared these items for the PM. In my case, only 2 out of 20 PM used any software. Most of the projects were very simple in scheduling with a single path from beginning to end. Management hired a project planning expert to teach project planning skills to the PMs; his comment on reviewing the plans was most of our projects were too linear to benefit from software as complex as MS Project. However, our team leader who was one of the top management was locked and loaded on his goal.
Maybe a simpler program would be a better match of the projects and the PMs.
As to the modules, one of them was contracting. I laid out the steps of getting a contract awarded from the PM's perspective. That is writing the statement of work (SOW), preparing the independent government estimate, preparing the procurement document to commit funds (PR), review of SOW by the contract specialist, legal review based on dollar amount, processing time by finance to provide financial ok to contract specialist, time to advertise in CBD, and so forth to issuing the contract. Most tasks were fixed time where the PM had no input to resources. Others were tied to generic resources such as Project Manager or Mechanical Engineer. Later, you would change the generic over to specific resources (in our case names of people) when inserting the module in the project. The main benefit to the PM was understanding how long something took and having a way to track the progress. Most PM underestimated the turn around time for other groups and on the other hand, the other groups did not have a standard turnaround time for their function. So the module will also get people on the same page. You will need the help of other functions to get good modules. The notes section can serve as a primer for options such as times when additional legal review is necessary. Calendar restraints can be used to make the PM aware of cutoff dates such as when Finance would no longer take procurements.
Once you have a good version of the module from the process perspective, you may have to simplify it (combine tasks) to get the PMs to use it. I found that many objected to seeing a lot of tasks they were not involved with or in control of. Many tasks also increase the effort in updating the project plans. The simplifying may be an opportunity to get the PM’s input into their tool.

 

[machinetooldesign]

Hi

I know this situation, don't get hold up by this, but if you base your input on on level lower information as your PM's. but based on fabrication or site people, site managers and so on, and you have a daily or weekly progress list base your info on this, then this becomes reality and nobody will feel him or here self passed.
harry

 

[cosmicchris]

Big thanks to all who have contributed. I'll check back on this thread if new info is posted

 

[DRC1]

PM was orginally a tool to help a supervisor organize and moniter the performance of his project. In many orginazations it has become more of an end in itself than a means to an end.
I work in constrution and have seen huge scheduled that have taken hundreds of man hours to produce and maintain. The schedules were produced by people who knew every tiny detail of the program. The schedules were terrible and the project managers were blindsided by huge changes and delays. Why? Not because the schedulers didn't know how to schedule. It was because they kneew nothing about the work they were scheduling. They had little background in constrution and were so busy creating or updating or forcasting, they never got out to really understand the job.
You never mention what process you are scheduling. It's the important thing, and the schedule is a tool to help the PM do the important thing. You have a good idea and can be a great resource to these PM's. However, don't tell them what they need. Commit a lot of time to go to the PM's (including the 8 at different sites) and ask them to explain what they do. Once you understandwhat they do, explain what you can do and ask them how you can help them get the information they don't have. This approach may be a little slower, but I think it will be much more succesful.
Good Luck!