Google+ LIBA Consulting and Advisory Services » IT Enabled Change

Archive for IT Enabled Change

“If you can’t think of anything nice to say…”

Change Ahead

Here’s a thought – is the language of change management intentionally designed to make change hard; to actually increase resistance?  I do not know what you have encountered in your experience of business and IT-enabled change programmes, but we have seen plenty of examples of business change programmes that just sound like hard work right from the outset.  The people affected by business change initiatives are told they have to change to accommodate new technology – to operate new processes; change their behaviours, gain new skills and even adopt new “values”.  IT-enabled change programmes seem to be purposely positioned to deliver solutions that need “users” to “understand” & “adapt” to them; they encourage a “change is hard” perception, rather than something that can be slotted in willingly and easily. If IT-enabled business change is so difficult and requires such intense and deep rooted change at a personal level, maybe, just maybe we’re going about it wrong?

Talk to many change management practitioners and you will hear about the need to “overcome resistance”; “get buy-in”, “assess the impact”, “analyse the gaps” and maybe even “win over hearts & minds”.   In one client this past year, I even heard of the implementation having a “blast zone” in which we needed to “perform damage limitation”. Was this a packaged software implementation that we were talking about or a full on assault on some rogue state?!

Perhaps the reason that many change initiatives fail is that the problem lies less with the willingness and ability of the people expected to utilise new processes and systems, and more with the leadership of change and the way in which such changes are designed and formulated; the way they are described and positioned.  Introducing new business models, new processes, different systems and technologies immediately comes with rhetoric and baggage; hyped expectations, fuelled by overly optimistic business cases and unrealistic delivery schedules, and a history littered with very public failures. Not surprisingly, most companies, their management and employees approach such initiatives with apprehension.

Its true that humans do not generally react well to change in their environment and even fewer relish the prospect of having to “change themselves”; change at a personal level usually needs an external stimulus and/or motivation.  Few business changes start at the individual level or are initiated through some internalised motivation, they are typically a response to a wider business objective and one that is expected to benefit all or part of an enterprise.  The effect on individuals is generally a by-product or result of the change, not something that tends to be considered or designed in upfront.

In his April 2013 HBR guest blog post “Change Management Needs to Change“, Ron Ashkenas asserts ”the content of change management is reasonably correct, but the managerial capacity to implement it has been woefully underdeveloped.”

Similarly, I am not suggesting that current, organisational change practice is particularly flawed – well not if its done well! Rather that change should utilise a more positive vocabulary; engender more advocacy and harness more positive energy. So, rather than the Sword of Damocles hanging over an organisation’s head, how about we use language intended to build organisational rapport; to remove the “barriers”, the “blockers” and the “fear” associated with change?  In cultivating that internal motivation, to answer the “what’s in it for me?” question, it is often easier to think of the metaphorical “sticks” rather than “carrots” when you are dealing with change at the level of the individual.

There are ramifications of course, for project teams, consultancies, systems integrators and software vendors – they need to make people the central concern of their approaches, designs and solutions. Whether it has a small “c” or a big “C” – customer centric solution designs and implementation methods are needed to deliver solutions that demonstrably add value to organisations and the people that work in them.  If something has inherent value, then any associated change will be easier to effect, but a less confrontational lexicon for describing the process of change will go a long way to get everybody in the right frame of mind.

So, before you start talking about change, establish a more positive vocabulary – find the “yang” to the typical “yin” words used to describe change, and dust off your thesaurus!

Why are you investing in IT?

IT investment aligned to support growth

The challenge of IT for start-ups & high growth businesses

So you’ve come up with your great idea for starting a business. Through hard work and personal investment, you’re starting to get the business off the ground. The vision that you’re painting and plans for growth are attracting outside interest and investment.

To start with, you could run the business on spread sheets, in your spare time, but as you grow you quickly appreciate that this could take up more and more of your time. Taking you away from where the real value is, your customers, your proposition, your product, your employees, your “whatever”. You’re aspirations tell you “we’re going to need a bigger”… office, warehouse, software development team, IT systems.

‘IT “systems”? We develop applications/make widgets/distribute whirligigs. We don’t do “IT”!’ Where do you start?

The range of options for implementing IT systems to support your business is overwhelming. So many choices. So many vendors after a slice of your hard-earned finances. How do you know which is the right one? Well there probably isn’t a “right” one. There are certainly “good” choices and “bad” choices, but one absolutely “right” IT system? Probably not.

Before you get too stressed, take a step back and consider a few things that history, academic research and practical application have taught us about the effective use of IT and the delivery of business benefit.

IT systems must serve the business

If you’re going to invest in IT, it needs to support your business and improve business performance, not add unnecessary cost, inefficiency or detract from “performing” business. So, the first step is to understand how your business delivers value to your customers; the capabilities that requires; how your employees do their work to provide that capability to deliver that value. Once you understand the value-capability-organisation linkage, the next step is mapping IT enablers to this “value stream” representation of your business.

