|
| I know what you are thinking. Engineers don't need
salespeople because truly great software will sell itself and the only thing
sales people are good at is wining and dining management in order to push
unwanted products onto unsuspecting users and running off with their cash. I used to think that as well until I experienced the benefits of good salespeople first hand. It turns out that salespeople are much better than developers at predicting the future. In fact, successful businesses rely on sales forces to predict the future with a fairly high degree of accuracy. On the surface this may seem impossible. It would seem that developers have much more control over their own destiny. Whether somebody will be interested in buying a product on a given date or how much they will be interested in buying seems completely random and unpredictable. Similarly, whether there is a sufficiently well performing algorithm to solve a problem and exactly how long it will take to find it, implement it, and verify it also seems completely random and unpredictable. An Agile Principle: Software Development is Inherently Unpredictable One of the principles of Agile development is that because it is hard to know exactly what will happen with a software project, you might as well give up on predictability, schedules, and traditional project planning. In return, you will get the highest priority changes on a regular basis, so things aren't all that bad. After all, big releases are rarely delivered with the originally planned content on the originally planned schedule. This sounds wonderful to developers. Finally! Somebody has come out and said it. The crazy deadlines and pressure is off. The inherent unpredictability of software development has been exposed! Vive la revolution! I think this is taking things from one extreme to the other. I absolutely agree that large software projects are fundamentally unpredictable as traditionally planned and executed. However, successful businesses expect their sales to be fairly predictable. It is surprising in contrast that not only is the predictability of software development worse than sales, it is tolerated more. There is a lot that developers can learn from how salespeople predict sales and apply it to the management of software development projects. A Sales Principle: Sales are Inherently Unpredictable At first, you might think that sales and engineering have nothing to do with one another, but salespeople rely on a technique to increase predictability that is directly applicable to software development. They use something called a sales pipeline to produce a sales forecast each quarter. The sales forecast is a surprisingly accurate and effective tool. It gives you a heads up on problems early so that you can react. Not getting enough leads? Focus on marketing. Not getting enough demos? Focus on sales. Not getting enough technical wins? Focus on product. Not getting enough business wins? Focus on sales tools and messaging for management. The forecast also helps in predicting cash flow in order to help with financial planning. Forecasting Sales The forecast has two fundamental underpinnings which allows the sales organization to regularly predict sales each quarter. First, it is impossible to predict the outcome of any particular opportunity in the pipeline. Second, it is possible to organize opportunities in such a way that you can make useful predictions and act on that information in order to further increase the accuracy of your predictions. The pipeline has many stages in it. The input to the pipeline is people contacting the organization. They may be contacting the organization out of curiosity, real interest, or they may just have the wrong number or e-mail address. The output of the pipeline is orders for the company's product. Here's an example set of pipeline stages: suspect, qualified, interested, technical win, business win, in purchasing, and purchase order. Each of these pipeline stages acts as a filter. You assign a probability to each opportunity based on the stage that it is in. That probability is then multiplied by the deal size to produce a weighted amount. You add up all of the weighted amounts, and that produces your sales forecast. The sales forecast does rely heavily on four key factors for accuracy: the accuracy of the sales model itself, the experience of the salespeople, the number of salespeople, and the number of deals in the pipeline. If you have just created a sales model, it is unlikely to be very accurate, but it doesn't matter as long as you continuously refine the model based on your experience. Some salespeople are very good at keeping their sales data up to date and as accurate as possible, and others are not as good. The more that the salespeople believe in the model and work with it, the better data you will have as input into the model. Of course, the more salespeople you have, and the more deals you have in the pipeline, the less sensitive the model is to problems with individual salespeople or individual deals and thus the more effective it is at forecasting actual sales. The other important part of the sales process is that if a deal has been forecast for a particular quarter, but a problem arises, it is often moved to another quarter further out. On the other hand, if it starts to move through the stages more rapidly than predicted, it is often moved to a quarter closer to the current date. As a result, what would appear on the surface to be a completely unpredictable process becomes surprisingly predictable. Of course, there are always surprises, but they don't spoil the overall effect. I believe that it is possible to obtain the same result in software development by making two fundamental changes. Forecasting Software Development Translated to software development, the sales process becomes the development process, the sales model becomes the development model, and the sales forecast becomes a forecast of content and ship date. I believe the core of the problem is the intermingling of predictable tasks with unpredictable tasks, amplified by the problems inherent in long iterations. The reason that much of software development is unpredictable is that it involves a fair amount of solving of problems that have not been solved before. Usually though, if you have a new project and it involves solving new problems, it isn't the whole project that requires research. If you break the project up into parts, I'm sure that you will find that many of the pieces are things that you already know how to do and have value in and of themselves. Short Iterations The first step is to move to short iterations. With one big release, you have many opportunities for schedule delays. By breaking things up into shorter releases, there is a much lower chance that any one of them is delayed. Plus, none of the functionality leading up to the problem release is "held hostage" until the cause of the delay is removed. And, after the problem release is finished, you return to frequent releases. By breaking a big release up into small releases, you can still do planning. But instead of a single end date, you have a series of milestone dates. As you learn more about what the market needs, you can adjust the planning of your future releases, move functionality from one release to another, and give an early heads up when problems are discovered. A heads up doesn't mean letting people know that you aren't going to make it, it can also be a call to action that says the project is going to need more resources than expected to keep the desired date and/or content, so if those things are important, more resources can be provided or alternative plans can be devised. Problem Filters The next step is to create "problem filters." A problem filter is just what it sounds like, a mechanism that detects and filters out problems. Problem filters come in many forms: creating a clear set of requirements, writing a spec, creating a design, producing estimates, writing tests first, prototyping, code reviews, usability testing, and customer review. Each of these problem filters are also predictors. For instance, you know that if a task is in the design phase and it is taking much more time than expected or there is a problem which is proving to be a tough nut to crack, there is a good chance that all further phases will be difficult. It isn't guaranteed, but it is a good leading indicator. In practical terms, leading indicators and problem filters can be used to put individual problem issues on a separate track in order to reduce risk of overall delay and to increase the predictability of issues that are on the main track. This is completely in line with customer expectations. Which would you rather do, tell a customer that all of the changes you promised will be late and you're not exactly sure how late or how reliable your estimate is, or tell them that 95% of what you planned will in fact be delivered on time and 5% is completely unknown? I think that's a no-brainer. Once an issue has been identified as a problem, it is good to think of it as a research project. Don't promise it, but put it on a separate track and try to increase its predictability. Once you feel comfortable the issue has returned to predictability, it can now be put back into the main track. That might take one more iteration than expected, or it might take many more. In fact, it might not return until it has been completely finished, tested, and accepted by the customer. But better that than endangering everything else. Turning Predictability into Business Results By moving to short iterations, implementing problem filters, and treating different kinds of problems differently, you have a sporting chance of making your development process more predictable than your sales process. If you can do it, your business will be able to enjoy more of the same benefits that come from a predictable sales organization: reduced costs and higher revenues. Damon Poole is currently CTO at AccuRev. Prior to AccuRev, Damon worked on a range of projects, from building a layer on top of Rational's ClearCase, to leading the SCM tools development effort at the Open Software Foundation which worked on massive multi-vendor integration projects.
Set as favorite
Bookmark
Email this
Hits: 6890 Trackback(0)Comments (3)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Thanks for your feedback mikx. The article is only using sales as an example of how another profession deals with the problem of unpredictability. I'm not suggesting that they are identical or that development should follow the example exactly. Regarding unexpected problems, that's part of the definition of unpredictable. Good unpredictability happens in sales, they call those "bluebirds," but it doesn't happen very often. And it also happens in software development. That's called "finishing ahead of time." Also rare! In any case, unpredictable is unpredictable. The major point of the article is that the two main ways that sales deals with unpredictable problems is to use "short iterations" and to use pipeline stages. These two practices can likewise be applied to software development to find problems earlier and filter them out. The filtering process find issues which can lead to unpredictability and keep them out (or take them out) of the main stream of development. Part of the benefit isn't so much making individual issues easier to predict, but rather identifying issues that may be difficult to predict as soon as possible and treating them appropriately. |
mikx
said:
|
... Interesting point of view. But how would such a system deal with dependencies across features and unpredicted items in the pipeline. In the sales context "unpredicted" items in the pipeline is a great thing. You have a revenue target and the more things are in the pipeline, the better it is. More chances to make revenue, you can even allow to let pieces flow slower through the line since your overall chance of making the target increases (10 items at $1000 with 50% plausibility = 20 items at $1000 with 25% plausibility). But in the development world it is not sales plausibility - it is progress of a feature. And while in the sales process (based on my experience) a client walking 95% of the sales process with you is likely to walk through the rest. A professional isn't spending so much time on negotiation and than hops off - at least not that often (and sales people develope a pretty good "guts feeling" to predict). In development usually the last 5% of a feature take 60% of the time. Well, you could argue that the 95% is than a flase measurement, but predicting software is different than predicting sales because there are many things you do not know in advance. At 95% you might need to ad 20 news items to the pipeline you have to finish first to bring you to 100% you haven't thought about. Sure, in the sales world you might have a client so far that he is willing to buy and than you have to jump through hoops with "central purchasing department" or such. Part usually you will not have a client being willing to buy (lets say after 20 hours of sales work) and you than need to spend 80 additional hours to close the deal (you might even pass those topic to legal or inbound sales people and keep on generating new revenue as an outbound sales guy). In software this happens frequently. And quite often many featurs are connected, problems are dependent and need to get fixed in the same timeframe. Lets assume you need to sign all deals for a quarter the same day. And if only one client doesn't sign you don't get any commision for the entire quarter... well... that example doesn't fully apply... but you get the idea. Anyway, really interesting article - but would like to know how you incorporate those aspects of dependencies and unpredectied new item being a bad and not a good thing. |
Derek Morrison
said:
|
... I believe that sales can learn a lot from engineer ? see Part #1: Implementing an Agile Sales Framework for more details. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
