Making the most of your supplier relationship

In business, we all have suppliers. Whether they supply the transport to shift your goods from place to place or supply you with equipment, services or people, we all have them.  Your business relies on these people or organisations, but do we all know how to manage them?  

Supplier or Partner?

Make a decision as early in the relationship as possible, whether you have a supplier / customer relationship or a partnership. A partnership will, like all partnerships, require involvement from both sides but should be a lot more fulfilling. You may be expected to share more about your future plans so that your partner can anticipate your needs and help you deliver.  If your relationship is customer / supplier based it will likely be more transactional and not deliver the same overall value to your organisation. However, each relationship should be evaluated individually.

Set expectations

Once you have decided upon the type of relationship, make it clear at the outset. If you want a partnership and the other party is not ready for that, it’s better to know early. Likewise, if you are just looking for a transactional relationship, but the other party assumes a partnership, that too can get awkward.  Clarity early on saves time and embarrassment later. 

Meetings

This is where any similarity to a personal relationship will probably disappear. To avoid any surprises, it’s best to make sure you have regular, pre-planned meetings with set agendas, as well as informal meetings.  These informal meetings could be phone calls, coffee or whatever suits, but a brief chat about how things are progressing could save a large amount of disappointment or embarrassment later.

Minutes

Ensure that the formal meetings are minuted. I would recommend that the customer minute these meetings so that there is no misunderstanding about actions and timeframes. Of course this will depend on your trust and relationship, but I have seen and experienced meetings where suppliers fail to document some of the more uncomfortable actions so that they get additional time the following month.  Any actions need to be clear, with agreed owners and agreed upon delivery dates. 

It is also vital that minutes are circulated as soon after the meeting as possible, and that the agenda for all meetings includes a review of actions. Otherwise, why bother?

Keep the relationship as intended.

Obviously there may be occasions where a relationship changes from one type to another, and that is fine if both parties agree to it, but when it doesn’t you need to remember to keep things as they are supposed to be.  I would strongly recommend against conducting business when invited to events.  The provision of access to events can sometimes be used to influence decision making within customer / supplier relationships. It is often a different matter with partnerships, as it is in both party’s interest to be open and concentrating on the same outcomes. 

So these pointers may seem overkill but by being clear throughout the relationship it can save those uncomfortable moments where one or both sides have failed to deliver something. However by following these tips, you will likely never need to revert to contract waving or termination.  That rarely adds value for either party.

If you’ve got principles, do you need anything else?

I’ve been working with ITILⓇ since the early 1990’s when I was first introduced to it at F.I. Group and worked my way through the Foundation certificates, ITILv2 Manager’s Certificate, ITILv3 Expert and recently ITIL4 Managing Professional certificate. 

Then, once I became a self-employed consultant, the breadth of my knowledge grew, as I started to absorb other ways of doing things.  About 12 years ago I started to play with COBIT, through 4.1, 5 and now 2019.  Then I started to speak with people who used Lean Six Sigma and learnt a bit about what they do and how they think and work.  I can’t say it made a huge impact on me, but I was aware.

In 2016 I was encouraged to get interested in DevOps and flew to San Francisco for the DevOps Enterprise Summit conference. That was interesting for a few reasons. Firstly, I’d never been surrounded by so many developers before. I also realised that just because they used Ops in the title, it did not mean that they would talk about Ops, although admittedly there were two out of many which did. Those speakers were Mark Imbriaco and Erica Morrison. The conference was also during the 2016 presidential election results, so as you may imagine, that in itself was interesting. 

Through DevOps I started to look at agile ways of working, Lean IT and Kanban.

Due to my interest in all these things and my own inability to remember as much nowadays, I have to keep refreshing myself about all the different versions, frameworks, ways of thinking etc. and that’s because there is so much to learn. If you want to work in a modern organisation, it is expected that you will be across or aware of most of these approaches. You may not need them all, all of the time, and in some roles, you may not need some of them at all, but most modern organisations who have been through some level of digitisation will be using or talking about those approaches.

It’s this interest in all the different ways of thinking and working which has made me realise that we’ve now reached a point where all frameworks or approaches seem to have a set of principles behind them, whether it is the so called dinosaurs of ITIL & COBIT, or the cool kids at the party, DevOps, Lean etc. Agile tries to convince people that it’s cool, but it’s nearly as old as ITIL and Kanban is older than all of them!

So principles. What are they?  Why do we care about them? Why do we need them? What are all of these principles? 

