Friday, 15 January 2016

Key Attributes of an Effective Process

When I used to cut code for a living there were a number of attributes we used to look for in a 'good' program (application!). Maintainability, Efficiency, Readability, Flexibility, Reliability, Reusability, Portability and Testability are some of these non-functional or quality requirements that spring to mind. A programmer today may have a slightly different list as development environments have changed and technology has advanced. Security probably trumps portability for example.

A couple of days ago I started writing a post whinging about processes that, at least from a user's perspective, appear to be constantly changing. These are often pretty, bureaucratic changes but are exceedingly frustrating for those on the receiving end of the changes.At the same time I was documenting an existing process as part of the day job, and I started thinking about the quality attributes for a process. What makes an effective process?



I know that many folk would argue that there is no such thing as a good process. but for the rest of us here's my list - written from the perspective of a process user (not purely as a process author)...
  • Stable - whilst the whole point of continuous improvement is to ensure that processes are kept up to date, there must be a period of bedding down a process before you start changing it. Constantly fiddling with a process, even in the minutiae, irritates and confuses users, and will inevitably lead to some kind of failure before too long as people simply don't know what's right and wrong anymore. Unless a process is shown to be fundamentally wrong (in which case it there should be big questions about how or why it was published in the first place), let a reasonable amount of time pass before updating it. And where processes are cyclical, e.g. monthly, don't make changes every month, especially at the point of execution!
  • Complete - there are plenty of great examples of how to document a process, but all too often these are ignored, and valuable or even critical information is missing from the process definition. For example, entry and exit criteria are often missed out, sometimes inputs and outputs are only partially listed. Attention to details gives users confidence in the process
  • Understandable - if you document all your processes as essays, don't be surprised if people struggle to follow them. It's also important to get the level of detail right - don't mix up process definitions with work instructions. Few users actually need to read a process end to end if they are already familiar with it. They are more likely to want to find elements within the process like process inputs or specific roles and responsibilities. If using web based descriptions, draw on good user interface guidelines to hide or show levels of information that people can focus on. If your using more traditional document based descriptions, a tabular approach is often a good way to present information.
  • Current - people expect to be able to access processes that are up date and relevant for the work they are currently doing. Old, irrelevant processes should be withdrawn and archived if necessary. And publishing process changes is simply not enough - there needs to be communication that processes have changed, and how they have changed
  • Usable - in the age of corporate intranets, wikis and even SharePoint, there is no excuse in not making processes easy to find, navigate and access. Libraries of documents are no longer relevant nor desirable as vehicles for users to access information. The best process libraries are those that users can interact with, even to the extent of having processes describes from different user perspectives according to their role or function. More importantly, thing about how the process flows from a user's perspective - something obvious to an author may not be so obvious to a user, especially in the heat of the moment when they are battling against a deadline
  • Simple - many working environments are already unnecessarily complex so your processes need to be documented to help remove the complexity as much as possible, They need to be clear and precise, and focused on the people who do the work - they should not attempt to showcase the author's writing talents!
I'm sure there are other attributes that you may want to add to my list - drop me a note or leave a comment and I'll include them in a future post






Friday, 8 January 2016

Why The Shareholder Should Not Be At The Top of the Food Chain

Earlier this week I read yet another article about the imminent demise of Yahoo's leadership team due to a letter from an activist shareholder group - who in this case owns less than 1% of Yahoo. OK, 1% of a multi billion dollar company may well be more than I'll ever earn in several lifetimes, but it's still a very small stake-holding compared to all the other investors.

What struck me was how such a tiny stakeholder thought it had the right to make such demands on a business and why, if it was so unhappy with the business why it simply didn't divest itself of its stake?

(Picture borrowed from Kristen Maxwell Texas Enterprise)

When I first started working, there was a very clear mantra that was drummed into my head with remorseless frequency. The shareholder is the king of the jungle - the only reason you are in business is to make money and return the investments of the shareholders. Nothing else matters - not even the customer, and especially not the employees.

That always seemed to me to be a bit of a perverse way of looking at the world, but everybody was saying the same thing, so it had to be right - and I was a newbie and at the very bottom of the food chain, so what did I know? But the concept has nagged at me right through my working life like a dull tooth ache that won't quite go away completely, and occasionally rears up and hurts like heck.

In my world I always had the naive perspective that if you treated your staff with dignity and respect they would work their socks off to please the customer (and their managers). The customers would increase their support for the company with increased spending and referrals, and the benefits would be realised by the executives, and ultimately the shareholders. A positive reinforcement loop if every I saw one!

Finally, it appears that I'm not alone in that ridiculous notion. A reasonably successful businessman called Richard Branson talked about the concept in a recent interview. Peter Leeson speaks from the same perspective in his book Orchestrated Knowledge

"Unfortunately, in recent years, many management teams have started believing that they work for the shareholders rather than the clients"

