September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Aziz- I have a fairly long career in the aviation industry, and although I started with a BS in Aerospace Eng., almost nobody else I work with in the field started with a formal aviation related background. Many have an engineering degree of some kind , but I've seen people with business degrees who move into IT management quite successfully.
Some background in the domain is very helpful, but it's not always critical. Often what is more important than the detail level technical knowledge someone brings to the job is their ability to quickly get up to speed on whatever the new domain is that they are dropped into, and the organizational skills to make it manageable.
When dealing with any complex problem, you need to be able to abstract it effectively into a simple mental model at a high level. You need that outline view or executive summary to be able to wrap your brain around the different pieces, before you dive into the details in any particular area. It's often described as "peeling the onion" as there are layer upon layer of details the deeper you go.
I have used a Systems Engineering top-down design, bottoms-up verification "V" approach to understanding projects throughout career on a very wide variety of subjects and later earned a degree in that science so I'm understandably opinionated on the approach ;-). It looks remarkably similar to the PMBoK with more focus on certain areas.
When taking on something completely new, I try to understand both the larger picture I fit into, and familiarize myself with the technology domain, but focus on what layer of the onion I manage, along with how my level interacts with those above and below me in the organization. I have limited control above and below, and know so I focus on my scope of influence. Over time, I will surely learn more about technical aspects both on the work that is feeding into my layer from below, and how my work feeds into others on my level and the organization level above my own.
That is sort of my career history in a nutshell.
Your boss in principle is right, many companies don't require the PMs to be technically competent.
What I've seen in my career however is that PMs that are not technically competent are not really in charge of the project team (technical leads or technical project managers are needed) and can't fully control the project.
A PM that is not technically competent can't take crucial decisions that would impact the project outcome and can't give feedback to the project team members about their individual performance.
Still non-technical PMs can bring value to the project and can play an important role for its success but with limitations compared with a technically competent PM.
Adrian, I would agree on projects that focus on one technical specialty, but in aerospace, we quickly combine a dozen specialties into one system and nobody can be an expert in all of them. Someone has to herd the whole flock of cats. That's where PMs become somewhat of generic problem solvers above the design group level in the org chart.
In a lot of cases, the challenges in the projects aren't the fundamental technology. They are supply chain issues, short deadlines, target costs etc, and the PM doesn't even know what the tricky technical part will until they are already assigned to the project. In those cases, the crucial control the PM has over the project is working with the technical leads to find a solution that fits inside the business requirements.
There is a lot of debate in this topic. One of the people that I do not agree with is @Adrian but I learned a lot of his comments. I fully sustain that worst thing for a project manager is to be a technical expert. I sustain it because my personal experience and because other people I have the pleasure to interact. Obviously, at the beginning, I was assigned to my first project because my technical knowledge in a field. It was in 1984, long time ago, when perhaps it was more reasonable. But I understand that it was not the right way to growth. I worked on something related when I lead a geostationary satellite creating (software and hardware) and because the great amount of specialities involved as @Keith stated above make it challenge. BUT, while PM must not be an expert, she/he MUST have knowledge to work in the initiative and have knowledge mean to perform a mostly forgotten but critical activity: Elicitation. That must be happen before the project begings. Why is so important? Between other things, if you do not perform that, you can not communicate with the people or you can not understand the solution to create all related to the project.
Thank you so much for the explanation. The stakeholders I work with nearly all come from Civil, Computer and Electronics Engineering.I loved the strategy you pointed at the last paragraph. Will practice that.
Please login or join to reply