Project Management

Project Management Central

Please login or join to subscribe to this thread

The difference between PM and project engineering
I have an interesting dillema. My management believes that one of our vendors handles "project management" at a better, hands-on way than we/I do. What this company does is assign a project engineer to help install and implement a technical product, does the training, solves problems that crop up, handles software issues if they appear, and stays on-site the entire implementation process. I would consider this person more of a project engineer. My idea of a PM is more of a facilitator that is NOT on-site every day during a project, and plans/allocates resources, etc. to get the job done within resource and time constraints. How do I compare the two concepts and prove to management that this other company's "project management" technique is not the right concept? The hook: management now things PMs should be taking the role of what I would consider a hands-on project engineer and thus not really capable of handling more than one project at a time. Gaaaa!
Sort By:
This is an interestin dilemma. The Project Engineer role allows the person to be seen to be very productive and useful by troublshooting and dealing reactively to any problems. While all this is going on however who is making sure that the project is delivering to plan ? Who is managing the project Budget ? Who is managing Risk/Issues and taking responsibility for Reporting and Communications ? If these projects are small in size and scope and cannot justify a full time PM then one way to deal with this is to group them under a portfolio of other similar projects and make the Project Engineer responsible for Work Package delivery. He should continue to report into the Project Manager and the PM should manage all Comms and Reporting. I don't think its a good idea to let an Project Engineer to report directly to the stakeholders (if anything it reduces your perceived added value.) Anyone else have any views on this ?
I do agree with Gavin. The issue is this person is reactive to every wish the customer/our management has and is solving issues. The decision making and prioritisation is left to your management. This might be a fovourable concept when a package is installed however when also activites of your own company are required, e.g. delviering requirements, testing, accepting, data migration etc this person will not manage those actvities.

The best way to explain this to the management is to ask who will take responsibility for those tasks. As when the answer is you and at the same time you also must act as the implementation support resource you can explain they are looking for the sheep with the five legs.
Let me provide the argument in favor of the hands on, involved project manager in regards to reactive vs. proactive management; managing budget, scope, and schedule; and general leadership of a team.

Although a manager can be reactive in any situation, the manager is best able to be proactive when he has ongoing interactions with the customer. The manager who is only on site a couple of times a week for a meeting is more likely to only become aware of issues once they have reached a critical state and the manager is then forced to react. It is better to learn of issues early through informal contact.

When managing a budget, it is always best to have one individual understand the technical issues as well budget affects to requested changes. When skill sets require separating this role across two individuals, it is critical that the two work closely together to ensure the techncial and financial aspects of decisions are considered. To have an isolated "project engineering" making day to day technical decisions without financial knwoledge ensures the "project manager" back at the home office is doing little more than tracking what happened.

In terms of leadership, there is much to be said for an onsite project manager who, when a crisis erupts, can pitch in and help if he is technically qualified or can provide coffee, pizza, and a shoulder to cry on if he is not. This manager will be far better informed than someone sitting back in the home office badgering the staff with e-mails and voicemails. The onsite, involved manager helps ensure the project staff do not feel that they have been abandoned on a desert isle.

Being an involved, technical project manager is highly rewarding. This role serves as both the glue and the wall between the project staff and the client or business staff. It is challenging to serve as the central point of communications, but it is also the difference between managing the project and merely tracking the results.

Thanks for your insight. I do agree with you. I do think a project manager should be on-site during implementation and make sure the team is able to solve issues. So he is creating the environment where a team can be successful.

My comment was that I do not believe that he himself should solve issues, implement software etc. This more or less a team lead who focus on the team he is working with and only reporting upwards. This will not lead to managing the environment as I described in previous post

Hopes this clarifies
It sounds to be like this person is the Technical Project Leader. In our environment, this is the dedicated resource who troubleshoots technical issues, distributes work to the technical staff, and keeps the project manager in the loop. Our PMs work several projects ensuring that good practices are followed, schedules and budgets are adhered to, and the TPL does not let customer good will drive scope creep. The resources have different skill sets and the client is always happier with the guy who says, "We can fix that" without considering scope or budget. Watch the burn rate of these on site resources as they typically have a difficult time telling the client, "No."
I agree with the concept of Technical Project Leader.

Here's the point that I'm not sure is bring conveyed - if I'm on-site with a project implementation effort, no one else is handling any aspect of project management. I'm it! So either I need to hand-off the Technical Project Leader effort to others (as I have been doing) or I go on-site and the program grinds to a halt - or I work 20 hours a day keeping my program afloat.

I do think you need to be on-site to inspire the team and to have a firm understanding what is going on on the customer site. Are htey happy hat are the issues and so on.

At the same time you must manage the stakeholders and the environment. If these are located at a different location you need to travel. Based on the isses and the complexity you need to arrange the logistics, which frequency to choose and where to spend most time.
Hi Todd,

Similar with general management, there are multiple styles of project management – one classification is Autocratic, Paternalistic, Democratic and Laissez-faire. The PM style depends of both the individual’s personality and organization’s culture, so what works in one case might not be suitable in another one.

Back to your specific situation, for an external vendor it makes absolute sense to send on-site a Jack-of-all-trades (if the project is small enough) that will handle both technical issues as well as operational planning (day-to-day activities, typically based on a predefined plan). The major decisions are maintained at the level that signed the contract, so the on-site person is certainly not a project manager but a technical lead. Only for very small projects the project decision maker (a.k.a. project manager) and the hands-on resource are one and the same.

For large projects, going too deep into details might lead the project manager to focus on the “trees” and forget about the “forest”. In such case there should be a clear separation between the project manager and the hands-on technical/project lead to enable each one to have their proper perspective. Even if the PM does not need to be on-site every day 9 to 5, I also recommend a tight relationship with the client – and nothing works better than face-to-face. Especially when you have to travel to get at their site, the clients appreciate even more that you took the time to provide them with exclusive attention – and stakeholders management is one of the most important tasks duties of a project manager.

From a client’s perspective, receiving services from a vendor or delivering internal projects, I typically recommend to separate the project management function from technical/project lead. The main reason is that the lead has to be focused on getting the activities done, while the project manager should be worried about maintaining business alignment – especially on long running projects. Once again, only very small projects could combine these functions, and only based on criteria related to efficient utilization of resources or for training/mentoring purposes (to provide a project lead with experience to become a project manager).

I hope the above will help you explain your management why the approach should be different for you company vs. the vendor’s style.

George Jucan

Please login or join to reply

Content ID:

"If life was fair, Elvis would be alive and all the impersonators would be dead."

- Johnny Carson