and then suggests that shareholders are often only ever interested in short term speculation (usually with each other) and rarely bring any real value to the company.

The downside of raising the importance of the shareholder above everyone else is that, ultimately, people start equating the value of stock with the quality and viability of the business (look no further than Apple and the performance of its stock which is completely divorced from the profitability of the business and totally at the mercy of Wall Street analysts who live in a completely alternative reality distortion field). Once you start people thinking there are potential risks to the future of the business, you set a negative feedback loop in progress and the vicious downward spiral begins.

Meanwhile, global IT giants like HPE and IBM continue to treat their people like mediaeval serfs, constantly under threat of redundancy, and being squeezed of every ounce of loyalty left in them by one-dimensional strategies which are focused purely on cutting costs, rather than improving the business (and their customer service).

The relentless march towards corporate capitalism will be our downfall and the balance needs to be  redressed towards putting real people first, namely employees and customers. After all, what's the point of empowering people by creating agile environments and then making them redundant simply to generate more money for people who can't actually do anything to make the business better?!





Monday, 23 November 2015

Think Global, Act Local - How To Sub-optimise Your Global Operation

I think it was sometime in the early 2000s when I first came across the expression "Think Global, Act Local". The phrase has been attributed to Patrick Geddes, a Scottish town planner and social activist, and originated way back in 1915. These days it is a rallying cry for global corporations, and it has appeared in nearly every leadership presentation I have seen over the last 10 years.

At the time, I was working for a major IT outsourcing company, whose business was truly global, and where corporate shared services were already being farmed out to 'low cost centres' across the world. In Applications Development and Maintenance, we were also beginning to talk about 'follow the sun' development, whereby developers would work in relay teams around the world to build software systems 24x7 in a factory model - but that's another story for another day.


I remember being quite excited about the 'Think Global, Act Local' paradigm, mainly because I had my fingers in many pies. I was a member of a number of global task forces looking at various elements of our software development activities, whilst being responsible for all business improvement activities across Europe, and also looking after a team of UK based process improvement experts. And for a while things were hunky dory...we achieved an enormous amount, it was fantastic collaborating with people from all over the world and we actually worked in an environment where people understood how the paradigm should work but more importantly what the limitations were.

When I came across the phrase more recently, I started thinking about how jaded it now seemed, and more importantly how it has been so poorly interpreted by so many management teams that it has probably caused more harm than good. On top of that I realise how naive I was to be taken in by some of these slogans, although I'm pleased that I now finally see them for what they are and that I'm able to think around the consequences of these and other management hypes, although that is largely the result of seeing how things have evolved in the real world, and the problems that have ensued.

I have two main examples of where the paradigm breaks down. Both involve the transfer of work to places with relatively lower cost bases, which is possibly a very desirable thing to do if you are an accountant, but less desirable when seen from other perspectives.

In the first example, let's consider the situation where highly skilled knowledge workers form an operational hub in a low cost region. Depending on the location, it is possible to hire very skilled people (often contractors) at slightly lower rates than they might expect from their home base, but who benefit from the reduced costs of living abroad. The company benefits from lower wages bills and generally lower operating costs by setting up such hubs. A win-win situation it would appear.

It's only when you start working that the problems become evident. And in my experience the single biggest issue is that all collaboration and communication is done electronically. You rarely, if ever, meet the people you support, and your lives are spent working in sound bytes of information, struggling to catch people for a few moments of their time.

In other words, support staff can only provide a sub-optimal service to their front line colleagues. No matter how hard we try, we are limited by the problems inherent using in electronic communication alone - technical issues, misinterpretation of messages, misunderstandings, language issues - all of which are potential issues when working face to face, but compounded horrendously when our only interface to our colleagues is through a computer.

[The irony of this situation is that often the work could easily be done by contractors tele-commuting thereby dispensing with the need for office space and the associated costs of doing business. Personally, I would be perfectly comfortable working from my own home, on a lower day rate, than having to relocate to an office on the continent, incurring the costs of renting an apartment, paying management companies to represent me and still not having face to face collaboration with the people I support]

In the second example, whole functions are relocated to a low cost centre. These are often administrative functions, such as invoicing, procurement or payroll. It may seem quite obvious that these ‘self-contained’ functions can work remotely, servicing requests from across the globe. However, this assumption fails to take into account the biggest single weakness that is inherent across all organisations, regardless of size, longevity and maturity. Most organisational dysfunction occurs at departmental interfaces.

Some organisations have taken this relocation of function to an extreme. Payroll is located in country 'x', procurement is located in country 'y' and invoicing is located in country 'z'. And of course, all the transactions originate locally and then start their long and intricate itinerary across the world. Even some seemingly trivial activities that used to be performed locally in a matter of seconds now take a week or more to fulfil, assuming there are no issues with the original request. If an issue does arise the error has to be backtracked through it's travels and then start all over again.

