Skip to content

The Summit - April 2023

The newsletter for PS Executives!

Welcome to the April edition of The Summit. To see the full archive of The Summit, please go to the Summit Index.

Services Strategy

As we describe in one of our classes, the promotion from consultant to PS Manager is one of the most significant job changes you can go. Shifting your focus as a billable resource or even as a non-billable resource (such as PMO Manager) to become the head of a profit center is dramatic. The joke we make is that it is like landing a 747 on an aircraft carrier once every 13-weeks (1 fiscal quarter) and then immediately taking off to repeat it all again. While the analogy is a joke, many experienced managers laugh uncomfortably at it and nod quietly as the trauma of their first experiences flood back. The reason this shift can be so traumatic is that most services managers begin their role as a P&L owner without truly understanding the strategy for professional services within their firm, and to be fair, this is because many companies don't clearly articulate it.

Step #1: Define the Mission

What is the role of professional services within your organization? This is a critical question because it is not you that answers it. More specifically it is your CEO & CFO that need to set this as your mission within your organization. The reason it is a combined answer is because services, in general, has two masters that it must serve when attempting to be successful.  The first is that it creates value for a customer in some way. For the most part, this is the easy part of the equation. Professional Services' role in front of the customer is to help the customer achieve an outcome.  While this can vary depending on the service type (consulting, implementation, legal advice) it remains fairly common regardless of the company type (product, services).

The second element however is dependent on your company type. For a pure consulting firm,  service delivery serves as the sole revenue generation engine for the company to survive. But for an embedded services team in a product company it is immediately more complex. Is the primary focus getting customers live? Leading partners to get customer's live? To make profit? How much profit? To be a sales differentiator? Many of these objectives compete in a way that makes it impossible to maximize all of them simultaneously. They must be prioritized.

So, if you are in this situation, get clarity! If you are a PS Manager ask your executive and if you are the executive ask you CEO & CFO to align on a definition. The reason you need both of them to decide is because CEO's and CFO's see the company through different lens that help the company succeed. It is critical that they agree on tradeoffs that occur when one priority is selected above the others. Not all of them can be equally served so consensus on what is being lost in order make gains is agreed and understood. 

Step #2: Determine the Role

While the mission describes what we will achieve, the role describes how. Do we want the service delivery team to grow proportionally to the company growth or disproportionally? Every services group has a different way in which it is going to achieve its mission based on the maturity of the company and the maturity of the professional services team. For example a startup with an immature services organization may need to have its service delivery team rapidly scale faster than the rest of the company to avoid future churn. A mature firm with a large delivery team may want to reduce its services overhead and train partners to lead implementations as an alternative.

Another area of the "role" discussion is how professional services fits into the company's customer lifecycle. Typically, service delivery is accepted as being a profit generating and transient organization. This makes "adoption" a very difficult role for services to fulfill. Customers don't want to pay for this time as "services" and the company can't afford to be wasting its best implementation resources on facilitating customer change management. It is not for me to say whether or not services should or should not do this work. It should be driven by the mission and then determining how that mission can be achieved given how the services team and P&L is established.

Step #3: Find & Build the Resources

Now that you have the what and the how the question turns to who? How will we find and prepare people to achieve the mission through the role we have outlined? This requires detailed planning that looks at a resource model that takes consultant career development into account. One of my early learnings within the services world was the fundamental importance of a career  map for my team. In every organization I joined, it was the first thing the team asked me for because it is one of the key motivating factors that has people want to do their job well.

Equally as important, an integrated career map can help executives and managers developed something I call a "leveraged" resource model. Others sometimes call it a "farming" system. The idea being that services is an industry where you can charge a higher price for greater experience and greater depth of skills. So, if you can segment the skills you offer to the market in a way that reflects the onboarding and growth elements of your team then people can naturally enter, grow and move about in a way that is constantly strengthening your team rather than reaching career "dead ends".

An example that I often implement is the creation of a simple service such as "Administrative Services". This is where the customer purchases an admin (not a developer or support technician) from us to administrate their solution. The training for this role rarely exceed 8 weeks and we can take any untrained resource and turn them into an administrator that can instantly start earning profit. If you work well with your support executive you could use Support as the entry point for services and train them there. Regardless of where you start them, the progress for each role needs to be both forward (in terms of ownership) and depth (in terms of knowledge expertise). Each person must have an ability to move in either direction at any time based on what they want to do with the "next step".

As they take those steps, the career should move into the provision of other services (eg: implementation, advisory, etc.) which can charge a higher fee but that also come with a higher cost of salary. This is a leveraged model because at all points you are working to keep costs under control in order to maintain optimal profits. It prevents your P&L from becoming top heavy which is stagnation point that many organizations reach when all they do is attempt to hire the best talent. The best talent is the most expensive talent, so at some point, if you want to keep scaling, you have to learn to build the talent that will make you successful.

If you can establish and maintain these 3 elements within your organization as being the agreed model for how you are going to run your organization, then it will give you guidance on how to manage achieve your goals with confidence. The clarity will drive through every element of your operational execution and remove obstacles to growth and success by avoiding before they even appear.

Revenue Portfolio Balance

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 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. 


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. 


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.


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.


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.

Improving Time to Live (TTL)

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.


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. 


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.


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.


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. 


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.