Objective assessment of PM problems 3

[TigerDog]

I am new to ENG-TIPS but so far I am very impressed with the postings I've read. Thanks to everyone who keeps these postings professional and informative.

My particular question is related to the quality of Project/Program management at my company. Among other problems, in my opinion the accountability of our PMs is non-existent, and the responsibility tends to get pushed to the Engineers. I realize my perspective may not be objective so I am wondering if there are some common traits that "good" Project and Program managers/management have in common. And what role upper management plays into the equation such as clear goals, metrics, etc.

Further, what can be done about poorly performing PMs? Is this exclusively the realm of upper management or are there ways that team members can get the PM back on track?

Thanks to all who reply.

 

[IRstuff]

Well, how does YOUR management handle these things for you?

And would the cajoling of people below make any difference in YOUR behavior?

Fundamentally, there should be little difference in the management environments that apply to engineers and program managers.

Also, fundamentally, poorly performing PMs, like poorly performing engineerings, are a symptom of poorly performing management.

In most companies, the tug of war between Engineering and Program Management is a never-ending struggle. A good management team recognizes that both parties must be carefully matched in power to ensure that no single viewpoint holds sway.

TTFN

FAQ731-376

 

[GregLamberson]

TigerDog

Typically upper management will set the objectives & strategies for the project. The Project/Program Manager will develop plans to meet these objectives. Part of that should be specific and clear direction, effecient staffing plans, schedules, roles & responsibilities, etc.

As far as what you can do - the best way to suppoort or get a Program/Project Manager "back on track" is to do your job as best you can, bring issues to his attention promptly along with recommendations.

Your objective may be a little skewed, it may seem like he has no accountability and pushes the responsibility to the engineers, but unless the company is run by misfits, he does have (or should have) full accountability for all aspects of the execution.

Greg Lamberson, BS, MBA
Consultant - Upstream Energy
Website:

http://www.oil-gas-consulting.com

 

[TigerDog]

Thanks to IRStuff and GregLamberson for the posts. I think there are two different viewpoints there. I'd like to add some more background to the discussion:

At my company the planning and tracking of programs/projects is handled by the PM, however the accountability for execution clearly falls on Engineering. If a project is not meeting goals, it is up to the PM to track it, but it is up to Engineering to fix the problem(s). Manangement feels there is little a PM can do to influence the execution of a program/project once it has begun, in fact I have been told by management that they'd love for PMs to do more, but they don't know what to ask them to do!

I have worked with PMs previously who were constantly "squeezing the orange" trying to find creative ways to reshuffle schedules, eliminate buget waste, scheduling team-building activities, adjusting customer expectations, etc. DURING the project to help the EXECUTION, rather than just sitting back and assuming everything should just work out while they watch from the sidelines.

Was my previous experience just an anomaly? What are realistic expectations for a PM? And how to you enforce these expectations so they are held accountable for their fair share?

 

[IRstuff]

Seems to be a big disconnect here. How can you have the PM plan a project and expect someone else to adhere to a program schedule/plan for which he has no ownership nor buy-in?

In our contracts, the work scope is bid by, and planned by, the engineering organization that does the actual work. The PM serves two primary purposes, to be the voice of the customer, and to maintain schedule/cost, through his surrogates, the integrated product team (IPT) leads. The program manager is expected to be following work costs on a weekly basis and is expected to fire/hire IPT leads/engineers as needed to maintain schedule/cost. He's also expected to anticipate his future engineering load and demand bodies required to execute his program. Program managers are expected to keep control over scope of work. It's either in the contract, and must be done, or it's not, and must either be dropped or the PM is expected to extract the appropriate cost adders to account for added scope.

At the end of a contract, it's expected that the original bids are reviewed for accuracy and adjustments and compensation applied to bidder history to ensure that future bids reflect the nuances of particular bidders.

Seems to me that your PMs are extremely passive.

TTFN

FAQ731-376

 

[MadMango]

