Dynamic Solutions Delivery Methodology

Aug 16, 2023

Whilst working as a technical project manager I often came across the issue of the right level of management tasks to implement in and project and by extension, the correct sort of tasks that wouldn't get in the way of doing the work. It was always a point which niggled at me. I had some formal training in a couple of project methodologies and one main one stuck out because the emphasis was on getting things done versus admin. A huge plus in my book.

Over time I progressed into managing the portfolio of project works and similarly programmes of collective projects. At this stage, the problem became more evident when leading project managers, as opposed to directly, leading the project itself.

Someone suggested using sprints, which we were already doing to a degree, except we called them phases. That triggered something in me though. In my experience, often we take pieces of different methods to go about doing things. The problem with this approach is you can leave behind really integral elements or plug things in that really don't fit.

With this in mind I started reading the Scrum guide, which I hadn't done since my time in Organisational change. I like scrum, its lightweight, its simple to grasp and or course, it is a nod to Rugby, the finest sport on earth.

Scrum didn't quite fill the system I had built for our project work. Its an end to end, inter-departmental, whole lifecycle approach starting with the creation of an opportunity to delivery, handover and billing.

Scrum is very good for shipping features for a particular product. Which is why it lends itself so well to software development. Software, especially nowadays, ships on a continuous deployment cycle. I am in Infrastructure IT and there isn't a consistent level of work - although productisation of services is something my lifecycle thrives on - there are peaks and troughs, multiple customers and the requirement to maintain income to pay for us.

So with Scrum as the bedrock, I expanded on our approach to create what I thought was going to be a bespoke method but is becoming a truly Dynamic Solutions Delivery Method, actually, I think i'll call it that from now on.

Thank you for reading Bad Infrastructure. This post is public so feel free to share it.

This method uses some key elements or objects, if we like to use computing terms. I like computers, so I have and I will. These objects are:

Backlog

A backlog is a simple, nice and complete term to describe all the tasks or actions requiring completion. I use a couple of different backlogs which align very closely with the Scrum methodology:

The solution backlog. This comes from my design work, which happens pre-sale. Then that solution is initially organised into Sprints, more on those shortly. Each of those sprints, having fixed time boundary, have their own backlog. When that sprint is done, god-willing nothing will be left uncompleted and there will be no re-work. In the highly unlikely event that you dont get everything done - I am joking of course - those remaining tasks temporarily return to the solutions backlog to be re-allocated into the next appropriate sprint backlog.

Within each sprint you might have a further backlog, per individual.

You cannot complete a project without completing everything in your backlog. You can discard things from your backlog and even abandon a project. until you complete your backlog however, your project is incomplete, because your solution hasn't been delivered.

The Solution

The product or service that you are going to deliver is the solution. Projects are about change.

You effectively have two types of work at a high level. Routine Operation and Extraordinary work. Routine Operation are your replicable things. Things that are easily quantified or if not easily, they are still quantified sufficiently for people to know what they need to do.

Extraordinary work is different than your routine operation in that you have to think about it and plan for it. If that thing is change, change is a problem that must be solved. Change requires a project.

For me, this could be Azure Virtual Desktop implementation, Microsoft 365 Modern Workplace or a network deployment, amongst other things. In that case, you are delivering a change from the current state, which might be an on-premise Active Directory domain and delivering something different. As a project team, you need to boil down your method to routine operation. For your customer, this is extraordinary work and needs to be handled as such.

The change is the problem and your project delivers the solution.

Stand-up

Simply an incredibly short meeting of all required participants in the project done every day you are working on the project. Its a stand-up because my boss in my very first IT role, wouldn't let us sit down during them. We all got comfortable and lethargic, but when we stood up, we stayed on point and got through things ready to smash on with it.

The best agenda I have seen for a stand-up is:

What did you work on yesterday?
What are you working on today?
What challenges, obstacles or pain points are you experiencing?

That's it. Get you team (regular & specialists) in the room, if you are big enough, get a facilitator (not a project team member), if not the Project lead runs it. Go round-robin. Don't throw a beach ball between each other, simply don't talk until its your turn. Listen! No gimmicks.

The facilitator or project lead, whoever is running the meeting, needs to take down the challenges, obstacles or pain points. These get addressed at the end of the meeting, if you have time and it is beneficial. If not do it outside of the stand-up. You might have some top technical minds in this meeting, don't waste that if its needed. By the same token however, don't waste their time if thats not needed.

