Powered by Squarespace

Digital doesn't have to be difficult

So what is digital? Is it IT? Shiny new technology? No, digital is “the application of information, communications and technology to raise human performance. Changing what people do in ways that enhance their ability to achieve their goals. More than a set of technologies, it is the abilities those technologies create.”

So forget about the tech for a minute and think about what could be.
  1. Start with why. What’s the point really? Why do you want to do this? Efficiency, growth, innovation?  What will make that happen? A new website for educating an audience about your subject area or better direct interaction, a database for managing engagement and relationships and tracking outcomes or equipment and tools to make you more productive? Be very clear about the goal and the point behind it all. Is it worth the time and the money? Would you spend your own money on it (remember, grant funding has come from somewhere, it didn’t grow on trees).
  2. Know what you need. I mean really know. Start from the user perspective – talk to them about what they need and want, create user journeys (how people act and interact), imagine what could be (not just what is and always has been). Don’t assume someone just knows (especially it that someone is the boss). Craft your user journeys (how people act or might act) by talking to users, develop your requirements specification (what the tool is ‘required’ to do, functionally and technically), work out what skills, expertise and support you’ll need, what things you will need to do differently (doing things better or doing better things). Digital offers a lot of potential but best to change your processes first than fit shiny new tyres to a clapped out old car. Choose your technology and suppliers carefully – cultural fit matters but don’t exchange competence for ‘nice to work with’. Spend money getting it right first time, or waste money getting it wrong and learning from your mistakes.
  3. Make a plan. If you don’t know where you’re going and how, then how do you intend to get there? Technology can be unforgiving (and expensive to reverse), you can trial and test but that’s not an excuse for making it up as you go along. Have a destination, staging points and outline timetable, a means to evaluate success or failure and a group of people to assess whether it’s worked. You wouldn’t run your organisation by the seat of your pants would you?
  4. Appreciate change. Be aware of the Change Curve and its implications. However well you prepare and plan, you need to take people through the phases, through the disbelief, the frustration of the new (which may be more painful than the frustration of the old), the pit when things can’t get worse, the experimentation when they get better and finally acceptance and commitment. Lead the change and ride the curve – don’t just be a victim of the rollercoaster. Use your plan to help show where you should be. 
  5. Drive through better. Your ‘why’ and ‘plan’ define the map. Keep your destination clear and focused, know what success looks like and keep going. Make sure someone is driving the project and can get it to its conclusion. Mind-set and attitude matter – don’t give up, this won’t be easy. Never let anyone say “I don’t understand technology”.
  6. Make sustainability a forethought not an afterthought. How will you sustain your (funder’s and own) investment? Commit time, money (where necessary), headspace -think this through. Many great projects fail because of a lack of sustainability. Don’t start what you can’t finish – the ‘end’ of a digital project is two or three years after you’ve started to use it. Projects need time to mature.
  7. Don’t try and do it alone. Find buddies (they might be other CEOs and managers, consultants, similar minded people in your own organisation, even ‘techies’ – paid or volunteers). Plan for help and support and take it. There will be dark days and complications and you’ll need a friendly face and a helping hand (or two).
As they said on Crimewatch, don’t have nightmares. But do think this all the way through – you’re much more likely to be successful (and to get funded).

Digital defiance - why people must stop saying I can't do that and learn how

 “It's time to get with the Program. Not knowing about IT could cost you the biggest opportunity of your working life.”

Language is powerful. The words we use influence our ability and our motivation and as a consequence our actions.  To quote Aristotle, “We are what we repeatedly do. Excellence then is not an act, but a habit.” Saying “I can't” all the time or “I don't know” becomes a self-fulfilling prophecy and there are few more dangerous areas to do this than IT and ‘digital’.

As individuals, the biggest leaps in your capability were as infants learning to walk and learning to talk. If you underestimate the amount of effort, character and support those learnings required then ask a stroke victim (or anyone who has suffered a severe brain injury). They will remind you just how hard it is to relearn what we take for granted.

IT, digital or whatever you want to call it isn't difficult. It’s not the domain of the ‘young uns’. There’s growing evidence that the story of the digital native (those born and living solely within the era of smart technology) is somewhat of a myth. Everyone learns, grows in confidence and skills, and becomes more natural – providing they focus and apply themselves.

No one expects you to know everything about IT (or everything about anything else for that matter). Yes, you need to learn (and to be a little selective about what you focus on) but stop saying you're stupid or ignorant about IT. It's not big or clever and it's not a legitimate excuse anymore. You may think you have bigger priorities but you're running out of excuses. Every time you say “I can’t” or “I’m stupid when it comes to IT”, your brain reinforces that and the power of neuroscience makes you that bit more stupid and incapable. Guess where that ends?

