Commiserating a week or so ago with an old friend, struggling mightily with some external consulting firm providing technology talent, developing customer management systems for Big Sales Company. There were some critical dependencies on the server side, and the (internal) project team needed some on-site assistance working through the issues. Ad hoc phone support was just not cutting it – but the external project lead was pushing back. It’s very difficult to get on-site, dedicated help for these in-demand DB technicians with little advance notice. My friend would have to wait a few weeks – which did not sit well, hence the commiserating.
Of course, I could easily see his counterpart at the consulting firm venting over his own frosty mug; I myself would feel ill-used (to some extent), because it’s not really reasonable for Big Sales Company to ask for something immediate like this – you just don’t turn these people on and off like a faucet.
I [politely] note that my friend is not the greatest at diplomacy, especially when dealing in shades of gray. He gets too specific, too black-and-white with his thinking; I really don’t think he’s empathizing with the components / teams he needs to work with to get the projects done. They are the subcontractor, the subordinate – he just wants to tell them what he needs, and expects them to hop-to and get stuff done. Don’t define problems, define solutions, yada yada.
That’s not always the most effective way of dealing with the situation; it helps a lot if you can empathize some with the subcontractors / subordinate / supporting teams’ world. Understand the tasks you are asking them to do – so you know when they are sandbagging, but can appreciate when they are committing to getting some really significant stuff done. Don’t just tell people what to do – work together, in a partnership.
But then, as I said this, it occurred to me that this was all just a reflection of how this person manages up when working with the business. Ok, he’s a bit older than me, so after all is said and done, he still thinks the business can ask for anything, can put any wacky requirements out there – and IT just has to figure out how to get it done. Of course, what’s good for the goose is good for the external consultants – the frustration stems from the fact that the consulting firm is not behaving the way he thinks he would behave, if put in the same situation.
This is wrong on many fronts. IT needs to push back on unreasonable requests, if only to set the right expectations for what can happen. We need to help the business differentiate between what they want and what they need, to drill into root causes instead of fixing symptoms or papering over the tough issues.
The best PMs are good at managing up and down; pushing back (respectfully and constructively) on the project sponsors, and working with their supporting teams, not telling them what to do.
Previously …
- PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
- How to Win at the PMO Prioritization Game (December 18, 2007)
- Don’t Accept Snap Answers Too Quickly (July 6, 2008)
- The Power of Paper in Business Communications (October 22, 2008)
- A Plea for Empathetic Communication (November 16, 2008)
- PMO Nirvana is a Conversation, not a Schedule (February 22, 2009)
- Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)
Technorati Tags:collaboration, innovation, people management, PMO, project management, tech management, vendor management