A stand-up shouldn't take any longer than 15 minutes unless you are a big team that can't be easily segmented. I do and have done some pretty hefty technical projects overtime. I have rarely experienced a team bigger than 4 people. The way I work is, other than a facilitator who is actually outside of the team, everyone within a project team needs to have some part to play in the delivery. If not they have no place in a stand-up. That should be between the Project Lead and that person, outside of the stand-up.

Keep the emphasis on delivery. If its not on delivery, don't ignore it, park it and address it outside.

Sprint

Sprints are a closed, finite period of time where a backlog of work is actioned in an intense and focused way. The objective is to complete as much as possible, accurately and in a fixed timeframe.

Sprints are not about speed, they are not about a race to the bottom. It is about focus and delivery. If you are unfocused, things slide. Focus, like will power, has an infinite supply over the long haul, but you only have a finite amount in the tank at any given time.

You need to plan for this so you and your colleagues aren't getting burnt out.

Delivery is about getting it to the customer correctly. You can never be 100% correct all the time. You objective is to be correct and accurate as much as possible and work continuously to improve that accuracy.

Sprints enable you to adapt to changing needs for you and the customer. They also allow you to adapt to your strengths and leverage them, instead of trying to mould something unsuited for they job. Sprints are also rigid enough to ensure you keep moving forward.

Reviews and Analysis

I use different levels of this, they are essentially much longer stand-ups, but you can sit down. The objective is to review each sprint, figure out where things have worked and not worked. its not a back slapping exercise. it is designed to keep you focused. Ensure that you understand where you are in the work and any issues that might come about.

Then, at the end of the project, its important to review the whole thing and record the results in some form of information management system. It might mean you require a statistical control chart to see where problems lie in a quantitative way. Do you spend too long on a computer and therefore need to find a more efficient approach to that slice of the work?

Accountability

Many methods and organisational management approaches hold this. One such management philosophy, from the book Traction, is to maintain an accountability chart, listing who is responsible for what. I take this further by introducing a reports and delegates to field.

I like military leadership. I am not talking about National Service, Bad Lads' Army Corporal Nauyokas letting his Royal Army Ordanance off in your face. I am talking about proper military leadership.

That means, leading by example, discipline, high performance and striving for the teams goals. To even aspire to this, everyone needs to know what is expected of them, they need the support to complete their work and they needs to know who to talk to, about what to talk to them about and when that can be done.

Accountability charts do this. They keep clear boundaries between work so that you are not treading on each others toes and therefore creating wastage. They keep things moving.

This is not about siloing work. In-fact this whole method is a sort of anti-silo. I haven't finished Hugh Howey's Dust yet, I wonder if he has an anti-silo. It is also not about introducing additional bureaucratic process.

Checklist

They are exactly what they sound like. A list of items which you MUST check off. I got this from the book Checklist Manifesto and it always stuck out to me that incredibly experienced surgeons require checklists to keep them accurate and consistent i.e. not chopping of the wrong foot or amputating anything when the patient simply came in for a simple day surgery.

Consistency leads to quality in my book. If you are consistently poor at something, at least you have somewhere to build from. Marginal Gains, and all that.

Objects

Objects are the components of the work. The backlog is an object in and of itself and so are the tasks that fit within it. Objects are generally tangible and describe pretty much any other element of this method. An event is an object, your resources are objects - not in the sense that you treat them as such, in the sense that they are necessary to the formulation of the delivery.

Events

I hope this one is explanatory. Events are things that happen at a point in time. A Stand-up is an event, execution of a task, is an event. A review is an event. You get my drift.

Actions

Actions are the day to day activities. I said that I like to get work done. I enjoy thinking about things but ultimately if things do not get done I get frustrated. Correct me if I am wrong but this is the case for many, if not most people depending on what the thing is. Actions are the things that keep the ball moving, the offload in the tackle, the pickup and run that you should never do as an unfit second row and the hour and a half device transformation to tick off another tasks on your checklist.

Roles

Within this method, something that is key is definitions and assignments. Without those elements, I don't care how experienced you are, your process is inefficient and causing you problems at some point through this process. or Pipeline. Lets call it pipeline, I dont think I have enough cliches in this yet.

