The Back of the Napkin Part 10

There we have it: If we want to make changes to our software, we'll want to start with those areas. These maps show us not only where we should focus improvements on our software, they also show how complex the integration of our system is. In order to make so many changes, we're going to have to undertake a major project-something taking months to complete. In the next chapter on timelines, we'll look at how long such a project would take and when we'd need to complete each step.

CHAPTER 12.

WHEN CAN WE FIX THINGS?.

PICTURES THAT SOLVE A WHEN PROBLEM.

One Step at a Time We can now see where changes to our software might make the software more appealing to our biggest buyers. a.s.suming that we can convince our own management that making those changes is the right way to increase sales (a huge a.s.sumption, but one we'll be dealing with when we get to the why framework), the next question is how long it is going to take. Will it take a couple weeks, a few months, or a year or more to make these upgrades? Clearly, we're now facing a when problem, which the codex tells us to address with a timeline.

REVIEW: A TIMELINE SHOWS WHEN.

After we saw where-and as some time pa.s.sed-we saw objects change in any of the three previous ways: in quality, in amount, or in position. In order to show those changes to somebody else, we use a timeline to represent the various states of our object at various times, or the relationship of those objects over time.

Life cycles, process maps, Gantt charts, progressions, swim lanes: Timelines can take many forms, but they all show the same thing-when one activity takes place in time in relation to another.

Timelines: General Rules of Thumb 1. Time is a one-way street. Although discussions about the fourth dimension and the fundamental nature of time can be fascinating, they're irrelevant to the types of problems typically faced in business. For our purposes, we're going to think of time as a straight line that always leads from yesterday to tomorrow, and always tracks from left to right. Although the former rule may not be true for time travelers and the latter is nothing more than a cultural bias, both are useful as standards that we can all recognize and agree on.

2. Repeating timelines create life cycles. Chickens and eggs, up-and-down marketing cycles, days into months into years-timelines frequently repeat over and over again. When they do, we call them life cycles and represent them either as an endless circle or as a returning "back to the beginning" arrow placed at the end of the line. For our purposes, it doesn't matter if the timeline repeats or not, we create it in the same way. If we can't identify the starting point, we pick a major milestone anywhere along the length of the cycle and begin there.

3. Round versus linear. Both a clock and a ruler are made up of a single line, the first one just happens to curve back on itself. While circular timelines are in many ways a more accurate representation of a repeating life cycle, it is almost invariably better to go with a straight line. It's not only easier to draw (especially when the steps are accompanied by detailed text), it's cognitively easier to read, and easier to remember. Circular timelines and calendars (like those of the ancient Aztecs and modern astrologers) are wonderful if your fundamental point is to emphasize the repet.i.tive nature of a particular cycle, but even then it is advisable to create a straight-line version so that you can add details.

To make a SAX Inc. project timeline, we need to start with a coordinate system. And since a timeline shows the relationship of things over time, that's easy. We start at the present and show the pa.s.sage of time as we move to the right. Since we at SAX have been developing software for a long time now and know exactly how to get started, let's start this timeline at the beginning: discovery.

At SAX Inc. we begin every project by determining what the general problem is that we need to address. We call this the" discovery" phase, and we're already a long way down that path: finding a way to make our accounting software more appealing to Jason.

We begin every software development project with "discovery," when we nail down what the problem is that we're trying to solve.

Once we've got a good handle on the problem, we start coming up with possible solutions. We call this "conceptual design," and this is when we nail down the specifics of what we're going to build.

In "conceptual design" we figure out our solution and nail down what it's going to look like.

With the solution designed, we've got to build it. That's where "development" comes in: writing the code, both for all the individual software subcomponents and for the entire application.

"Development" is when we write the code and create the application.

Once everything is written, it has to be tested... and tested, and tested again. That's why the next phase is nothing but testing: bug testing, first-round testing, testing with a small group of customers, and finally user-acceptance testing with a larger group.

The fourth phase is when we test and test and test again to make sure our application does what it's supposed to do.

With testing complete and all the bugs worked out, we're ready to start selling. We call this final phase "deployment," because this is when we package up our software and get it into the hands of our customers for their use. It's also when we hand over the application to our user support organization so that we can go back and start working on the next version.

"Deployment" means we start selling the software to customers and turn everything over to the user support group. Our development process is complete.

That's it: our software development timeline. That was a simple, qualitative, execution-oriented, individual, as-is view-just the thing that the SQVID tells us to create if our audience is new to the software industry and interested in seeing the big steps. It's a useful starting point, but here we need to get a lot more detailed if we're really going to implement the timeline. So let's take that simple overview as a starting point but redraw it, this time with a focus on the complex and quant.i.tative. Here we go with the same timeline, but with a different intent in mind.

The first thing that was missing in the previous timeline was that it didn't accurately reflect time. It showed the steps over time, but didn't represent how long any of the five phases actually took. So the first thing we have to do is lengthen the phase arrows to show relative duration-something we know from having completed this same process many times before.

The five phases take differing amounts of time to complete, with development more than double the length of any other.

Past experience gives us a good estimate of how many weeks and months each phase realistically takes to complete, so now we can map in a calendar.

Adding in a calendar makes the timeline more accurate.

There will be a lot of people working on this project, so let's create a list of project teams and run them down the side, where we'll be able to plot in their individual activities for each phase.

We add in the project teams down the side so we'll be able to plot in their individual activities during each phase.

We've now got two coordinates set up, just as we did on the charts and maps before, but this time we've also got two different kinds of information represented on the same playing field: who (our teams) and when (our timeline). With those two coordinates in, we can start plotting in the whats, starting with the critical milestones that mark the close of one phase and the beginning of another.

By plotting in critical milestones, we show the triggers that indicate the close of one phase and the beginning of another.

How do we know when we've actually hit one of these milestones? Milestones aren't physical things, they're just predefined moments in time. The way we know we've succeeded in meeting them is by measuring what we've actually gotten done-in the case of a project, those physical things are the "deliverables." For example, once the business team has completed its "business rationale" doc.u.ment, the design team its "user need study," and the sales and marketing team its "market study," we can say that the problem-defined milestone has been reached, and we can begin conceptual design.

Plotting in the individual team deliverables indicates what physically needs to be completed in order to meet a milestone, to say that one phase is finished and the next really ready to start.

Valuable as they are in content, deliverables are simply the end results of all the heavy lifting that went into them. While seeing when the deliverables are due is critical to planning, we also need to see what is required to create them. That's where work streams come in: They are the task lists of things to do that each team follows in order to know what to do to get their deliverables done. Mapping in the work streams completes this more detailed timeline so that we can now see how long this project is going to take.

By drawing in each team's work stream, we finally see everything that needs to take place to complete our project, and how long it's going to take: nine months.

Nine months from the green light to rolling software out the door to customers: We now see how big a commitment of time it is to complete an upgrade to our application. At the million dollars a month it costs to cover salaries and expenses for all team members, that brings us to $9 million. That's a big "ask" at a company our size, so before we go to our own execs, let's see how $9 million compares with the cost of previous development cycles.

A time series chart is a superimposition of a timeline axis onto a typical how much chart: It shows the variations in quant.i.ty of something over time.

To see this, we're going to call upon our first hybrid framework, the time series chart. This is something we haven't seen yet but that will nevertheless be familiar-it's simply a combination of a how much chart overlaid on a when timeline, two frameworks that we already know well. As the name describes, a time series chart plots the quant.i.ty of something changing over time. This framework merges the coordinate systems of its two underlying frameworks in order to show the rise and fall of prices, rates, numbers, temperatures-anything that can be measured at one time and then at another.

Creating a time series chart lets us see how the cost of completing a full software-development cycle now compares with what it has cost in the past. If we're going to be asking for $9 million, we'd better know up front if that's more or less than before. If less, it should be relatively easy to get; if more, we'll have to make an extra-solid case for the project.

Just as in any other timeline, the horizontal coordinate shows time, and as in any other chart, the vertical coordinate shows amount. With those coordinates in place, we can start plotting in development costs from previous years, data we can collect from previous project management files. SAX Inc. opened its doors with its first version of Super Account Manager back in 1996, so let's start there. In that first year, it cost less than $500,000 to create SAM version 1, with a team of ten people working nights and weekends for nearly a year. The cost of the second version, launched two years later, quadrupled to $2 million. The simple reason: The team had grown to forty people, and more people cost more money. By 2000, it cost nearly $6 million to release SAM 3, the version that made SAX Inc. an industry leader.

Then came the bust. In late 2001, the entire market came down, and SAX Inc. had to lay off staff just to stay afloat. We managed to keep releasing upgraded versions of SAM, but development costs went down because teams got smaller and the company became less ambitious with each release.

This time series compares development costs to release cycles every two years. At the beginning of SAX Inc. in 1996, it cost $500,000 to create the original application. Two years later it cost four times that, and two years after that it had risen again-to $6 million.

Boom: With the collapse of the market, development costs dropped due to layoffs, then started to rise again as the market recovered in 2004.

Since 2004, development costs have risen consistently with every release. So if we go ahead with a $9 million version now, we'll be right on track.

Let's build the same time series but show company revenue rather than project costs, obligating us to slide the vertical scale up to $40 million.

Since then, development costs have increased for every release. SAM 6, which came out in 2006, came in at over $6 million, topping the previous maximum set back in 2000. Given the trends since 2002, it appears that a $9 million cost is right in line with where we'd expect costs to be.

But that doesn't tell the entire story. Much as we'd love to go to our execs and ask for $9 million, showing them this time series chart to justify the cost, we know they're going to ask us to show them something we ourselves haven't uncovered yet: How do these costs track with the overall revenue of the company?

To figure that, we're going to create another time series chart using exactly the same horizontal timeline, only this time the vertical axis will reflect total company revenue, which means we're going to have to slide that scale from $10 million at the top (the highest ever spent on a release) to $40 million, the highest revenue. Once again, we start plotting in numbers in 1996, when total company revenue was about $1 million, through the next four years, when revenues skyrocketed up to $21 million.

Again we see the bubble burst in 2001: Over the next two years revenue drops by more than half, and even after the market recovers we're still sliding down.

In 2004 revenues bounce back with a vengeance, jumping up to $30 million in two years. Then... well, then we just sit there: flat sales, flat revenue. Which brings us back to the problem that got us started way back with the who/what framework.

In 2001 revenue heads south and keeps going, even after the market starts coming back.

There was ma.s.sive revenue growth in 20042006, and then it all stopped.

After we lay the first chart onto the second, we have to squish it down to make the vertical numbers align.

Viewed individually, these two charts tell us two things: The first showed that development costs are going up at what appears to be a consistent rate; the second shows that revenues (although still high) have flattened. But it's when we put the two together that the real insights-and questions-emerge. To put the two together, we have to do a little fancy footwork. Since the vertical scales were different, we're going to have to squish the costs chart down across the board to align the numbers.

With the scales aligned, we can compare apples to apples and see how development costs have varied compared to revenues.

One chart lays out development costs and revenues side by side, where we can easily compare one with the other.

And we can already hear the execs' response to our $9 million request: If four years ago a 30 percent increase in costs brought about a 300 percent increase in revenues, but another 30 percent increase two years ago coincided with flat revenues, who's to say another 30 percent increase in costs is going to help at all?

Good question: Revenues aren't going up, so why should costs?

We see the question we're going to have to answer, now we've got to figure out how to answer it.

CHAPTER 13.

HOW CAN WE IMPROVE OUR BUSINESS?.

PICTURES THAT SOLVE A HOW PROBLEM.

How Can We Fix This?

We're facing yet another new problem: How are we going to convince the executives (how are we going to convince ourselves) that spending $9 million to improve our software is the right way to get sales moving again? Let's face it: Jumping from the desires of the last guy on the org chart to a $9 million spend is a pretty big leap, isn't it? Stated that way, it is. But maybe that's not the right way to state it. In fact, let's not state it at all: Let's show how we came to that conclusion.

REVIEW: A FLOWCHART SHOWS HOW.

As we saw the ways in which objects interacted over time-changing in quality, number, or position, but now with visible influences upon each other-we saw cause and effect come into play: we saw how things work. The codex tells us that when we need to show such cause and effect, we create a flowchart.

How company decisions are made, part 1: First, the exec will ask us to tell him or her about our problem.

But let's not start with a flowchart as elaborate as the one we'll need to visually link Jason's software desires to a complete rewrite of our platform. Let's practice with a simpler (but equally useful) one. Let's look at how executives in our company go about making such a big financial decision.

The table of frameworks tells us that the coordinate system of a flowchart runs from action to response, and that the starting point should always be the beginning action. So we'll start with the first thing an exec will say when we show up with our spreadsheets: "Is your problem defined?" followed by, "Have you thought of any potential solutions?"

Knowing that if our answer to either of those queries is no, we'll be shown the door, we'll then pull out our problem definition and proposed sample solutions.

Part 2: If neither the problem nor any potential solution is defined, the conversation is over. On the other hand, if we have some possible solutions, the exec will be all ears.

Then comes discussion of the solutions: Are they technically possible? If no, forget it. If yes, are they then financially reasonable? Again, if not, it's back to the drawing board. But if yes, then comes the acid test: the "gut check." Our execs have been in the software business for a long time and have a good sense of what can really work and what probably won't. So they then ask themselves, "Will what I'm seeing here really fix the problem?" Then they start really thinking.

If our proposed solutions are neither technically nor financially feasible, they're rejected. But if they pa.s.s on those fronts, they face the biggest test of all: the "gut check."

If the exec's gut tells him or her there is at least a three-quarters chance of success, he or she gives the green light, and then we're off and running.

If it feels as if our solution has a 75 percent chance of working, we're off and running. If not, we'd better come up with something else.

Now we know what we're going to face when we go into the big conference room to make our pitch. First thing we'll need is a well-defined problem and an accompanying potential solution. So let's again ill.u.s.trate our understanding of the original problem using the same flowchart process, but this time things will be a lot more complex-and even our starting point is bad news: flat sales.

We can come up with at least three potential reasons for flat sales: First, our clients aren't themselves growing (which isn't true; they're all growing at least 20 percent per year for the past two years), or they don't need our software anymore (also not true; ours is the most comprehensive product in a growing industry and it will be at least a year before any compet.i.tors offer a similar full range of services). No, the only other likely reason is that customers are simply uninspired by our product.

We've got to define our problem. In this case, it's big and obvious: Sales aren't rising, but they aren't falling either-no, they're just plain flat.

The most reasonable explanation for flat sales is that customers just aren't inspired by our product anymore.

We can think of two possible reasons for our clients to feel blase about us: Either our software isn't making them happy or we're not targeting the right clients. Both could well be true. Interestingly, addressing both requires the same thing-a better understanding of who our customers are and a better understanding of what they want.

We suspect that our clients aren't happy with our product and that we're not targeting the right clients. The good news is that getting a better understanding of who they are should tell us more about what they're looking for.

It's at this point that we created that customer portrait so many pictures back, so now we do know who our influential customers really are (technicians, especially Jason, and execs, and, to a lesser degree, the accountants themselves) and we've identified what they want from accounting software: flexibility, security, and reliability. This brings us to a possible solution: If we improve any one of those three features of our software-especially flexibility, since that's what Jason is really interested in-we should be able to increase sales again.

We've got a potential solution: If we improve our software's flexibility, we should be able to inspire Jason to buy more software.

Step one of our executive pitch is ready: We've got the problem clearly defined and we have a potential solution ready. The only trouble is that our solution will cost $9 million. Now we've just got to convince the execs that it's worth it.

CHAPTER 14.

WHY SHOULD WE EVEN BOTHER?.

PICTURES THAT SOLVE A WHY PROBLEM.

Why Spend the Money?

We're confident that the best way to get sales growing again is to spend the $9 million to rebuild our software platform. Only that ground-up approach will enable us to make the software improvements demanded by our most influential customers. But the fact remains that we could spend a lot less money by making smaller improvements to our existing platform. And with our executives focused intently on the bottom line these days, that's very likely the decision they'll make.