The speed at which IT delivers projects is often discussed over coffee or lunch. Although staff shortages, other resources and complexity are often the cause, there are other underlying aspects that can slow down IT projects to snail’s (or turtle’s) pace.
So slow
ZDNET reports on the Computerworld article “The 5 reasons IT can’t speed things up”. I think the first two are way overdue in being addressed.
A focus on big projects. In every case, the whole structure of the IT organization — from project offices to approval processes — is geared for large projects that last a year or longer. The projects are strictly linear, with business analysts interacting with architecture to produce reference solutions, then development experts converting that into designs, and then specifications being laid down. All this is good for getting a big effort right, but these steps slow down the work.
Hostility toward new ways of doing things. These IT organizations won’t invest in and experiment with new tools, approaches and methods until there is a project “worthy” of them. Meanwhile, no business client will take a chance on anything new. The result is that yesterday’s languages, tools and methods remain today’s — and likely tomorrow’s.
Silence rather than dialogue on IT investments. When business people are left in the dark about IT’s existing portfolio, they can only wonder: Are the existing pieces expensive to maintain and test? Is the company losing technical quality through skills attrition or lack of investment by vendors? Is it suffering declining functionality as the work processes evolve and the software doesn’t? Without portfolio feedback, the business can’t judge whether to extend what it owns a little longer or to start again for the next decade. More often than not, the business defers to IT — and IT defers to what it already knows.
The business side’s commitment level. Not all the problems are in IT. In every one of these companies, the business does not make IT tech projects a priority. Decision-makers don’t come to meetings, and key issues aren’t worked out early. Far too often, core questions — “What is a superior customer experience?” or “What is a premier supplier?” — aren’t asked until late in the game.
At project’s end, the business won’t participate in testing or invest in deployment support. That’s a governance breakdown. Successful IT projects are a partnership, but too often the business side fails to do its part.
Corporate style. Corporate behavior influences what you can do. If your performance evaluation system is too rigid, or if you are required to plan (and then execute according to that plan) with nothing held back for change, your speed will be limited. Here, IT can push against the limits, but it’s hard to go any great distance past them.
Computerworld column by: Bruce Stewart