|
Failure? Who says? Traditional criteria for judging IT project success - or more often failure - are no longer correct and should be replaced by measures which reflect new approaches to system development, argues Andy Hyde. After decades of experience and countless publications, most IT projects still fail to reach a satisfactory conclusion - but satisfactory to whom, and to what criteria is the judgement made? Cost and time overrun are traditionally the main criteria, plus failure to meet requirements. But this can have two sides: failure to meet the users' current requirements or failure to meet the original requirements. Requirements definition is at the centre of the problem of defining success and of running an IT project. Traditional project models require a fixed set of requirements, against which cost and time are estimated. The newer models, iterative in nature, accept that requirements will change over time for many different reasons. But, just as a new model for development and implementation is required, so too is a new definition of success, based more on the value of the end result for the business, such as competitive advantage, increased knowledge, changed culture, and happier staff, than purely on the hard financial performance of the project. Here lies a dilemma. Finance departments require realistic estimates of at least cost and time for calculations to compare the financial benefits of competing initiatives. But if requirements are not fixed, these estimates will never be met in reality. But is this really failure? Is it rather our definition of project failure that needs to be updated to reflect new development methods? Research by project management specialist and BCS Member Andrew Taylor (January issue) ranks several reasons for project failure. He found the key stages of failure to be requirements definition, implementation, acceptance testing, project planning, project identification, and development. These can all be related to initial defining or changing of requirements. The causes of failure show the same pattern: unclear objectives and requirements, lack of business commitment, business requirements changing, and poor communication. The use of iterative prototyping with systems thinking addresses all these issues. Iterative prototyping elicits requirements as they emerge in a changing environment, enables user and organisational learning, and establishes a positive attitude to new technology among all stakeholders. In systems development there have been three generations of approaches: developing for the user, developing with the user, and developing as a user, with users crossing into the development team or developers crossing into the user area. This last would be the preferred approach, as systems are being developed to meet a business need, not to teach the users how to develop systems. Other benefits of working this way can be seen when the discipline of systems thinking is considered. User participation in the project is then seen as a continuous learning process for users, the organisation, and developers. It is a communications facilitation technique, a barrier removal technique, and a way to adjust users' thinking about IT projects. All this builds some basic psychology that says that if people are involved in and can influence their own change they are more willing to accept it. Systems thinking also adds an understanding that each person experiences the world from different viewpoints or with different attitudes, these being made up of a combination of values, visions, expectations, motivation, knowledge, experience and often also assumptions, guesses and hearsay. Attitudes affect actions. There are many negative attitudes among end-users and other stakeholders that must be won over for the project to have a positive outcome in terms of stakeholder satisfaction. The iterative prototyping approach must be combined with the understanding of individual attitude differences and focus on providing continuous positive feedback to the affected parties. There is a big difference between participation and involvement: participation is a physical action, whereas involvement is a mental state. All too often users feel that their contributions are pointless. Another aspect of systems thinking is that the interaction of the elements in a system are more critical than the elements themselves. You cannot break up a defective system into its constituent parts, fix each part in isolation and then put it all together again and expect it to function better. Mostly it will function worse. Fixing the technology without addressing organisational issues also reduces the chance of success. This failure is one of implementation, not development. Implementation is the development of the organisational aspects of the business such as the politics, culture and skills to accept the change in technology. One methodology in systems thinking, Soft Systems Methodology, covers just this aspect of change, especially technological change.
The scope of a
project may need redefining as a result of all this, but if this is part
of the project management strategy it will not be unexpected. Communication is listed as the fourth highest cause of failure. Developing the understanding of the need for continuous positive feedback between developers and stakeholder groups will facilitate better communication, especially where users see that communicating is beneficial.
From all this it
will be clear that the traditional definition of success does not hold
up for most IT projects. And by changing the definition of success to
one reflecting the tangible and intangible business benefits, not just
the costs, more projects will be defined as successful. If there is one single reason preventing a change to iterative, prototyping, participative system development it is the failure of the financial organs in businesses or the public sector to adapt to the realities of the complexities of IT projects. If all costs must be balanced by tangible benefits identified at the start of the project, we will see today's failure rate continuing. If, however, value can be put on the intangible benefits of both the technology and the iterative change process, the true cost of development and implementation - probably three times that of the initial estimates - may well be effectively balanced out.
Andy Hyde is a
professional Member of the BCS. He currently works in Norway as a senior
project manager.
©
Copyright
British Computer Society 2000
|
