Does a Project Manager Need to be a Technical Expert?

“Could you just…..?” is one of our most hated phrases on projects as these words are usually the harbinger of the dreaded scope creep.

The next one is “Could you just take on this role…..you know how it all works after all…..” And then our radar buzzes the alert that we are being asked (again) to be far more than the project manager.

As project managers we often find that business sponsors expect us to have an in-depth knowledge of the business, the technical aspects of what is being delivered, or have deep experience from similar projects. In other words, to be the subject matter expert on the project.  Now, that could be because they don’t truly understand what a project manager brings to the table or that they are trying to keep costs down by making the technical expert also manage the project.  

However, I believe this approach is inherently risky because the two roles are naturally conflicting: 

• A project manager needs to manage the project process.  If he or she is spending time being the design architect, other project disciplines are likely to be impacted

• A project manager needs to be the arbitrator of decisions through the appropriate forum, to ensure that the boundaries of all decision making on the project are clearly understood and adhered to  

• A project manager should be developing a Tribe of people who challenge, develop and own the solution which is difficult if that solution is viewed as belonging to the project manager

I absolutely understand that any project requires appropriate expertise and knowledge to develop and deliver the right solution, but I believe that our skill and value-add is as the project leader and skilled facilitator.  I rely on the business-as-usual staff to know and understand their own business and therefore bring the technical expertise themselves or bring specific subject matter experts from elsewhere.

The skills I have found to be particularly valued as a project leader are: 

• The ability to listen well, be very curious and understand quickly.  Even if I don’t know the detail of the business I need to be able to demonstrate that I can follow technical conversations

• The tenacity to keep asking questions until the technicalities can be distilled down into a simple description which can be used in communication across the business.  In most cases project sponsors do not want to understand all the detail of the solution they just want enough information to be able to make a decision – the ability to summarise, and then expand as required, is a vital skill for a project manager

• The confidence to ask the ‘stupid’ question – the question that sounds stupid to start with, but is actually the powerful question that moves the understanding and discussion forward.  This is often the question that gets the whole group to acknowledge that they are having a conversation based on conflicting assumptions.   One of the disadvantages of being recruited for your knowledge of the business is that you are not able to ask those ‘stupid’ questions precisely because you are expected to know the answers already and therefore you may miss the opportunity to avoid a whole load of mismatched assumptions

• Negotiating with the business sponsors for the resource commitment, to bring together a whole group of varied individuals to explore the real issue, rather than being expected to progress too quickly to a solution

• Holding onto the KISS* philosophy.  When you are deep in the weeds of all the complexities it is easy to over engineer a solution so that it cannot be completed in a time frame that delivers the benefits to the business.  Whilst I am not advocating that any project should ignore the full complexities of the business I have also seen solutions that are technically wonderful, but far too complex for the users to handle and therefore the benefits cannot be realised

• Maintaining good project discipline by exploring and documenting all design options rather than jumping straight into a single preferred or expected solution

• Impartiality to ensure that I do not own the solution, it should always belong to the business users who will be left to operate it after the project is finished

• The ability to dissolve a problem rather than resolve it. Being able to disaggregate a challenge and simplify the situation often avoids very complex solutions being created to solve the issue

With small projects contained within a single organisational function, the technical expert is often expected to act as project manager.  In this instance it may be practical for both roles to be imbued in one individual, because they already have authority over the resources and will be the ultimate owner of the solution.  For sponsors that do not fully appreciate the role of a project manager this looks like a cost effective and practical solution.  Unfortunately this model rarely works on larger projects that cross organisational boundaries.

So my advice is that, if you find you are being sought for your business or technical knowledge rather than your project management skills, push to ensure your project also access to the specialist skills and expertise that are needed.

Ensure you are clear with your sponsor and project board that your role is to lead the project and not to own the solution and put a mechanism in place to enable your sponsor and the right people from the business to engage appropriately and take ownership of the solution.  

If these subject matter expert resources are not included in your project resource plan prepare for a failed project!

Sarah

*KISS: Keep It Simple, Stupid