ITIL 

ITIL4, released in 2019, introduced the 7 guiding principles, down from 9 in the Practitioner book. 

These principles are :

• Focus on Value 

• Everything we do, whether it is in IT, teaching, manufacturing, retail, chimney sweeping or any other business, is about value. If we aren’t adding value, why are we doing it?

• Start where you are 

• Don’t reinvent the wheel.  If you are looking to improve something, find out where value isn’t being delivered and start there. You don’t need to start from scratch though.

• Progress iteratively with feedback 

• Make small changes and then ask your stakeholders if it's any better. If not, move on.

• Collaborate & Promote Visibility 

• Work with others and be transparent

• Think and work holistically 

• It’s not just about you or your team. Any change in your processes or ways of working may have an impact on many others, so consider them and the wider organisation.

• Keep it simple and practical

• Let’s not over engineer anything or make it so complicated that people now or in the future haven’t got a clue what it means.

• Optimise and Automate  

• Improve improve improve and then if there is value and you believe you have the improvements optimised, automate it.  This could be scripts, SM tool portals or a wide range of options. 

COBIT 2019

Then we have COBIT 2019.

• ​Provide Stakeholder Value

• Holistic Approach

• Dynamic Governance System

• Governance Distinct from Management

• Tailored to Enterprise Needs

• End-to-End Governance System

COBIT 2019 has basically stuck to it’s guns and been fairly stable, although it has made a few minor tweaks from COBIT5.  Many of its principles link in with those from ITIL4 and are also reflective of the DevOps principles.

They are very formal but clear: deliver value, think end to end & focus on a dynamic governance system as well as management.  This is pleasingly what you expect from COBIT.   

Agile

Now agile, which has its roots in the early 1990s with approaches like RAD in 1991, Unified Process & DSDM in 1994 as well as Scrum from 1995 is probably best known for it use mostly in the development world, but there’s plenty of other uses and flavours out there, with agile project management, agile managing & agile parenting courtesy of Rob England and Dr Cherry Vu at Teal Unicorn, and many other varieties of agility in the workplace.  

You can see their principles here:

• Customer Satisfaction

• Welcome Change

• Deliver Frequently

• Working Together

• Motivated Team

• Face to Face

• Working Software

• Constant Pace

• Good Design

• Simplicity

• Self Organisation

• Reflect & Adjust

Fundamentally, it's about satisfied customers, welcoming change, working together, delivering frequently at a constant pace, talking to others, being motivated, self organising and adjust when you need to. 

Kanban

Then we have Kanban which came about in the 1940’s or 50s at Toyota in Japan, with the intention of reducing stockpiles of material and to limit production to demand.

The 5 key principles of Kanban which have now been arrived at are:

• Limit Work in Progress 

• focus your efforts on fewer things at a time to ensure a faster flow of deliverables. You can’t work on lots of things at the same time, so don’t try.

• Make Process Policies Explicit

• Build your standards into the way you do your work rather than bury them in documents. Make doing the right thing obvious and easy.

• Visualise the workflow 

• Make your up to date work and workflow visible to the team and stakeholders at all times

• Improve collaboratively 

• Work together to improve continuously with a focus on results as a team rather than individuals.

• Manage Flow 

• Use your board and the data it generates to identify and iteratively remove blockers to work flowing smoothly through the system

DevOps

The principles of DevOps are lovingly referred to as CALMS or CLAMS if you prefer kaimoana.

CALMS for those of you who may not be aware stands for 

• Culture, 

• Automation, 

• Lean, 

• Measurement and 

• Sharing. 

Culture

Getting the culture right is hard.  Most people reading this are probably working and breathing within the IT Operations sphere of an IT department. Or connected to it.

IT Ops people, generally don’t like change. We are designed to keep things steady; keep the lights on. It’s what we have learned over 5, 10, 20 years of Ops work. If things are changing, it’s the Operations person who gets the call at 2am and has to fix the server, network or whatever is broken. 

Ops are risk averse.  So you need to create an environment where they feel safe and can experiment.  

It’s all about creating a safe environment where they can not be blamed. Too many CIOs still blame IT Ops as a team or individuals when something fails. If that happens, then you are never going to get people who want to try new things or better ways of doing things.  

Start at the top.  

Automation

So many DevOps conferences, presentations, articles etc talk about tools.  If you are an IT Operations team keen to use the DevOps principles to improve the way you are working, it doesn’t need to be a massive spending spree.

