Custom Development


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 Products

Custom 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.

A Custom System Is Never Finished

When we went to a plant to install a process control system, we were told to expect lots of requests for changesand this was considered a good sign. If our systems made a difference to the plant, they would generate a lot of ideas for better ways to use the technology.

Because we never expected a control system to be finished, we always designed systems that were configurable. Some of the original object-oriented ideas came from process control systems, because these systems were designed around such objects as pumps, rollers, ovens, and so on. Since a tape line was constantly making different products, the control system had to allow an operator to change the speed, pressure, and temperature of these objects very easily.

Even with configurable systems, we always liked to come away from an installation with a long list of changes and additional features that the plant operators wanted. This was the highest form of compliment.

Mary Poppendieck


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 Collaboration

In 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:

[24] "When IT's Customers Are External," by Simon P. MacGibbon, Jeffrey R. Schumacher, and Ranjit S. Tinaikar, McKinsey Quarterly, Q1 2006.

  1. Software companies do research to really understand what the market wants, so they can come out with products that will sell. If they do this poorly, they won't last long. In fact, software companies update their market research continually, always looking for better ways to serve the market. Because they can't demand that their customers get involved in the system design, software companies devise all manner of advisory panels and focus groups to discover firsthand what customers really need. Too often IT departments skip the marketing step assuming that someone else has done the market research and are surprised when their products don't meet the business needs.

  2. Software companies sell to highly competitive markets, so they have to keep their costs in line. They design products that are simple enough that they can develop and maintain them cost-effectively, while making sure the feature sets provide their customers a compelling reason to buy the software. Too often IT departments assume that a list of business requirements are all essential features of the system, even if very expensive features are involved. They have little incentive to perform the same cost/benefit balancing act that software companies must play to stay in business.

  3. Software companies realize that if customers are not successful with their products the company will not have a sustainable business, so it looks for every opportunity to help customers be successful, creating a broader revenue base for themselves while ensuring their products are successful in the marketplace over the long run. Too often IT departments feel that success with the systems they deliver is the responsibility of the business unit. While it is true, as we discuss below, that business units ought to be accountable for the success of software development efforts commissioned by their business, it is also true that the IT department is not successful unless its products contribute to the success of the business.

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.

Everything Else Failed

I struck up a conversation with the chief information officer of a large financial holding company at a conference. He was an electrical engineer by training, who had been asked to take over IT and "fix it."

"That was well over three years ago, and you have to understand, I failed." He said. "I tried the CMM thing and I tried the PMI thing, and after two years I got frustrated and went back to my old job.

"But after another year they asked me to try again, so this time I did things differently. I split the organization in half: operations and development. Then I divided the development group into six product teams. Each product team has to sell its products to the businesses, and they are measured on how much profit they generate compared to cost.

"It's only been six months, but so far it has been immensely successful. Don't know why I didn't think of it earlier."

Mary Poppendieck


Accountability

IT 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]

[25] See "Who's Accountable for IT?" by Dan Lohmeyer, Sofya Pogreb, and Scott Robinson, McKinsey Quarterly, December 7, 2004.




Implementing Lean Software Development. From Concept to Cash
Implementing Lean Software Development: From Concept to Cash
ISBN: 0321437381
EAN: 2147483647
Year: 2006
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net