Sunday, March 24, 2013
When ECM's “How” gets in the way of the “What”
It's one of those golden rules of IT projects to collect the business requirements with an open perspective, unshackled by technical or operational concerns. But, what happens when this rule is broken? What are are some of the symptoms of putting the how ahead of the what? Here are a few categories (out of many):
Capital projects are structured in such as way as to be viable for certain period of time. These projects can have moneys which are over allocated. This creates a “bucket” to use on other, related projects, which can benefit from the “shared” software application or servers. There's a time limit, so the deadline of spending approaches, management will get creative and spend money on more innovative projects.
This where the time-line of initiatives and ROI objectives get delayed and pushed back to the point where the original project sponsors loose faith in IT's ability to deliver. Sometimes years will go by with nothing happening, meanwhile the business is forced to find alternatives. Shadow or cloud projects are developed on the side, within the view of IT, but without consequences. That is until a system goes down and someone begs IT for help. Then IT takes it over and begins the journey back to standardization and optimization, and lest we forget, shared services.
The larger the IT project, the more integrated it is going to be. Without a concerted effort at understanding the full breadth of requirements and assumptions at the beginning of the project, the project will falter each time an integration step is needed. Why? Because the time and effort was not taken to include the key players of integration during the planning and funding phases of the project. The assumptions were glossed over by the deadlines to get a budget in place.