I recently came across this
2 year old article on CIO.com about a project at Hewlett-Packard where they were implementing SAP to replace old legacy systems for their supply chain. Migrations had gone fairly smoothly until they got to a much larger department that handled customer orders. They knew this one was going to be a bigger challenge. Before the start of the migration, the project managers did their requisite contingency planning and padded their workplans to accommodate for a few glitches they foresaw with one particular legacy system. Long story short, they severely underestimated those issues and were hit by others they didn't plan for, business operations were negatively impacted, and HP pegged revenue losses at around $40M.
Another anecdote in the article was about Nike:
"Other companies besides HP have faced similar business disasters from relatively small IT errors. Nike, for example, had a problem with a demand-planning application when it switched to a centralized SAP system in 2001. The problem was tamed within a few weeks. But because the company did not have an adequate business contingency plan, the small glitch in IT cost Nike $100 million in revenue." The article goes on to talk about the need for better contingency planning and a more thoughtful approach that considers the impacts IT snafus are going to have on operations. If you're a project manager, it's all good advice. But having managed several large projects myself in my consulting days, I learned contingency planning only gets you so far. Having a great project manager who is a Gannt chart ninja only gets you so far, having managers from the "business side" involved only gets you so far, having good team chemistry and lots of fancy collaboration tools only gets you so far, having a robust methodology only gets you so far, and even having all A-Players on your team only gets you so far.
So why do so many promising IT projects go bad?
Let's dissect at a very high level how a large IT project is run. The standard operating procedure is to do a lot of planning up front (including formulating contingency plans,) create thorough workplans that are managed throughout the project, create and manage issue tracking spreadsheets, if the project is large enough, set up a "program management office" with several project managers working in concert, set up a team collaboration space for files and dialogue, create protocols for reporting status up and down the project hierarchy, schedule weekly status meetings, and facilitate ongoing communication between different parts of your project team and the business.
That all sounds great, but obviously there's something wrong or else we wouldn't read articles like this.
One key element missing in so many of these large IT implementation projects is ongoing,
unfiltered feedback from the project team itself AND from those whose business is impacted by the IT changes. On our projects at Accenture we certainly were never accused of not having enough meetings and documentation (what do you think your millions are paying for?) We used to collect status reports from every person on the team and have status meetings at least once a week. We had liaisons from the business units we were building the systems for and met with them regularly to keep them updated on the project and to hear their concerns. Sometimes they even joined our teams full-time. We had an extensive knowledge base of sample deliverables and project post-mortems. We had collaboration tools and executives coming around to QA the project every few weeks. We had Subject Matter Experts from the software vendors. Any of this sound familiar?
I would argue that you don't have to look much farther for one of the problems with IT implementations today than the ubiquitous "status meeting." You get together in a room with all the "leads" on the project, usually at the end of the week, and talk about how each of your teams are doing. Sometimes you even have the entire project team there which can be 100 people or more. (It goes without saying that no one really even wants to be there.) You highlight things that have been accomplished, what you're going to be working on next week, and talk about the critical issues you're dealing with. A good project manager will ask a lot of questions during these meetings to try and coax more information out of people, and every once in awhile some squirming and squabbling ensue. After the status meeting the project manager may send out notes and an updated project plan reflecting people's comments and how he/she has interpreted their impacts.
But is the project manager really getting the information they need to make informed decisions about the direction of the project? There's a game of self-preservation and chest thumping that often occurs in these meetings that is a filter for everyone's comments. Who wants to look like an ass in front of the people they get evaluated against for promotions and raises? Are you really going to let on that you haven't been able to work through some problem that you think will sound embarrassingly easy to others, or that you think another manager is full of it?
It turns out that us humans are all just a little egotistical, sensitive, jealous, and competitive. Those characteristics are oil in your glass full of project management water.
Meanwhile despite the project manager's best intentions and traditional information collection techniques, signals about milestones that are going to be missed or issues that are going to blow up are not revealing themselves and the project rolls on like a tank in a minefield. A project manager has to respect their "lines of communication" on the project or has to respect the larger organizational hierarchy of the company. They only hear about the big ticket issues, the issues that their direct reports are even aware of, or worse, just the excuses that make the issues sound minimal.
Now you have a project manager, no matter how talented they are, operating with large blind spots because they aren't getting proper exposure to reality. Next thing you know you're getting written up in CIO.com as a case study and your CEO is talking about $40M losses in revenue. Ouch.
What if that HP project had been running a prediction market where their entire implementation team AND people (not just liaisons) from the business units their project was affecting could trade on their project milestones? Or what if the project had taken their list of project issues and put those in a prediction market to understand the probability of them occurring? Or even better allowed people from the business side to ask their own questions about the health of the project and impacts on their operations: issues a project manager could never expect to always be on top of? I suspect HP's talented project managers would have done a lot of things differently if they had access to this new information.
There is no getting around the fact that large-scale IT system implementations are always going to be messy and complicated. Prediction markets are not only an efficient mechanism for providing actionable feedback to the project manager to hopefully avoid many of the issues and lost revenue they encountered, but serve as a credible counter-balance to the fact that we're all...human.
