November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
Your question carries the answer 'studying to get some basic technical knowledge on the new domain'.....
Find a trusted, seasoned mentor who has deep experience in that domain.
If you truly are unable to bridge the domain experience gap in a short enough time to be effective, you may need to recuse yourself from the project to avoid putting it in jeopardy.
Your boss has placed you in a very difficult spot and I believe there is a high risk of failure, either personal or project - maybe both. IN my experience there typically is some stress/conflict between the PM and the SME even with the most experienced PMs. You have to find some way to bridge that gap otherwise you become an administrator at best - a PM in name only. How to achieve that is the $64,000 question.
- get up to speed technically; easier said than done. how long will it take to catch up to a thirty-year specialist?
- find a suitable mentor; again time is a factor. If you chose internal then that person will become the true PM especially in the eyes of the project team.
- acknowledge your technical limitations and focus on management of the project not the technical matters. Use your personality to get team support, make it about the team not about you, WE rather than I
- identify the project risk to your superiors and come up with some mitigating measures (see above)
Last - good luck
I espouse an approach called “Architectural Awareness,” which is an approach for navigating domains through architectural knowledge; that is, non-engineering big-picture knowledge that focuses on the strategy and structure of domains. If you check my profile, you will see an article that I did on this subject earlier this year.
Bottom Line: You don’t need to be an expert in a domain, but you do need the ability to Understand, Interpret, and Communicate within it. So, in the immediate timeframe, I would recommend that you get a primer from someone who understands the architectural-view of the business-domain and how your technical deliverable relates to that. However, do NOT get into the weeds; keep everything at the 30k foot level.
This is never easy, but possible. It all depends on the required level of knowledge that gives a good enough picture to drive the project. In my case, I always had to read and learn fast some basics related to the life cycle of the project and a bit more to catch if we have a slippage somewhere, but most importantly a good reference (Kiron called him/her a mentor) that I could trust. In some cases, I had 2 to also double-check and learn.
Of course, it is always better to have deep knowledge, but I think as PMs we need to be generalists as well and use our transferable skills. I've lived some reorganization in a company and had to change teams/boss many times. If I wasn't resilient enough, projects would fail. thankfully didn't happen for me. On the other hand, I refused twice, 2 types of projects that I knew that I cannot do them and they need specialized resources/PM. So, you have to evaluate and always be transparent. keep the success of the project first.
You are doing the right thing by relying on those resources supporting you. Your knowledge will come progressively and with the help of those around you. The second step is that you are studying and this will allow you to have better inform conversation with those that are helping with the project. Gaining track into a new domain will take time, but you need to remain doing project in this domain for a while to get to a point where you leading more than following. However new or old to a domain you are still going to need the advice of those that have been around doing it for a longer time. Good luck.
Each and every project in my career was in a new domain, technically and industry-wise.
What was the same was dealing with people, though in different cultures (e.g. retail people think different from investment bankers from court staff). Listening, understanding perceived fears and problems, translating between groups (conflict resolution), building trust with right people, getting the right people on board, communication puts you in the leadership position.
And yes, get a mentor, but outside of the project.
It's great you are doing your own learning and you are not afraid of asking questions! I've been in your shoes and I did the same.
I echo what George and Soha have already pointed out. And, definitely humility as Thomas mentioned above!
From personal experience: I would recommend
- Build trusting relationships with your SMEs, they are SMEs for a reason, it's not the PM's job to be a specialist, I think of it as understanding the big picture and concepts just enough to connect the dots/people so you can communicate with your team and clients. You need to understand what are roadblocks and what are the accelerators in your project. Start with getting to know the people first and let them know you are not there to change how they do things. You are here to learn from them.
- Have an open and honest communication line with your supervisor, have frequent check-ins with him/her to discuss project updates, successes and obstacles. You should keep him/her informed, ask for advice for similar situations. Discuss ways to strategize together and anticipate any positive or negative impact to the project.
- I don't know what type of organization you are in so if your supervisor is not reachable or if what I recommended above isn't feasible. Then find yourself a Sponsor. A sponsor is like a mentor, he/she will advocate and speak on your behalf at the executive table when it's time for promotion vs a mentor will give you advice but may not in the position to elevate you to the next level.
Hope this helps. Best of luck.
This has been discussed many times here. In some domains like IT this is common.
You can still manage projects if you don't have domain knowledge but in most cases you will be a facilitator rather than a true decision maker. If you deliver to an external customer then you will be the first point of contact for that customer and will have a key role even without domain knowledge. In internal project your role will be less important.
While you can still be successful be prepared to be bypassed by some stakeholders who may not want a middle man between them and the team and/or other stakeholders. Be prepared for the sponsor to bypass you and go directly to the SMEs and make decisions with them. They can still invite you to meetings to take notes.
If you are managing an internal project without domain knowledge then you may end up being just a project coordinator. If you manage an external project to a customer who is paying then your role would be much more important even if you don't have domain knowledge. You may not be too much involved in the technical decisions but you will be responsible for managing your customer's expectations.
Trying to gain technical knowledge would help a lot but this would not enable you to make technical decisions but instead it would allow you to better communicate with the team and with the other stakeholder.
Very well said Adrian and true!
Please login or join to reply