Recently, I had a long phone conversation with a gentleman who knows what he is talking about: Michael Krigsman. His core interest are the causes and prevention of IT failures in the enterprise software industry. His background in developing tools and processes for software implementations makes him a well respected authority on the subject. He has turned his experience into a tool that will provide an early warning before IT projects go downhill. It is not just another project management tool, but uses people’s perceptions to realign projects with goals. I monitor perceptions to ensure the success of goal-oriented, adaptive processes. No wonder that we got along well.
Michael also quotes Peter Kretzman who mirrors some of my previous posts:
“First off, I’ve never seen a big project fail specifically because of technology. Ever. And few IT veterans will disagree with me. Instead, failures nearly always go back to poor communication, murky goals, inadequate management, or mismatched expectations. People issues, in other words.”
The typical solution to this problem is to call for more and rigid project management, best practices or a methodology. But project management issues can’t be solved by methodology, because if they could be then we would not still have up to 70% of projects either failing or not delivering as planned. Any step to improve this even slightly would be fantastic, but it rather seems to get worse as projects get bigger and more complex. Therefore the trend is to buy industry standard, off-the-shelf, out-of-the-box applications and align the business to work like the software. Oops: It is easier to change a business organization than to create a piece of software that supports as business as needed? Are we being serious??? Shouldn’t all involved be tarred, feathered and chased out of town?
The direct cost of failed IT projects in businesses all over the world must be in the hundreds of billions. The follow-on cost of lacking IT functionality to the economy must be staggering.
Michael describes the core issues of big IT projects in his post The Devils Triangle. It is a triangle of buyers, system integrators (SI) and consultants having different, hidden agendas. In most large projects, software vendors are represented through a systems integrator, who will not only make the choice of software – mostly for reasons unknown to the buyer – but also plan and execute the implementation. Another party has not been mentioned – analysts! To purely cover their back, no CIO or SI would dare to bring a software product into a project that has not been favorably covered by the analyst community. So how in the world can it still all go wrong? Well, read his post! I have voiced and written similar views in the past, but eventually decided to focus on a technology solution.
Wait a moment: If the problem is not caused by technology, why am I saying that technology can reduce those project issues. Why am I developing a communications and process platform if its implementation project can still be messed up by people? Well, if the technology requires less manpower, skills and elapsed time to implement then the people problems will be reduced. A model-preserving application definition that uses an evolutionary, iterative implementation style reduces scope creep and the danger of obsolescence. It solves the problem partially. But it is our experience that IT and business both still need to unlearn the old ways. If business and IT are empowered to adapt applications to needs without big projects, the first rollout does not have to contain everything. Weekly improvement cycles become possible! Faster iteration, more innovation! Less complex analysis, less misalignments. Less people, less problems. But yes, that is not yet enough.
Michael and me agree on one substantial problem that is at the same time an important part of the solution: PERCEPTIONS! I have been writing a lot about business strategy lately, pointing out that processes aren’t optimized when they are executed as designed, but only when the customer perceives them as satisfactory. I am not just talking about delivering a defined outcome, but understanding how bad perceptions are often created by a misalignment between marketing and execution. Happiness is a matter of managing expectations and it won’t be improved by fancy advertizing, a CRM database, or by social networking.
And because perceptions are hidden away in people’s heads, they can’t be managed in a project plan. The bigger the project, the worse it gets. Each individual involved in the project may have a very different perception about the project’s target, progress and cost. Because we can’t control someone’s perceptions, the most we can expect is to understand them. That is Michael’s focus. He uses questionaires to define perception markers that point to project issues rather than monitoring project plan metrics. The whole project has to start with creating the right expectations and too often, these are already wrongly set, just to get the project off the ground. The only way to take care of this is by improving communications and by working towards a project (ideally business) culture of openness. While social networking might improve communication, it does neither improve project transparency nor empowers to take action.
Technology is not the direct cause of project failures, but it is the people who chose complex target solutions that thus create the project nightmares. We should accept that we arrogantly overestimate our ability to manage people in large projects. Keep them small! We misjudge our ability to define a clear solution to a fuzzy problem. Make it flexible! It is the same kind of arrogance that we use when we think we can encode our human business interaction into flowcharts. Stay humble! We don’t have it all under control. Project planning as well as business processes have to consider and support the irrational heuristics of perceptions, choices and decisionmaking. People simply aren’t logical, they are human!