Rate structures: respect the pyramid

22.04.18 05:58 PM By Matt Koopmans

Keeping the program cost in check starts at the planning and procurement stage. The rates negotiated will determine the cost of the project... right? Well... not exactly. The rates obviously have an impact on the overall cost structure, but when procuring the team for the program, it is not simply shopping around for the lowest rate, it is crafting a well-balanced pyramid (or diamond - see further below).

 

All resources are not equal

There is a wide variety in the resources - their experience level, the company they represent (and backs them), the value they bring to the program, and - not to forget - their scarcity in the market. Differentiation in rates is therefore expected - and even welcomed. From a rate perspective, the resources on a project roughly fall in three groups, each representing a layer in a pyramid: the "value layer" - this is the top of the pyramid, it has few but highly experienced resources. This is your program leadership, such as program manager and solution architect. Expect to pay a premium for such premium resources, who typically have twenty or more years’ experience in the field. There is no substitute for the experience, especially considering the business transformation programs, and business application implementations are very complex with many moving components. The value layer provides the "know why" - not only do they bring vast experience in complex engagements, they can also relate with industry knowledge.

The second layer of the pyramid is the execution layer. This is where the project managers, senior consultants, and consultants add their value. Typically, there is upwards of 5 years’ experience in this group for consultants and project managers, and 10 years plus for senior consultants and senior project managers. The execution layer brings the "know how" to the program. Experts in their particular field of project execution or application configuration.

The third layer is the cost layer. In large engagements this is mainly where the work is outsourced overseas (off-shore development). In addition to this, think of people entering the market - such as interns or graduates at the beginning of their career. This layer needs to "know what" and they will provide the services and learn on the job. 

 

Pyramid or Diamond?

What would the appropriate relations be with regards to the layers? There are two ways to look at it: from a cost perspective, and from a resource count perspective. Another variable is the size and structure of the program. Let's break them down below with the two extremes in the spectrum.

A large program with a sizable off-shore component will have a cost relation in the pyramid ranging between 30/30/40 and 30/40/30 in the value/execution/cost layer respectively. The resource count will roughly be 1/4/6 to 1/5/9 value/execution/cost layer respectively. Note that with off-shoring, it is usually based on a fully loaded workweek per resource, do not assume the team will switch between projects if there is only 24 hours work for the team.

A smaller engagement, or an agile/iterative engagement usually has no option for off-shore work that is cost effective. The cost layer is therefore smaller than the execution layer. instead of a pyramid, the layers represent a diamond. Typically, the average cost rate is higher in the execution layer of a diamond, than in the execution layer of a pyramid, as you would have a higher ratio of senior consultants than consultants. 

 

Shaping for success - layers are essential

The adage "if you think you cannot afford a professional, you certainly cannot afford an amateur" holds true. Not to say there aren't any great consultants and senior consultants in the market - far from it - most are extremely capable in their field, experts in the application. However, knowing what to do, or even how to do it, does not absolve from the need to know why or why not to do something. It is in the "why" where you either realise value or run into significant unnecessary cost - either short term or mid to long term. Putting the program in perspective, this usually represents a major investment and is something that should provide benefits for the years to come. The higher cost per resource in the value layer seems significant, but actually has a much smaller influence on the average cost rate for the whole program. Especially if the tasks in the execution layer are properly scoped, and what can be moved into the cost layer is moved there. The question is not whether you can afford the value layer, the question is: "can you afford the program without one."

 

Originally posted: 13 September 2017

Matt Koopmans