The Summit - March 2024

Something I learned recently was the technique of Pre-suasion. "Pre-suasion" was a book written by Robert Cialdini that provides evidence from multiple studies that human psychology can be "hacked" into agreeing with something by priming them to agree with your proposal. The general approach is effective enough that it could be put to use for consultants. 

Pre-suasion suggests that before you ask someone to agree with anything, you prime them to be more agreeable. The problem is that many of the pre-suasion examples are done within the construct of marketing and sales. In these scenarios you are attempting to "out-relationship" your competitor and the techniques work well when you just want someone to agree with you.

For consultants, the scenarios are a little different. Your "competitor" is not someone else, but the customer's own desire or expectation. Not only must they change their expectation, they may also need to spend more money to achieve it. That said, the psychology can still work, but we have to think about how it can be adapted. The concept of "pre-suasion" is already built into a technique I developed called, "Self-Imposed (or Progressive) Ultimatum". The idea being that the best way to get a customer to agree to a change order is prime the customer to believe they have caused the need for that change. The process works like so:

Step 1: Identify for the customer that their actions have created a situation that is causing an impact to the project's ability to progress effectively. This might be something like a missed deliverable, not signing something off in time or simply not attending a meeting. At this stage, it is OK for the incident to be trivial, in fact, it works best if it is trivial because it is those trivial snowballs that eventually roll down the project hill to become the avalanche that kills us. What we are doing in this step is simply notifying the customer that their action caused the need for an impact to be absorbed.

Step 2: Offer to absorb the impact for whatever limited time your budget will allow, but only upon agreement with the customer that they will rectify their miss prior to that deadline as to protect your from having to begin to lose money because of their actions. This helps established both the Self-Imposed and Progressive part of the ultimatum. The customer is openly agreeing to fix a problem they created by a specific date and the ultimatum you are creating was progressive rather than sudden. You've done everything a good service provider should.

Step 3: If the issue is resolved prior to the deadline, well done! You resolved the issue with minimal budgetary impact and the customer knows that you just saved them. This is leverage you can "bank" and reuse in the future if they miss another deadline. For example, "Unfortunately, we would love to be able to absorb this missed deadline, but having already absorbed the previous one, we have no absorption left I'm afraid." If the customer happens to miss the deadline again, then they are now fully primed to accept the change order because they told you explicitly that they understood that such a miss would result in them having to take over the absorption of their missed deadline.

I learned this technique from a research paper many years ago that identified that service companies (such as Telcos and Insurance) could get customers to accept penalties by "pre-warning" them of the consequences of bad behavior. The Self-Imposed (Progressive) Ultimatum just uses this concept in a way that guides a customer towards the self-acceptance of a change order. 

Another use of "pre-warning" or "pre-suasion" is to pre-state as many penalties as you can, that the customer might experience on a project if they do not follow your guidance. But rather than present such things as "pre-warnings" simply reframe them as "keys to success" which is the optimistic way of saying, "If you don't do this, there will be a penalty." Keys to Success should be written and shown at Kickoff, during Design Session, during testing and whenever we can think of something we need the customer to comply with. Pre-warning simply uses the same psychology as pre-suasion to prime the customer to be mindful that their behavior can have an impact on the project's ability to be successful.

Pre-suade away!

One of the most consistent metrics that get asked about is how a PS team can improve the length of time it takes them to get a customer live (TTL). While the answer to this is extremely complicated and eventually leads to me blowing it off as a "useless" metric it is important that we understand that TTL, as a PS Metric, is critically important right up until the point that it is almost irrelevant. Confused? Let me explain.

TTL is interesting because it typically starts as a measure of professional services efficiency. It can help us identify where our projects can be more efficient at making progress and reduce the time it takes for us to get customers live and secure the software annuity revenue they purchased. But as we do that, the product continues to get more complicated, expanding its capabilities to take on more and more market scenarios so that we can sell it to more and more customers. As we optimize our implementation and go through countless post-project reviews we eventually realize that we reach the law of diminishing returns (explained in more detail below). As a result, we begin to realize that TTL is now primarily a function of the product's complexity more than it is our implementation efficiency.

Nevertheless, if TTL is something you have started to look at then lets look at how you can reach that point of optimization.

DEFINITION OF TTL

Trying to create an apples to apples comparison for TTL is the first critical step in being able to eventually retire it. A customer wanting a simple out of the box implementation versus a customer wanting a highly customized mega-solution will clearly take different timeframes to implement. So why would we combine them to create an average that no other project will equate to? For a metric like TTL if what we calculate is the average then the only project that it should be compared to as a guide is an "average" project. Everything else is expected to be on either side of that number. 

The objective of TTL is not to force complex projects to unnecessarily add risk by attempting to speed up or to slow down simpler projects. It is to refine the process so that it can be accomplished more efficiently. What's more important than trying to find an average of time to go live is to see if your project lengths align with customer revenue. What I mean by this is do your larger most profitable projects take longer to implement. If not, you might not have a services issue but a marketing and sales issue. If it is easier and faster to implement a certain kind of customer and more difficult to shoehorn the solution into other types of customers, then let's correct that if we can. The honest truth however, might be that we've still got to eat and a shoehorned sale is still a good sale provided we can ultimately make the customer successful in the short and long term. 

For most companies though the complexity of implementation correlates to the size of the software deal. Hence, we should make sure that the types of projects we include in our TTL are segmented accordingly. Maybe there should be a TTL Small, TTL Medium and a TTL Large each of which representing a specific dollar, complexity or effort value that resulted from the project's statement of work. Doing this gives you three averages that you can use based on the initial size of the project. In some cases, while a project might start in the TTL Medium category, it is possible that new discoveries could push it to the TTL Large category. The point being that you want to make the decision about which TTL measure you compare any given project to after it is completed.

