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):
Over funded with small scope
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.
Project over scoped with not enough resources
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.
Assumptions are not coordinated with other systems: other systems solve their own issues
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.
No comments:
Post a Comment