Tuesday, December 21, 2010

Chaos rules in various government IT shops these days. With tech experience obtained on the 2008 campaign trail, an army of sprites have taken up residence in leadership positions to change government. Theweapon of choice for these tech savvy, techusers is the citizen engagement web site. This is great stuff, long overdue, but a darker side has emerged, too.

Proving the dictum a little knowledge is a dangerous thing, some of these folks actually think they are technologists. Attracted to cool end-user tech (content management systems, scripting languages, social media, and mobile apps), they view the rest of IT as "overly complicated, old school tech." Absent from the tool chest are: business cases, sound security, project discipline, data management, software practice, portfolio strategies, operational procedures, risk management, and... deadlines.

By itself, the lack of appreciation for the difference between real mission software and a content web site is unsurprising and not harmful. However, the amateur hour is making its way into work on mission systems.

I'll be the first to claim that there is far too much process heavy, narrow minded "we do things this way because we always have" thinking in IT, particularly in the US Gov. But, in this pendulum swing away from discipline, we're witnessing a 12-year old delinquent in the driver's seat of Jeff Gordon's #24 winging through the streets of DC at top speed. This can't end well.

Sunday, November 21, 2010

The best technologists are business focused, technically sound, and have a long track record of successful solution delivery, yet so many newly minted head geeks are not technologists at all and have delivered little or no technology. For example, the White House Deputy CTO is a law professor, the Technical Director of Code for America is a policy analyst, and the CTO of HHS has a recent degree in economics and no apparent technical experience.

An industry shift to non-technologists as leaders could be a necessary response to the changing technology landscape for several reasons. Paraphrasing Nicholas Carr, technology has become commodity, provides no strategic advantage to business, so there is no point for a real technologist to have a seat at the table. Or perhaps by appointing a business person to run tech, the annoying business-technology gap can be closed, or at least moved out of sight. Or maybe because data analysis, communication (web2), and policy are increasingly important parts of IT, economists, communications specialists, and lawyers might make better technology leaders.

While these trends are real to some degree, organizations lose something important when they mistake a soundtechnology user for a sound technologist. In what other profession would we accept a leader who is ignorant of the fundamentals of the profession? Would you elect surgery at a hospital if you heard the Chief of Surgery say, "Oh, I don't get surgeons, they're artists; I've used them before, my value is that I ask stupid questions."? Swap "programmer" for "surgeon" and these are the words uttered by a CIO who has no tech experience and a $1.3BB budget. By the way, she was fired after 3.5 years of disastrous results. (It took that long for reality to leak to the boardroom.)

Most IT leadership positions require experience across a broad range of business/technology conditions. Multi-year projects, cyclical business, complex integrations, transactional systems, analytical systems, supporting business process, chasing capacity, vendor management, security posture, long-tail maintenance, each presents distinct challenges. Relevant experience matters and takes time to accumulate. Unfortunately, the distance in time between cause and effect is often too great for most to see how much pain is created, and money is lost, by lack of relevant experience in technology leadership positions.

Wednesday, November 10, 2010

In a perverse inversion, the split personality of Information Technology (IT) subjugates strategic application development to operational management. Surely because 70 - 90% of the business of IT is operationswork*, most CIOs are operations specialists. While operations is important however, most operations-focused CIOs have no business managing application development.

To understand why, look no further than the differences between the two professions. Stability and reliability are the bedrock of operations, whose main enemy, change, must be eliminated. Drawn and managed by a few masters, detailed procedures are executed by low-skill workers to ensure conformity. Key partners of an ops leader are predictable vendors of stable technology, and peers for product reference checks, while mortal enemies are software developers and demanding customers.

By contrast, application development is about embracing and managing constant change under uncertainty. The work is a high wire act of continuous problem solving, built on experience, with acute sensitivity to local variability. Key partners are a patient customer to guide the conversion of time and money into business value, and disciplined yet creative teammates to share the load, while mortal enemies are CFO's, who see all resources as fungible, and inflexible CIO's.

Is it any wonder that app-dev under the operational CIO is trail of expensive disasters? A good operational CIO suppresses change and therefore innovation, forces vendor COTS into places it cannot possibly fit, grinds app dev leaders to paste by demanding recipes for software creation while hamstringing them with armies of cheap dolts.

It's time to break the mold: hire a good ops CIO under the CFO to keep the trains running, but hire a good VP of development under the COO to help innovate your business through judicious application of custom software. Application dev in IT departments might just then begin to approach the efficiency and reliability found in the software product industry.

* See the ITIL framework, but skip the lame section on Application Management.

Tuesday, November 2, 2010

The reasons for project failure are endless... and always the fault of forces beyond our control. Some real excuses from IT executives:

"Senior management set impossible deadlines."

"The users keep changing their minds."

"Those developers, are artists; I don't understand them at all."

"Finance wants to offshore to save money, we have no choice."

Grow up. For those who need to learn to artfully say no, I suggest Bill Jenson's book "The Simplicity Survival Handbook" (http://amzn.to/dfmoOF). For those who need a refresher in risk management, you could do worse than read Hugh Clare (@intsystemdesign).

Sure project failures are sometimes beyond our control, but these reasons are rarely heard: the budget was withdrawn, we lost the team to a plane crash, the Internet went dark for a month, ...

As technology professionals, we must take accountability to say no artfully, and we can refuse to work for organizations that hire leaders who fail to take accountability.

Monday, November 1, 2010

The US Government routinely spends $1B or more on software projects, which almost always fail to deliver anything close to that value. In a stunningly sane move, OMB halted $20B of "financial system replacement" projects this summer. Perhaps to show they mean business, again this fall OMB and Vivek Kundra began detailed inspections of 26 troubled high-ticket IT programs worth $30B. On this list the poster child of offensiveness is the $4.7B ACE modernization project, for which IBM has been paid $2.7B to date in exchange for exactly bupkis.

High risk, high value projects can be justified, even at high cost. The US effort to ramp up its wartime footing in the 1940s, the Manhattan project, or even the race to put a man on the moon. But where do we have evidence that $1B software projects for routine IT usage have ever made any sense? At 260 people the avionics software team for the space shuttle* is large -- and has probably cost a billion dollars over it's 40 year lifetime -- but is a rare exception.

The literature in software projects clearly documents that risk rises much faster than team size. Ideal team sizes are measured in the 10s not in the hundreds. Even for multi-million line systems, tens of people over a decade are far less risky than 100s of people over the same time period.

How do these flagrant wastes of money and opportunity come about? A demanding user base that doesn't have to pay, a swarm of large IT service mercenaries who make a profit on "asses in seats," business school case studies hawking governance to guarantee success, a blind congress to foot the bill, clueless government management, and cause and effect so distant in time that there is no accountability.