Project Managers: The Value of Understanding Technology
Image by $ydney via Flickr
BRIDGING THE COMMUNICATION GAP THROUGH TECHNICAL AWARENESS
Many project managers are extremely successful in their role by simply managing a project plan and checking off tasks as they become “100% complete”. They’re able to manage teams, create budgets, assess risk… pretty much perform all of the basic and yet complex project manager duties. And more importantly, they’re able to do these things without having to dig too deep into the technical details. They can lean on the technical lead to solve all of the technical issues.
But what would happen if that same project manager took it one step further to truly understand how all of the technical pieces fit together? What if they took the time to understand the technology and how it related to the project that they’re managing? Would that add value to the project as a whole? Would the project team have a new found respect for the project manager? Would managing upper management’s expectations become easier?
Yes, Yes, and Yes! I’m a firm believer that understanding the technology of a project that you’re managing truly elevates you from a task manager status to a “real” project manager. But what does “understanding technology” really mean? Some would argue that you’re not really a “technologist” unless you’ve done your time putting in countless hours of education, cranking out millions of lines of code, or surviving a production outage lasting longer then 30 minutes. Then, and only then, can you call yourself a technologist. In fact, after those battle wounds, you can even run a data center out of your cube or hang an endless supply of network cables as victory medals.
But wait a minute; I’m not trying to be a developer, a technical lead or even a systems architect. I’m simply trying to get a project delivered on time and under budget, so why does being technical add any value to my ability as a project manager?
Ahem…no offense, but have you spoken to a techie lately? It’s like trying to interpret what Chewbacca was saying in all of those Star Wars films. Folks, that may be it… you’ve gotta be able to communicate with the people that you’re managing. Managing a project means managing people and if you’re both speaking two different languages, you’re in for countless hours of frustration and lost productivity.
Of course I’m not implying that all PMs out there should rush to become a “Chewbacca,” I’m simply suggesting that investing the time to understand the project that you’re managing – technically – will be worth your while for the sake of managing and delivering the project. Understand the technical issues and their impacts on each other or the project as a whole. Understand what it means when an application can start on a physical piece of hardware but shows no signs of life on VMware. Know what it means when you start getting error messages or warnings that you need to “increase the file descriptor size” on your Web servers.
If you can take some time to not only understand these technical issues, but also regurgitate them, then you’ve added value. How?
- By improving communication with vendors to escalate the right service requests as needed
- By effectively communicating with the project team to understand status, technical issues and to help prioritize their tasks
- Competently assess risks and determine more accurate mitigation plans
- Proactively arm management with the right information about their current or future infrastructure
- Ask the right questions when screening candidates to work on your projects
Most importantly, you can bridge the gap between what’s perceived as the “task manager” versus a true project manager.
You have to know when to let the technical team troubleshoot an issue or when to lead them to the solution. You have to know when to ask the questions… no matter how stupid you feel. And you have to know that you can only hide behind a project plan or a status report for so long. At some point you have to step up because as the project manager you are responsible.
In the end, you don’t have to be a rocket scientist or rather a techie, to be a good technical project manager. You can spend your life as a PM trying to find the ultimate task tracking tool — or you can plunge into the universe and mingle with the Chewbacca’s… even if it’s a galaxy far, far away!
Jan 20th, 2009 at 3:00 pm
Sonal –
Your point has been debated in the PM literature since I first got involved in project management in the mid-1970s. In my opinion, your perspective is neither right nor wrong … it’s just too narrow.
Technically skilled and knowledgeable PMs are fine on smaller, simpler projects where they are as apt to be making technical decisions as management decisions. But as their projects get larger and/or more managerially complex, they will be making management decisions, and their technical skills are as likely to be a handicap as a benefit.
Here’s one way to look at it: if everyone on your organization’s most important, most difficult project can spend 3 weeks in training before the project starts, how would you want your PM to spend hisorher time? Every minute of classroom time that is devoted to developing technical skills that MIGHT be used and that MIGHT be stronger than those of the technical staff is an hour taken away from developing management skills that WILL be used. And who do you wanting making the technical decisions on this project? The PM with limited knowledge and less skill? Or the technical lead who has deep understanding of the issues involved?
Don’t get me wrong: all other things being equal, I will take the more “technical” PM. But all other things are seldom equal. And I have seen situations where the PM’s technical abilities were useful. But I’ve seen many, many, more situations where the PM got into trouble because heorshe did not have the sense to defer to the technical leads on the project.
Duncan
William R. Duncan, Project Management Partners
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Board Chair, PMCert, the independent certification body of asapm
Reply
Jan 21st, 2009 at 11:34 am
I think I agree with most of what Sonal and Bill are saying. I think there is a “sweet spot” that changes depending on the nature and complexity of the project.
One of the two great wastes (it was Hal Macomber and someone else whose name escapes me right now) is Not Listening. One of the key reasons for this can be a technical PM who thinks (or really does) they know more than the leads and takes on technical decisions when they should not. Like Bill said, on small projects this can be fine, but as the project increases in technical complexity and size, there’s an increased risk of bad consequences from having too much power and knowledge in one person. For this reason, I’d advise that even if the PM is the most technical person on the project, if they have a technical lead they should try to step back as much as possible and let that lead do their job and own the technical design. The PM should be primarily focused on communication and management as much as possible.
If a project is large enough to have technical leads for the various elements, I think it’s best for the PM to get into the technical details as little as possible. Enough to understand what is going on at a high level, but not enough that day-to-day technical decisions are being made by a PM.
The key is being able to effectively communicate with the technical people…and some level of technical experience is required for this.
Reply
Feb 1st, 2009 at 11:23 am
Sonal,
Very interesting article and I agree with a lot that you are discussing. Understanding technical components of a project is helpful, but at the same time getting lost in the technology is not the role of the Project Manager. The Technical Lead needs to communicate better and if you are facing situations were they are speaking a foreign language, I would suggest asking them to speak in plain english.
I am a very technical person and have gotten lost in the technical abilities of an idea/implementation and lost the business resources and the project managers. I was fortunate to have a project manager pull me aside and assist me in approaching my technical discussions into more business terms.
1.) Find the business goals/objectives
2.) Change the wording to be more business friendly
3.) Develop cheat sheets to assist in the transition
4.) Deliver to the general public
Doing this for a few projects I have increased my delivery of technical solutions and increased business buy in with the side effect of less meetings and more time dedicated to delivering.
Regards,
Chris
Reply
Feb 2nd, 2009 at 11:19 am
All,
When the project is chartered, a Responsibility Assignment Matrix (RAM) should be built. It assigns “accountability” for each deliverable to one-and-only-one person. The accountable person for that deliverable. The RACI (Responsible, Accountable, Consulted, and Informed) assignments should stop at Accountable. That person can make further assignments if needed.
The Project Manager is Accountable for the project management “deliverables,” – all the deliverables that might be found in a PMBOK compliant process – or your favorite PM process.
If there are other PM deliverables, those can be defined during this chartering session.
This approach (the RAM, a dollarized RAM actually) is mandated in government contracting and flows down the line to all participants. Large construction is similar – in my experience. In the absence of a RAM the discussion of “what is the role of a PM,” is an endless death march.
Reply
Josh Nankivel Reply:
February 2nd, 2009 at 3:02 pm
Thanks Glen, we also have a dollarized RAM which is also a piece of our EVMS. It is very helpful to quickly show who is responsible for what, especially on a complex project where you have multiple project managers leading different segments.
Reply
Glen B. Alleman Reply:
February 2nd, 2009 at 8:07 pm
Josh,
When Bill (Duncan) mentioned the endless discussion, I’ve been part of those. Like many discussion a simple inverting of the question goes a long way to clarifying the issue.
Instead of asking what skills a PM needs, ask what deliverables does the customer expect from the project. When those are placed in the RAM and the skills to produce those deliverables are identified, it becomes clearer what roles are needed around those skills.
In the case of PM’s the deliverables shoudl be “programmatic” in some way. Those are the deliverables of the PM. If those “programmatic” deliverables include some or deep understanding of the technology – say a Control Account Manager for a mono-propellant propulsion system research project – then that may be different than say – installing carpeting in the lobby of the propulsion research laboratory.
Start with the end in mine, as Covey would remind us.
Reply
Feb 22nd, 2009 at 6:03 pm
Having read the post and previous comments, I would say the everyone has made some valid points.
That said, I believe the project manager in a software development project should have at least some knowledge of the software development life cycle and the computer technology upon which it is developed and hosted.
It is important to be aware of some of the issues that can arise in this environment in order to plan for them and ask the right questions of your project lead and your team. While some may say that technical people need to learn to “speak business” (which I do not dispute), the technical team will have more respect and appreciation for a project manager that can go at least part way to understand some of the tech talk. Not only will the project manager benefit from the points that Sonal has listed, but also from the human element of the cohesiveness of the team as the team members can relate better to the project manager, feeling that the manager “understands” them. Duncan’s point is well taken that the PM must know when to defer decisions to the technical lead, but if he/she also has a better understanding of the issues facing the team, expectations will be more realistic.
Reply
Apr 15th, 2009 at 8:34 am
[...] Farmers should Get More Water in California (MercuryNews) – LeakBirdDPI Weblog » Tackling the Niger-delta Challenge!Project Managers: The Value of Understanding Technology | pmStudent [...]