Examples of "good" engineering program management? 14

[mloew]

I have been continually frustrated with the lack of any real engineering program management in the automotive industry. It seems that program management as it is implemented is just a title for the engineer charged with shepherding the project through. These program managers often function as the customer, and supplier, baby sitters never adding any value to the engineering process. Companies rarely seem to use there own standards and treat the FMEA as a “check the box” item to complete before the customer wants to take a look at it.

Where are the good examples of engineering program management and how to implement a system from the engineering level upwards?
Best regards,

Matthew Ian Loew
Sr. Engineer

 

[DaveinIndy]

I share your frustration. There is often, in my experience, an overkill of non-value added documentation just "checking the box" as you say without applying the resources or discipline to each step of the process.

My suggestion is to read as much as you can- search the web, look at the Project Management Institue and PDMA (Product Development & Management Assoc.) websites. A variety of good books and various websites, but none that I would call all inclusive. That's what I've done, and collected articles and portions of books that interest me the most.

Hope this helps.

 

[DesignControl]

Mathew & Dave,

I think that Program Management and Portfolio Management are lofty goals of many large organizations... lofty because to properly manage multiple projects, and their interdependant input and outputs, a plan or tracking mechanism must exist. The input and output milestones must be mapped and as the milestones are completed, the approapriate deliverables should be communicated to the customer project.

Most things in project management, by themselves, are apparent -- almost simple. But when you combine a hundred or so tasks (or more) per project, maybe a dozen projects per project manage, then try to manage a handfull of these project managers... things can get tangled up pretty good. Rather than addressing the issues that would make a difference, which would require the backing of the entire business, program managers default to setting arbitrary deadlines to motivate a completion date.

The problem starts with the project plans. Not all projects warrant a plan... sometimes just a work breakdown structure will do. There just is not enough time in the day to formalize every project that come across your lap. If you agree to this, then you will understand that the risk of not planning these "smaller" projects is that they are not monitored like a "big" project. So, when things get delayed, or someone just hasn't found the time to complete their task, then maybe nobody finds out until it impacts another project. Then the "big" project is held up because of the "small" project.

The devil is in the details. Even small projects need to be monitored -- use a shared To Do List, Wall Chart, periodic email, what ever... but communicate the status consistantly. Your team members will come to adopt your updates as their guide to when they "really" have to start working on their tasks... because they will see it coming. And we all know that nothing gets done until it is needed.

Here are some things that I would suggest to help manage up. First start by planning your big projects with your input milestones labled as inputs (for instance: I101, I102) across the top of your project plan (in other words, don't burry your milestones within the depths of your project). Do the same across the bottom of your plan for the output milestones (O105, O106). This way you can sort by milestone and your inputs and outputs will be grouped in the order that they should be completed... a quick report should indicate any trouble areas.

Now that you know where your communication channels need to exist (i.e. you input and output milestones), identify which projects will be the customer of your outputs, and which projects will be the supplier of your inputs.

If your program manager is not mapping your milestones with other projects, then you have to assume that responsibility. Find out who owns the tasks in the other projects that will be providing your inputs. You need to communicate your dependancies on their completion and delivery of their outputs as your inputs. You need to come to an agreement as to how you will handle delays (will you and your project be considered if the supplier project needs to be pushed out? will you notify them if your project gets pushed out... perhaps providing them more slack time?).

Do the same things for your output milestones. You will have a project plan that uses milestones as triggers for communication with other projects.

Most projects fall apart at the edges because nobody manages that grey area. By using milestones to establish the communication channels between projects, it becomes black and white.

Once you establish a mothod of communication among projects, and show that it works, the program managers will likely adopt the tecnique. Just remember to keep an eye on those "small" projects that grow into "big" ones.

I'm not sure if there is any glory in a job well done, but it sure beats announcing a delay. Don't give up.

Best regards,
DesignControl

 

[babyyoda]

In agreement with yourself, I find it frustrating and annoying when an individual is called a Project Engineer or Program Manager. It seems to be buzz word for the masses, as everyone wishes to be a leader.....

Do a web search for PMI or Program Management Institute. This an organization which trains individuals for a certificed PMP (Program Manager Professional). Some cities will have a PMI group; which will help you learn new skills, and network with other individuals who are program managers. I have no suggestions for books with good engineering examples. Sometimes a Project Manager is not evualated on how well they did the project, but how happy the client is, and if the project made money.

In the corporations I have worked at (both industrial and automotive), the project engineer is the person who handles the project from time the contract is signed to the time the unit leaves the building. Sometimes, resources report directly to you, and other times you need to manage people who are not reporting to you. The individual is responsible for the client correspondence, design, procurement, and debugging of unit. It can all be overwhelming if you do not have good organizational and time management skills.

To start small, develop a system which helps you track the project. Once you prove to other project managers that your system is working, saves you time and headaches, then they will quickly pick up your system, or your boss will impose it on them.

From your comments it sounds like your company does FMEA analysis, but no one is assigned to follow up, and once the widget ships, there is nothing driving the solution forward. This may be an ideal situation to sort through all the outstanding FMEA, and create a new project! Resolving all the outstanding FMEA, before one of your clients calls to complain.

Babyyoda
Fellow Project Engineer

 

[gjb1]

Mathew,

The only accredited Project Management organisation in the UK is

http://www.apm.org.uk/.

The web site gives interesting information regarding PM in the UK and there are links to other PM information.

I realise your question wasn't specifically regarding Project Management but it is the lack of Project Management (which is the ultimate controlling function) that leads to the downfall in Programme Management.

GB

 

[Dipy]

Dear Friends,
I read all the views posted here and feel that we are little astarying from the problem. The very title of the problem is 'Good Engg Program Mgmt'. Look at the problem by setting up the goals first. It is necessary to look at the customer pattern first. Is the customer looking for the cost edge or the quality or the brand. its almost normal that the customer wants everything, but lets all agree that the enggg industry is customer driven and focussed. With this baseline, now develop your program backwards and integrate and place the various people, disciplines and the activities in this map. An engg program or proj manager is just a facilitator. Now a good manager or facilitator is that who can otimise this process or program best. No doubt its wise to always have a feedback analysis by senior management and the anatomy of this multi path and multi variant program must be studied. Clearly, if the finding proves that there could have been a better option or path to achieve the proj goal, the hyped up manager would be exposed.

 

[TurboTag]

Mloew,

I too work in the automotive world. Good project/program management can only come from the top. Unfortunately I have yet to see this in the automotive world. There is way too much micro management. I don't know how many books I've read and experts I have listened to. But the common elements seem to be empower the people at the bottom and don't micro manage. When this is presented to a company it seems to last about 1 to 2 months. This happens for several reasons.

1. Unqualified people in critical positions (inexperienced engineers with no mentors or even non-engineers in engineering positions)

2. Inability to give up control.

3. Inability to or no desire to communicate.

The PMI has a great guide to project management but without true support from the "company" management it is doomed to fail.

There has been some good advice posted here by others, absorb it all.

My 2 cents,

Tim

PS: Dipy I have seen too many managers that repeatedly fail who are not identified but PROMOTED!!!