Getting someone to book your travel or manage your diary may be acceptable for an exec. Inability to fill in a form on a website or enter or retrieve information from a basic database isn't. Dismissing your IT infrastructure (or email server) as ‘the boxes in the corner’ is a concern. Not all systems are designed as well as they should be and for sure, many techs don't explain things well but this isn’t a world you can avoid. The dinosaurs died out because they didn’t adapt and there is a whole cohort of senior leaders heading the same way. Start with a purpose and learn. Take wise counsel. But stop burying your head in the sand and pretending it will all go away because it won’t. And let’s be honest, in most cases, you are not as stupid at IT as you are pretending so why keep pretending? Confidence? Disillusionment? Apathy?

CEOs and other leaders don't know, or need to know, the fine detail of what goes on under the bonnet of Internet security (or even their email servers). Yet they need to know the key risks and how they affect their organisation because it’s the CEO (or even Secretary of State) in the firing line when crises happens and because the consequences can be devastating. As more and more systems, organisations and government become ‘digital by default’, we need everyone to learn more than the location of the ‘off’ button and the phone number of the nearest geek and take responsibility. Gone is the world where we could afford to palm things off on others, for them to do all we couldn’t be bothered to learn and pretended didn’t matter.

Inability to read the bottom line of your accounts before you go bust will get you fired (from a job) or evicted (for not paying your rent or mortgage). Tragically, the inability to engage in the basics of IT is still worn as a badge of honour. If you call yourself a leader or a professional then stop talking yourself down and up your game. It’s your language letting you down as much as your tech skills. The latter will take time, the former you can fix today and get your team and colleagues to hold you accountable to.

For those who remain digitally defiant, the next ten years will look more and more unpleasant for you and you'll continue to do a disservice to the people you lead and everyone around you. It’s time to stop, look around and smell the coffee.

A trustee perspective on social media

What if you had another easy way to listen in on the performance of your charity, understand key stakeholders, raise awareness and manage reputation? Well, the tools are literally at your fingertips through social media.



But I only wanted a database? It’s a bit more complicated than that…

Be careful what you ask for. The prescription might be more than you anticipated.

"Good morning, I would like a database please! And can I have it to take away as I'm in rather a hurry."
“Very well Sir. Our takeaway databases come in 3 sizes: 
Ultimately frustrating, 
Soon to be chaotic, Complete and utter disaster....”

The means to justify the ends
Does your organisational report card read like this?

“Works hard, lacks focus, can't demonstrate progress.”

Do you remember the days when you could buy a database off the shelf and all you needed to worry about was whether it differentiated home and work phone numbers?

In these days of increasing transparency, performance management, complex stakeholder relationships and on demand reporting, your data needs far more TLC (tender loving care – you don’t see that in a data dictionary very often). To give it that TLC, data needs a good home and that home is your database. 

“Now sir. What's your data for?”
“I don't know, I just collect it....”

If only there was a better way… Well there is, but be careful what you wish for...

The ingredients of a good database (and how to make it come to pass)
Business analysis and process re-engineering – the secret to a successful database lies with a good business analysis. Mapping and then optimising processes, understanding why you do what you do and whether it’s the right thing to do and the right way to do it. Too often rushed, this is the firm foundation to your project. Dig deep and understand the basic pathways of how you use data to reach decisions and be a better organisation.

Planning – a database will take time, capacity and commitment. So you need to plan. Decide who will lead, what external support you need and who else does what. Create deadlines, a project schedule of what gets done when and by who. Fail to plan and you plan to fail they say. They’re right. You really can’t wing this unless you want the project to run on for years. 

Data model and information architecture – what are you collecting, why are you collecting it, how does each piece/set of data relate to each other, what do you want to get out at the end of the day/month/year. Think of this as optimising data collection (inputs), data management (what you do with it) and reporting (outputs). The latter will undoubtedly be streamlined and made easier and yes, you are going to have to review those forms you’ve been using for the last ten years and work out exactly why you ask that question in box 23. After all, you don’t want all your data disappearing into a black hole.
Technical requirements – variously called technical specification, functional specification, requirements analysis. It’s what the system must do – specifying the technical detail of the tool and the functional operation. A set of functions and characteristics of the technology which supports you to record data, store it, process it and re-purpose it. Make sure your requirements are SMART and especially specific. After all, without this how does your supplier or developer know what you want (slap on the wrist for anyone who says “because I mentioned it in a meeting three months ago”)? How do you measure the success of the system against its intended success criteria? How do you know you got what you paid for? What do you mean, you don’t do that?

