More and more CIOs are finding themselves outsourcing or co-sourcing software development projects. Whether it is to take advantage of reduced offshore development costs, to fill a skills gap in the internal IT resource, or simply because the internal resource is so overloaded, many businesses will engage in a lengthy and expensive tendering and procurement process.
If a software project is worth undertaking at all, it will involve risk. The procurement process is designed to manage this risk as much as possible by putting the contractual onus of delivery onto the supplier, and is also intended to get the best price. A good procurement manager will try to squeeze every last drop of value out of a supplier through hard contract negotiation.
This approach, while it has its merits in other fields, has not worked in software procurement, where getting the best price may not equate to getting the best value. The traditional methods of tendering such as ITT or RFI have been shown time and again not to work. An agile approach that replaces the big, upfront planning and analysis stages with regular, small-scale micro-planning and just-in-time analysis does.
What You Already Know About Software Project Risk...
Before we can talk about procurement, we need to understand the problem it is trying to solve: namely, project risk. Any number of things can go wrong on a software project. Among the most important are:
- Late delivery -- The project deadline is looming and there is no sign of a delivered system.
- Delivering the wrong thing -- When users find during user acceptance testing that the software won't solve the original business problem. Or when a financial system fails to comply with external legal criteria.
- Delivering unstable software -- The application fails under load or is unstable in its production environment.
- Delivering poor-quality software -- The system is overly complex, which makes it difficult and expensive to maintain, immediately becoming a legacy application.
The larger or more daring the project, the more pronounced these risks become. On a large program of work, it is harder to keep an eye on all the details; on a ground-breaking project, the team will by definition not have previously solved this type of problem.
What You Don't Know...
The theory behind the exponential cost curve (and the corresponding change aversion late in the cycle) comes from an historical link between programming computers and building bridges. Software development is seen as an "engineering discipline," subject to the same rules and restrictions as, say, building a road traffic bridge to span a river. This metaphor is disingenuous, at the very least, for a number of reasons:
- Software projects are much more susceptible to change than civil engineering projects, simply due to the nature of their respective industries.
- Subject to a few best practices, software projects can be set up to absorb change much more easily than civil engineering projects. Software is (or can be) malleable. Steel and concrete are not.
- The cost of change on a properly controlled software project remains constant and minimal throughout the lifecycle of a project. The exponential cost curve is a self-perpetuating myth.
- A software project can be delivered in small pieces that have independent value. A bridge is useless until it is complete.
- Automated tools are utilized to ensure a software system works and continues working. A civil engineering project needs time-consuming and expensive manual audit and management to ensure quality.
What This Means for Procurement
Ironically, if we slavishly follow the civil engineering metaphor, we end up creating a self-fulfilling scenario in terms of cost of change. We invest heavily upfront to create a detailed project plan; then we invest a second time in maintaining the project plan in the face of reality; and we invest yet again by creating and executing an expensive change management process. The more detailed the project plan, and the more "careful" the change management process, the more expensive it becomes to make a change.
Let us assume you are going to invest a number of weeks tendering a reasonably sized, complex, business-critical software project. You could either engage a number of vendors to send you documents describing what they would do, or you could get them actually doing something. Most vendors would far rather be proving themselves -- on a project and technology stack -- than writing tortuous documents. Of course the organization will still need to draw up the usual terms of engagement and contractual pieces required in any other engagement, but now the process itself will guarantee that the business gets exactly the system it needs, when it needs it.
We can now deliver software in a much more collaborative and inclusive fashion, putting the purchaser in a much stronger position of control (with weekly veto of all project work), and transparency (since there is no padding a one-week project). The procurement can be done on a rolling weekly time-and-materials basis: as soon as the customer is happy with what has been delivered, they simply say "stop." Or direct the team onto the next exciting challenge.
This makes the procurement process far less risky than it traditionally has been, and gives it a rather different focus. Acknowledging that right now we don't actually know every last detail, and that we can work it out as we go, the procurement process becomes one of establishing a vendor's credentials for delivering in an agile fashion.
Changing the way companies look at procurement and project risk is a large task, but one that is imperative for the long-term success of software development projects. As an industry, we have been led to believe that the cost of making a change to a software development project rises exponentially throughout the delivery cycle. Thus the onus is on the program manager or CIO to identify upfront all the things that could go wrong, and put the appropriate checks and balances in place to prevent them from happening. This is what a large proportion of the tendering process is about: the purchaser is trying to ensure that every base is covered, requiring the vendor to demonstrate that they can respond to any eventuality.
As the project progresses, the unforeseen inevitably occurs -- new requirements come to light, misunderstandings are ironed out, and things turn out to be more (or sometimes less) complex than first estimated. As a result, we track actuals against the project estimate and we implement a change management process to identify the cost implications of introducing these changes. Because we fear the damage that late changes cause to our project deadlines and the exponential costs associated with these, we naturally resist any change. So we have committees of people who are charged with gate keeping the change list, which makes the process of proposing a change unattractive and expensive in itself, thus deterring all but the most important of changes.
We work in an industry that has grown up over 30 years with a mindset -- and a toolset -- that treats software like bridges. But because software projects are immeasurably more susceptible to change than engineering projects, a wealth of tools, methodologies, products and literature -- and a very lucrative industry -- are involved in selling the idea of managing that complexity. But is this the best use of everyone's time? A better approach would lower the risk in the following areas throughout the project and, ideally, from the very beginning of the procurement process:
- Analysis and planning -- If it were true that we could change a project's direction at the drop of a hat, with minimal cost, we could get away with much less upfront planning and analysis without introducing any risk to the program. Of course, we would still have to do the same amount of planning and analysis over the lifetime of the project, but we could do it in a much more just-in-time fashion. This would mean that our planning could take advantage of better information and better estimates (project teams become measurably better at estimating during the course of a project). Our analysis could leverage up-to-the-minute requirements and respond to changes in business direction.
- Integration and user acceptance testing (UAT) -- If we were able to deliver a system in small, self-contained stages, we could practice the difficult tasks of integration and UAT regularly, with manageably sized chunks. We could get feedback from the users to ensure the project was delivering what it was supposed to. We could verify that the system performed under load. Most importantly we could choose to deliver the highest value features first, to gain an immediate and measurable ROI to the business. This would eliminate the risk of late delivery -- at any point we would simply be adding new features to an already valuable live system.
- Development and delivery -- If we had automated tests to ensure the system was always working, we would know straight away if we made any change to the system that broke existing behavior. We would also practically eliminate regression bugs.
- Maintenance -- Given these comprehensive, automated tests, it would be possible to continuously improve and simplify the code base while knowing that it continues to fulfill all of its existing requirements. This would allow us to keep the software as simple and clean as it could possibly be, which would have an immediate and ongoing impact on ease of maintenance. A simple system is easy to change, and a system with good test coverage is difficult to break.
The scenario described above is a description of what we call "agile" project delivery, and the methods it uses can help you reduce risk in your procurement process. This approach replaces the big, upfront planning and analysis stages with regular, small-scale micro-planning and just-in-time analysis. Each week on the project is treated as a mini-project in its own right, with agreed deliverables. Automated tests define the behavior and boundaries of the system so there is no concept of "80% complete." Either the tests pass or they do not -- the system is working or it isn't. It may only contain 80% of the features we require, but these features will be 100% delivered and working (and they will be the most valuable 80% because they have been regularly reprioritized by the business, every week).
The week-by-week planning allows us to acknowledge and absorb change easily, beginning in the procurement process. Any new requirements can be introduced and any existing ones can be reprioritized or descoped during the weekly planning session. In practice this should take no more than a couple of hours each week. (A one-week project doesn't take much planning.) This, then, is the low-but-constant cost of change.
At the end of each week, the team actually delivers working software. If the business is prepared to take delivery of a system that frequently, it can receive production-quality, fully tested software on a weekly basis, containing the current set of highest-value features.
Because the team only delivers the features within the scope of each week's mini project, they don't invest any unnecessary effort in work that may never come into scope. The team does, however, invest a lot of energy in writing comprehensive tests, which serve to define the system and act as live, executable documentation. It also invests in keeping the system as simple and clean as it can be, which is a lot harder than it sounds. Of course, there is an overarching plan, or rather a desired feature set, for each release of the project as a whole. This allows release-level estimation and planning, and reporting back to the enterprise.
A procurement solution utilizing agile methods would give the competing vendors a small feature set to deliver and see what they come up with. Require that vendors do this at their own risk: you only pay the vendor you choose to end up working with. It is no more of an investment for the competing vendors than the time their developers would spend delivering a tender document, and provides both you and the selected vendor with a couple of weeks' head start on your project delivery.