Field knowledge V.S Project management knowledge

Simple and right to the point, That was absolutely and utterly amazing.However, Is there any source were i can learn more about the three points you talked about them (moderate, collaborate and challenge) like techniques to use, More insight, etc ?

I think it is a fundamentally flawed assumption that the PM’s technical knowledge is the sole determining factor for how much they must the decide on the technical issues, and that having both a PM and a SE/BA/Chief Engineer/Chief Scientist/Acronym-de jour assumes the PM is not technically capable to do both. Many times the PM and tech leader are fully capable of switching jobs, and we fill in for each other when needed.

When bodies like the PMI and INCOSE divide responsibilities between the PM and some technical leader, it has nothing to do with competency. It is simply a WBS division. There is often enough work under each responsibility that it takes a team, not just one person to execute each role. We need our deputies or we become the bottleneck. The resource level required for the PM is something we need to plan as part of the SOW development. Additionally, when someone has to flip back and forth between tasks like technical reviews and schedule scenarios, that multi-tasking causes an efficiency drop. Projects can often be led more efficiency by dividing responsibilities by technical vs. business, focusing on individual areas, and collaborating closely to manage the integrated plan.

To divide the responsibility requires trust, not just competency. Much of how much can be delegated is not the technical competency of the PM, but their ability to trust the team. Some of that is dictated by the competency of the technical team. An engineer with 30 years of experience and who always performs at a high level and has led their teams for decades requires less oversight than a new-hire with little work experience. If the PM believes they cannot trust anyone to make decisions independently, then perhaps there is a systemic problem that the company does not hire competent people, or the PM lacks the ability to determine who to trust.

Often when dealing with very large projects and many layers of management, the review of design decisions is not a deep dive of every technical aspect. That should have occurred already at the working level. It tends to be more about how the decisions were made, and who was involved as the scope of decisions becomes larger. We don’t need to rehash every decision, but we need confidence in the process for how they were made. Even if the PM was highly skilled in all involved knowledge areas, they lack the time to review all the lower level details, so they focus on whether those who made the decision considered all the angles important to the project.

Hi Zaid,

Myself and a colleague are putting together a presentation on the subject of Architectural Awareness.

The idea of navigating domains from an architectural viewpoint is not new; however, many project professionals disregard its value as the term “architectural” conjures up images of a highly-skilled engineer (i.e., an expert) who is operating on the delivery side of our profession.

Being able to navigate domains from an architectural (i.e., strategy and structure) viewpoint provides a project professional life-cycle knowledge of a domain and then (by that nature), its relationship to other domains as well. The beauty of this perspective is that you do not need to be an expert to acquire this knowledge.

The “collaborate, moderate, and challenge” aspects are essentially levels at which an architecturally aware project professional can operate within. If you or anyone else has an interest in this subject, then send me a message regarding your thoughts on it (e.g., does it sound practical or hypothetical, how would this help you in your practice, etc.). I assure you this is a practical venture and not hyperbolic theory.

Rami,
This topic does get debated passionately, and I don’t claim that you don’t need any specific domain knowledge, but rather disagree with respect to how much, and how is it used. It certainly depends on the domain, and the scope of the project. Some need specialists, others need generalists.

That is where I completely agree with George on the concept of architectural awareness. Architectures are not the detailed products. They are a set of high level views of something which forms the framework upon which the details are developed. When PMs are assigned into growth positions where they take on more responsibility than before, often they include some of what they already know, and some things they must learn about in order to be successful. Being able to apply existing knowledge to new problems, while quickly learning the key aspects of other domains in the process is what helps make skills portable. It promotes agility, rather than a reliance on “Because this is just how it’s always done”.

Even in fields like construction, if you were building a complex project that integrates some new technology or procurement process, do you need someone with significant expertise in that aspect as the PM, or can you hire consultants to advise? If it is the latter, how to you review the inputs of people with domain expertise different than your own? Can you trust the information of the specialist, rely on others to review their inputs, or must you flatten the org chart so that everyone reports directly to you as the PM? There are advantages and disadvantages to each which must be balanced.

The same goes if you are an expert PM in some field that you are applying it to different domain. I have seen where someone with a high level of technical knowledge in one science was assigned as the PM to a project involving many technologies, but they completely lacked the breadth of knowledge of how it all fits together. They refused to listen to the people who tried to explain it to them, and they were a disaster in the role.

As projects become larger and larger, it is simply impossible for one person to be the gatekeeper for all aspects of a project, so the critical question for the PM becomes how much they much know to manage the project at the architectural level, vs. how much detail decision making they can delegate to the people closer to those details. The same goes for the technical specialist. All that detail knowledge is of limited use if they can’t apply it in a way that it is practical to the business.

Keith

Thanks for your clarification - In this sense, I totally agree with you and I think we are on the same page because I mentioned in my response above that I am not saying you have to be a technical expert but you must have the minimum knowledge and experience to be able to make sense of the schedule, estimates, budgets, change orders, communication strategy, mitigation plans, risk assessment.

Like you said, one man show doesn't work these days with the complexity and scale of the projects so you definitely will have consultants or specialists on-board and having the minimum technical and domain knowledge will allow you to make sense of their advise and make objective decisions. Does this make sense ?

RK

Keith

Thanks for your clarification - In this sense, I totally agree with you and I think we are on the same page because I mentioned in my response above that I am not saying you have to be a technical expert but you must have the minimum knowledge and experience to be able to make sense of the schedule, estimates, budgets, change orders, communication strategy, mitigation plans, risk assessment.

Like you said, one man show doesn't work these days with the complexity and scale of the projects so you definitely will have consultants or specialists on-board and having the minimum technical and domain knowledge will allow you to make sense of their advise and make objective decisions. Does this make sense ?

RK

Rami,
I think we are on the same page as well, so it makes complete sense to me. :-)

I caution people about this because I have seen people take a new job, and panic leads to their resignation when they find that they lack in one of many knowledge areas. Some people also pay for a lot of courses in the technical details and find they never use them. Plus if you become and expert, and the job changes, you either need to gain relevant skills again, or seek a new job.

I sometimes have to coach newer PMs on this subject. Some of them think they should just collect and present raw data but not interpret it. Others do their homework, and ask lots of questions (sometimes to the point of being frustrating), so that they can distinguish between what is important, and what is just noise in the data.

Keith

The armed forces in most countries are made up of three branches: the army (as the land component), the navy and the air force.

In many missions military personnel from at least two if not all the three branches must work together as a joint-task force in a similar fashion as cross-functional project teams work.

Who do you think is the leader of such a joint task force? Obviously a senior officer from one of the three branches or in other words a senior SME with a lot of experience in a relevant line of work. This means that an army general can end up leading navy and air force military personnel even if he is not a specialist in those areas. Still he is a specialist in a relevant domain involved in the military operation.

By saying that you only need some minimum domain knowledge to lead a project team is like saying that a military joint force task can be led by a senior police officer and not by a general or admiral. The police officer also uses guns as the armed forces so he does have some minimum technical knowledge. :)

The companies that don't require the PMs to have good knowledge in one of the relevant lines of work of the project simply don't want the PMs to lead the project teams. These companies expect the PMs to do administrative work and act as facilitators for all the project stakeholders.