IT should be used only where it delivers benefit

Technology is not the “silver bullet” that many vendors would have us believe. Sometimes, it seems like they’ve got a solution looking for a problem. Other times, introducing or over reliance on systems, actually destroys the business benefit by adding unnecessary complexity; removing important personal interaction; neglecting a critical business flow or compounding the integration of information.

Take a step back. Don’t jump into providing “point solutions” that end up as disembodied limbs or organs within your business, which work perfectly in isolation but do nothing to service the greater good of delivering business value. Look at the whole business system; the flow of information and product; the customer-employee-supplier interactions, and identify the options to deliver both functionality to a particular business area or process, and the overall integration and flow of the business.

Developing a business case, a rationale for the investment is widely regarded as essential, if you’re to remind your employees and yourself as to why you are implementing a change. Clearly state the benefits in cost avoidance; enhanced customer service; ability to be more responsive or ability to exploit an opportunity, whatever the purpose is to support your business operations and growth. And if the IT solution(s) doesn’t help you achieve those benefits, deliver against that purpose, then don’t do it or at least re-evaluate your approach to maintain focus on the benefits, outcomes and purpose that originally motivated your decisions.

Involve everyone

Well perhaps not “everyone”, after all this is a “benign dictatorship and not a democracy”! Seriously though, the effective design, selection and implementation of new IT enablers for your business is dependent upon them being “fit for purpose”. That means satisfying both “what“ the system does and “how usable” it is. That means understanding how the systems will be used, how they will fit into the organisation, and encouraging participation throughout the life-cycle of requirements-definition-selection-implementation. You’re probably not going to be the one that primarily uses the new IT systems, so it’s important to engage those that will. That includes engaging customers and suppliers as well, if the processes and systems are likely to touch them in any way.

Now you’re likely to be a smaller organisation, closely knit and bonded as a team. You hopefully don’t suffer from one of the major challenges that larger organisations face when they are defining or implementing new processes: middle management. Research has shown that the support, cooperation of middle managers (or not) is key to the success of the implementation of business change be that organisation, process or technology or all three. If you have got a “middle management”, or even if you haven’t, engage key senior stakeholders from the outset. If there is any resistance, or persuasion required, then address it. Address it head-on and address it quickly. If managers, supervisors or team leaders are not “with the programme” then it will only make things harder.

It’s all about the individual

A common problem with the implementation of IT systems is that there is often a mismatch between the wider business needs and expectations, and the requirements, desires or behaviours of the employees who will be expected to use the systems. Now it’s generally not possible to offer individually tailored systems for each employee, but it is essential that systems effectively serve the needs of the user community. Actually, it’s probably not just about the individuals alone, you need to consider the team, the integrated organisation, the hand-offs and flow of information and work between individuals. The effectiveness of the overall business is as dependent upon interactions between individuals and components of a business, as it is about the performance of an individual aspect. This in turn leads us on to “ways of working” and individual or collective behaviours, as much as the technical execution of processes and operation of IT systems. Which leads us on to…

Planned change

It is not sufficient to simply define the business process and requirements for IT systems and plough ahead with the implementation, without considering the impact on and changes required by the organisation. New processes, new IT systems will undoubtedly affect your organisation not just because it’s a new set of tools or procedures to be learned, but potentially new responsibilities, new skills and new behaviours as well.

Too often organisational change is considered as a bolt-on to process and systems implementation. Too often its tackled in an ad hoc manner. Identifying and tackling these changes requires a proactive, planned programme, integral to the business and technical activities of any project. A structured programme that is however flexible and can be tailored to changing organisational requirements. After all, your business is dynamic, and isn’t going to stand still, even for a few weeks and certainly not months.

Your employees have got to be willing to use the systems.
One of the key outcomes of this structured and proactive change programme, is preparation of the organisation and employees for the introduction of new ways of working, new processes and new tools for them to do their jobs efficiently and effectively. This means that any IT products that you implement need to help them with their daily activities; help them do “meaningful” things to service your customers, to deliver your products, to run your business efficiently and effectively. The employees need to be able and willing to use them. Not by-pass them; have to devise a cunning work-around; print things out and retype them into a different system, or blame the system for poor performance.

This means, not only understanding what employees do to deliver value to your customers, and involving them in the definition, selection, design, but also, training them in the use of the systems. Whatever applications you implement, or cloud service that you buy, don’t squander that outlay by scrimping on education and training.

Finally, evolution and growth

No process, system or service is going to be perfect on Day One. It’s also highly unlikely that what you implement now is going to remain unchanged indefinitely. You’re business will continue to grow; continue to adapt and mould itself around new opportunities; respond to market intelligence and feedback from customers. These changes, potential future requirements, the need for additional capacity, capability or functionality need to be anticipated and progressively planned. Actually they need to be identified upfront, before you select or implement anything. You need to make sure that you have an evolutionary path, and are not going down a cul-de-sac with your initial investments.