Cleaning data – oh the drama! Do we really have six different phone numbers, four email addresses and three house addresses for Mrs Miggins? Which is our most up to date? Is Mrs Miggins the same as Ms Miggins or Mrs Miggggins? You’re going to have to tidy up and clean your data before it goes into your new system otherwise you’ll just pollute the shiny new tool. No, the database won’t do it for you. You put garbage in, you get shinier garbage out but it’s still garbage. This will undoubtedly take a lot longer than you expect so start early and be conscientious. Don’t just dump it on a junior who can’t say no.

Integration with other technology – “So they fill in a form on our website, it gets emailed to the admin team who print it out and type it into an Excel spreadsheet. Then they email it around the organisation at the end of the week.” Oh. My. (Substitute relevant exclamation/deity here!) Now you should have picked this up in Business Analysis whilst you were optimising processes but if not now is the time to make sure your database integrates with other tools and the requirements of how you operate. With communication tools (bulk email, texting), with your website, for remote access, for security purposes. After all, you wouldn’t drive a Ferrari down a farm track towing a caravan – yes, that is an analogy for how your systems talk to (or rather ignore) each other. 

The change project – “They all said they want it so it will just work.” Oh no it won’t. “It’s much better than the last one we had.” It still needs to be managed. A database project is a change project. You need to engage users, to carry out a well planned and deliberate and effective implementation, to manage the transition. You need to address the three areas of emotional drivers, intellectual (rational) drivers and showing the way (ideally in baby steps). There’s a reason the ‘Change Curve’ mirrors the ‘Seven Stages of Grief’. Fail to plan and manage change and you’ll fall headlong down that curve and stay at the bottom. Plenty of database projects end in grief.

Training – “But everything’s intuitive these days!” Not quite. Your database is (I hope) a powerful tool. It has the capability to do great things with data (reducing those 2 to 3 days a month your admin person spent pulling together the management report). It needs to be used correctly and that requires training. Everyone will need to learn the right way to use it and how to use it well - effectively and efficiently - otherwise they will start to hate it. Then they will start to hate you. Then they will stop being effective at anything. See also ‘Death Spiral of Organisations – Going Bust Quickly But Not Quietly’. 

Testing – “But it should just work.” Yes, and the sun should shine in Summer but some of us carry an umbrella just in case. You will have customised the system for you. Your organisation will have very specific ways of working. Your data will have been imported into its new home. You need to check this all works the way it was intended to work before letting too many users on it and finding it’s broken (only a bit broken but still broken). Testing comes in two flavours: system admin testing (the geeks who try to break it early) and user acceptance testing (a select group of staff who follow a test script to prove it works and then spend a bit more time messing with it trying to prove it doesn’t). If it passes the test then you can let it off its leash. If it doesn’t then fix it and test again. Rinse, repeat. 

With ongoing support – The most excellently planned, brilliantly implemented database project (you did do everything I recommended above didn’t you?) is destined for failure without ongoing support. You need commitment from the organisational leaders, someone to do things and a reasonable ‘guard dog’ to make sure commitments and accountabilities are upheld. Decide where you need expert help and get it. Remember, a database is for several years not just the backend of this financial year. Like Peter the Polar Bear, if you don’t look after your environment you get diminishing returns.

A good reason – well, yes, hopefully you had a good reason before you started. This is the foundation of the database – why you need one. A database should be ‘purpose driven’ not knee jerk. It should meet specific needs. It should, in and of itself when well used, be worthy of outcomes. Buying one in a hurry to empty the budget before the end of the financial year is the action of a fool. You wouldn’t do that, would you?

– oh the rules and regulations. Databases are a real opportunity for bureaucrats and detail obsessed administrators. Can’t live with them? You certainly can’t live without them! Keep it light touch. Set principles and intended outcomes alongside some specific rules and protocols. It’s important that you have a standard naming convention for e.g.  ‘University of’ but remember that the more rules you have, the more joy your users will take in ignoring them or breaking them. And don’t forget that data protection, privacy and security impose certain legal responsibilities.

Establish new ways of working – heard the one about the new database that was implemented on top of the old processes? Of course you have. You need to make the database relevant to users but relevant to the ‘new world’ not what you used to do because it was comfortable. Some things may be harder and more time consuming but there will be clear business benefits for a large proportion of staff (if not, you got something badly wrong in the analysis at the beginning). 

In summary, you only need to worry about five things in a database project:
  • People – the who
  • Technology – the what
  • Processes – the how
  • Data – another what
  • Change – another how
Seriously, how hard can it be? Anyone would think you needed help and a consultant… 

Dr Simon Davey is available to help negotiate leaders and organisations through the seven stages of grief - I mean change - and to provide counselling for those who messed up the first time.



Why rescuing is wrong, yet profitable and why we do it

It’s time to stop the rescue act.
What is the role of a consultant and where do the boundaries lie? What does the drama triangle have to teach us about better client relationships and better outcomes?

Introducing the drama triangle

