E-Commerce Times Talkback
See Full Story
In 2003, half of all information technology projects involving third-party consulting will be considered unsuccessful by executives who oversee them, according to a new report from Gartner, because they fail to deliver expected return on investment or operational value. To avoid such an outcome, the research firm said, enterprises should set up a series of regular, formal meetings with contractors to ensure projects stay on track.
Over the past several years I have seen a shift away from a focus on the change management component. It appears to be cheaper to code oneself out of a perceived process stalemate than to address how to change human behavior. The growth of offshore code writing is one result of avoiding the resistance to this change. 3rd party consultants are often forced to present this option as a way to meet unrealistic deadlines where little effort has been spent in deconstructing and reconstructing the business model. It is very difficult for companies to understand the costs to support "customization" moving forward. It can literally handcuff you to a partner and cripple your ability to change the application when the market changes.
It is always good to deal with one company for outsourcing. Administratively it is convenient and we come to know the organisation's delivery standards of quality and time. This helps in quotes for future projects. But one major hurdle comes in if at some later stage there is some change in management of the outsourcing agency and some disagreement happens, then we are in a major loss, especially if we have outsourced majority of our work to a single agency. I believe it is very risky proposition, especially in this market, when margins are so less and there is always the LD clause and quality clause in nearly every contract.
I think the main reason such a large percentage of projects will fail is because organizations fail to develop a clear scope and achievable schedule at the beginning of the project, same as in previous years.
Organizations don't typically do a thorough analysis of their business practices and tend to have unrealistic expectations of what IT can do for them. It's not a "silver bullet"; if you attempt to automate a BAD PROCESS, you'll end up with an AUTOMATED bad process =).
If you don't know what you expect to achieve and fail to involve all the stakeholders during the design and planning phases, then you're bound to hit roadblocks during implementation.
It's important to determine WHY you want to do something and IF the selected technical "solution" will really provide any operational value, much less any return on investment... in many cases, it simply results in a cost avoidance in one area and increased costs to support the "solution" in other areas.