Many of the organisations who have divested their back office activities across the four corners of the world are simultaneously embarking on 'Lean' and 'Agile' initiatives. Because they have no real understanding of what 'Lean' or 'Agile' really mean, they fail to see the irony of their actions.

Think Global, Act Local, in many respects, is the antithesis of Lean and Agile. Saving money by relocating certain functions at the expense of operational efficiency and effectiveness is almost certainly not going to lead to a net gain against the bottom line. People in higher cost centres are being hindered by the delays in transactions preventing them from realising their own operational effectiveness. Time is spent chasing up requests, often being passed from function to function, as there is no longer any clear overall ownership of the process. In fact, the whole thing smacks of an exercise in job creation, whilst at the same time, hundreds of skilled people with unique domain, customer and product knowledge are being made redundant (before being re-employed as much higher cost contractors).

If businesses took a moment to map out their end to end processes, looking at such things as value chains and process topography and topology, before they shipped out their support functions, they may realise the potential folly of their actions.

As usual, there are more dimensions to executing business processes than that of cost alone! And any Lean expert, worth their salt, will understand that optimising all your sub-functions in isolation, out of context, and without a holistic overview, will lead to the overall process being completely sub-optimised...and probably completely dysfunctional...especially to the people who depend on it!


Wednesday, 23 September 2015

The Change Centre

I read an article a couple of days ago called The Change Habitat: Why 70% of Change Managers Are Wrong by Jurgen Appelo. I’d need a lot of convincing before accepting much that was written in the article, but it got me thinking about a problem I’ve seen in many organisations struggling to succeed with their change initiatives.

A common denominator in many organisations where there is a history of problematic change is a lack of a change management competence. By that I mean that there are :
  • no corporate change method or common approach to change 
  • no recognised subject matter experts who can assist in change initiatives
  • no change management tools or assets to help change leaders and teams
  • no lessons learned data to help future change programmes
In other words, change is usually performed in an chaotic way and is dependent on the skills and ability of the individuals leading any specific change project.



Most IT organisations involved in project work have a set of project management standards and some form of development/support lifecycle in place, along with supporting governance processes. They usually have a set of standard templates for key deliverables - a project plan (not just a schedule), status reports, budgets and outlooks, and requirements and specification documents. They have mechanisms for raising change requests and recording defects and issues. New projects and new members of staff use the materials already available rather than having to reinvent them every time.

Very few organisations I’ve worked in have a similar set of assets available for managing change initiatives. People who are asked to manage change initiatives either have to try and make do with the existing project management templates or need to build their own. The problem with using standard project management assets is that they are rarely adequate for projects other than technical ones. And as I suggested in my post from August 2014 (Unifying Technical Project Management with Management of Change) there are significant differences between the two types of project, and there are additional things that need to be considered for change projects.

By establishing a Centre of Competance (CoC) for organisational change, with a defined lifecycle, toolkit and group of dedicated change management professionals a company can begin to establish a consistent approach to running change programmes, large or small, thus greatly increasing the potential success of any individual initiative.

There are some caveats with such an approach. Exactly how you set up your CoC will depend on your organisational culture, history of change, and operational structure, but here are some ideas.

The lead of any such group should be a recognised expert in organisational change management, with a reporting line to a C-Level executive. It should be understood that the team as a whole acts in a support capacity, like internal consultants. Individual change initiatives are owned by their executive sponsor who is responsible and accountable. Members of the team may act as change managers for specific initiatives and in that capacity become responsible and accountable to the executive sponsor for that change.

The centre of compentance maintains records of lessons learned and continuously improves its change management assets over time. It is subject to the same quality controls as other parts of the business, including business/quality assurance, internal audit and organisational governance. The group is centrally funded as a shared service across the business as part of the 'change the business’ budget.

There should be a consistent core of team members and other members of staff may be co-opted into the team on specific initiatves to increase the knowledge, understanding and awareness of change management through the wider organisation.

An additional responsibilty for the Centre of Competance is to co-ordinate all change within the organisation. This enables the CoC to manage the big picture of change within the business. The CoC performs basic impact analysis and due diligence against all potential changes before they launch. This is critical to understand where effort is being potentially duplicated (or worse!) and to establish where there may be synergies between apparently independent initiatives. It helps the business establish priorities and most importantly makes sure that the change is adequately thought through before being launched. Recommendations are fed back the steering board who make the final decisions on which initiatives should proceed, be put on hold or cancelled.

The role of the CoC should be communicated to all staff - and they should be encouraged to interact with it. Having an open and transparent change organisation is key to getting people on board. If the CoC is kept behind closed doors its very purpose will be undermined.

Building a  Change Centre will take some time and success certainly won't happen overnight. There may still be issues regarding change projects, but fixing these issues should become easier and your change initiatives should become less painful. More importantly you are setting a foundation for sustainable change in the future - and you can be sure there will be plenty more change to come.