Thursday, November 3, 2011

IT projects: it's all about the people

http://www.infoq.com/news/2011/10/risky-it-projects

Well, still no progress on large IT project implementation in the last decade or so. Which compounds on the lack of progress in the previous decades. Of course it's practically impossible to measure projects on the basis of scope, requirements, complexity, etc across the ages. But they can measure the perceived rate of failure and cost.

Software development, delivery, maintenance, and interoperability have not produced major gains, and this study underlines it. I'd argue that the only real broad-scale efficiency success stories have been defined around widely accepted standards, especially HTTP, HTML, and other web standards.

After a couple decades in IT myself, it's pretty apparent to me what gets in the way, and it's not particularly controversial: it's the people, stupid. And that's highlighted by the fact we added several zeroes of capability to the hardware our software runs on, from tens of megahertz to multi-gigahertz processors, from 250 megabytes of storage to 2.5 terabytes of storage (!!). From 4MB RAM to 16 GB of ram. Mother of god those are amazing engineering accomplishments.

First off, lets start with the business people, who control the purse strings and decisions. it astonishes me that still, STILL, to this day, dealing with business people in systems specification at every stage from incubation/prototyping/formal design, indicates fundamental ignorance of IT delivery complexity, concerns, lifecycle, delivery times, etc. They don't even have an approximate understanding. Considering your typical business person has been through the process of getting an MBA, and thus have been "baselined" in the standard practices of business administration, this is pretty telling.

About the most complex thing MBAs learn universally is accounting. IT knowledge is still siloed into the "MIS" degree. And there we have the problem. What business function isn't intimately related to an IT system? Accounting, budgeting, production, supply chain, HR, recruiting, marketing, customer care, I can't think of ANY MBA-concerned business function whose efficient operation isn't tightly coupled to IT systems.

And yet, the basic process, scale, risk, and results from IT projects to integrate, install, configure, adapt, and deliver IT capabilities is treated with absolute ignorance on all these MBAs. Hell, you still, STILL hear about CEOs that proudly state they can't even turn on their computers and have their secretary print out their emails and do dictation. For every dinosaur like that, there are hundreds of people with other stages of malignant IT ignorance, running major companies whose very operation is fundamentally dependent on their IT systems.

I don't get it. You want a competitive edge in MBA land? Have basic-level IT management knowledge. Know about technology at a basic level. Know about the "great divide" between the detail necessary to specify a system expected by non-IT people, and IT people. Know that large-scale IT projects succeed when they represent an evolutionary process, not a dramatic huge system rollout. There's a ton of MBA-level IT knowledge that can be gleaned without knowing how to write a java class, what CORBA is, or any of the other limitless technical complexities and low-level protocols are involved. But your typical business person (as in: 99% of them) are utterly clueless about this.

The second major people problem is access. I''m not just talking about defending your systems from script kiddies and external threats. It's the more insidious beauracracy-generating internal access processes set up by IT organizations. Need to install software? Need to deploy from dev to test to stage to prod? Need access to a machine? Need access to a database? Need a machine to install a server?

Yeah, typical IT organizations you need to navigate a metric crapton of apathetic ticketing systems, signoffs, okays, and manual people decisions to do even basic things. And why? Cover Your Ass. It's all it is. All these managers with oversight over their specific concern (servers, databases, deployments, desktops), rather than enable access and freedom and innovation, would rather lock it down. Really tight. As in nothing goes in or out without them knowing about it.

What causes cross-business systems development failure? Inability to integrate. If you need access to some data (even read-only), you can't just look at the database, slap a quick web service gateway, and then enable the data access. Nope, you'll need to request access to the database, then request access to a new server, request access into the server server, request permission to install applications on the server, request permission on the internal firewall ports, etc etc etc. Sound simple? Typically those are queued behind formal request systems and take days if not weeks to review and complete. Massive time and efficiency losses.

Unfortunately, this is an area I can only complain about, I don't have any good solutions. Perhaps systems need better design from a "future data access" concern. Many/most systems are developed as "service oriented", but rarely are the specifications for the access well documented. Of course most services are probably still written in SOAP, which makes the service convoluted and inaccessible, destroying all the advantages of service orientation.

The third people problem is the IT churn of old-hat new-hat software, protocols, terminology, frameworks, and the like. A lot of these problems are due to the lack of evolved standards and practices that became prevalent over a couple centuries like accounting.

Almost every concept, problem, and concern in IT is represented by a half-dozen terms that largely mean the same thing. Even technologies around well-agreed standards like the internet have far too much terminology variation. This represents a fundamental communication problem even among IT people, who can't communicate concerns, architectures, approaches, and practices as efficiently as occurs in science, law, and accounting.

The fourth problem is the goddamn sales people. This is the most insidious source of problems in IT, since the software sales people talk to the business people, and I can't tell you how many "hey look I built your app in 10 minutes" demoware presentations that completely pull the wool over the businesspeople. Then they get angry when "10 minutes" becomes "10 months".

Businesspeople love being told that all the work done by their underlings that seems so inefficient but usually isn't that inefficient, could be done 100x faster, and they're just morons. The magic bullet. Businesspeople love this, since if the magic bullet works, they get promoted. And all they care about is getting closer to stock options.

There's dozens of these sales jobs underway in large IT organizations at each time, each subsuming and disrupting things right and left. Each basically not solving or enabling anything new.

Because you know what really produces progress? Not magic bullets, but boring evolutionary changes like gradual service enablement, stabilized systems, virtualization.

No comments:

Post a Comment