I believe in the apprentice/expert model which lends itself really well to project work. Anybody can lead a project with the right support and the right framework, provided they know how to complete the tasks and direct the delivery. That said, there are some key roles that must be filled for any project. There are also some roles that maybe needed or not, depending on size and complexity.

Some roles are part of the project team and some actually sit outside of the project team and maybe called on at various points, to address various things.

Solution team - Outside of project

Customer Advocate.

Often a sales person or account manager. They are the person who has taken on the solution from the customer, obtained the specification and will be the person driving things forward at pre-sale.

Facilitator.

A facilitator is a specialist of sorts. Its often really beneficial for a facilitator to have nothing at all to do with a project. They are the objective individual who facilitates meetings to ensure you and the team are not getting bogged down on things that will unnecessarily delay things.

They will support the Solution Principle, Project Lead and Customer Advocate at various stages through the project such as agenda prep and scheduling internal meetings.

The facilitator is not a dogs body. it is a difficult and respected role that is lacking all to often in and around meetings in general.

Solution Principle.

The principle is often someone senior who will agree and maintain the scope of the work. Often they have been the designing architect of the solution and whilst they should sit outside the project, they are ingrained in the work.

The solution principle need to have a level of authority to ensure the project lead keeps on track. They also needs to be able to keep the project within the agreed scope or make decisions if the scope needs to be changed.

The Solution Principle, doesn't deliver the project work unless there is an absolute necessity. They are their to ensure that the project lead has everything they need to complete their delivery. This might be equipment, team resources such as engineers and specialist, facilitators and the information required to commence work.

Their role is vital however and they must have the discipline, professionalism and courage to address challenging situations, head on.

The Solution Principle reports to the Customer Principle and the Customer Advocate.

Project team - Inside Project

Project Lead

Think of the project lead as the captain or the pack leader. They have the solution to deliver, they know what they need to do. They work on the project tasks and utilise the available resources to see things to completion. Once the project starts. The project lead has the autonomy and control, within the defined remit or scope of the work to make the necessary decisions.

Project members and specialists report to the project lead during the project work. They are not the line manager. I once read - Peter F. Drucker I think, or maybe W. Edwards Deming - and I really like, "You do not manage people, you manage things. You lead people!"

The project lead schedules and adapts work to meet the solution, they enable the resources to achieve the objectives.

The project lead reports to the Solution Principle.

Project Member

Project members are technical people allocated to a project, usually throughout the whole lifecycle, to complete assigned tasks. They are technical people not in the computing sense but in the operational definition in that they are completing tasks as required.

Project members report to the project lead. If their is an issue, they should not try to resolve this, instead they should escalate it to the Project lead, so that they can continue working through the backlog.

Project Specialist

A project specialist usually will join the project to either complete a very particular task or provide a specific piece of supervision, review or advice. In the technology world they could be a security engineer, a cabler or a database engineer.

Mostly advice should happen at pre-sale. it is important to separate out thinking. You shouldn't need to think about your project work, you should deliver it. Thinking should be done before you agree the scope. Otherwise you introduce variation. You might get away with this once in a while. On the whole you will run the risk of either poor quality or poor results.

Specialists tend to only be involved for at a point in time and don't see the project through to the end. Whilst they are working on the project however, they must operate as a team member, participate in stand-ups and complete tasks in an appropriate way. Adaptation of process might be needed in terms of the intricate bits, but the project lead still needs progress reports and an understanding of issues.

Specialists report to the Project Lead.

Customer - Outside of project

Customer Principle

This is the person who has brought about the project work. They have commissioned it, defined the specification (with advice where necessary) and either approved the scope or seen this through within their team.

The customer principle, will be the point of contact and liaise with the customer throughout the project, unless they delegate and communicate those tasks.

Customers do not have to be external. Your colleagues will become your customer if they are asking you to deliver a solution. This is not in the Kum Ba Yah scouting variety it is in the professional sense.

The Customer Principle is in effect the Patron or Commissioner of the work. They do not report to anyone from a delivery perspective, although they may report to their leadership structure.

End customer

In the technology sense the end customer is both the organisation experiencing the change delivered by the solution and also a computer user. it is who the work impacts. If you are completing a profile conversion or replacing an individual workstation, it is the end customer's machine.

The end customer does not report to anyone from a delivery perspective however, they will often report to their own leadership structure and the Customer Principle, should be sufficiently senior to remove any blockages the project team experience with an end customer.