A PM can only manage the project with timely and accurate information from the engineering team. Then the PM can spring into action and do what is required (get more bodies, manage customer expectations) before their roll turns from action to reaction. Many times I have seen the failure of a project (cost overrun, slipping of dates) due to the engineers too busy fixing problems to be bothered by informing the PM. I have seen PMs too busy dealing with the business end to get timely technical status from the team.

I am not saying it is any particular entity's fault, but PMs are not mind readers, and engineering can't assume that all of their work is noticed. If the engineering team doesn't raise the flag, the PM will happily go about their merry way in blissful ignorance.

"Art without engineering is dreaming; Engineering without art is calculating."

Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[IRstuff]

There's a fundamental problem if the PM can't figure out there's something wrong. That implies that the measureable and objective products and milestones are either being ignored or not even planned for.

In the old days of Loral, "3 reds and you're dead," applied, i.e., a PM had to report earned value monthly and there was essentially no excuse for have 3 months in the red. What that means in practical terms is that the PM shouldn't be behind the data curve by more than 2 weeks. Any longer than that, he's not doing his job. If engineering doesn't cooperate, he needs to fire someone until he gets the cooperation. There is no excuse for not communicating, nor is there any excuse for not eliciting communications. It takes two parties to mess up the situation, not one.

TTFN

FAQ731-376

 

[TigerDog]

I think MadMango has captured the attitude of our PMs very well. They have often complained of being uninformed when problems occur. However, IRStuff has captured the feeling of our engineers, which I share. That is, if the program/project is having trouble, the PM should be sufficiently engaged to know it. Aslo, as IRStuff has indicated, many of our schedule/budget problems have existed for several months, so "not knowing" no longer applies. My feeling is that if the PMs were held more accountable that they would become more engaged, for fear of the reprecussions.

I definitely like the idea of "three reds and your dead". However, the way things are currently run at my company the "dead" would be the engineers, not the PMs.

Any more ideas about how to get things on a better track would be much appreciated. Thanks to all for the great discussion so far.

 

[GregLamberson]

TigerDog

I am in the midst of putting together a roadmap for a company that is struggling through some project management issues. Basically the roadmap will address the criticality of having the following:

• Clear objectives and a well defined scope,
• Documented processes for achieving the objectives,
• Assigned resources responsible and accountable for system administration and execution,
• Verification and measurement processes to determine if desired results are being achieved, and
• A feedback mechanism to provide a basis for further improvement.

As noted by some of the posts above and by your frustrations, without processes, metrics and accountability, there will be little improvement.

I am a firm believer in managing with processes, but without the right people in the job (at all levels from junior checker to CEO) the processes are just pieces of paper.

Greg Lamberson, BS, MBA
Consultant - Upstream Energy
Website:

http://www.oil-gas-consulting.com

 

[MadMango]

Is there anyone you can talk to in order to coordinate a "time out"? It may have to be someone above the PM. Perhaps an all-hands meeting, or perhaps just key personnel, to lay everything out on the table concerning your Project. Maybe a brief summary of the contract; deliverables, dates, testing, etc. Don't make it a witch hunt, but try to bring the issues that are hindering your project to the surface. We are here, we need to get there... how?

You should be able to walk away from this meeting with a little less confusion and a little more communications (even if its only temporary). You should also be able to have a list of actions items and deliverables with attached names. This should help greatly in getting your PM back on track. If nothing else, it gives your project new visibility.

"Art without engineering is dreaming; Engineering without art is calculating."

Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[dcasto]

I agree with the general direction of everyone here.
I like to compare incidents and accidents their control to PM. Just like incidents or accidents, it takes more than one thing going wrong to make a disaster. And like accidents, a bunch of little things going wrong is an indication of a lack of controls that GregL highlites.

My experience is that with the best PM controls, you still get upper managers that try to take control. The Business or sales person promised this, the VP in charge of budgets promises that, and the operations person wants another.

To over come this part, make everyone; sign the documents, approve the changes, BEFORE you lift one finger. If there is a hold out, then write a letter saying "If you have no opjections, I will proceed with doing XXXXXXX." You have to keep the pressure on those that will not commit.