Voices on Project Management

> Back to Voices Home

Project Management Knowledge Versus Technical Knowledge

| | Comments (10)
As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge.

There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat."

Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture.

When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience.

Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team.

Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources.

Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise.

Do you ever rely too heavily on your technical expertise?

Read more from Dmitri.


Bookmark and Share


The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.


It's a nice theory, but in reality, it depends on resources. Sometimes, when resources are tight or under-powered, circumstances are such that quality will suffer unless the PM steps in and closely manages details. And it helps for the PM to understand details so that he or she can delegate them effectively and help the team develop.

To make it work, the PM needs to track his or own time and have a clear understanding of how what he's doing affects the big picture. As long as it's an informed choice, and the PM understands that his or her own time is a limited resource to be deliberately managed, I think letting the role lines blur is sometimes the only option.

The concept PM as a pure strategist seems a little dated to me, from a time when staffs were bigger and everyone was a specialist. Now, we sometimes need to get our hands dirty, particularly in smaller organizations. Too deep in the weeds is obviously problematic, but an occasional rescue is par for the course, and obliviouness regarding what's actually happening or an inability to make effective corrections are also dangers to project outcomes.

Too much golf adds project risk, too.

I strongly agree particularly when dealing with multi-million $ projects lasting years. When you have Project Management responsibility for Architects, Design Engineers, Constructors, Owners, Users, and other stakeholder groups you must maintain a vision and with that vision a focus on the outcome. Getting bogged down in too much detail will not only detract from your primary responsibilities but can present the opportunity for missing something else that is more important and crucial to overall success.

I fault companies who in their quest for efficiency and cost savings have pushed Project Managers into functional roles and therefore extensive technical detail. This is not to say the Project Manager should never get into the details. You do whatever it takes to get the task(s) completed including getting into the details. However i have trained myself to be uncomfortable in this position and constantly remind myself that I need to be back in a role of leader watching the big picture and promoting the team's focus on the outcome.

I agree with the statement:

"But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization."

I strive to let my team handle and address the technical details and work closely with them to make sure we are on the same page.

Well stated article.

I somewhat disagree. There should not be an extreme either way. I know great project managers that have no idea how their end products operate.

I agree that the PM should not be DEEP in the details, however they should be more than a facilitator. If a PM has valid input or a different point of view from a technical aspect, their input should be heard, just as much as any other idea. In some cases this may keep the discussion on track.

I totally agree that is not up to the PM or the Customer to provide solutions, however their ideas might be valuable.

To totally rule out the input of anyone, or puting blinders in place, risks going in the wrong direction.

Additionally, although not a focus of this post, a PM with a technical background has a better understanding of the situation and whether a level of effort estimate is within a valid range.

The approach of the article seems to relate to the feeling that a PM is a PM everywhere, it doesn't matter the project, the processes are the same. That begs the question, "Would you want someone who has been the PM of road blacktopping projects for 10 years to suddenly run a mission critical IT project?" Yes, they know the PM process, butdo they know the product they are producing?

Is it good for a PM to wear his/her technical hat while leading a project?
I think it'd be a technical leader in the team so it's not the PM role to do it!

I think it also depends on the culture and PM maturity of the Organization. Process intensive organizations prefer PMs to focus more on 'managing' rather than getting detailed into the technical weeds. Project Leads (technical) do most of the deep diving and managing the technical side.

On the other side, have seen Organizations who empowers PM to do all and that’s where the outcome of the project sometime gets into jeopardy.

Personally, I think the PM should have the right balance and do whatever is necessary to manage the project driving towards the successful implementation and oblige all contractual obligations. If needed the PM should also get involved into the technical aspects but should delegate or engage stakeholders as appropriate for quick and positive resolution.

The moment the project manager dives into the detail is the same moment a risk arises that the project loses its project manager. They are taking their eye off the ball. Other, more serious, problems may be emerging that they won't see.

The project manager's most important role - and therefore sole focus - is to 'manage'. If increased technical input is needed, their response should be to find someone to provide that input, not provide it themselves.

The only exception to this is small, single deliverable projects which may not justify a full-time project manager.

The real test of a project manager is to manage a project outside of their technical discipline. Then the 'comfort blanket' of being able to contribute technically is taken away!

Well, being a project manager and managing projects is very hard work for me. I agree with this article. Every project manager encounters it.

For me as a professional, I keep developing on project management and always give a lot of effort and time in that case, so every problem will be easier for me.

How true! I find it very difficult to stay away from diving in with my "technical hat" and helping my team when I see something wrong!

I believe a PM is a technical specialist first and then a PM. Asking not to intervene is like taking away an opportunity from him. He is there of course to see that the project is delivered accordance with business requirements.

But being a PM, if I was in this situation, I would at least suggest my technical team and take a wise decision in best interest of the project on the whole.

Venkata Ramana Nandigam

While not easy to do, you must step back and lead. I tend to offer my guidance but let my team execute because that is how you learn. Trust and respect are vital to a strong project team and by allowing people to grow and feel valued.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll