Resistance is useful

Many words have been written on the subject of ‘overcoming’ and ‘dealing with’ resistance to change.  Much of the literature takes the view that change is good and resistance to change is bad (Huy and Mintzberg, 2003), with those who resist change being described in a way that suggests they are self-serving or dysfunctional (Huy at al, 2014).  But perhaps we should take a different perspective on resistance to change?  Rather than treating it as a problem to be solved (by fair means or foul), maybe we should instead welcome it as a blessing in disguise?  Perhaps those who are brave enough to speak up and challenge the groupthink should be respected and listened to rather than being manipulated or ignored?  In this article I want to argue that resistance to change is a useful –  sometimes essential –  part of achieving the best possible outcomes for an organisation.  Useful because the challenges being levelled against the change are a fantastic opportunity to further inform and validate what is being proposed, both in terms of the change outcome and in terms of the approach to implementation.  Only when all possible inputs are received into the change process can you be confident that the best outcomes will be achieved; and that is what resistance to change really is – a part of all the required inputs.
Read more

Culture change

I want to talk about the risks and rewards of attempting culture change in an organisation.  Culture change is arguably the most powerful tool for transforming businesses, but it is also one of the least well understood.  Without it, many well documented company turnarounds would not have happened (eg the transformation of Marks & Spencer under Stuart Rose).  Of all the varieties of business change, it is culture change that delivers the most important outcomes.  However, it can be the riskiest and most demanding type of change – and if done badly it can make things worse. 
Read more

Commit to the sprint

‘Commit to the sprint’ is Scrum’s secret weapon.  I know that many other aspects of Scrum are powerful, but my own experience as a COO / CIO is that without full commitment to producing a ‘potential shippable product’ at the end of every sprint you just have a less controlled version of what you had before you used Scrum.  To commit to the sprint is to focus on the only thing that matters – delivery of working software on a predefined date.  It removes any temptation to focus on non-value adding activities such as producing project artefacts ( and puts the focus and effort where it belongs – on producing software that can be used by customers. Read more

No such thing as BAU

I don’t believe in the existence of ‘business as usual’ (BAU), any more than I believe in the existence of (spoiler alert) Santa Claus.  I especially don’t believe in it when the phrase is used to delineate a certain sort of organisational activity from ‘business change’.  No organisation is providing the same services with the same products using the same processes delivered by the same people to the same customers as five years ago.  That applies whether your organisation is a major religion, a derivatives exchange, or a football club.  In fact, they are not doing that compared to a year ago – but if they are, then they are in danger of losing the confidence of customers, whose needs and expectations are always evolving.  I know I have used the phrase ‘BAU’ as a form of lazy shorthand for business operations in the past, but I am going to stop doing so with immediate effect.  I should know better.  ‘BAU’ sets in stone a major piece of faulty logic that can be dangerous when it translates into things like organisational design and how change is perceived and managed.

My experience tells me that all organisations are changing all the time, through necessity and through ambition.
Read more

We are all ‘the business’

I’ve been listening to people in IT departments use the phrase ‘the business’ for many years.  Though I can understand why people use it, I confess it is a pet hate of mine.  At a couple of recent business technology conferences, I heard it so often (and never in a positive context) that I felt compelled to write this article.  What I will do (briefly!) is describe what I have done in the past to address the unhelpful beliefs, attitudes and behaviours that I have found to be hiding behind the phrase.  Hopefully some of my experiences will give you food for thought.

Whenever I hear ‘the business’ as a starter, I know I have to brace myself for
Read more

why repeat the mistakes of the past?

A software developer told me recently that she and her fellow developers hadn’t been involved in the start or end of a project for years.  This was a bit of a shock, and seemed rather sad.  Did she really have no involvement in what was to be built and why?  No contact with customers in starting something, or getting their feedback once it was delivered?  The answers were ‘no’ as her organisation (a large financial services company) had divided the lifecycle up into discrete stages that were completed by separate teams with ostensibly different skills (business analysts, architects, developers, testers etc), all housed in separate departments.  Project managers controlled the overall process. How anyone other than the project managers was supposed to feel genuine responsibility for the product, outcome, or customer was beyond me.
Read more

why projects fail (part 3): death by documentation

Two of the biggest project failures I have seen had also produced the most documentation I have seen. I don’t think it was a coincidence.  I’m not arguing for a direct causal link between project failure and volume of documentation, but I am arguing that a mindset that focuses on recording everything to the nth degree is not a mindset that is focused on achieving business outcomes.  In this article I want to suggest how to strike the right balance between artifacts and outcomes.
Read more

why projects fail (part 2): business readiness

My article last year on ‘Why Projects Fail’ referred to projects that were ill conceived, poorly defined, lacking in customer need, had vague or unreliable sponsorship, and needed stronger governance.  In this article I touch on one of the other reasons why projects fail – namely business readiness (lack thereof).
Read more

systems development is not a commodity

An article in one of the broadsheet business sections argued recently that computer programming could be done perfectly well by “highly skilled and cheap developers in the Far East”.  In effect, the author was arguing that is what people should be doing.  Though the statement is not completely wrong (some outsource providers do great work), it is the underlying assumption that is wrong; ie that systems development is now commoditised and should be bought on price as quality is universal.  My own experience tells me that:
Read more

Customer Before Process

I hope I can be forgiven a little anecdote about my private life in this article, which does quickly turn to the subject of business.  I recently had knee surgery to remove the broken bits caused by my years of competing at weightlifting and powerlifting (they give you a voucher for surgery with every trophy in those sports…). At the pre-op assessment they threatened to bump me to the bottom of the waiting list if I refused to confirm what had been entered onto their computer system – ie surgery was taking place on the left knee.  I couldn’t do that as it was the right knee that was broken, and in the end I had to contact the surgeon to pull rank… 
Read more


About Me

Cliff Moyce

I am a management consultant, board advisor and interim director specialising in business transformation. I have a life long passion for business change, and like to write about it here. Please feel free to get in touch with me at

LinkedIn Profile

Subscribe To My Blog