The drama triangle is a psychological and social model of human interaction about three roles – Victim, Rescuer and Persecutor. It suggests that we often play one of these three roles in situations with others.
The Rescuer is not someone helping out in an emergency – rather they have a mixed or covert motive and benefit egoically in some way from being the one who rescues. They have a surface motive for resolving the problem but also a hidden motive often focused on their own self-esteem or on enjoying others’ dependency and at a deeper level play on the Victim in order to continue getting their payoff.

As Claude Steiner put it, “The Victim is not really as helpless as he feels, the Rescuer is not really helping and the Persecutor does not really have a valid complaint.”

These situations can play out when one person takes on a role as Victim or Persecutor and the two (or more) players than move around the three roles of the triangle. So the Victim might turn on the Rescuer who switches to persecuting.

The covert purpose for each ‘player’ is the meeting of unspoken/unconscious psychological needs without having to acknowledge the broader harm done. Each player acts on their own selfish needs rather than in a genuinely responsible or altruistic manner. Relationships between the Victim and the Rescuer can grow into co-dependency.  

But what does this have to do with consultancy and the where is the ethical dimension?

The need to challenge not just fix the stated problem

I pride myself on being challenging - note challenging rather than difficult. I do like to get to the end of an assignment, leave on good terms, get paid and I count it as a mark of success that I do get follow up work and referrals from clients. 

Like any good consultant I dig underneath the veneer of the assignment to find out what the real issue is. It requires a thick skin, particularly in technology related projects when the client can demand you focus on the technology element when it is often leadership and change issues which are behind the problem. Sometimes this can result in overstepping the boundaries but why do we allow these boundaries to be created in the first place – whose interests do they really serve? Do we allow the client to fulfil either Persecutor or Victim roles? Are they ‘rescuing’ us as consultants by giving us work?

I have always believed in following the spirit, rather than simply the letter of the assignment. I believe it is my responsibility to support the ‘end goal’ rather than look the other way (something of an issue with Enron’s auditors if I remember rightly). 

Consultancy can become formulaic, about using toolkit X with a standard sized team of Y to achieve outcome Z. It can be about covering people’s backs rather than deriving real value and beneficial outcomes for the client. It can be about not rocking the boat in case you lose the work. Hell, it’s only work!

Permission is an issue. If you are commissioned to do ABC, is it ethical to question that and deviate from it once the assignment is underway? In my experience, consultancy is too often used to prove a specific point, in someone’s specific interest and it’s only once you have dug under the bonnet that you start to see the real implications. You can’t know all the questions at the start of the assignment. When you are a ‘trusted advisor’ it’s easier to have the more difficult discussions but shouldn’t we question everything regardless? Or are we just highly paid lapdogs doing the client’s bidding in the interests of a good financial return? Is there a co-dependency here where if we do exactly what the client wants we will get more work? 

The need to ask very difficult questions

No one enters the consultancy profession to be popular. I believe it’s our duty to dig deep, to take risks, to benefit the organisation as a whole (or its stated mission in the case of a non-profit). Anything else puts us into the ‘Rescuer’ role. The Victim (client) shouts ‘help me’ and we, as Rescuer, do their bidding to feel good.

There is a parallel here with Education. Increasingly teachers are under pressure to get their students through assignments and exams. Increasingly students are finding the challenge difficult and rather than sit with that difficulty, there is a growing tendency for the teacher to step in and ‘rescue’ the student. The end result is simple – the challenge and growth are denied. There is no sustainable improvement. There is only a good result in the immediate term. Students like it – they get to keep winning at the game for as long as possible without pain. Teachers like it – they also win at the game and feel good (sometimes addictively so) by solving the students problems for them. However, in the long game, no one wins. At some point the student’s weaknesses and flaws are revealed. Your parents were right – it’s not good for you in the long run if someone else does your homework.

And so it is with consultancy. Sometimes there are problems which are urgent and need a fix. The situation is critical and the role of the consultant is to provide emergency expertise and experience. Yet, these assignments are arguably still relatively rare.

Too many times we are commissioned to ‘fix’ something. To put a sticking plaster solution on a problem which suits key individuals but may not be of long term benefit to either the organisation or its objectives. We (or our companies) earn well. But where is the sustainable solution? Where is the client growth? Where is the real benefit?

I believe the first role of a consultant is to put themselves out of future work with a client. That is my ethical starting point. I want to offer expertise and experience of value, to make a significant difference, to resolve what needs resolving. It’s not my goal to derive a long term, ongoing paycheque. I think that’s called a job rather than an assignment. 

It’s easy to be a rescuer. It feels good. You can earn well from it. But is it right? Is it ethical? Does it deliver a sustainable benefit for the client? 

Surely making victims of our client base isn’t a good thing in the long run… At least not for them.