Top 10 Ways that Guarantee the Failure of a Project
Comments(0) I was reading an article about why projects fail and found interesting points and the following list has been inspired by actual mistakes encountered in real-world systems projects.
1. Don’t use a specific methodology because coding is all that is really important.
Using a structured systems development methodology is one of the critical success factors in a systems development project. For this reason, some years ago, Peter Koletzke and I came up with the CASE Application Development Method (CADM) as a successor to the traditional CASE method pioneered by Richard Barker. CADM is based upon a few core concepts. First, an engineering manufacturing approach to software development was used. This approach pays careful attention to quality control points, identifying where in the Software Development Life Cycle (SDLC) these points occur and what types of checks are necessary to ensure that each phase is successfully completed before the project is ready to move into the next phase. Explicit quality control points must be included in any successful project. For example, the formal model defense after the data model is complete is an often skipped, and later regretted, step. Conversely, within CADM, quality control points were eliminated where unnecessary due to implicit controls. For example, performing data migration helps to validate many aspects of the physical database design.
A second major philosophical component of CADM is an audit trail for system requirements. We included the ability to track a requirement throughout the SDLC from its initial gathering during analysis to its impact on user acceptance testing at the end of the process.
2. Create the project plan by working backwards from a drop-dead system completion date.
Working backwards from a fixed project completion date is a sure way to guarantee project failure and yet, unfortunately, this is an all too common practice in the IT community. Managers may make a decision about when a new or re-engineered system would be useful to have in production without the necessary technical knowledge to determine whether or not it is possible to accomplish successfully in the given time period. No project ever went completely smoothly from Strategy to Implementation. There are many places in the SDLC where schedules can go awry:
- Failure to perform careful analysis resulting in critical new requirements being uncovered late in the development process.
- Failure to take data migration into account.
- Failure to accurately assess the political climate of the organization vis à vis the project.
You must set a realistic timetable for the completion of a systems project and expect that some deadlines will slip as unexpected setbacks inevitably arise. Forcing a deadline to drive the schedule will cause corners to be cut, greatly increasing the risk of the project. Even if the system gets built, it is usually of very poor quality as application after application is built just to get them completed.
3. Don’t bother with a data model. Just build whatever tables you need.
The data model is the core of the system. Without a carefully constructed data model, any system is doomed to failure, or at least to not meeting the users’ needs and requirements.
I am always surprised when I hire a developer with several years of experience who has never seen a data model. Even if they have worked with data models, they have usually never seen anyone carefully audit one.
I am equally astounded when I go into a large financial institution and find that there is no data model for a system that has several hundred tables. When I audit such a system, I find that there are numerous critical flaws in the system that allow bad data to be entered. In such systems, data migration to a new system can take many months because so much of the legacy data has to be cleaned up.
The worst situation I have ever seen had each developer building whatever tables and applications they needed to support those tables. The technical lead came in later to try to make the disparate pieces work together. Needless to say, the system was never completed.
Data models should be directly under the control of the technical lead. Each subsystem should be integrated into the whole prior to development.
Models should be designed and audited, and re-audited, and re-audited until no more errors are uncovered. The audits should first be done by the technical lead. Then an outside auditor should always be brought in for an additional audit.
4. Use a Technical Lead that has never built a similar system. Hiring such talent is too expensive.
The person in the role of project Technical Lead must be experienced. He/she should have completed other successful similar projects. The role of technical lead is like that of a skilled heart surgeon. You would not expect a family doctor to perform brain surgery or administer anesthesia. It is critical for the person in charge of the technical aspects of the project to have experience with the type of system being built.
Of course, such a resource is quite expensive - not nearly as expensive as a failed project, but still expensive. I have to admit that I am mystified by managers that will gladly put 5-10 more $700/day consultants on a project but will refuse to accept that a good project lead will cost several times that amount. So, they have a large team generate a bad system for a great hourly rate.
My favorite example was a large organization with 80 developers that were unable to bring up a system. In fact, according to the project manager, little progress was being made on the system. However, the same organization was unwilling to bring in a senior technical lead that could have put a solid development environment in place, and would have made all 80 developers productive.
5. Hire forty developers to make the coding go faster.
More is not always better. This is especially true in the case of development teams. A project with a few skilled developers, carefully supervised by the appropriate technical lead has a much greater chance of success than one where hordes of developers are cranking out mountains of code each day.
On one system where I was hired as technical lead, the project had 40 people assigned to it. I was asked what resources I needed to make the project succeed. I told them “20 fewer people.” They thought I was kidding, I wasn’t. However, this was a consulting firm, where billing was evidently more important than efficiency.
6. Selecting wrong tools and technologies for development
“The right tool for the right job.” This motto is as true for building systems as it is for building houses. One of the problems for many system architects is the fact that the available tools greatly influence the way systems are built. Even the basics of the development process are influenced by the tools selected. Make sure that the necessary expertise is in place for whatever development tool is selected.
7. Three months before the system goes live, assign one junior developer to handle the data migration.
The data migration phase of a project can consume up to 30% of the total project resources. Typically, the amount of attention paid to it in existing methodologies is very small. The cost of data migration tends to go unforeseen, until far too late in the project schedule. The most common flaw in data migration planning is that too few resources are invested in it. Many project schedules will list data migration as a single task in a development effort. However, by project’s end it will be evident that data migration was indeed an entirely separate project, highly dependent upon several of the deliverables of the development project.
For these reasons, it is very important to plan ahead for data migration on any project. In particular, implementing generic data structures, which are desirable for increasing the lifetime of the system, can create significantly more complex migration issues than implementing traditional system designs.
After witnessing a number of failed projects and learning from bitter experience, waiting three months before going production to assign one person to handle data migration will inevitably cause system failure.
8. Skip the testing phase because the project is way behind schedule.
Putting a system into production without adequate testing is like diving into a swimming pool without checking to see if there is water in it. No system was ever created completely bug-free. The time spent to thoroughly test any system before placing it into production can save much more time in the long run.
In the Test phase, you should develop a test plan that should describe not only the tests to be run but also how test failures or variances will be handled. Especially for a large system, it is not practicable to wait until the end of the Build phase to start developing this test plan. There must be some overlap. As each module is tuned and passes unit-level testing, it is stable enough so that formal tests can be planned.
It is not necessarily true that every test failure or variance leads to modifications of the system prior to production. Within the Test phase, it will be necessary to re-audit the design process, perform system- and user-level tests, audit the quality of the documentation, test the internal controls and backup and recovery procedures, and in all ways ascertain the fitness of the system to move into a production environment.
The lead QA person needs to develop a test plan. Users need to be involved to identify the test cases, and they can write the test scripts and expected outcomes. There are two components to a test plan: the approach and the design. The approach includes the testing techniques, testing tools, roles and responsibilities, method of error detection and logging, change control process, re-testing process, and testing environment. The design part of the test plan includes the test objectives, cases, and scripts. The test plan is the framework in which the different levels or types of testing are performed, i.e. system testing and user acceptance testing. You should develop a test plan for each type of testing.
In one system that I worked on, the company insisted on doing testing by putting the system into production and letting the users find the bugs. When the bug filled system was put into production, the users were furious.
9. Change the system to support critical new requirements discovered during final development.
It is important to prevent the onset of “scope creep” on a project. There will always be new requirements to support, slightly better ways of modifying your data model and better ways to design an application. Unless you set a formal rule that prevents the majority of well meaning suggestions about improvements from “creeping” into the system, the system will never be completed. Once you freeze a deliverable at any phase in the CADM process, it should not be altered. The only exception to this rule is when a mistake in the design of the system is uncovered that will prevent the system from going into production. If you do not enforce hard and fast rules about what changes are acceptable and when changes can be made, the system can be delayed for weeks, months or never go into production at all.
Who decides what will get done and when? Throughout the system life cycle, there should be a management team made up of the project leaders, a representative of upper-level management, one or more functional area users and, perhaps, a DBA (if no one else on the team has DBA experience). This small management team controls the CADM process and either performs all of the review tasks or delegates them to appropriate individuals. The process of review and quality assurance is critical to the success of the CADM process and should be handled by the best talent available. Of course, a key principle is that no one can perform a QA review of his or her own work.
As you progress through each phase of the project, you have more and more to worry about with regard to changes to earlier phases. In the Analysis phase, you only have to worry about changes to the Strategy phase; whereas in the Design phase, you have to worry about changes to system requirements and changes in scope from the Strategy phase. At each phase, we will identify all of the major deliverables from the earlier phases and discuss the impact of changes to any of those deliverables. Ideally, this information would be displayed in a giant matrix with all of the deliverables lined up on one axis and all of the phases on the other in order to clearly see the impact of changing each deliverable for each phase.
Systems are not like works of art that, once completed, are hung in a gallery. They are inherently evolving structures that will inevitably need enhancements and subsequent versions. Every requirement does not have to be included in Version 1. It is much better to have a system that is adequate and running than a perfect system that is never delivered.
10. Buy a commercial, off-the-shelf package and customize it… a lot.
The only successful way for a commercial off-the-shelf (COTS) implementation to be successful is to decide at the outset that you are going to reengineer your business to fit the limitations of the COTS package. These packages usually imply a specific method of doing business with a corresponding set of capabilities. A managerial decision must be made that whatever the package does is good enough and that customization is not an option.
If you do not follow this philosophy, implementing a COTS package is no cheaper and no less risky than building a system from scratch. I have heard more horror stories with respect to implementations of large, famous ERPs than any other type of systems project.
Just recently, I flew back on a plane with a manager who was recounting his horror story. His company is a $30,000,000 a year manufacturer. Two years ago they were sold a large well-known ERP. The project had a 2-year schedule and a two million dollar budget. After two years and four million dollars, the project is 10-15% complete.