Project problems to avoid
commentary How to avoid failure ââ,¬" following are some common problems in IT projects.
Have you ever had a project fail? Perhaps it went a tad (or a few hundred thousand) over budget, or the deadline was extended once or twice, or maybe it was a total loss and you had to cancel the project altogether. Most likely one or two of those scenarios is familiar to you. Some projects fail, and it stands to reason that not every project is going to be a success, but when it doesn't work it can be a painful, scarring experience.
| what if there was some way that you could make every project a success, thereby avoiding the pain of failure. |
But what if there was some way that you could make every project a success, thereby avoiding the pain of failure. During my research for an article on the next phase enterprise resource planning (ERP) for our IT in Government magazine (a supplement of Technology and Business) I was told a few of the common problems in ERP projects, some tips for getting it right, and changes in the way businesses are approaching IT projects that I thought I should share.
Andrew McAdams, CEO Jigsaw Services, has been consulting to the public sector aiding with software implementations. Of course government is notorious for being bad at making decisions -- approvals need to go so far up the chain that it feels like the decision will never come back down. But project failures in both the public and private sectors can be traced back to bad decision making at some point in time.
McAdams' advice is to be aware of decision processes and only involve those that need to be involved. He had the experience recently of a council where no one could agree, a situation he calls a "confrontation phase" -- what is worrying here is that he has seen it so much that he has given the problem a name! "They ended up consulting and it should never have to come to that" he says.
However one bit of talking that McAdams does see as necessary is talking to the people who will actually be using the system in question: "If you want to do something you have to talk to your users."
He also sees a lack of leadership as a definite problem factor in IT projects. He cites the case of one council Jigsaw worked at and says if Jigsaw didn't put itself into the position of leader then he doesn't know where the project would have ended up. He also gives part of the leadership blame to IT vendors, saying that perhaps they could do more to ensure project success.
Speaking of vendors, Len Augustine, marketing and alliances director at SAP, notices two common problems: one, which he says affects all industries, is not successfully managing change and employees' reaction to that change. We all know that few people like change, so perhaps here would be a good time to implement McAdams' earlier advice of talking to the users.
The other problem Augustine sees is companies not first improving processes before embarking on a project. "Some... are going straight to the outsourcing without first standardising processes, sharing services, and eliminating duplication of processes," he says.
However, it does seem that vendors are learning from previous project failures because Augustine has observed a shift in how projects are planned: "The one thing I have noticed over the years is that we talk to customers first about solving a business problem through improving business processes."
If a large multinational software vendor can change the way it approaches projects, then maybe there is hope for the rest of us.
This article was first published in Technology & Business magazine.
Click here for subscription information.