Posted By Cary Toor
About a year ago, I had an in-depth conversation with some very experienced, very smart people involved in building business software applications every day. The focus of the discussion was which project management strategies worked and which didn’t. Unfortunately, the discussion ended on a very down note; everyone around the table believed that projects rarely, if ever, end with a satisfied customers (or end user), even when virtually 100% of the requirements are met.
This is not a surprise, as the typical opinion of business people is that software developers never get it right, that all projects end behind schedule and over budget, and that the customer has to settle for less than they want, no matter how simple the application, how big the budget or how long the schedule.
In 1994, the Standish Group published the first version of its Chaos Report (which it now publishes yearly). Based on the findings of the study, the “Chaos Report” was a great name! The report concluded that only 16% of all software development projects were completed successfully, 53% were over budget or lacked key features, and 31% were complete failures. Today, 20 years later, this hasn’t improved much. The 2015 survey, with easier criteria, found that 29% of all projects were successful, 52% were over budget or lacking key features, and 19% were total write-offs.
Regardless of the findings, I think my friends are wrong and that software projects do not need to end with unhappy customers. I have run a business focused on building business software applications for both public and private sector customers for 34-years. Besides becoming old, I have been involved with a large number of projects, mostly successful, with over 95% going into production in the last 5 years. This experience has demonstrated to me that there are strategies which can be employed to dramatically improve the rate of success for software projects.
The purpose of this discussion is to explore some of the deficiencies called out in the Standish’s Chaos Report and discuss some of the strategies that I have seen which can improve the chances for project success.
Building Bridges vs. Building Software
The first Chaos Report compares building software to building bridges. It makes the point that if bridges were built like software, there would be a lot more cars falling into the water. In discussions with my project managers, I have frequently compared building software to building a house, but neither is a reasonable comparison.
- When building a bridge, there is a fixed objective: connecting physical points in which the geography is known and never changes. In building software, the objective can easily change: collecting orders through an order entry system can easily morph into supporting an e-commerce front-end and managing fulfillment. There are no physical boundaries.
- When building a bridge (or a house), all of the requirements and architecture work are done before construction starts. When building software, even if requirements are all collected correctly up front, requirements and architecture rarely remain the same from the start of the project to the time it goes into production.
- The process of drawing plans (and blueprints) for a bridge is standardized. There are a lot of people trained to understand and review these plans. For software, the process for defining requirements and sharing those requirements with users is not standardized and there are very few people trained to understand them (or who even have the patience to look at them).
- There is a set of rules (or standards) for building a bridge. Software development has no universal set of rules (standards) and, even when standards are present, they rarely enforced.
- When building a bridge, any changes are taken very seriously, with physical design changes being made to the architecture before any construction changes are made to the bridge. When changes are identified, the bridge project is then re-scoped. When building software, changes are taken less seriously, the changes are not necessarily reviewed against the original architecture, and the project is rarely re-scoped when changes are made.
- And so on…
Most importantly, though, in physical construction there are architects and engineers, each responsible for their own functions and each providing a check on the other. This type of team structure does not really exist in software development.
Building a bridge or a house is about the mechanics for building the bridge or house (1) designing the bridge or house, (2) building the bridge or house, and (3) ensuring that the bridge or house is well constructed and follows the building codes. Each step is very focused with specific personnel dedicated to the process.
As the Chaos Report points out, building software is not just about process, which is not standardized in software development. It is about the quality of the Team. Important factors identified by the Report include a standard architectural management process, a staff that has skills in both business and technology, and a design which is based on what Standish calls “modest execution,” which means translating the requirements into simple, well defined pieces that are then strung together to create the software application.
Finally, the costs associated with physical construction (and reconstruction in the event of a mistake) are substantially greater than the comparable costs of building software. This is one of the reasons that there is a lot more staff, training, and structure in building bridges and houses than in building software.
Business Rule Hell
Everyone in the software development business has heard customers say: “There are over 2-million apps in the App Store. Why can’t we get our application built?”
The difficulty with business applications is that they have business rules which define how the application operates. For example:
- The user must enter a number between 1 and 10 into the items purchased field.
- The Ship date displayed to the user must be greater than the current date but must be calculated based on total order backlog and staffing available.
- When a user selects an item for purchase, the number of items in inventory must be greater than 0. If the number of items in inventory are not greater than 0, the item must be automatically placed in back order status to be fulfilled upon receipt of new inventory items.
In even a very simple business application, there can easily be thousands of business rules. Frequently, as these rules are collected during the requirements phase of a project, they are incomplete, incorrect, or contradictory. It is difficult to identify these problems during requirements collection, and many times they can only be seen after the user has looked at actual application and can see the results of all of the business rules which were implemented (i.e. during user acceptance testing). Even if these rules are implemented in a way which is easily altered, testing with incorrect rules shakes user confidence and causes a problem with user perception of the software quality.
This is in contrast to most apps in the app store which are focused on a single, simple process and have a very limited number of business rules. Bridges do not have business rules, nor is there an expectation that they can be flexible like software applications.
Why There is Hope
I strongly believe that today, from a technical perspective, we know how to design and efficiently build software applications using the tools available. It is many of the human factors — such as collecting requirement, over complicating designs, and performing incomplete testing — which cause the problems.
I can spend a lot more time defining the problem, but I would rather talk about some solutions. A brief list of some of the most important and straightforward strategies for success are listed below.
- One of the most important strategies is to have an analyst on the development team who understands (a) how business processes work in general, (b) how the business process around the application should work, and (c) the actual work flows required to implement the business processes of the application. This is typically not a technical person, as the vast majority of technical people I have met do not think this way. In the Chaos Report, Standish referrers to this idea as the maturity of the team.
- Business users need to be shown what they application will look like before development starts, using processes like prototyping and visualization. If the user can actually view the user experience prior to development, this significantly reduces the number of changes during user testing (although it will not eliminate them). The users really need to understand the requirements, and prototyping and visualizations are a simple way to provide this understanding.
- Typically, the customer (or end user) is not relieved from their day-to-day duties during critical portions of the software development life cycle, such as requirements definition and testing. This means that supporting the software development team becomes extra work for the customer. The customer commitment needs to be defined up front by the development team and customers needs to accept this commitment.
- The design of the application needs to be simple, easy for developers to understand, and both technically and visually consistent. An example is a user experience comprised of a summary page followed by its associated detail pages (in other words, a hierarchical structure). Although this might cost users a few extra clicks or pages movements for a complex transaction, it is worthwhile to ensure that the developer understands what he or she is building. This strategy allows for a Senior Developer to build model pages that all other developers can work from.
- Like the design needs to be simple, it also needs to be modular. Every page or business flow should be run and testable on a stand-alone basis. Ideally, there needs to be one way into a page or flow and no more than one or two ways out of that page or flow.
- Invariably, the development schedule and budget are based on available time and resources. This is planning for failure – and bridge construction would never be planned this way. The bridge would be scaled back to meet the budget and schedule or the budget and schedule would be expanded. Unfortunately, the plan needs to be a realistic representation of functionality, time, and cost.
- The end users need to be involved in testing (User Acceptance Testing) and the development team need to plan for and budget to make changes to business rules, and potentially other functionality, during testing.
Evolution Improves Everything
Yes, evolution improves everything. Invariably, we try to put every feature and capability into Release 1 because there is never a concrete commitment to a Release 2. Think about commercial software products you have used and how they have improved over time.
It is unrealistic for the customer or development team to believe that the application will be perfect in Release 1. As software applications go through additional releases, capabilities can be added, functionality can be enhanced, and usability can be enriched.
Evolution can save time and money as well as make it more likely that software applications will be delivered as scheduled with planned functionality.
My Conclusion
If you have read this far, you know that I am optimistic about our ability to deliver software projects as planned. I strongly believe that using the development strategies briefly discussed above, it is possible to deliver business software applications as planned and budgeted. Given the failure rate in the industry, it is definitely worth a try!
Never forget: bridge building is physical; we can see all parts of it as it is being built. Even though we strive to make software development more physical, it is not, so we can’t see it until all the pieces are complete. This can make complex software much more difficult and costly to plan and build than a bridge.