Why is it so hard to get good software?

May 29, 2012

Once we get over our wonder at the broad capabilities of software running on modern computers and devices, we begin to ask why so much of the software we use is of questionable quality.  Between vulnerabilities to malware and constant updates to correct problems, it seems that software is never stable and reliable.  Why?

Software is abstract, invisible and runs at very high speed.  This combination of features makes developing software the domain of a special kind of person who can deal with the abstractions and with the incredibly fine detail of software creation.  Managing a group of such people also requires a special kind of talent as well, because there are tradeoffs to be made between getting new features added and stabilizing the functions that are already built-in.

Usually, the pressures of commercial software development lead software marketers to place much more emphasis on new features than on stability, because features are what differentiate one software product from another.  However, the long-term stability of a product also contributes a lot to the product’s reputation.

Software testing is the usual way to verify proper functioning before shipment.  But since software development routinely takes longer than anticipated, it is the testing that gets short shrift in many cases.  The result is premature delivery of software that is not yet ready for commercial use.

A 2002 study commissioned by the National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually. The same study found that more than a third of that cost — about $22.2 billion — could be eliminated by improving testing.     http://on.msnbc.com/Kae58w

In addition, the operating context of software is constantly changing.  As operating system upgrades are released, the software that works under that operating system often must be adapted to the upgrades.  This means that a lot of the work of keeping a software package current goes to merely maintain the capabilities that were already built.

Users continue to ask for new features.  And marketers want the software to be useful in more contexts – such as making an app useful on an Android phone in addition to an iPhone.  These demands guarantee that a software package will always have an endless backlog of potential changes in the “to-do” list.

As more contexts are supported and more features are added, the software inevitably becomes more complex.  And complexity multiplies the difficulty of testing, and also makes each change to the software riskier.  The more interactions that are possible with each part of the code, the more possibilities there are for mistakes.

What can I do to help make software better?

Purchasers of software don’t have very high expectations, because the track record of the software industry does not set a very high bar.  If users demanded better software and rejected poor software, software vendors would provide better packages – or go out of business.  Why don’t we demand better software?

One reason is that it is hard to switch.  Once we have adopted a piece of software for some function, we tend to stay with it.  First of all, it’s what we are familiar with.  This “makes us rather bear those ills we have than fly to others that we know not of.” [Shakespeare – Hamlet]  The cost of learning a new system is high, and we tend to stay with what is familiar, even if it is painful to use.

Second, the vendors of software don’t often make it easy for us to switch to another vendor.  Try taking an Access database and “porting” it to FileMaker Pro.  The conversion process is a barrier that most of us are unwilling to undertake.  In addition, there may be many people who need to be trained in the new system if we switch.  That adds to the cost.

In the future, we should look at the cost of switching before committing to a software vendor or cloud system.  The more “open” the system, the better for us in the long term.

And we should always insist on demonstrably high quality in software.  Keep this in mind the next time you’re making a purchase decision.

 

Filed Under: Painless IT Tagged With: , , , , , , , , , , , ,

Risk Management in IT

April 25, 2012

Risk management is a key area for financial leaders.  When we look at IT development projects, we’re usually focused on opportunities rather than risks.  But IT investments have risks beyond security and privacy issues.  Project failure can lead to losses even beyond the intended investment.  Here are seven ways to look at IT development projects from a risk management point of view.

1. IT Operations and IT Development must be managed differently. Development is Engineering and must be managed as such. In particular, this means that there must be a certain amount of experimentation to find the best implementation. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Success criteria for IT Operations and IT Development are also different. Development should be measured based on expected ROI plus the strategic value of the project.  For externally visible development, time-to-market and accuracy in delivery against market requirements are also relevant measures.  Operations should be measured on predictability of spending and on Quality of Service.  Operations measures should undergo regular and consistent assessment of their relevance to the business.

3. Most failures in IT Development are caused or compounded by management errors. Very few failures are due to technical inadequacy. The probability of future failures remains undiminished so long as the management errors are not addressed. Examples of these errors include not planning for scalability or not emphasizing modularity of the implementation.

