Friday, December 30, 2011

The Expert User Can't Provide Software Requirements

Watching Harriet at the keyboard of that old legacy application stirred images of Mozart at the piano.  After 20+ years of daily use, through small change and large, during crises and the boring times, she had learned every secret command, every shortcut, and all the workarounds for bugs and unfinished features.  Even with all the time she spent supporting dozens of other users who weren't as proficient, she still pushed more work through that beast than anyone.

So, when it came time to choose a leader for the redesign of that old system, the business owner insisted that it be Harriet.  "She will protect our interests and make sure that we don't lose any of the functionality that we've come to depend upon," he said.  "Surely, she'll know what we should change to make it work better for us," he reasoned.  And that's when the real trouble started.

Why, you ask? When you get right down to it, two basic reasons: skill and status.  Harriet's key to success was to master the system as it is, and to be slave to it for decades.  Nothing wrong with that, and in fact, every ecosystem needs operational dedication.  But, to be able to redesign a system requires the ability to step back and abstract the essence of what is to be accomplished and then to map that onto a new way to accomplish it.  To do this well takes great skill cultivated by years of practice.  If Harriet had that inclination she would have exercised it years ago - or left in frustration!

If that isn't enough of a reason not to choose Harriet, consider that Harriet had an inbuilt, subconscious bias against making the system more democratic, more efficient.  While no one would ever accuse Harriet of being selfish, every step to replace that system would take another strut out of her status.  Simplifying so that anyone could use it would have removed the need for her to provide expert answers to the new and confused. Yes, while the project was going, she'd be the queen bee, but when it ended, what would she do? Who would need her?

Making the Harriet's part of the solution, without letting them control the outcome, is important.  Or you can do what many teams do - wait for Harriet to retire.

Friday, October 7, 2011

Failing at Failing: Why IT Will Continue to Suck At Large Projects

Air Florida's Flight 90 departs Washington DC's National Airport in poor weather, and four miles from departure splashes into the Potomac River killing 78 souls.  In response to this event, Air Florida flight operations springs into action by standing up an Investigation Management Organization (IMO) to explain or salvage the failed flight. While no person in the IMO has ever captained a successful flight, each speaks with authority and has demonstrated loyalty to Air Florida management.  Several months pass before the IMO presents its findings and remediation plan to Air Florida's board.  Key amongst their findings, the IMO has determined that the flight wasn't a disaster after all, but a limited success! Consider: the mistakes leading to the crash were forgivable given the circumstances (high complexity, factors beyond corporate control), partial service was in fact accomplished (320 seat miles were delivered), the aging aircraft and staff were disposed of only slightly ahead of schedule and below planned cost (public rescue covered the expense), demand for the route is firmly established (all seats were sold even in blizzard conditions), and new flight management is now prepared to resume service (this time with better union and vendor contracts).

Sound familiar?  Probably not.  But, if we replace the nouns related to flight with nouns related to delivery of large Information Technology (IT) projects then this becomes a boringly typical story.  Standard procedure for handling an IT failure must first and foremost save stakeholder skin.  To do this the team in charge must quickly reframe expectations to allow the disaster to be viewed as a limited victory, replace a few mid-level managers "quietly" to pay lip service to accountability, blame the outcome on something intangible or inscrutable to defuse inquiry, and then issue new contracts and reboot the project, often under a different name to hide the trail of failure.  Because nothing is learned from the failure, the next attempt at the project often yields exactly the same result.  In fact with only 1 in 6 large IT projects actually meeting expectation-time-budget, IT failure is so routine and so poorly handled one could say that IT fails at failing.

