by Darren Lynch
01 October 2020
5 mins read
In this blog post, I will be discussing delivery teams’ use of methodologies and frameworks, and how they use terminology.
It should be noted I am no expert when it comes to all of the ways of working that are out there. My opinion on this broad subject shifts like the sands, as I use and adapt the skills and experience I have gained within the programmes of work I am delivering.
A few weeks ago I posed the question on Linkedin, “Do delivery teams use methodologies & frameworks correctly” and the results were:
Yes – 8%
No – 31%
Dependant on the project – 61%
The results are interesting. You would think delivery teams would be using methodologies and frameworks correctly; shouldn’t they?
After all, they are the ones that have gained experience, knowledge, education and proven that their skills are what is needed.
They are supposed to be the EXPERTS delivering to the client what the client wants, or more importantly, needs.
However, having spoken to a few colleagues and asked for their opinion, it seems these results are a true reflection on how delivery teams have used methodologies and frameworks, in most of the environments they have worked in.
The methodology or frameworks they use will depend on the business, programme or project they are engaged in. It will depend on the skills and knowledge of the teams within those environments. Knowing a lot of the time the team put in place to deliver the outcome are not the right people in the right roles. Then, stick in the problem of not having the right tools to administer and manage the methods or frameworks they decide to operate in.
“Everyone is potentially a Project Manager, especially in the Public Sector.
Whereas, in reality, pretty much everyone identified to run projects of any magnitude against the public purse, is usually the wrong person for the role.
The limitations are often down to funding, budget or availability of resources you believe are underutilised.
It’s them, or no one.
So what tends to happen, is that organisations send an admin grade employee on a PRINCE2 course. To bolster their ability to deliver the hospital pass of a project that you have assigned them.
If you have ever done this, then shame on you!
An inch thick textbook doesn’t make a good project manager.
What you need is someone with a love for detail, the ability to document pretty much everything; a genuine stayer.
That’s the key. You are looking for someone who can explain where you are on a timeline, where the likely bumps in the road are, and what decision-makers need to do to support the team around them entirely. You don’t get that from the answers to a multiple-choice ‘quiz’.”
“PRINCE2 doesn’t claim to make people Project Managers, but teaches a particular framework. But people genuinely go on a PRINCE2 course expecting to come back trained as a PM.”
Image: Agile Umbrella https://deepgnosis.me/agile-an-umbrella-view/
Take a look at the agile umbrella and every framework that sits underneath it (illustration above). In my most recent experience, the agile approach is what every programme of work or project wants to take in order to deliver their required outcomes.
The word agile is banded around like it is a badge of honour and teams all say we are agile without actually knowing what it means to be agile.
Often not knowing what approach to agile they are taking or going to take.
They will start to use terminology from within one or more of the frameworks under the agile umbrella, in the belief they are now ‘Agile’. But it is most likely they are miss-using the terminology, as well as miss-using the frameworks themselves. Remember ‘having standups’ does not mean you are agile, and certainly doesn’t mean that you are following ‘Scrum’.
Another colleague at Difrent pointed out:
“…it’s better to have the right mindset and misuse the terminology, than the other way round. Unfortunately, most orgs say they are agile, send people off on courses from Scrum Alliance etc, and then when they come back, shoehorn them into a PRINCE2/MSP world”.
Then try introducing ITIL into the mix.
If you want to see several eyes roll into the back of their sockets, bring a group of so-called agile, fast-paced thinkers into a room and then explain how you are going to implement an ITIL framework going forward.
We’ve all been there. Someone is critical of the way service management is working. The services are undocumented. The process to understand progress is overly complicated. There is a bit of training budget to spend, and someone on your team is a massive fan of acronyms.
ITIL isn’t bad. It just has a bad reputation. Which unfortunately means, those with the coloured badges to show their proficiency, are not always the right people to convert the rest of us. You are ITIL or you are AWOL when those meetings are taking place.
Having a load of people with v4 ITIL Foundation is not enough. You need the adoption of ITIL from the top-down, and from people who have the right experience ITSM to start with.
The real issues with methodologies and frameworks are that you have to believe in them honestly. You have to buy into it from the start, or otherwise, you’re not going to pass the course.
The focus will be on getting the terminology right and not delivering the right outcomes. The team will produce the wrong documentation at the wrong time.
Which means you are then in too deep. You are past the point where you can’t see the faults in the methodology or frameworks you love so much. The cultish, almost slavish devotion to the diagram on page 666 of your textbook, means that you will never admit that there is a better way of working.
The courses (and badges/certs/post-nominals) that come with them, are never enough. The people have to have the core attributes of the role within them before they learn the framework/technique.
I have mentioned just a few of the methodologies and frameworks that are out there in this blog. There are more, so remember there are many ways of skinning a cat. Your programme or project has to start somewhere. I have no hints or tips for this blog as any hints or tips I would give would have to be method or framework-specific.
The decision on which methodology or framework the delivery team will use is almost always thrust upon them from above. So next time someone introduces you to a new way of delivering outcomes, designing patterns or understanding strategic intent – ask yourself – is this a fight I want for the next five years of my working life? Is this the programme of work or project for me?
I would like to thank my colleagues, Kirk Bedford and Chris King, for their input into this blog.
If you have any thoughts or questions for the Difrent team please feel free to contact us on the details below.
Written by Darren Lynch – Business Change Manager @ Difrent
Receive the latest and greatest insights on digital transformation and service delivery, fresh from our newsletter.