Organisations running numerous projects often look to solve their problems through adopting production line thinking to their project portfolio. Evidence for this is the presence of delivery teams, working on their particular projects, and drawing on the services of other teams who provide a service to the business.
This is great, as the project moves through its production line, getting the service it needs at each stage, and ending up delivered into service. I’ve written about this product factoring before, it allows us to remove the blocking processes from our project delivery picture. This makes everyone happy, but I’m not telling the whole story here.
In reality, the project bumped along going before the various teams. The designers. The architects. The data people. The list goes on, but the grammar illustrates that this can be clunky, as a result of the service teams not having sight of what is to come.
When talking about the reasons for service teams impeding project flow as opposed to inducing it, I am always told that things would run smoother if the team knew more about the project up front. This is really useful insight, but in an agile world, we have to be careful that we aren’t just pushing the work to the front of the project and doing, “Big Design.”
In the worst cases, service teams actually end up stopping projects, and when asked, come back with, “If only they’d asked us first.” This leads to a vicious circle of delivery teams trying to solve problems best left to the experts, and experts becoming aloof from the realities of the operational environment.
Thinking about a pragmatic way to make it easier for delivery teams to engage with service teams, I find that it is much easier to get down to business, if there is a rough idea of what that is going to involve for both parties. This is so that we don’t dive into the low level detail, and loose the point that we are supposed to be accelerating delivery.
Working with service teams, I often ask them to produce a “Car Wash Tariff,” to better explain to a delivery team, the services that they can provide. It could be like my local garage where you get seven levels of service with the top level offering complimentary chocolates, but more usefully you could just consider small, medium, or large projects.
The automatic car wash is a useful metaphor, because it allows for someone tasked with delivering a clean car, to choose the right level of service for their requirements. What it doesn’t do is confront the driver with the soap type, water consumption, and power requirements for the particular make of vehicle, and require that you use a series of graphs to choose the optimum wash.
Service teams that can set out a tariff for their activity, can therefore produce a consistent way to qualify which level is appropriate for the project they are looking at. So they reduce the time it takes to estimate, and plan their engagement, whilst at the same time making it easier for their customers to use their services.
A tariff for a DBA service might look a bit like this. It doesn’t specify how much of each activity there will be, or how long it will take, but it does focus the types of activity to avoid them getting out of hand. This makes sure that the DBAs can add value, and the delivery team know what to expect. Based on an initial consultation, the team choose the appropriate tariff, and can then ensure that they cover off the work that is outlined there.
Another benefit of this approach is that it is possible to map the activities, to stages on a portfolio representation of projects. This makes it so that organisations which have these high level views of their projects, can see the maturity of their projects through them having satisfied high level policies at each stage. They can also be confident that the maturity is underpinned by appropriate technical and operational excellence, which is proven by evidence that is mapped to these policies.
This is part of a larger pool of joined up thinking that helps to underpin activities associated with accelerating delivery. If it raises any questions, it would be great to hear them. Thanks for reading.