An alternative to TTL could also be to look at implementation time per dollar of license product earned. A $100,000 project that takes 100 days to implement yields a rate of $1,000 of achieve revenue per implementation day. This is now a number that can be used to compare with other projects almost regardless of their size. Remember also to be clear on when the clock starts and stops and don't allow customer shenanigans to elongate the numbers. For example, project Kickoff to Acceptance is much better time period than Deal Closure to Launch. The delay between deal closure and kickoff can be days or months depending on many factors. Likewise for the time between Acceptance and Launch. 

METHODOLOGY

While you must have a methodology, I also believe that if you have had one for a while, this is not where you will find significant TTL improvements. The reason being that unless you are grossly over estimating the amount of work that needs to get done,  an improvement in methodology is only going to marginally impact the efficiency of how it gets done.  Unless you can remove a whole stage or shift customized work to become packaged then we get to a point that it takes what it takes to get the product to what customers want it to do. That's a terribly "not my problem" thing for me to say, but at some point it is true.  

Regardless of whether your methodology is Iterative based or Waterfall the same amount of work (+/- a few % points) is getting done. The difference is just a reprioritization of risk assurance. An iterative project confirms progress (reducing misaligned expectation risk) as a priority while a waterfall project prioritizes the determination of scope (reducing budget-scope risk) as its priority. And "yes", each of these methodologies could include mitigating steps to help alleviate the over prioritization of one risk over another, hence my reasoning that it simply doesn't matter which one you have. Just have one and use it.

One area of methodology that might yield TTL improvements is to ensure that the methodology is optimized for uninterrupted engagement (more detail below). While this is a general area where some TTL improvement can be found, there is a methodology-specific way that it can help. Make sure your methodology requires continuous consultant contact with the customer. Never leave the customer to come back to you at some point in the future when they are "ready". If your methodology interrupts itself or creates an opportunity for the customer to disengage and then re-engage then this will never happen in a consistent manner and will only serve to add time to your TTL.

To reach methodology optimization I suggest that investment in a center of excellence is always of value. Even once optimized, the center of excellence can then continue to focus on further enhancements on the next topic...Wisdom.

WISDOM

A good place to find TTL improvements is to prepare as much of the solution as you can in advanced. We do this in a cascading way. Can parts of the system be prebuilt for specific business workflows? If not, or once all of those are done, can the integrations in and out of the system be standardized? Then, consider if any of your documentation can be pre-populated with specific user stories or use cases or industry specifics? Now that you have covered all aspects of the delivery, can you verticalize any solutions? At some point, the TTL benefits from this approach begin to diminish and the real benefit comes in the enhanced solutions you are able to offer the customer regardless of how long it takes. You also begin to demonstrate a desire to never start from a blank sheet of paper which is something that always impresses the customer.

Preparing the customer fore the project journey is another area where wisdom can impact TTL. Helping the customer learn the use cases and seeing their business through the lens of our software will ease but not remove the New Product Paradox (the customer's first attempt to build a solution with a new product never results in an outcome as efficient as they will achieve in subsequent attempts). To do this effectively you have to know your audience. The project sponsor is not going to spend three days learning how to configure an installation. The project manager probably doesn't want to do this either, so instead you have to have a commercial summary of the decisions required to be made in a project like this so that they can prepare. Yet, more technical customer resources still need to receive a level of technical preparation that will help them make important technical decisions in the future.

In general, any way in which you can reuse collective wisdom to either speed up your own implementation or better prepare the customer to complete their role more efficiently will reduce your TTL value.

UNINTERRUPTED IMPLEMENTATION

One the of the areas that many services teams find TTL improvement is in reducing the number of project interruptions. While we mentioned that the methodology should attempt to present an uninterrupted use of our resources to push the project forward, we must also ensure that other interruptions are not allowed to occur. This is because "Focus" drives "Quality". If we are able to focus on the complexity of a project then we are able to deal with all of tis complexities in a timely manner. The more that process is interrupted, the more likely we will make a mistake or miss something important. 

The idea of uninterrupted engagement applies to both the service provider and the customer's resources. We want the customer's resources engaged in the project to the highest possible level of engagement for the shortest period possible to achieve an outcome. As we pointed out, we want the methodology to take this into consideration, but regardless of how well it does, the real world will always have an impact. People go on leave, get sick and quit which all result in an interruption as the role is backfilled at short notice. 

From the service provider's side the number of projects given to each consultant is the primary source of interruption. While trying to complete the design document of Project A the resource is trying to investigate test results on Project B and get to the Kickoff for Project C. Every attendance to one of the projects is an interruption to the others. Multiple project assignments is often needed to drive optimized billable utilization, but again, there is a law of diminishing returns that depends on the size and complexity of the project types. 

RETIRING (OR REPRIORITIZING) TTL

If you have done all of the above then you are beginning to realize that the only remaining significant area of TTL improvement lies in the effort required to implement the product. This is because the time it takes to implement a piece of software is far more dependent on the software's complexity than the services team's efficiency once the implementation process has been optimized. That's why, at some point, the argument can be made that as a PS metric it can be removed or reprioritized. Once the PS teams assignment of resources is optimized the variations in TTL are now driven by variations in the complexity of scope, the level and quality of the customer's engagement, the skill level of our own resources or the product's ability to be tailored to a specific customer workflow. 

This latter point is interesting because as a product grows it usually increases its flexibility so that it can be sold to more and more customers. As a result, the time it takes to configure or implement that product increases. So, while we have a massive impact on the TTL the more we optimize ourselves as a service delivery organization, the harder it becomes to find meaningful improvements.