Recently, I was participating in a conversation with a CEO group regarding consulting and how few companies can deliver what they commit to. Somewhere in the conversation, I mentioned the importance of delivery flexibility, and had one CEO challenge me to explain what a flexible delivery model really was. I answered it and we moved on and had a very productive conversation.
But later I started to think through my answer and I began to ask myself what a flexible delivery model really means, and what does it really matter to successful delivery. So in this blog, I am going to explore what I think a flexible delivery model is, what types of delivery types make up a flexible model, and if/how the model can help. I hope it is informative and helpful. I also hope you will provide your feedback and thoughts. So with that, let’s get to it.
What is a Flexible Delivery Model?
The simplest explanation of a flexible delivery model is that you change the way you deliver a project depending on what the client needs are and the project dynamics. You will use different methods to deliver a project based on the business requirements and technical demands of the project. While this is true, and it makes complete sense, it really does not go far enough.
Flexible delivery goes beyond just changing the method of delivery. A flexible delivery model also refers to what type of project you will use. Or more accurately, it refers to how you build the team and assign resources. Having flexibility in how you build and engage with the team is a key component for delivery flexibility. Delivery flexibility also encompasses how you bill or charge back a project.
Depending on the needs of the customer or internal departments, you may decide to bill, or charge back, using various different methods. By providing this flexibility, you align cost with actual behavior and you may enable the client to begin a project that would otherwise be rejected or put on hold. So financial flexibility is part of the overall delivery flexibility. In fact, all of these individual things are components that make up a flexible delivery model.
In short, a flexible deliver model refers to how you attack solving the problem, how you build your team to deliver the solution, and how to best charge those costs to the client (whether internal or external).
What types of basic delivery options are there?
There are five types of delivery options that can be used in a flexible delivery model. The delivery options are based on how the delivery team is structures. They are:
- Assigned Resource(s) – On or more resources are assigned to a client or project for an extended period of time. An example would be if you assign three Workday resources to a two year implementation. There can be various billing options like hourly, daily, weekly, monthly or quarterly rates.
- Pooled Resources – An allocation amount of effort (usually in terms of man hours) are agreed to for an extend amount of time. An example would be when you hire a company to provide one thousand hours of Java development per quarter for the next three years. The vendor will allocate those hours to you and ensure that the resources are available as planned.
- On-Demand Resources – Resources are provided as needed. This is usually to provide temporary support for peak times. For example, you may buy a support contract for 100 hours a month to cover any network outages. Or you may pay for 100 hours of call center support to cover those times where there are more than 10 calls in a queue. This is usually paid on a per usage basis or as a managed contract with a minimum amount per period (weekly, monthly, or quarterly). Companies who have seasonal fluctuations tend to need elastic resources to manage changing demand levels.
They will forecast their needs in advance and schedule resources to cover those forecasts. Once they know if they need more or less than the forecasting models predicted, they will rapidly increase or decrease resource loads.
- Elastic Resources – Elastic resource allow you to spin resources up or tear them down within short period. Think of a resource cloud. You add more resources as you need them and if you ever have too much bandwidth, you reduce the team size. Staffing is one way of doing this, but it is not an efficient way. Staffing takes a while to get someone started and you do not want to get a reputation for treating the contractors badly by eliminating them quickly. There are better ways to provide the elasticity.
Companies who have seasonal fluctuations tend to need elastic resources to manage changing demand levels. Most of the companies who are effective at this model have someone at least part time at the client so they understand the culture and requirements.
They, in effect, are the engagement manager and the HR manager. When a client needs to add a new person, all they need to do is to contact the onsite manager with an authorization. The onsite lead will coordinate identifying the right person and starting the project quickly. They will transfer all the relevant customer culture and procedural information to the new resource.
- Usage Based Resources – Think resource as a service. Rather than paying or requesting resources, you pay by the resource task and the vendor charges you a price for the service. The vendor then becomes responsible for managing to the service cost and SLA. In a since, fixed price projects would fit this model.
This can be a good model for companies that are mature and have a handle on their cost accounting. The vendor likes this model because it allows them to try to manage to better efficiency. It is a shared risk model.
What types of project delivery are there?
There are also at least six types of project delivery methods as well. They are:
- Augmentation – The vendor provides their resources to augment your team
- Outsourcing – The vendor assumes responsibility and they become your team
- Project Delivery – The vendor uses their resources to deliver the outcome you need
- Product Development – The vendor team manages either the development of, the QA for, or both development and QA for a reoccurring release schedule. This is must delivery scenario. The vendor is basically charging a set price for a set of agreed to functionality on a reoccurring basis.
This becomes a shared risk model, but there must be reliability as the company is marketing the functionality in a release well before it is set to release.
- Managed Services – The vendor provide a certain amount of resource units per a specified time period. (ex. 30 hours a month for network support). This is typically used to manage ongoing systems and applications. Help desk services are the most common of the managed services categories. Managed services are also moving into the …as a service model. For example, mobility as a service, IT as a service, or procurement as a service.
- Block of Hours – Much like a managed service, the client buys a certain amount of units for a specified period. However, there is no regular interval for the hours. The hours are used when needed. For example, if a client buys 5000 hours of development time for a six-month period, they may use all of the hours in the first month, the last month, or anywhere in between.
Does a Flexible Delivery Model even matter?
For years I have been touting a flexible delivery model as being key to delivery success. Was I right? Well, to give a consulting answer; it depends. It will help in some cases and in others it will not. When you get right down to it, a partner delivery model doesn’t matter one iota if they do not have quality resources.
It always comes down to the people. If you got good ones, you will be a good delivery company. If you don’t, you will never be good at delivery no matter what model or methodology you use. So, if you do not have good consultants, a flexible delivery model is irrelevant.
But what about those companies that do have good consultants. Will a flexible delivery model help them and if so, how? I believe it will for several reasons.
- First, it allows you to match the project demands and the client’s capabilities with the best way to meet those demands. If the project requires periods where there is no work, and then there is rapid deployments, then an elastic delivery model is perfect for that. If the vendor is familiar with this model, they will have the appropriate tools to help predict the demand, and they will have processes for starting up a team quickly.
- Second, a flexible delivery model will match balance cost and risk. For example, if the company has high risk because they do not have experience in application development project in a new technology, they can use a fixed price, assigned resource approach to eliminate the risk. They may even be able to use a product development approach. This will cost a little more money that the other methods, but it will reduce, if not eliminate some of the risk they face.
- Third, a flexible delivery model can help clients get projects out to market faster and they may allow them to do more projects overall. I just had a client who wanted to outsource a project, but there were severe accounting constraints on capital expenditures. But this was an important support contract and the CIO was in bind looking for a solution. We set down together and look at various delivery options.
- We finally found one that met his budget, his goals, and his accounting requirements. One of my partners signed a three-year support contract with him and everyone is happy. But without having a lot of options available to me, I probably would have never found the right one for the client.
So in summary, I do think that a flexible delivery model can be helpful, assuming the delivery company has good people, processes, and methodologies. It allows the delivery team to customize an approach to meet all the needs of the client organization.
Thanks for reading this. I hope it was entertaining and helpful. Please let me know if you have anything you would like to add, or you just have feedback or comments. Until next time, I wish you health, happiness, and prosperity.
President & COO