4. The cost of failure in IT Development nearly always exceeds the allocated budget for the activity. Project failure has consequences beyond the immediate failed project, both for people and for other projects.  For example, one late project often cascades through to lateness of follow-on projects.  Another risk factor is the loss of key people when a development project fails.  It is rare to find IT management mitigating this people risk immediately on learning of a development failure.

5. Failures and losses in IT Operations involve directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less familiar, to Operations managers.

6. IT management should be able to communicate to top management the tradeoffs in IT Operations and Development, so that they understand the strategic implications of decisions in IT.  Operational budget must not be the exclusive determinant of IT decisions. In general, the CIO should not report through the CFO.

7. Multi-year planning is essential for both IT Operations and Development. A roadmap for upgrade and integration of resources and services is necessary, even if it must be revised multiple times per year as new services and equipment are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.

If these ideas resonate with your experience – or if you disagree, please add your comments below.

These thoughts were triggered by a recent paper, “Risk Management Failures” (http://tinyurl.com/7ew4t79) by Prof. René Stultz of Ohio State University, published by Cornerstone Research in 2009 (http://cornerstone.com).  With thanks to Andre Neumann-Loreck for his feedback and comments.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,

Three causes of IT project failure

February 13, 2012

IT projects often don’t get done.  Not just done late, but not done at all.  Industry statistics show that over 50% of major IT projects are not regarded as successful. They get abandoned because they’re too late or because they’re so far over budget that the sponsors give up.  Many more deliver something, but not what the sponsors really want, and not on time within budget.

Why do these projects fail to complete? Here are three major causes of IT project failure.

1. They’re not defined well

If the sponsors don’t define the project well, the people implementing it will apply their own ideas to define the outcomes.  This usually leads the project astray, because no matter how technically competent the implementers are, they are not mind-readers and they rarely have a clear idea of the business purpose of the project.

The best way to define an IT project is to start with the end – defining the measurable impact on business parameters that the project is intended to have.  From these, derive criteria for completion including demonstrations of the key capabilities and measurable test results.  If this seems hard to do, then you need to review why the project is being done.

2. The people doing the work are not a team

People implementing the project need to behave as a team.  If they don’t, the project is likely to fail.

You need good teamwork to get a project done.  What’s good teamwork?  It’s good communication with blaming; it’s clear acceptance of accountability for doing what each member said he or she would do;  it’s working cooperatively to solve the inevitable problems that come up.

If your implementation team is split across town or across continents, there needs to be active management of the communications so that the teamwork criteria are met.  Agile development, which relies a lot on self-directed teams, requires outstanding teamwork before any benefit from the Agile principles will pay off.

For example, a client company I worked with had parts of its web implementation team split between two facilities 750 miles apart.  When not enough results were coming through, the manager decided that Agile methods would solve the problem.  But the two parts of the “team” did not trust each other and each blamed the other part for the lack of results.  Only after bringing the top dozen people together in one room for two days per month did they begin to work out their common goals and start to solve the problems.

Leadership is also required in a self-directed team.  Leadership in this context means actively managing the team process and the management.

3. They don’t have enough resources or the right resources

The effort needed to complete an IT project is often underestimated.  A combination of implementer optimism and wishful thinking on the part of the sponsor conspires to make the budget for many projects inadequate.  This causes an unpleasant surprise when the project is nowhere near complete when the budget is spent.

You also need the right resources.  People who have the skill and competence to plan, design, code, test and deploy the program are necessary.  If any part of this sequence is weak, then a lot of time and effort can be lost during the project.

The implementers need the right tools, including software tools and a work environment in which they can use them properly.

Under-estimation of the scope of a project may lead it to grow too big for a single team to accomplish within the time required.  That can lead to further complications, because multiple-team projects require segmentation of the effort into coherent modules, and then the integration of the whole project has to be done by an integration team.  So when you discover the realistic effort needed to accomplish the project, you may also have to rework the whole management structures used to implement it.

If you want to insulate your company from IT project failures, you need to pay attention to project definition, team formation and adequate resources.  Then you have a chance to beat the odds and reap a successful conclusion to your IT project.

Filed Under: Agile Management, Painless IT Tagged With: , , , ,