The Summit - April 2023

Just like your investment portfolio, your project portfolio can be assessed by how much risk it contains. As such you can also take action to mitigate that risk through balancing it (specifically from the perspective of revenue). If you look at your business from a profit and loss perspective every month you need to make enough revenue to pay for next month's resources. To assure that happens month after month you want to minimize the chance that you get hit with a sudden loss of revenue that turns your P&L upside down. For example, a portfolio full of top tier complex implementations could have a handful of projects enter high escalation resulting in a dramatic slow down or even halt of revenue. Similarly, a portfolio full of subcontractor engagements could go sideways if a downturn forces partners to bring work in house. Even more important than revenue, think of the burnout impact on your consultants when a portfolio is filled with nothing but complex, high value and demanding clients. For these reasons, we want balance.

CUSTOMER PROJECTS

Customer Projects are projects where it is your responsibility to own and deliver the project directly to the customer. These represent risk because you own the delivery. Following our usual best practices helps you mitigate many of these risks but we can't mitigate all of them. Assess your portfolio to determine how many of them might lead to an escalation that will interfere with either your revenue generation or your consultant burnout status.

Even within this type of project there are several categories such as packaged projects, fixed fee custom projects and time and material custom projects. Each of which has a risk profile that need to be balanced.

The upside of these kinds of projects is that they fuel growth! They keep a handful (or maybe more) people busy for a long time and they generally (unless escalated) keep the revenue counter ticking. Consultants like working on them because the work is challenging and sizable which allows them to flex their mental muscles much more than short burst work tasks.

The downside of large projects is that they do escalate and when they do, their billing can get out of hand. If we don't carefully control who is on the clock and who is not we can end up with some hefty invoices rejected and not being paid, leaving us with a P&L full of revenue holes (or R-holes for short). Also, large projects tend to burn consultants out if the customer is challenging. While complex projects are a mental playground for consultants, being on that playground with a bully ruins the experience. If a consultant rolls off of a heavily debated $1.5M project acceptance and then rolls straight onto another of the same size to discover a heavily misaligned statement of work or contentious customer then burnout is imminent. 

STAFF AUGMENTATION

In the strictest sense, these are not projects yet could easily be signed on a similar looking statement of work. They are the provision of a skilled resource for a period of time to partake in an activity (project, advise, consulting) that you are not the owner of. In this situation, it is consulting services at its purest, the time of an expert in return for a fee without deliverables.

The upside of staff augmentation is that it is almost risk free. That sounds enticing but they are also usually of a smaller value than complete project ownership. That said, if you can find the right market that has a high need for a specific skill as a subcontracted or time based expert, there is a lot of margin to be made not having to implement projects.

The downside of staff augmentation is that the deals are typically smaller than project implementation. Hence, it makes high growth harder. They are seldom sold with greater than two resources and no sooner did they begin, you are trying to find the next job for them so the sales overhead is high. 

ANNUITY

Similar to the administration service I mentioned earlier, this is a contract where you are providing a fixed capacity of an FTE (or several FTEs) for a period of time on a renewable contract. While it might be as a part of an administrative service it might be for a large scale project. Annuity contracts are not the first place PS executives and managers think of finding revenue, but in every job in the last 10 years I've managed to find at least one annuity service we can offer.

The upside to these contracts is that they keep people busy for a long time. If you are selling capacity in 50% increments you can get 5-10 people billing full time pretty quickly. 

There are limited downsides to these contracts except they don't typically have the same mode of operation as other engagements, hence it is hard to have one resource be on both a project and an annuity contract. You can't be on a project trying to meet a deadline and be servicing an urgent customer request to whom you are meant to be dedicated. If you don't establish the service well then you might end up selling a lot of 3 month renewable agreements which is not fun. Be sure to establish a service that sells in 6-12 month contracts so you are not run off your feet with renewals. Also people doing this kind of work usually get bored with after 2 years or so, but I like that because it is the right time to move them into something new.

TRAIN WRECKS & RUBBERNECKING

When one of your project's becomes an investment and you have a team burning hours with no revenue, you need to set your portfolio into risk mitigation mode. Unfortunately, the typical portfolio response creates the opposite effect. The project that is having the issues escalates and the customer starts screaming (figuratively and literally). The PS Manager runs towards that project because that is the one screaming. The rest of the portfolio is now unmanaged. See the risk? Just like rubbernecking while driving can cause another accident, we allow one project wreck to distract our attention while small fires ignite and rage in the remaining portfolio. 

PS Managers often find that it is the project fires that start in the temporarily unguarded portfolio that ultimately sends the P&L into loss making territory, not the initial one that distracted them. I can't say that there is a great fix for this other than to be aware of it and minimize the temptation to commit yourself entirely to that first fire, or as you do, get someone to backfill your role as sponsor across the portfolio you are no longer paying attention to. Again, there is no perfection, just continued mitigation.

SUMMARY

This is more of an executive framework than a manager framework, but it applies to anyone with multiple revenue types within their portfolio. If you have the luxury of having multiple revenue types then spend the time to invest in them so that they can help you create balance. Too often the initially dominant revenue stream gets most of the attention and the smaller revenue stream eventually dies off. This is a missed opportunity to balance your portfolio and hedge your bets on how you will get this months target or even cover next month's cost. 

If you don't have multiple types of revenue look to create them, There are always ways to make money. This is something I spend a lot of time on when I start advising a new firm. "Paths to Revenue" is an exercise we do that helps a firm consider a variety of different ways in which it can generate revenue and then determine which of these paths has the least resistance. It is never a bad idea to have multiple revenue streams as long as they provide your customers with a service of value and it doesn't imbalance your resource pool.

This leads us to revisit the "Resources" from the Services Strategy article above. If you are trying to establish a leveraged resource model then establishing your revenue streams to allow you to do that naturally then you have a fantastic farming model that bring people into one part of your organization, have them gain experience while generating profit and having plenty of career options to expand their skill development and grow.

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.