Are you a Newly-Hired Project Manager? Here are some questions to ask.
When you’re working on a project with a team, department, or company for the first time, there are nuances and political undercurrents unique to your new organization that won’t be immediately obvious to you.
To avoid potential blunders, meet with your project sponsor and key colleagues to ask specific, probing, and open-ended questions to help you get your bearings. Below are some questions to get you started.
1. What’s my top risk?
Given what you know of sprints / products / projects / task forces / initiatives / implementations that the company has undertaken in the past, what do you think is the single biggest risk that I must actively manage first? How would you go about mitigating that risk?
These questions let you gain insight into the risks that are specific to the organization you’ve just joined. Is there inadequate budget? Undefined scope? Lack of skilled and experienced team members? Lack of political will to push through much needed changes? No sense of urgency? Poor morale? Don’t be surprised if different people choose to highlight different risks — we’re each predisposed to identifying risks we’ve encountered before. It will also be good for you to know what approaches have worked in the past.
Even if the answers you get are utterly mundane and expected, it’s worth it to go through the motions of asking because this initial conversation opens the lines of dialogue between you and this important group of people. You’ve demonstrated that your door is open and that you respect their opinion. They are more likely to reach out to you with more tips and advice as you make progress on your project.
2. Where are the political minefields?
My current scope of work is X, which implies that the following individuals must be involved: A, B, C. Given what you know of these stakeholders and their priorities, what should I watch out for when I present / prioritize / communicate / work with them? Are they part of any project / team / system that will be affected by my project?
These questions allow you to quickly identify people who have reasons to want to see you succeed or fail. It could be that they’ve spent years lobbying for a project like yours. It could be that they previously owned your project but failed to deliver. They could see your project as a boost or a threat to their career. They could see your deliverable as something that will replace them or their work.
Whatever the case may be, you’ll want to quickly align with allies and find ways to reassure potential adversaries. You can’t safely disarm the political minefield if you don’t know where the mines are.
3. Who are the key people behind the scenes?
Given the scope of my project, are there individuals I absolutely must talk to / consult / keep in the loop to ensure my project’s success?
We tend to focus on titles and positions of power when we first join an organization. While that practice is a good thing, we should also keep an eye out for the key people who actually get things done behind the scenes.
Are you working on a new dashboard for the CEO? Her executive assistant will be a goldmine of information. Are you building a data warehouse? You’ll want to talk to the analyst who is intimately familiar with all the data quality problems in your databases. Are you looking to craft new policy, procedures, or workflows? Find the person in the company who does detailed postmortems when things go wrong. Your chances of success go up when you can find and tap the experienced doers who have been working in the trenches getting things done — they’re the ones with the real knowledge.
4. What lessons can I learn from your experience?
If you were given a chance to do things over, what things would you do differently in similar, past projects? Why?
As the adage goes, “a wise man learns from the mistakes of others.”
If you can find a colleague who is willing to share the lessons they’ve learned from the mistakes they’ve made while working on projects similar to yours, then you will have found a potential new ally. Invest time in that relationship and see where it leads.
5. When is it okay to break the rules?
I understand that the company uses methodology / framework X. What aspects of the methodology / framework have been frustrating? Have there been times when you consciously deviated from what’s prescribed by the standard methodology / framework? If yes, why and what were the results? Would you do it again?
It’s not unusual to join an organization that has adopted a specific project framework or methodology. Every methodology brings certain advantages because it has been optimized to deliver a specific set of benefits.
When you optimize for a specific context, however, you also create non-optimal conditions for other contexts. For example, a compact car has been optimized for use in city driving, while a pickup truck has been optimized for transporting a large quantity of goods. Neither vehicle is perfect for all situations.
The same holds true for whatever framework or methodology your company has chosen to use. There may be times when adhering to the letter of the methodology creates more trouble than it’s worth. In such cases, you need to know ahead of time how much you can safely deviate from the methodology without getting flack for it.
—
The answers to this first set of questions will no doubt lead to more follow-up questions, and that’s a good thing. Follow the trail; be genuinely interested in listening to the answers and understanding their implications. Your new job as a project manager will go a lot more smoothly and you’ll have a higher chance of success if you initiate and nurture these open dialogues with the right people.