As importantly, you need to anticipate the problems that will occur post-implementation. There need to be mechanisms for capturing and responding to issues and suggestions from employees, with the ability to fix things that aren’t working and make rapid changes to ways of working and/or systems. You will need indicators that processes, systems and people are working, as you would expect; that customers are getting the value that you need. If something isn’t working, or needs a little tweak, then change it. Don’t become a slave to the “as-designed”, “as implemented”, “must make it work” mentality. If you’ve done your groundwork in the initial stages of the design and selection, then the issues shouldn’t be fundamental. Fixing them quickly, responding to feedback and making improvements, will ultimately enable you to get the benefits and business value from your new systems and processes that you had originally envisaged.

Investing in IT systems for any business is a significant activity and event. Too often the selection of good solutions is compromised and the implementation fraught with difficulties. By adopting the principles described above, which originated from Socio-Technical research and practical application over the last 20-30 years, organisations no matter what size or stage in their life-cycle can improve the likelihood that those investments will deliver the benefits and value required by you as a business owner or senior manager and that expected by your customers.

LIBA Consulting and Advisory Services believes in providing clients’ businesses with robust, practical advice grounded in sound academic principles. To that end, we have developed a strong partnership with Professor Neil F Doherty and Dr Crispin Coombs from Loughborough University School of Business and Economics.

This post is a great example of connecting practical application to academic study and the structure was extensively informed by a research paper – Doherty, N.F., The role of socio-technical principles in leveraging meaningful benefits from IT investments, Applied Ergonomics (2012), (or direct from the authors)

For further information about current benefits realisation management research projects at Loughborough University visit:

The journey starts with a purpose and a direction

The journey to the moon started with a vision

In the last few months, I’ve spoken to a number of clients who are struggling to deliver their portfolio of business and IT change projects efficiently and effectively.

Several have started to look for a “Portfolio Manager or Director”. The role descriptions tend to combine implementation of project and programme management standards, referencing Prince2 and MSP and quality assurance; ability to manage senior stakeholders, including those that own or are accountable for the very success of these individual initiatives.

They perceive the problem as being the domain of the project manager or project sponsor, which in part it might be.  However, when asked to describe the changes that they are seeking to make these are either vague or couched in terms of needing to implement particular IT systems.  On too few occasions is the intention of the change described in compelling terms or with a vivid description of the value the business will derive from the range of initiatives that are planned or in progress.

To me there seems to be a number of steps for achieving meaningful and sustainable change, and it starts with knowing what you want to achieve and following a logical path to describing the journey that will be required:

  • Define the strategic objectives that the change is going to address
  • Describe the future mode of operation that will deliver those objectives
  • Assess the gaps to be closed; the improvements to be made to realise that future target operating model
  • Distil the conclusions and prioritise
  • Define an initial roadmap and the options to be evaluated
  • “Finally”, produce the proposed implementation roadmap

I say “finally” but in reality that’s really just the start.  At this stage all you have done is “define” the changes required. You probably haven’t changed anything yet, but at least you now know what you need to change and for what purpose.  You can describe the changes in terms that provide your organisation and stakeholders with a rationalisation and justification for change; a clear statement of intention and direction, and a pathway to delivering the business outcomes that individually and collectively will help you to navigate from where you are today to where you want to be in the future.

It’s unlikely that any organisation, charting their roadmap will consider making the journey in one big step.  On the way to the moon, the USA and the World needed to develop better rocket and engine technology; put satellites into orbit for communications and scientific experiment; to develop and test out equipment and life support systems, and to invent new materials that could withstand temperatures and pressures not previously contemplated.

The journey to the moon, for the public at least, started with arguably one of the most evocative speeches and vision statements of our time:

“…. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too… “

John F. Kennedy
September 12th 1962

Defining your implementation roadmap should start with a vision of what you want to achieve; the direction you want to take and the business outcomes that need to be delivered along the way.

It sounds corny and a bit of a cliché, but a compelling vision statement is not a luxury and must not be some vague, anodyne statement. It needs to be a specific about what is to be delivered and when. It should be supported by statements that reflect an honest portrayal and justification of “why?” “the thing” is to be done, and a depiction of what will or might be different in the future – with and without the changes; the challenges that will be faced, and the budgets and resources required.  After all do you think a man would have landed on the moon on July 20th 1969 if Kennedy had not committed the funds and the nations best resources to the endeavour?

So, as you embark on the next instalment or step on the journey of business change, be sure to understand and define the context for the change, its purpose, objectives and alignment to the longer-term aims of your organisation.  Create that compelling vision of your intention, one that describes what’s in it for you, your employees and the wider business environment.

Please implement my SAP/ERP system ASAP

Unravel complexity









