Projects should not proceed without first establishing a sound business case for doing so. Within the business case for the project, there should be a firm understanding of the investment appraisal of the project and an analysis of the risks that may prevent or diminish the delivery of benefits.
Once the project has been initiated, it is vital that the conditions on which success is dependent are constantly monitored. Change can affect the project in many ways, regardless of whether that change is internal to the project, or external. The impact of change may well render the original investment appraisal obsolete.
Equally, the viability of the project should be reviewed at key stages throughout its lifecycle, especially when decisions are taken which may alter the objectives on which the project was built. The business case should, therefore, be a constant source of reference throughout the project. If the project is deemed to be in serious difficulties, with little chance of it delivering the expected benefits its viability and continued funding must be reviewed at the earliest opportunity.
Do not be afraid to terminate the project if the benefits case for the investment no longer holds true. If the decision is taken to terminate the project, do not let the procedure become a long-winded and drawn out affair. Abandon the project and move forward, making sure you learn some valuable lesson out of it. A key factor in the cost of a failed project is often the length of time taken to stop it. If you are in any doubt as to the viability of the project, stop development and audit the project. If this cannot be performed within the organization, seek advice from outside consultant. Additional costs will be incurred but, ultimately, they may save you from financial and commercial disaster.
Lesson 9: Manage external suppliers
It is of paramount importance that formal terms of reference are established for all external suppliers to ensure that the exact scope of their work is clear and unambiguous. In particular, attention should be paid to the quality management systems of the supplier to ensure that they are adequate and can be assessed within existing quality systems.
There are considerable risks in relying too much on assurances made by contractors that the system can be delivered and not having sufficient involvement with them when the project experiences problems. The key lesson must be to develop close relationships with suppliers, but avoid undue reliance on them. At all times customers must retain ownership of the project and its progress.
Control must be established firmly during the procurement process and must continue throughout the project. From a number of the projects examines within this book, it is clear that the capabilities and financial standing of external suppliers must be reviewd as part of the procurement and tendering process.
Lesson 10: Invest in quality
Introducing of quality systems is not cheap; quality standards, assurance processes, tools and training will all contribute towards the cost of quality. For business and IT managers under pressure to deliver systems into the business as soon as possible, quality is often sacrificed in the hope that delivery times can be reduced. For short term it may to ease schedule pressure but will failure to invest in quality significantly diminishes the return on investment for the project.
The lack of testing and defect prevention is still one of the main contributors to IT project failure. Testing should not seen as a single activity that must be completed before the project can be implemented but as a program of tests that when complete, will provide the confidence to plan the release of the product. It is important to remember that the key of testing is not just to ensure technical governance, it is also to protect financial investment from the customer.
Lesson 11: Contingency plan
Fundamental to the risk management process is the need to identify and manage risks within the project. This is particularly important for organizations who outsource the delivery of IT projects to 3rd party organizations because it is likely that risks which are left unmanaged by the supplier will transfer back to the customer with disastrous consequences.
Business and IT stakeholders must, therefore develop contingency plans that can be implemented in the event that the risk of non-delivery actually happens. Some consideration should also be made concerning possible compensation payments to customers who may suffer from a degraded service or reduced business efficiency.
Lesson 12: Senior Management should involved throughout the project
Senior management have a crucial role to play in championing the successful development of IT systems. Decisions regarding IT projects must be treated as business decisions rather than technical ones, and have the full support of senior management. There is no point in having a formal control structure within the organization if senior management do little more than to rubber stamp decisions made at lower levels within the organization. They must accept that the responsibility to track and control the project is needed.
Lesson 13: Owner that accountable for its success
Whilst executive ownership of IT projects is vital to their success, there is considerable evidence to suggest that this is either weak or non-existent. There must above all be a single strong owner for the project, especially where a number of parties havea vested interest in its outcome. Throughout the project, compromises were made in order to please everyone with the ultimate consequence of satisfying no one.
Lesson 14: Software Development project must adopt Capability Maturity Model.
Achieving software excellence takes time and costs money, but do not use this as an excuse for doing nothing about it. Building poor-quality systems will ultimately cost more than building high-quality systems. As an absolute minimum processes that support a basic level of configuration management, requirements management, software quality assurance and project planning must be adopted within the project. Do not rely on the dedication and expertise of your development staff to deliver the project. In a nutshell, if they leave, your project will suffer.
To Be Continued...
No comments:
Post a Comment