Just because software is being developed for a one-of-a-kind application does not excuse an organization from the obligation of creating value and delighting customers. The objective is still to create software that will deliver outstanding value to the organization that is paying for it. In fact, the need for leadership and complete teams is perhaps more important for custom development than for product offerings, because the absence of competitive pressure can weaken the intense customer focus that is the core competency of successful software product companies. From Projects to ProductsCustom software is often developed as a project, but we believe that product development provides a more useful model. One of the interesting things about projects is that they tend to be funded all at once at the beginning of the project (see Figure 3.2). Once funding is allocated, the question naturally arises, "What are we going to get for that investment, and when will it be done?" The answers to these questions are regarded as a commitmentafter all, money has been allocatedso the success of the project is measured based on whether or not the cost, schedule, and scope commitments are met. Figure 3.2. Typical project funding profile
Products, on the other hand, are typically funded incrementally (see Figure 3.3). This incremental funding is a clear signal to all that the scope is expected to evolve as knowledge is gained. The success of product development is generally measured based on the market share and profitability that the product eventually achieves. Figure 3.3. Typical product funding
There are other differences between projects and products. Projects have a beginning and (apparently) an end. Products, on the other hand, have a beginning and (hopefully) no end. Software is much more like a product than a project, because most good software lives on and changes for a long time. As we noted in Chapter 2, well over half of all software is developed after first release to production.
Projects tend to be staffed with a new team for each project. Products tend to be developed by intact teams that continue to support it over time. Software would be better off supported by an intact team, because the knowledge of the customer, the code, and the domain are difficult to transfer, while most software has a long useful lifespan of upgrades and improvements. ITBusiness CollaborationIn the McKinsey Quarterly report "When IT's Customers Are External,"[24] Simon MacGibbon and coauthors propose that business-facing areas of an IT department should be run like a software company. They point out that software companies differ in three ways from internal IT departments:
Many IT departments use the project model for software development, but the project model comes from the contracting industry, where trust is not part of the contract. In order to create healthy ITbusiness collaborations, we suggest that a product model be adopted, because the incentives built into this model are much more likely to produce a collaborative relationship. When IT is inside a company, there is no reason, really, to set up the we-they model for doing business that projects were designed to deal with. In particular, you do not need to fix scope at the beginning, you do not need customer sign-offs, you do not need to monitor detailed scope to schedule, and you do not need to do everything that your customers say is important. Instead, you need to work in collaboration with your business partner to deliver the most business value in the shortest amount of time for the lowest cost, help them to use the system effectively, and continue to deliver more and better features over time.
AccountabilityIT departments inside large companies have traditionally been separate organizations from the businesses they support. This is usually because the company desires a standard information infrastructure and because technical expertise can be more easily developed when experts are in the same organization. However, it has led to lack of clarity about who is responsible for the results of software development activities and, quite often, a lack of clarity about how to measure those results. The problem of accountability is not unique to IT organizations. It occurs any time people on the same team work for different organizations with different ways of measuring performance. For example, an organization developing embedded software might be managed separately from the hardware development department. A consulting firm working for a business clearly has a separate management structure from its client. It is not particularly effective to subdivide the effort along organizational lines and then have one part of the development team give "requirements" to the other part of the team. This approach has a tendency to obscure the overall business objective of the joint venture, and has a long history of generating suboptimal results. It is far more effective for members of a complete cross-functional team to share responsibility for achieving the business results that justified the funding of their work. But in the end, there should be a single point of responsibility for the overall business results of an IT investment. We believe that this accountability should rest with the business funding the effort. When business leaders manage IT investments with the same rigor they bring to running their business, these investments will be more likely to produce significant business results.[25]
|