Ironically, the large consulting firms that tend to run these projects (er, failures) know this lifecycle so well that their management practices are designed to inoculate against blame, i.e., to hide the facts.  Their playbook calls for billing handsomely during the early years, but delivering nothing of note (except hard-to-validate deliverables like plans, processes, architectures, and environments).  During this time, the team celebrates many meaningless milestones in order to capture key stakeholders on record declaring that the program is making great progress and is on schedule and budget.  When failure eventually becomes evident, all stakeholders are bound together in culpability for misrepresenting progress lo these years. As part of the conspiracy, the leading Business Schools support the marauders' view that these failures can't be prevented ( The only choice for stakeholders is to be part of the coverup or to be blamed.

IT needs to change.  As a profession, we must examine failure accurately and publicly to reduce the chance of future failures.  This change can't come from the private sector directly, which already has reasonable fiscal accountability and relishes secrecy for competitive reasons, but it could come from government.  Governments are accountable to more than their organization (i.e., taxpayers) and suffer an inordinately large number of spectacular failures.  Imagine the equivalent of the National Transportation Safety Board (NTSB) for software - a National Software Success Board (NSSB).  If staffed by active professionals focusing on empirical evidence and adhering to transparency, within ten years the industry outcomes for software projects would look very different.  The 1 in 6 ratio for success would be inverted to 5 in 6, the largest software projects would be one tenth the size of today, a growing body of fact-based knowledge would guide new projects toward success, and buyers would be more able to distinguish the silver-tongued impostors who run many of their projects today from the seasoned professionals who could ensure success.

Saturday, May 28, 2011

The ROM Curse: When Guesses Replace Estimates

A ROM refers to a rough estimate of cost and time for a software project or software feature.  It usually stands for Rough Order of Magnitude, although I've heard people mistakenly but perhaps prophetically translate ROM as Random Order of Magnitude.  In an IT setting, customers and bean counters can legitimately ask for ROMs to assist in budgeting, planning, or prioritization.  However, many organizations are too immature to handle this practice and the consequences are often painful for the delivery organization.

As a planning number a ROM should never represent a commitment as it rarely has analysis to support it, however this fact is often lost once the numbers are delivered.  For reasons malevolent, ignorant or practical, too many senior managers and customers later use the ROM as a negotiating cudgel to drive down the real cost of the project, or to change the scope of the solution, leaving the weak project lead holding the bag on a project destined to miss on cost, quality or expectations.

Even more insidious, ROMs become the check written by one party to be cashed against another party's bank account.  For expediency, people who aren't going to be on the hook for delivery create the estimates, but then accountability for delivery is weakened.  As if this isn't bad enough, a more serious dysfunction is created, too.  The implicit manipulation of those who must deliver by those who do the estimate creates a culture of disdain for the delivery personnel.  Over time, only delivery staff with lower skill or lower self-esteem will work in such an environment.

Finally, because ROMs are attractive to the customer - they are created quickly and no customer accountability is at stake - the desire to use ROMs as a surrogate for real planning elbows out any discipline and skill for real planning.  Having lost its planning ability, the organization will consequently lose its ability to do anything novel or complicated. This fact alone may be responsible for many IT failures. 

Like any drug, ROMs feel good in the short term, but the long term consequences are unpleasant for those who deliver.  Your mandate is to fight off the ROM and instead ask those who will deliver to produce analysis-based estimates that you are willing to commit to, at least, until your organization is mature enough to handle ROMs.

Thursday, March 10, 2011

Bipolar Project Funding

"When can I stop funding this project?" asked the CFO, every month for about a year.  "When you decide to shut down the business," was always the answer.  Eventually he stopped asking, but I am quite sure it wasn't because he was satisfied by the answer.  Like many business executives, his belief was: software is written once, it should then just work and not require any more investment.  In an ironic twist, it was this kind of thinking that led to this project in the first place.

This project was the multi-year, multi-release, multi-million dollar overhaul of a large mission critical custom application that was the indispensable core of a $60 million per year line of business.  Due to years of neglect the application had been hindering business expansion, and worse, had caused several Wall Street Journal Events (the corporate term for accidents that require the CEO to perform a public mea culpa).  Which brings me to the point of this note: useful software has a lifespan of more than one release and requires care and feeding appropriate to whether it is a newborn, child, adult, aging, or elderly.

Simply, useful software requires continuous investment because its lifetime will be measured in decades and neither the business it serves nor the technology it is built with stand still.  Moreover, in the growth years (newborn to child), it is impossible to deliver all functionality that could be useful in one release because what is needed is unknowable: the act of using the software changes the organization hence exposing future requirements.  This is unavoidable co-evolution.  Of course, continuous improvement doesn't mean the investment amount is always constant, as some years require more and others less.

Too many organizations do not recognize this fact and impose onerous justifications for every feature, or worse, stop and restart the team.  Team is italicized because stopping and starting ensures that you will have many teams, not one, causing knowledge to be lost, ramp-up time to be added to every restart, and new features to be far more costly than they could have been.  The most efficient way for a software team to deliver maximum value is to keep it lean, minimize turnover, and maximize utilization by feeding them a constant stream of prioritized features.  And stop investing when the application is no longer useful.

So what happened to the project the CFO wanted so badly to end?  Eventually, the overhaul was completed and the business was able to overpower the CFOs desire to cut funding (again).  They kept a reduced, but capable, team to continuously deliver new value against a large backlog of prioritized features.

Wednesday, February 9, 2011

Government IT procurement is so Broken...

The DoD recently mandated shorter release cycles for software programs, as covered in a Fed News Radio piece ( Five decades of IT best practice finally makes it onto the radar.  Hooray, kudos, congrats.  But, we still have a long way to go, judging by the magnitude and number of misconceptions communicated in this short piece.  Here is a classic:

[said Wert] "Literally within the past few years, IT infrastructure-things we call service-oriented architecture-are becoming readily available. It used to be, 'how do we design one?' Now it's 'let's pick one and buy it.'"

Service oriented architecture is about the tooling?  Wrong.  The heavy lifting is determining the services within your portfolio, and then making them act as services, which often involves significant organizational change (both human & procedure).  Tooling helps, but this tools-first practice just feeds the billion dollar disaster parade of: buy first, figure out what to do with it later.  For a review of mile markers on this trail of tears, see

And another widespread misunderstanding is highlighted by these statements:
But one challenge Wert faces ... is a lack of skilled Air Force acquisition experts. ... "The atrophy that happened, especially in our government workforce, really is shocking," he said. ...The acquisition workforce is one of the few areas that secretary Robert Gates exempted in his hiring freeze in the Office of the Secretary of Defense.

And the problem with IT projects is acquisition?  Federal IT acquisition is buying $80B/year of services and products, but not getting $80B of value for that purchase.  Where are the program staff who know how to run an IT project? ...who know how to make a business case? ...who know how to build a roadmap to generate steady results? ...who value the people and skill part of the equation?

Framing IT problems as acquisition problems ensures that we will continue to see large COTS purchases that fail to deploy.  Well, perhaps they'll fail faster.