Perceptions, Prospects & Progress: Time to Payback
Success predictor in the development of an optimization project tied to client satisfaction.
By Maurice Schlumberger
Successful delivery of a new solution is closely tied to client satisfaction. A fair amount of client satifaction is essential during the development of the solution, not just at delivery time. This article identifies a simple metric that is directly linked to the stakeholders’ satisfaction. This metric has been found especially useful in planning the development of optimization solutions. Many of the ideas presented here have been implemented as part of the ISIS (IBM ILOG Solution Implementation Standard) methodology that has supported such engagements for the past several years.
Most development support systems focus on the development team’s need to work in a faster, more effective and more predictable way. Yet successful development also depends in large part on the client’s ongoing perception of the project, the project’s prospects and its progress over time.
Placing oneself in the client’s shoes helps identify effective ways to better manage and fulfill the client’s expectations as well as to maximize returns for all stakeholders. Shared and attainable expectations of higher returns help during the development phase of the project as they make communications between the client and development teams easier and more accurate.
This paper first identifies issues commonly found during the development of optimization solutions. It then focuses on approaches that can alleviate these issues, one of the most important ones being the management of client expectations. It moves on to this management and an important factor involved in it, the Time to Payback (TTP). It concludes by giving some examples on what to expect for TTPs and how to use it as a guide to more rewarding projects for all stakeholders.
Optimization Solutions Development Issues
The development of an optimization solution is often considered riskier and more difficult than that of other IT projects in large part because of a combination of issues specific to these developments:
- Financial results are typically easier to measure than in many IT projects. The future application often aims at saving large amounts of time and money. Both elements help raise expectations, hence getting “all eyes” focused on the engagement.
- A well-known, well-honed existing process is usually at the heart of current operations. The future solution will replace this (relatively) successful and well-proven process with an unknown and scary one, making all current stakeholders weary.
- A high level of uncertainty on the quality of the end-result often remains until very late in the engagement, in part because results depend on data and expressed processes, which are often initially unreliable for optimization problems.
- Planners in place are very good at their job, and may worry that their job is at stake, that they will be replaced or devalued by the optimization solution to be. Thus they have little incentive to support the changes brought in by the on-going development and new process.
These aspects easily turn the engagement into an explosive mixture. The project manager faces the difficult task of leading the engagement while keeping the explosion at bay long enough for the results to prove their worth to all concerned, thus defusing the mixture. Shared objectives do help in keeping the focus on the final result.
The three main objectives for such an engagement typically are:
- the stated one, to deliver the solution as expected to the targeted business, as defined by the contractual agreement;
- the implied one, to make money for both parties; and
- the longer-term one, to build a productive relationship for more profitable future work for both parties.
The first objective is to deliver the stated project results to the client’s satisfaction:
- the solution delivers the expected functionalities within the expected time-frame; and
- the solution delivers the expected (optimized) results using an acceptable amount of resources (time and computer power).
The next objective is to make money on the project:
- The client wants the solution to deliver the optimized system, and wants to start making money (directly or indirectly) with it as soon as possible, while …
- The supplier wants to deliver a satisfactory solution that will be accepted by the client, with minimal costs and delays, so as to maximize its potential profit margin.
A longer term objective, common to both parties, is to ensure longer term collaboration, in particular so that:
- The client feels secure with the maintenance and enhancement of the optimization solution, while …
- The supplier has a longer-term opportunity for more profitable and satisfactory engagements with the same client.
Tracking to these common objectives and the productive collaboration during the initial engagement depends in large part on mutual trust among the parties. Once established, this trust is much easier to maintain if the expectations are met all through the engagement, not just at the end of it. Such cooperation is easier to obtain and maintain if the parties feel they both have something to gain by such cooperation and that they can trust the other parties to support the same goal. Participants are together and support each other for a specific purpose for the duration of the engagement.
Trust in the other participants and in the outcome of the project is both a matter of down-to-earth technical capacity, methodology and project management, but also of perception and feelings.
This last element can and should be managed. One of the immediate objectives of any project management effort is to effectively meet and manage expectations, both from the client’s and the supplier’s management. This way the engagement has a good internal flow of information, and the stakeholders don’t reject the project midway and can wait until the results are out. This was recognized as early as 1994, for instance, with Cap Gemini’s OTACE (On Time and Above Customer’s Expectations) motto.
There are two main types of expectations to manage that influence each other:
- short-term expectations: what can I expect today, tomorrow, this week; and
- longer-term expectations: what can I expect in a few months?
High longer-term expectations can relax the short-term ones since most people are willing to invest for what they feel is a good reason. Lotteries all over the world are a good example, where a high potential gain lures people to part from their current money.
A large return from a small investment sounds much better than a large return from a large investment. IBM ILOG uses the “Time to Payback” (TTP) measurement as an indicator of the value of a project for the client and the supplier. The TTP is the time it takes for the project to break even after it has been launched. It is different from the Time to Delivery (TTD), which is the time from the closing of the deal to the time of launch. This time of launch is the normal focus of application development support systems. Both these time-spans are shown in Figure 1.
A high TTP is enough in the case of lotteries for people to voluntarily part with their money. Similarly, one can expect that a high TTP would smoothen relations and shape expectations during the development of a project, while the chances of success are much higher in an optimization engagement than in the average lottery.
The next sections focus on the lessons we have learned from experience with using TTP as a success predictor in actual engagements.
In order to get a realistic TTP measure, you have to take into account all benefits and all costs, in both the client’s and the supplier’s cases. In particular, client’s costs include:
- hardware and software to be acquired for the project,
- cost of external services,
- internal efforts dedicated to the project (e.g. internal training, data acquisition, project management/interface with the supplier, validation and testing, launch).
These internal client efforts often cost as much as, if not more, than the external services.
Projects with a long TTP don’t look as good as those with a short one, especially with the “end of time” lurking quite close for IT applications. Suppliers tend to apply a TTP approach to their part of engagements, if only by checking that the expected margin is positive. This doesn’t take into account the client’s incurred costs, thus only covering part of the picture. Clients do not have such an easy approach, as they often have less knowledge of their potential expenditures and gains. Experience shows that asking about the TTP and following through makes a lot of sense. Three simplified cases (e.g. borrowing costs and inflation are not taken into account), each with a one-year development and more than three years of use, put this in context:
Project Super has a TTP of two months. Even if it takes twice as much to implement (e.g. two years instead of one), the returns, once there, are visible and large. This project will most presumably succeed, even if it entails extra efforts from all parties. If all goes according to plan and it takes one year to develop, the yearly returns reach more than 100 percent over four years (one year of development and three years of use). After 14 months, the project breaks even.
Project Standard has a TTP of seven months. As long as this project is delivered on time, there should only be minor issues with it. Expectations must be managed carefully as there is a risk of weariness linked to the “run of the mill” returns. If all goes according to plan and it takes one year to develop, the yearly returns reach about 50 percent over four years (one year of development and three years of use). This is a pretty good return, in good and bad times; it breaks even just over a year-and-a-half after the start of the project.
Project Slow has a TTP of 18 months. This would look like a nice investment. If all goes according to plan and it takes one year to develop, the yearly returns reach about 20 percent over four years (one year of development and three years of use). It breaks even after two-and-a-half years. Yet, compared to other possibilities within the client’s organization, this return may not be high enough to keep the project going during hard times.
In all three cases, the “end of time,” as shown in Figure 1, actually looms large, especially in the last example, as most software applications have a limited life-span. The usual limit is anywhere between three and seven years. A responsible financial director would not want to place a large bet on an investment that may never pay back and would want to amortize the development costs over the expected life-time of the solution and no longer.
The spread of TTP values has been very wide in the projects we have delivered. For instance, in an exceptional case, the lowest TTP in a project we delivered a couple years back turned out to be less than a day.
The expected TTP gives a good indication on how to handle an opportunity before making an offer on a potential engagement. If it is outside of the norm (which is, for our group, five to 10 months), the client and supplier should question the way this opportunity will develop. If the TTP is too low (less than five months), there may be a good reason for the supplier to participate in the anticipated revenues. If the TTP is too high (more than 10 months), the supplier and the prospective client must understand the client’s other, non-financial motivations for the project. These have an important role to play in the engagement and, in particular, in the key performance indicators (KPIs) that the engagement seeks to satisfy, as it presumably will not satisfy a simple financial measure.
Similarly the TTP gives a good indication on how to structure the deliveries in a project. A good approach is to have deliveries so that there is a short TTP as early as is feasible without endangering the overall project. This in turns pushes for specific iterations in the project, where each iteration delivers financially rewarding results to the client in line with the corresponding investment made for it. A follow-up article will give practical examples and guidance on how to do so, with an iterative approach to solutions development.
The presentation shows a simple measure that should be used to reduce the perceived threat of an optimization development, enhance cooperation among the participants in this effort and eventually help organize the project and its deliverables. This “TTP” (Time to Payback) in turn helps to identify a potentially “good” project and structure the project so the various stakeholders stay satisfied with the current and future outcome, making it a full success.
Maurice Schlumberger (firstname.lastname@example.org) managed optimization consulting for ILOG in the United States and then became part of the company’s quality support and service engineering for optimization consulting worldwide. When ILOG was acquired by IBM Software Group in late 2008, his role was extended to support consulting for the IBM Software Group. Prior to joining ILOG, he worked for Cap Gemini as a software consultant and eventually became CTO of its R&D. He also taught computer science for two years at U.C. Santa Barbara and U.C. Santa Cruz. He holds a Ph.D. in computer science from Stanford.
The author acknowledges Filippo Focacci from ILOG (now IBM), who had the original idea of TTP; Jean Pommier from ILOG (now IBM), who steered the development and application of ISIS; and Jean-Paul Figer from Cap Gemini, who introduced the OTACE concept to Cap Gemini.