Culture change (part 2)

In my previous article on culture change I argued that having a culture that is fit for purpose is critical to the success of any organisation.  I also described some textbook organisation culture types (eg power culture, role culture, task culture etc).  In this article I want to consider how to go about changing culture at work.
Read more

Culture change (part 1)

Culture change is arguably the most powerful tool in business transformation.  Without it, many well documented turnarounds would not have happened (eg Marks & Spencer under Stuart Rose).  Despite the fluffy name, culture change has been described as a ‘brutal’ process (Burnes, 2009).  Brutal, because if you accept that culture is embodied in the values, beliefs and behaviours of the individuals in an organisation then you also accept that not everyone will fit in the new culture.  Culture change almost always results in some people leaving and new people coming in who better embody the new culture.  It would be highly desirable for all of the extant personnel to adopt and embody the new culture – but it happens rarely.  And this is for a good reason – when culture change is the solution to your problems then culture was almost certainly a problem to start with (and culture is people). 
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 and non-executive director specialising in business transformation. I guide company boards on all aspects of business strategy, market positioning, client engagement, operational delivery, systems development, project management, outsourcing, and people development. I work across a wide range of sectors including information technology; financial and professional services; capital markets; manufacturing; engineering; and environmental protection. You can contact me at

LinkedIn Profile

Subscribe To My Blog