Nick Malik opines that measuring customer/sponsor/stakeholder behavior on projects should allow more of them to succeed. Nice thoughts, but I don't think it will fly, at least not in a lot of organizations.
Why? We focus primarily on what I call P-words: People, Process, Projects, Programs...and yet, there is one P-word missing; and it's the one that trumps all of the others almost every time:
Politics.
While Nick looks at projects as a partnership between business and IT - which it should be - it more often isn't, and the model most frequently used is the customer-contractor model. The business "hires" IT to develop systems and manage projects just like people hire general contractors to build or renovate their homes.When and if things on the project go awry, whether caused by the customer's actions or not, the contractor is much more likely to be blamed, take the fall and suffer the consequences - whatever those are.
Other project situations that may become politically-charged are when there are opposing forces/viewpoints against the project from other powerful people in the organization - including non-sponsor stakeholders that have competing interests or don't want things to 'change' in the manner in which they operate their portions of the organization. You can try and 'measure' that behavior all you'd like, but in the end, it won't much matter because a political crusade is being waged, not some rational discourse that leads to logical, obvious, and optimized conclusions and action.
Nick asks, "The project scorecard can be used to demonstrate that the right behaviors are happening on both sides. After all, if a project fails because the business sponsor was unwilling to buy in to the approach, or wouldn't sign off on the interface design, or because the business users wouldn't participate in the test process, why should the IT team take the rap for missing the dates or overruns in cost?"
Because in the culture of a number of organizations, IT always takes the rap for project budget overruns and missed dates, whether it was responsible for them or not. That's largely the result of politics at work, not process or maintaining scorecards on unhealthy behaviors on the part of project sponsors and business stakeholders. Granted, sponsors and stakeholders who develop track records for sponsoring projects that repeatedly fail or cost too much often fall on their swords - eventually - but it usually takes more than one discrete project failure to have that happen. Often it takes several and in some cases, it never happens at all.
The best one can do in these types of situations is the following:
- Perform the appropriate level of risk management on and in all phases of the project - or in every iteration if it's an Agile effort.
- All risks should be communicated to the business, not only the consequences of the risk events, but what the remedies (if any) will be.
- If risks are triggered for any reason, document it. Share it with sponsors and major stakeholders. If you encounter resistance or objection along the lines that Nick described above, there are reasons for those attitudes/behaviors (whether rational or not), and you must find out what those are and hope there are remedies short of project failure/cancellation.
- Deal appropriately with the consequences of customer-triggered risk events. Business sponsors certainly have managers looking over their shoulders, but going over a sponsor's head with 'scorecards' and 'metrics' may backfire on you huge. Do that repeatedly, and let me put it this way: it's the wrong time in economic history to be unemployed.
- Project managers must have an intimate business relationship with business sponsors and major stakeholders. There must be trust developed or already present on both sides, and when there is, that's a prime reason why successful project managers make the statements that Nick cites in his post about their sponsors. In such cases, there is no need to document business sponsor behavior on a 'scorecard.'
Projects are a lot like life - scorecards are useful for some things, but relationships matter far more in the end.
Fully agree on that one. While contractor has to care about their business there's alway a ghost of "customer is alway right" principle in the backgroud. Unfortunately the bigger the clinet is the more politics is usually involved.
As a relatively small company we used to exploit the old trick with a bad policeman and a good policeman. We always had a consensus internally whether we believed in schedule and cost, but sometimes when the client expected it'll be cut we told ourselves: OK, we'll try but since that's not something we believe we won't play a blame game if we fail. Of course we had to take the rap and usually it was technical team to do that, but at least internally there was no politics at all and we still had a good policeman (usually sales team) who was able to fix most things with the client.
Posted by: Pawel Brodzinski | November 24, 2008 at 05:06 AM