If you read articles and blog posts on enterprise software projects, it won’t be long before you see tales of blown budgets; slipped schedules; lack of realised benefits and even litigation.  Too often this class of project is the victim of poor delivery and, because of the costs involved, readily attracts poor press.  Regardless of whether these projects include software suites from SAP, Oracle, Infor or any other vendor, they are substantial and tricky undertakings for any organization.

In a recent pre-cursor to their now published 2012 ERP report, Panorama Consulting ( cite that nearly half (44-percent) of all ERP implementations fail to deliver at least half of their expected business benefits; 54% (down from 61% in 2011’s survey) run over schedule and over budget by 25% on average.  It’s true that the occurrence of failure is publicised more often in the press than success, but even so, why does the occurrence of failure seem so prevalent?

Plenty of time and blog-space is devoted to the topic of critical success factors (CSF) for successful projects.  Usually the list will include leadership, data, scope control, requirements management and managing the impact of change on the organisation – you can add your own 6th, 7th or even 8th CSF!  This might be vision or governance or testing – all very sensible, easy to understand and advice that has been repeated numerous times over the past decade and half that I have been involved in these programmes.

So surely, the majority of folks are not ignoring or neglecting this sage advice?  And hopefully the World is not completely stocked with incompetent project managers and leaders.

There has been a steady stream of articles, discussions and blog posts, including from Bill Wood at, highlighting that the lack of using a strong methodology is a contributory factor to project failure, and that project managers (in Bill’s case he was highlighting SAP Project Managers specifically) are ignoring the assets that vendor methods, such as ASAP, offer, in favour of developing their own accelerators because they either do not know these methods or “have a financial motive not to” use ASAP.  Whatever the motivation, the consequential lack of adherence to a rigorous method is contributing to failure and missed expectations.

To test the “state of the nation” @LIBACAS conducted a poll across several, relevant LinkedIn Groups to ascertain the extent to which SAP Project Managers have been formally trained and are keeping up to date with the ASAP method, by way of an example for vendor prescribed implementation methods.   The results are somewhat disappointing, but probably not all that surprising.

Out of a sample of 29 project managers who responded:

  • Only 10% had undertaken formal ASAP training within the last year.
  • For 31% it has been more than five years since they were formally trained in ASAP, so they may not be aware of the latest additions or how to navigate the method roadmap, access its repository and run an SAP project using Solution Manager – SAP’s recommended way of using the method to its fullest.
  • 17% have only ever been trained in their employers’ methods, which align, incorporate or, at best, pay homage to ASAP.  Again, potentially missing out all the available support and aids that the vendor method could provide.  And, perhaps most revealing,
  • 42% have learned everything they know about ASAP “on the job”.

Now, it’s probably fair to assume that many project managers will have had training in a formal project management standard – PMI or Prince2, but these do not offer the same extent of guidance and support for enterprise software implementation projects that vendor specific methods will.  So, it is highly likely that project managers are missing out on useful tools, disciplines and accelerators due to a lack of formal training.  That’s certainly not going to help the situation, but is method the root cause of a high percentage of project failures?

Ken Koch, from – responded in a recent discussion on the topic “My experience has taught me that it isn’t the methodology for an ERP system [that gives success] it is the company’s ability to adapt and adopt.”

Again the “adaption” theme has been often repeated and leads to the “we will stick to vanilla” and “change the process not the package” mantras of every client Steering Board.  However, this is easier said than done, with 53% of Panorama Consulting’s respondents admitting to “some”, “significant” or “extreme” amounts of customization in their projects.  In my experience, at least 20%-25% of a project’s budget will be consumed with development effort, as opposed to configuration, as the business changes the behavior of the software to fit their processes, rather than the other way around.

The “adopt” conundrum – getting the business to change to fit the application – is obviously the territory of organizational change management, communications and training.  Again an understandable feature of all lessons learned reports; CSFs for successful projects and high on the list of every ERP related consultant worth their salt.  While many businesses do underestimate the difficulty of getting their organisations to change, to understand, adopt and accept the new processes, practices and applications, most do at least plan for activities in this arena as part of their overall project.  So, is a failure to address business change really the main factor in project failure?

Or perhaps all of the above are guilty parties, accomplices to the crime, and the problem that needs to be managed is the inherent complexity of these projects, the breadth of scope, the business and IT dimensions, the impact on people, data, processes and infrastructure. Is complexity the root cause or at least the main driver of failure?

The breadth of their potential capabilities, their tightly integrated nature and the anticipated benefits of deploying commercial enterprise software suites often leads companies to “plan big”.  Wanting to implement to the fullest extent, there is a tendency for projects to bite off a lot (too much?) in one go.  Review the scope of most of ERP-enabled business change projects and it is likely to encompass a large proportion of an enterprise’s core business processes. That’s a lot of activities, functions, transactions and people to consider, even in a small business.

It’s true that the native integration; the ability to replace whole swathes of legacy applications, and to deliver standard, end-to-end business processes, is a powerful lure for any business.  Keeping the scope intact and delivering the new processes and applications in a “big bang” to the business, promises to keep technical implementation complexity down and more quickly realise improvements in business efficiency.

According to the Panorama Consulting survey, 57% of organisations that responded took a “big bang” approach across the whole company, or phased total process scope by geography or business unit.  On the flip-side, the larger the scope, the more resource is required from the organization to support the implementation; the more business change needs to be absorbed by the business and the more integration and coordination is required within the project to keep everything joined up and inter-dependencies under control.

Review the proposals from the vendors and their consulting/SI partners and you could be led to thinking that the bigger the scope the better from an integration and implementation perspective; that the risks are entirely manageable, and you can still get everything you want Mr/Ms Client within your budget (aka “the selling price”).

As Dave Heafield, a seasoned SAP HR and Payroll Programme Manager commented in response to our poll – “my experience has shown that if clients take [the vendor’s] sales pitch with a huge pinch of salt and as a balance take advice from experienced PMs, then they’d allow longer for the transformation and agree up front it’s going to cost them more than [the vendor or SI] told them. They can still justify it with a sound business case but they go in with eyes wide open and avoid the “it’s late and costing more than planned” discussions later when they’ve already spent too much to stop.”

So, to conclude, after 15-20 years of ERP implementations, the rate at which projects fail, judged in terms of time, cost and benefits realisation, is still too high.  Any list of CSFs is probably right. All those areas need to be addressed and factored into any project from the outset, but the top three things that will make or break a project are:

Experienced Project Leadership

Experienced leadership will obviously help. Make sure your programme and project management has proven experience from a business and project delivery perspective.  They need to be able to implement a formal and disciplined project methodology; know about and be able to access current, best practice tools and accelerators.  Above all they need to convey the method, expected standards and the use of tools to the team, then stick to the disciplines.

Realistic Expectations

C-level executives want results, the quicker the better.  They will (usually) rationally expect a fair cost, proportional to the expect return, with minimised risk and disruption.  Above all, they do not want surprises.  Heed the advice and data points in the public domain.  Challenge the basis for estimations; identify the areas of uncertainty and the gaps from today’s way of working or organisation.  Assess risks and mitigations, and budget time and costs accordingly.  Invest in the planning and preparation stage, but do not expect to plan the end-to-end programme in detail.  Build in contingency, but work to an aggressively realistic schedule and manage expectations of those that “just want the thing to be implemented”.

Tackle Complexity

Above all, any programme needs to address complexity upfront. The scope and implementation plan for your ERP project needs to be divided into manageable chunks – balancing scope, costs, time, risk and benefits, of both technical and business delivery.  Fundamentally, smaller independent or loosely coupled projects will be easier to manage and have a better chance of success than large, complex and overblown, multi-multi-million dollar/pound programmes.  Use Enterprise Architecture approaches to scope you projects and plan out your programme roadmap to deliver in releases and phases.

If it’s planned to take 18 months, two years or longer to deliver the project, whether your actually successful or not will be a moot point, the business will have moved on by the time that the shiny new ERP system hits the streets.

Delivering agreed capabilities, over a series of successful 6-9 or at a push 12 month projects, will be received far better than returning to the Steering Board to ask for a 6 month extension and an additional 30% to the budget, assuming that you still have a job in the first place!

Business process mapping is boring!

Process mapping is boring

Open any book on business change, process improvement, enterprise architecture or systems implementation methods and one activity is certain to feature early on in the recommended approach – process mapping.  Documenting a graphical representation of the processes, activities and tasks that the organisation performs to execute its business.  Whether that be the current or future state, capturing process descriptions is seen as an essential task for any business improvement, change or systems project.  However, for the participants, those that are being asked to give up their intimate knowledge of the processes they work with, it can still be a hard sell.

Too often the purpose of capturing processes is positioned as, or perceived as, the production of process diagrams – the mapping activity has a tendency to become self-justifying.  The amount of time and level of detail that is required to capture processes, gathering the underlying data and information, seen as boring, a drain on resources, even an unnecessary task conducted to educate the consultants and sometimes even a personal threat.

So why is process mapping identified as being so important? What can you gain by documenting processes?

The potential value of and reason for process mapping could include:

  • Analysis and problem solving – used to uncover issues, bottle-necks and come up with ideas for improvement
  • Process improvement – identify non-value add activities to improve process effectiveness, efficiency, decrease the opportunity for error or reduce costs by eliminating non-value add activities
  • To elicit requirements – the discussion and narrative that occurs when you map processes is used to frame and elaborate business requirements
  • Identifying interfaces and hand-offs – useful in defining service agreements and contracts between organisational entities or to specify system to system interfaces
  • Alignment of roles and responsibilities – which can be used to target training and define security requirements
  • Explaining downstream consequences – by exposing participants to the end-to-end process, the consequence of an error generated upstream can be explained more easily
  • Communication and training tools – the diagrams can be used to provide context for education and training.  This is especially effective if communicated by somebody who was involved in their generation, to provide the “colour commentary”
  • Hand over documentation – in outsourced arrangements with an external service provider, process documentation should enable a better understanding of business operations, process activities and systems configuration.  This is one of the purposes that may manifest resistance from participants who feel naturally threatened by such business arrangements
  • Alignment of performance metrics – both for process level and individual personal performance measurement, process maps enable measures to be defined and positioned at the appropriate part of the process to create leading and lagging indicators
  • Support for compliance and control processes – using process documentation to provide evidence of operating standards and quality controls to achieve industry or regulatory compliance and certification

The capturing of processes creates a shared understanding and a common language for the organisation.  It makes end-to-end process flows and interactions visible.  Depending upon how they are used, process maps provide the basis for improvement and change, as well as a framework for day-to-day management and controls.

There is as much, if not more value in the process of generating the documentation and maps, as there is in the end product diagrams themselves, but the mapping activity needs to have a clear set of objectives and shared purpose.

The approach and techniques used in process mapping should be easy to understand and supporting tools intuitive; complicated and abstract techniques and tools will only engender resistance to the task.  Approaches should encourage or enable an “outside in” or customer perspective of how things work or could work – a process that does not deliver what its customers need is not effective; a process that is inefficient does not give the participants/actors what they need either; a requirement that is not captured from the user’s perspective will not deliver the experience that is required from a successful system.

The diagrams and documents need to be in a form that is easily understood, communicable and accessible.  They need to have the ability to stand-alone with limited explanation, but must retain and be able to convey the information that underlies the process map, so that those not involved in their creation can still extract value from them.  The burden of and commitment to maintenance needs to be assessed upfront, you do not want to be repeating the exercise in 3 years time, because the information is out of date and a different set of participants do not feel any emotional attachment to the original documentation.

View process mapping as a means to an end, not an end in its own right.  Be clear on the purpose and objectives of process analysis and mapping. Explain to contributors the expected value and handle any change management concerns up front; provide context for the activity – is it to capture today’s processes in order to … or to capture a common perspective of the “to-be”, providing a target description of the future state that the organisation wants to be at/in? Do we want the ability to map the gap/changes that will be required to move from the “as-is” to the “to-be”? Are we trying to define requirements for new processes and systems? How will the documentation be used afterwards?

So, when somebody says “we need to map our processes” don’t be afraid to ask “why?”.  It is certainly an important stream of work in any project.  If you understand the objectives and purpose, then chances are there will be less resistance and better quality as a result.

What’s your perspective? Do you have any hints or tips for improving the effectiveness of process mapping activities?

Change – it’s written in the clouds

Cloud offers metaphor for change leadership

Change leadership inspiration from natural phenomena

In the week before Christmas 2011, the good people of West Yorkshire, England were treated to the rare sight of spectacular cloud formations – Altocumulus Lenticularis.

I have also had the fortune to see this type of cloud, in all its dramatic beauty, while walking in the Riff Mountains, Morocco near Chefchaouen. The vivid image of the cloud remains imprinted on my memory and led me to read a bit more about this cloud type and its formation. The conditions and formation process for these lens-shaped clouds, often mistaken for UFOs, actually provides an analogy for leading change – bear with me on this!

Referring to “Cloud Spotting” by Gavin Pretor-Pinney amongst other sources, Altocumulus Lenticularis are described as mid-level formations composed of droplets or ice crystals that form patches or rounded clumps of almond/lens-shaped clouds. Usually above the influence of localised air currents and thermals, lenticularis form when air passes over a large obstacle and cools as it is forced upwards. They are seen hovering close to hills. In the same way that a fast-moving stream flowing over a large rock can result in a stationary wave shape downstream, standing crests develop in the lee of the hill’s or mountain’s summit . As the air rises, it expands and cools, causing the moisture in the air to condense into clouds at the crests of the stationary wave.

Dramatic and beautiful, they look solid, with a smooth silky surface, but are actually composed of a large number of very small droplets. Although seeming to stand still, air is actually blowing through the cloud, forming droplets at the front which then pass through with the airstream and evaporate as they come down the back of the wave crest. When the airflow is at a constant speed, the point at which the droplets form and evaporate is fixed, creating the spectacular lens shape and the cloud appears stationary. In reality it is in a constant state of flux.

So, how does all of this relate to leading change?

Think about it -

  • Lenticularis form in the lee of major obstacles.
  • The clouds appear solid and stationary; presenting a consistent and stable image despite the flow and turbulence.
  • Unperturbed by “the influence of localised currents”, this single “structure” is actually an ordering of a large number of small components brought together, all be it temporarily, by a steady flow of activity.
  • They are often mistaken for UFOs, something far more strange, dramatic and inexplicable; to some scary, to others curiously exciting.
  • However, they are actually subject to and caused by predictable processes and laws of physics and nature, processes that can probably only be explained by a relatively small community; easily understood by a few more; viewed by most as a mere spectacle, passing curiosity or completely overlooked.

Lenticularis only form in specific conditions and close to specific landforms. If the conditions and landscape are different – warm airstream; vast, flat plains or expanses of cool water; air currents of differing speeds or directions, then turbulence in the cloud layer can take on a very different form known as a Kelvin–Helmholtz instability. Recently seen in Birmingham, Alabama, fast-moving, lighter density clouds slide on top of slower, thicker layers of cloud, dragging out the surface and making the cloud resemble a wave rolling along the top of the water. Again, it looks spectacular but more like a tsunami in the air – and we all know how dangerous they can be.


Read more:

Read more:

What can business change projects learn from the film industry?

Directing your own successful project

Learning from filmmaking

We’ve all heard of the successes and too often the failures of business change programmes, especially those that involve IT systems. The failure to achieve deadlines, deliver to budget or realise the expected benefits.  Nobody will deny that implementing change can be difficult, but need it be as fraught as it seems to be?  In thinking about this, looking for inspiration and innovative ideas as a change project leader, I have often been drawn to using the film industry for parallels and was reminded of this today, reading an article on Martin Scorsese in Fast Company (The Vision Thing).

So how are the types of projects and business change initiatives that we get involved in similar to the world of film? All be it from a layperson’s perspective, the following outlines some parallels which, I think, project leadership could draw inspiration, including:

  • Vision and objectives
  • Planning and preparation
  • Risk and change management
  • Prototyping
  • Project plan and budget management
  • Team management
  • Stakeholder management

Let’s start with the commissioning process – you need to have a “killer pitch” to get your investors.  Whether you’re the director with a pet project or writer with a story itching to be made, you need to get production houses or other potential investors willing to commit funds and resources to the project.  Without a compelling, initial pitch that grabs attention, there is no project.  Within our world of IT enabled change programmes, this is equivalent to the initial vision, high-level statement of objectives and business case; the answer to the “why should we fund this?” question.  Unless you are a “known name” like Scorsese, this needs to be the much vaunted elevator pitch – you only have a few minutes if not seconds to grab their attention, so it better be good, otherwise your sponsors and money-folk will move onto something more pressing.

So, let’s say, you now have approval to proceed, what do you do next?  Bring in the cast and crew and get shooting right?  Wrong, you need to do two things, visioning and planning, with visioning being most critical.  In film making, its the director who is key to creating a vision of what the film will look like; how the story will be interpreted; the types of characters the actors will need to portray and the process to be followed – in effect the principles by which the film will be made.  They will engage a few trusted collaborators to develop richer detail of the vision; to decide on cinematic style, sound, lighting and cinematography; to visualise the scenes and locations; form an idea of the key actors and the crew members that they want around them; identifying candidates who are suited or capable of doing what is required for this production.  This all takes money, so we need to have outline shooting plans and budgets developed.

Probably during this process the director should check back with the producers, making sure that they are “happy” with the vision and direction that is forming and giving them more information to secure final production budgets.  I say “probably” and “should” because in the creative process of making a film (or delivering a project) there is a balance to be had between keeping your senior stakeholders on-board; maintaining the vision; heeding advice and maintaining engagement, but not being overly influenced by individual opinions and pressure to do it “their way”, e.g. hiring particular actors who aren’t right for the film.

Now you are ready to start engaging cast and crew.  Through auditions and interviews, referrals and approaches, the producers and director put together the right team for the job, recognising the specialised roles that are required and the unique skills or styles that will fit with this particular production.

A filmmaker doesn’t cast or hire just anybody, they try to get the right people for the role, be it acting or production.  They’re picky and demanding; they use references and past productions to find the people for this specific production.  Like most project managers, they often go to the people that they know, have worked with before and can trust to do a great job.

The process of forming the cast and crew team has two or even three correlations in the world of IT enabled business change programmes – the key business actors, the internal members of the crew and the external crewmembers coming from the freelance community, consulting or systems integration partners.  The selection of each is important – the business team members (the actors) need to be perceived in the right way by the wider business community (the audience); the internal crew members need to have the requisite skills, or at least the ability to learn quickly, and the external crew members the skills, existing credentials and past performance references.  What is important in all cases are the individuals, not the organisation that they come from, but the individuals themselves – their experience, their skills and aptitude, flexibility and ability to respond to changes, resolve issues and pre-empt risks.

You’ve pulled together your key cast and crewmembers, now we can move onto shooting, right?  Not yet, each aspect of the vision needs to be communicated and broken down to the next level of detail; everyone needs to know what the film project is about; how it will look in the end; how the story develops and what is expected of them and their teams.  They need to understand and share the vision and objectives for the project, and plan their activities to deliver against their role.

This will take place in a number of ways – storyboards, walkthroughs, and briefings.  The story is broken down into scenes, often using actual physical drawings/sketches of each scene, as described in this article on the recent Planet of the Apes prequel, (again from about storyboard artist, Tim Burgard (Storyboarding The Apes).  A form of early prototyping, storyboards are another way for director and storytellers to flesh out the vision for all to share and engage with.  The actors will often conduct walkthroughs and script reviews to get the dialogue and acting directions defined and agreed before they set foot on the set.  The set makers, special effects and costume designers will get a better feel for what their creations need to achieve, and the location scouts will have a much better idea of the locations that they need to search out for shooting particular scenes that take place outside of the studio.

Armed with this information, the actors and crew can set about preparing, rehearsing, detailed planning and scheduling.  All the time the production team control budgets, schedules and keep their stakeholders informed and engaged, to keep the money rolling in to support the production shoot.

As for any project, risk, issue and change management are key activities that need to be started during preparation and continually managed.  Even in the world of films with human actors, things will happen or scenes will not work out as envisaged, requiring changes and adjustments to be made.  In wildlife filmmaking where the “actors” can be less predictable or natural events intervene – rain falling in the wrong place or at the wrong time for example – its important to plan for risks and alternative scenarios.  If the wildebeest on the Serengeti decide to cross the river two miles upstream from where you’ve set up for that big migration shoot or that once in a lifetime opportunity to film flowers in the middle of a desert, and the rains don’t come, you better have a plan ‘b’ and even a plan ‘c’ that can easily be put into action, without blowing the budget or the schedule.

As you start to film each scene, you have a detailed plan of execution; a clear idea of the part of the story to be told; the set directions; the lighting requirements; the lines to be spoken; the behavior to be captured; the time allocated for the shoot and a clear vision of what success will look like at each stage.  With the benefit of “rushes” the director and crew can get a quick, early look at the results – in effect another form of prototyping.

After principal photography is concluded, it is traditional to hold a wrap party; a party organized for the cast and crew of a film to celebrate the end of principal photography. Aside from promotion by the “stars” when the film is released, this usually marks the end of the actors’ collaboration (save from possible dubbing or pick-ups) on the film.

Post-production and the editing process is probably the major departure between our projects and most films.  The director and editor get to review, cut and stitch together the individual shots; play with the sound and add special effects.  For project leaders, there is usually only one completed version each scene that enables you to move on to the next stage, not quite a single take but close, so preparation and a shared vision of what is to be achieved at each stage is of the utmost importance.

Finally, although only really used in mass-appeal cinema, there is the filmmakers’ equivalent of user acceptance testing – pre-screening different edits of the film to audience test panels to gauge reaction, enabling final fixes and changes to be made before rolling the film out for distribution.

In summary then,

  • Vision and objectives – the Director needs to have a vision and communicate a compelling pitch, to get stakeholders on-board and to keep cast and crew (the project team) on the same page
  • Planning and preparation – systematic development of detail to flesh out the objectives and purpose of each scene and the plans, schedules and activities required for each part of the production
  • Risk and change management – preparation for the unexpected and adjustment to change when things don’t work out as expected
  • Prototyping – gaining early visibility through storyboards, walkthroughs, rushes and sometimes audience testing to ensure that the finished product will hit the mark
  • Project plan and budget management  – keeping on top of the project schedule and costs for each element, as well as the overall project and budgets
  • Team management – keeping the cast and crew engaged, motivated and heading in the right direction to achieve the vision of the finished production
  • Stakeholder management – keeping producers, studios and commissioning editors on-board and informed

Leadership and Innovation in Business Architecture

Welcome to the LIBA Consulting and Advisory Services (LIBACAS) blog page.

Over the coming weeks and months, we will discuss a range of topics related to IT Enabled Change and the part that Enterprise Business Architecture has in defining, planning and executing successful change projects or programmes. Focusing on the themes of Leadership and Innovation, we will be exploring what it takes to deliver real business value and sustainable business change enabled by enterprise applications and technology.

Reflecting on our consultants’ experiences and those of associated experts, we will look at the lessons to be learned from the successful and not so successful, to distill out the factors that contribute to successful change programmes.

By examining “disruptive” technologies and concepts, such as business process management (BPM), mobility, social media, “big data” and cloud, we will be discussing the impact on and opportunities created for companies planning their future operating model, business architecture and to-be business processes.

Too often we hear about projects and change initiatives going awry, with significant time and cost over runs, and failure to deliver the expect benefits.  You read about the benefits that enterprise applications suites offer, only to then read that they lack flexibility, inhibit agility and stifle innovation.  Through this blog, we will be looking to share our own perspectives, share insights from across the Web and explore approaches/techniques that just might make a difference to your next IT enabled change project.

We hope you’ll share the posts, as well as join us and contribute to the debate and discussion – just use the Comments button at the top of this post.