Monitor everything that you can. There are some great free tools and some great cheap tools which will help you get started. Hard to believe maybe, but there are organisations out there who don’t monitor servers - capacity or availability, networks, applications.  Learn what is happening. Alert when it is sensible to alert. Keep fine tuning.  If you don’t know what is happening, you can’t improve it.  

As you learn what needs to be done, to fix issues, look into what can be done to stop those issues. Most tools allow you to script auto-actions before alerting, so look into that. 

Do you have to perform the same task day in day out? Try and script it. If you can’t do it, get a contractor in for a few weeks to do it.  Work out what you need doing and get the contractor to script it for you.  A few days of a contractor will save you weeks or months of work redoing tasks or reacting to alerts. 

Lean

Lean is all about 

• Identifying value, 

• mapping the value stream, 

• creating flow, 

• pulling work and 

• striving for perfection. 

Note, this perfection is primarily to ensure that in your workstream you don’t pass errors to others in the flow. That creates rework and is waste.  

Lean is all about reducing waste. Don’t do the stuff that doesn’t need doing. 

So if we imagine a new member of staff is being on-boarded. The new person will be adding value to the organisation (identify value). The Value Stream will list all the teams involved in onboarding, their tasks and how much effort they need to put in. The flow of work is understood. 

Now let’s imagine that HR makes a simple spelling mistake in the individual’s last name - got the i and e the wrong way round - which is easily done when humans are involved.  

The new starter goes to get their id badge, but the name is spelt wrong. No biggie, but the badge needs to be redone. Then they sit down and their AD account is wrong because IT had the wrong spelling. Again, no biggie but that and their email address need to be changed. Then payroll ask the person to fill in an online form. Guess what..they have the wrong spelling, so the bank won’t recognise the person. More rework.  None of it may be big, but it all adds up. 

So just like most things in IT, baseline where you are. If you think you can speed up the time it takes to provision a new starter, understand how long it takes now. How often does the requester come back with “Very nice, but it doesn’t have this installed”  or “We requested a new user be set up with a laptop, but they don’t have the right software or access to the right groups in AD”. Measure this as a baseline and then try to improve it.  What are the new measurements? Have things improved - whether time to deploy or perceived satisfaction? 

Then you will know whether you are improving. If you aren’t why not? Can you improve on it further? Should you undo what you have done and try something else? 

Sharing

Another key tenet of DevOps is the sharing of knowledge, information and capabilities. 

Share knowledge of systems with colleagues, to reduce the risk to the business if you aren’t there. Give yourself a break from being called during the night or holidays. Heroes are not the ones who get woken up at 2 am to fix an issue that nobody else knows about. Heroes are the ones who share knowledge and skills so that they DON’T get called up on holiday. Start to embed that in the culture. 

Share capabilities with others. Fed up of getting calls for simple tasks? Show the Service Desk how to do it. If they don’t have permissions, script it so they don’t need the permissions.  

Shift Left

So for example, Change Management people could share what they are looking for in a Change, so that everyone knows what is needed before the change is reviewed.  

Sys. admins could provide developers or projects with their non-functional requirements at the start of a piece of work, so it doesn’t have to be rejected at time for support.  

If you can give others further left in the flow (remember that?) the information they need to give you what you need, then does it need to go to CAB? Could it just be a tick box and implemented? 

There’s a multitude of areas where knowledge, skills, capabilities, requirements etc can be shared with others to enable value and to deliver that value to the wider business.  The more that is kept in silos or individual heads, the slower everything becomes. 

You won’t lose your job if you share knowledge. You might, if you don’t. If you can share everything you know and do, the chances are you will get more opportunities in exciting areas. 

Shared Principles

So, we have all these approaches and ways or working, but I think we can extract the following 6 key shared principles to help us on a day to day basis

• Identify & deliver value - have satisfied customers.

• Understand how work flows and collaborate with customers and colleagues

• Keep improving how we work so we don’t stagnate. 

• Build and maintain a culture which welcomes change, collaboration and the sharing of knowledge, skills and information. One which embraces no blame and experimentation

• Always think end to end. Get rid of silo thinking

• And Keep it Simple! 

So there are many different frameworks, approaches and ways of working out there which help us work smarter.

And I’m not suggesting that you shouldn't learn them. If there is value to you or your job in learning them, get out there, read books, do courses, become certified.  But do you NEED to?

I think there are only 6 key things you need to remember, to be able to work effectively and efficiently in most roles.

Thoughts?