I believe that IT is not yet a profession because we do not learn from our mistakes. We do not change our behavior. We have not codified the body of knowledge gained from the past 40 years of experience, and we do not teach this knowledge in any coherent manner to those entering or already working in the field. Massive, multimillion-dollar debacles are not just isolated occurrences in IT. They are the norm.
We are all aware of The Standish Group’s studies of the past few years that document a 70 percent failure rate for IT projects. Some 30 percent fail outright, and another 40 percent drag on for years, propped up by huge cash infusions until they are finally shut down.
How can a group that has a 70 percent failure rate call itself a profession? What if surgeons had a 70 percent failure rate? What if airline pilots had a 70 percent failure rate? Would they even be allowed to continue to practice their professions? People in the construction industry routinely build buildings that don’t fall down until they are torn down. We IT folks — many of whom have fancy advanced degrees — can barely build an accounting system that will survive a month-end close.
Companies can’t afford to continue throwing money at IT projects and accept the paltry 30 percent success rate that’s the current norm. Yes, the IT field is full of complexity. Yes, the pace of change seems overwhelming at times. Yet if we who claim to be professionals in the field can’t define a basic set of practices and use them to drastically increase the success rate of IT projects, then we have little reason to exist.
I propose a set of seven design guidelines and six organizational principles for developing information systems. These guidelines and principles should remain constant over time, regardless of the technology being used. They create a clear and accurate framework that codifies what has been learned about building information systems. The simplicity of the framework makes it readily understandable so that it can be widely used.
Design Guidelines
A system design that respects all seven of these guidelines is the best. It’s still a competent design if one of these guidelines is violated, as long as it’s not the first guideline. If two guidelines are violated, there need to be very good reasons for doing so, and compensations must be made for those guidelines that are broken. If three or more guidelines are broken, then the design is seriously flawed, and the system can’t be successfully built.
The guidelines are as follows:
1. Closely align systems projects to respond to specific business opportunities or needs.
2. Use systems to change the competitive landscape.
3. Leverage the strengths of existing systems to build new systems.
4. Use the simplest possible combinations of technology and business processes.
5. Break the design of big systems into smaller subsystems to reduce the overall complexity and lower the risk of building each subsystem.
6. Don’t try to build a system whose complexity exceeds the organization’s capabilities.
7. Don’t renew a project that has failed once using the same system design and project organization.
Organizational Principles
If the design of a system respects the guidelines listed above, then the use of these six principles will ensure a successful project. If any one of these principles is ignored, then special precautions must be taken to compensate for that. If two or more principles are violated, then the project will flounder and fail.
The principles are as follows:
1. Make sure that every project has a qualified full-time leader with overall responsibility and authority.
2. Define a set of measurable and nonoverlapping objectives that are both necessary and sufficient to build the system that’s the goal of the project.
3. Assign project objectives (or subsystems) to teams of two to seven people, with hands-on team leaders and the appropriate mix of business and technical skills.
4. Tell project teams what to do, but let each team figure out how to do what has been assigned to them.
5. Break project work into tasks that are each a week or less in duration and that produce usable subsystems every 30 to 90 days.
6. Provide office staff to work with the project leader and the team leaders to keep project plans and budgets up to date and accurate.
We IT people need to understand these guidelines and practice these principles in different situations. The ability to do this consistently is what will deliver the successful results that enable us to truly call ourselves professionals.
