Have you ever seen the TV-series “House of Lies“. This is a quite funny TV comedy series that focuses on the extrovert lifestyle of a management consulting team. First of all it is a comedy and not very realistic, but it manages to illustrate the concept of how to create the most efficient organization form for solving problems; The Agile POD.
Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output. This blogpost is about how to organize a consulting business that is non-silo organized around an actual service product.
In many consulting companies today, we see increasingly alarming signs that prevents the full utilization of the people and resources. Some of the signs can be seen as:
– Many non-direct-operative managers. (If you have >5 levels from bottom to top you have an issue)
– To many internal meetings. (Why Meetings Kill Productivity)
– To much time are used to generate budgets, forecasts and excel spreadsheets. (No actual customer value)
– Organized into silo-team with similar expertise. (Functional, Technical, Support etc)
– New project teams for each project. (Spends 2 months of getting to know your team members)
– Outdated internal systems and processes.
– Mixed marketing message and costly (pre) sales and implementation processes
– Many partners is currently not ready for the Dynamics 365 cloud based disruption (Sticks to waterfall, while agile accelerate)
Agile POD’s is a different way of organizing a team for efficiency. How does a agile POD look like? In this example we have a small 5 person permanent team. This team is specialized for running a some tasks/phases in the initial Dynamics 365 implementation; The Agile preparation phase.
In this example the POD owner is the Solution Architect. The roles in the POD can be described as:
The solution architect:
He runs the POD, and he also have all the responsibility of the POD. It is the POD owner that recruit the POD-members. The Solution Architect is the “face” of the POD, and will organize the work in the POD and also discuss the solutions with the key decision takers at the customer. Very often the solution architect have lot’s experience. In agile terms this is also the SCRUM-master and also very operational.
The Finance expert:
When implementing Dynamics 365, there is an always a need to know how to connect the operational processes into accounting and reporting. This person is highly knowledgeable in Financial Management reporting, Power BI, Excel. He also knows how to improve the reporting from the financial perspective by defining financial dimensions, setting up Tax, Bank, Fixed Assets, HR and Budgeting/Forecasting.
The Vertical Domain Expert:
How to implement best-of-breed processes is the vertical domain experts expertise. In Retail-domains this means expert on Master data, Categorization, Stores, POS, Devices etc.
The Technical Architect:
In a cloud based system, there is a need to understand how environments are deployed, setup and make it all ready for an efficient Application Lifecycle Management. The Architect knows the ITIL-framework. When a change is needed the technical architect will create the necessary documentation/VSTS backlogs for developers to execute on.
The Junior consultant:
The junior consultant is here to learn, offload and support the team. As experience increases the junior will eventually more responsibility and hopefully some day move into other positions in the team.
Within the team we are looking to T-shaped person, that have a width to their expertise, and also a few deep expert knowledge domains. A gaming company called Valve(That delivers the Steam gaming store) described what we are looking for with the following picture of the T-shaped model. Take a look at their employee handbook. This same concept and idea is relevant for Dynamics 365 consulting companies.
The Agile POD’s must therefore specialize their own services. Each POD-team must therefore build WBS (Work-Breakdown-Structures) that enables the delivery to combinedly utilizes the entire POD.
The idea is that a POD-team is sent out to the field, then delivers the pre-defined services, and returns safely afterwards. Then it is off to the next client to again deliver the same service. As you may understand, it is therefore important that the services delivered is predefined. In this concept there is not one team that delivers a complete implementation. In larger implementations it would be a sequence of Agile POD’s that cover the implementation.
This way of organizing is not a new way of doing things. This working concept have been applied for decades at entrepreneurs and building companies. When building a house this is not done with a single team. It is done by a sequence of teams that is specialized. A POD team will have responsibility of a limited set of tasks, that needs to be performed in a predefined sequence.
By organizing operational skills into POD’s executed in a sequence, we now have a balanced unit. One pain in Dynamics 365 consulting companies I often see is that bottlenecks arises around a few selected roles. Typical on the solution architects. This unbalance will result on high utilization on these roles, with other roles have low utilization, because work is not correctly distributed. We also see that consultants are being placed into project teams because they have free time, and not because they have the right knowledge. This increases costs and reduces satisfaction for customers. Ultimately it also reduces profitability for the implementation partner.
Agile POD’s does not solve every thing, but it makes the center core operational services lean and efficient. Any consulting company still needs sales, project management and customer support as separate functions.
As seen in the figure above the each vertical focus area will have a management functions, that focuses on building Agile POD’s. The idea is not to hire single consultants but to create new POD’s. The POD itself must define the services that the POD can deliver. The role of a vertical department management is therefore to how on recruiting new POD’s. As Valve explains it, the hiring becomes the most important thing in the universe.
A model for money and revenue must also be established. All departments must be self-financing and make sure that they are balanced according to how the revenue stream is defined. One element that is common in the consulting business is bonuses. I personally don’t like the idea of bonuses but I see that it is very difficult without it.(Necessary evil) In the model below is a an example on how different departments can be revarded.
Marketing and Sales: The concept of cloud based systems it that the customer don’t need to purchase all the software upfront. They rent/hire the software in the cloud, and only pays a monthly fee. The Marketing and Sales divisions must therefore be financed by the monthly license revenue, and the bonus would be accumulating. The purpose is therefore to make sure new customers are onboarding and that existing customers hare happy with the services. As a new seller in this way of organizing it, there will not be much bonus in the start, as you have few customers onboarded. But as more customers get’s on board, the bonus will be accumulating, and after 2-3 years there will be a decent bonus and a decent ground for investing more in marketing.
Project and Management consulting: As described earlier, these roles are the only more “permanent” roles that exists in the project. They will ask Agile POD’s to come inn and solve specific tasks. Their services are based on T&M(Time and Material), and their bonus will be based on the revenue(not margin) on the project.
The Agile POD’s: These services are charged in a combination of T&M and Predefined Product Services. The Predefined Product Services is the key here. Create WBS-structures where the price and delivery is clearly defined. The bonus here is a team bonus. Internally in the team it is distributed according to a key. But the POD-team can also choose to use the bonus for other purposes also like training or conferences. Remember that an agile POD is a self-contained unit with costs, revenues and margins. If the POD is not profitable it will be dissolved and the team unattached/fired.
Platform Services: This department is making sure all services/software around the Dynamics 365 is working as expected. This means making sure the azure/tendents are set up correctly, that Office is working and that services like CDS(Common Data Services) and PowerApps are setup as expected. All their services should be Predefined Product Services. And the bonus would be based on margin. Why ? Because we want to become better and better delivering these predefined services. The faster this is delivered the more margin is generated. This is a Win-Win situation for both the customer and for the consulting company.
Customer support/After Sales: Customer support and aftersales is all about delivering excellent customer service after the project have gone live. It’s revenue should be based on support agreements and add-ons. The bonus for the department is based on accumulated revenue, because these services should be reoccurring services that the customer pays for each month. If the customer is happy about the services provided then they will continue to use this service. The alternative for the customer is to use Microsoft Premier Support that can be quite costly and not that relevant in most cases.
At the end of this blogpost I would like to visualize how we envision the Agile POD’s, where we have training on our services and delivering excellent customer services on time and on budget.
And if we don’t, then this is the consequence:
Additional details on Agile POD’s can be found here:
Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer EG or other parties.