Rethinking how to improve Project Performance by building business consulting skills and domain expertise
After almost a year hiatus I thought I’d start blogging again – and is my wont I’ve decided to pick a topic that should generate some strong reactions and offer lots for us to discuss.
As should be no surprise, I’ve recently spent a lot of time asking myself how to improve the actual performance of a project. The chart below is a completely subjective view of the levers I’d turn to improve the situation as I see it today (which might not be how I see it tomorrow).
According to me the biggest issue is that most PMs (in IT) are placed in an absolutely impossible circumstance, cause by what I consider by a flawed approach to resource management in their organization. This situation is further exacerbated by the fact that most organization have a fairly immature approach to portfolio management (if in fact they have any approach at all.) These too factors combine to say that everyone is trying to do more than is humanly possible with no real teams and poorly defined goals.
So if 60% of the problem is one that even the best PM in the world would struggle with why am I saying that 40% of the problem still belongs to the PM? Because despite (or possibly because of the emphasis on certification) PM performance has degraded over time. When I initially drew the chart above I was trying to quantify how big a problem I thought lack of knowledge of PPM principles actually was in project failure. By the time I had identified the issues (resource management, portfolio management, domain expertise, and leadership) you can see that I was left having concluded that it was only 5%.
So if it’s not PPM knowledge what is it? My answer is lack of what I consider to be “business consulting/domain expertise”. So the next logical question is why am I focused on this instead of something else and the answer lies in one of those aha moments that happened at last month’s PPM Summit.
While I was there I had the opportunity to listen to conference attendee make the indirect assertion that even though her job was that of a PM, she considered herself first and foremost to be an IT staff member. Now this probably doesn’t surprise anyone but me but here is my issue…
A project manager during the time she is running a project represents the interest of the sponsor and the stakeholders, first, foremost and always (as long as those interests are not at odds with those of the enterprise that ultimately pays her salary).
So, in this case, IT is just one more interested stakeholder. No more and no less. And it is here that we start to build the case for solid domain expertise. If the PM is going to represent the Sponsor, the PM needs to understand and internalize the reason why the sponsor is interested in the capabilities the project is supposed to produce. Is it a web site that customers will find attractive and easy to use? Is it new lead tracking approach that will increase revenue? The litmus test is can the PM carry the message of the why of the project clearly enough to show some level of domain expertise.
How much domain expertise is actually necessary and how much IT experience is necessary is a discussion I’d like to defer for another blog – but what I’d like to do here is start a discussion on any one of three aspects
1) Is it every acceptable for a PM to actually represent IT’s interests first even if they negatively impact the outcome of the project?
2) Can a project manager ever really be successful if all they know is the PMBoK?
3) How do you define domain expertise and how much of it do you need to know to be truly success in today’s environment?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.