Sunday, October 31, 2010

Stuff happens

When you are managing change, stuff happens. The important thing is not to become too reactive, we must manage the issues and not let them manage us. In order to manage issues, consider this definition:

 A project issue is an identified problem or concern that needs to be addressed either immediately or in the course of the project, in order to successfully deliver the business objectives.

If it does not prevent successful delivery of your objectives, it may not be your issue! Also, you do not have to deal with every issue immediately. Always identify priorities and the "last responsible moment" by which an issue must be addressed. For issue management to be effective the following principles should be adopted on your project:
  • All project team members and stakeholders must be able to raise issues, there should be no constraints in this process. Sometimes, people are hesitant because they are not sure if an issue is important. To deal with this consider introducing the concept of raising an "early warning" of potential issues, and put a management process around these.
  • Rapid and appropriate action is usually critical to the successful management of issues.
  • All issues should be assigned an owner, who is held accountable for resolution.
  • Issues must be escalated quickly, if they cannot be adequately resolved at the project level. If in doubt engage your programme / senior manager asap.
  • The issue management process must be formally defined in commercial agreements for products and services required by the project.
  • Issues often result in scope change. It is important that when this occurs the change process is followed rigourously, otherwise poorly considered scope may be instructed.
  • Issues are frequently first identified as risks that subsequently materialise. In this context they can be considered as failures of the risk management process.
  • Never allow an issue to divert the team away from work that still can be progressed to quality. Compartmentalise the issue, assess the risk and impact, then focus a sub-set of the team on its resolution. Keep others focussed on delivery.
Keep an eye on these KPIs, to help ensure these processes are working. They are also useful measures to provide to your project board:
  • Number of issues without owners
  • Number of issues open for multiple reporting periods
  • Percentage of issues due to failings in risk management
  • Average time to close issues
  • Average cost to close issues

Monday, October 25, 2010

Mythical beasts

In 1975 Frederick Brooks Jr. published "the mythical man-month", a series of essays on software engineering lessons from major programmes of the 1960's and 70's. For many years this was regarded as the classic work on software project learning, but today few people seem to read it.

The important lessons apply not only to software projects, but to all change projects. They remain true today. There are many excellent observations in this book, I would like to remind you of just two right now:

* Adding people to late projects only causes further delay.
* There is often a small optimum team size to solve complex problems.

In simple terms, as project complexity increases, project costs escalate and there eventually comes a point where adding further people or money simply cannot fix things. This point will vary depending on such things as the quality of management, experience of teams and tools involved. However, one thing is certain; as you approach this point the only way to achieve your objectives will be to radically redefine the problem and your approach. Anything less just postpones and increases the pain.







Often, one finds that complexity is progressively revealed during the early stages of a project, and estimates are repeated revised upwards. So build complexity measurement into your risk and estimating processes and measure it regularly. Look for the symptoms and be prepared think differently, and to kill these mythical beasts.


Internal cross charging

In many organisations there are complex and subtle processes for cross charging costs between departments on the basis of service costs or usage. Whilst some people think these create valuable control mechanisms, I hold a different view...

All cross charging is inherently not adding value. I believe it is only sensible to cross charge where this results in creation and reinforcement of behavioural change, otherwise cross charging is simply the result of other organisational failures, and can result in very wrong behaviours being rewarded.

For example consider the widely used technique of amortising project costs through suppliers, converting these into operational costs, and then cross charging for the new services resulting from the project. This could be used to encourage reduced consumption and careful management of expensive resources. However, some change managers use this approach to hide true project costs, or make a tough position more palatable. It can bypass the organisation's controls on investment, and it can also reduce the necessary emphasis on cost control in project delivery.

Similarly, cross charging can create bogus "profit centres", where managers encourage consumption in order to create income which hides the growth in operational costs. If you are cross charging, what is this doing to behaviours, and is this creating the best financial outcomes for your organisation?

Friday, October 22, 2010

Unblocking

Change managers face negative attitudes and cynicism almost every day. Often the challenges to change are primarily in peoples heads. When someone says "it will never happen", I ask:

In an ideal world, what would make it possible?

Listening to the answer to this question, challenging and exploring can help unblock your change.

Thursday, October 21, 2010

A penny saved is a penny of profit!

Sometimes people say to me "not another cost cutting project!". This attitude needs to be stamped out of the organisation. The easiest way to increase profits, or to free up money for investment and innovation is to attack cost. The change manager must create a sense of fun and passion about cost reduction, as this will always be a key part of the job.

Never believe that operational costs cannot be reduced. Whenever I have heard this, it has been subsequently proven wrong. Sometimes it may be correct to increase operational expenditure, but only when this is clearly delivering improved business performance.

I know you are thinking this is just consultancy speak and the real world is different. Well I am sorry, but my bitter experience is that I am right. I like to think of my operational processes and costs as the "goldmine in my garden". Every time I dig deeper, there is another nugget of savings, or improved performance. It just gets tougher, and requires more ingenuity each time. Think of it as a challenge!

Here is my standard recipe... Look at each operational process in turn, drill down, walk through it and talk to the people doing it. Ask them some simple questions like:

* who is making money here?
* what is the market for the products/services involved telling me?
* how do people feel when they are working here, and why?
* where and how is the time / labour used?
* what are my competitors doing?
* how do people in different industries do this or similar?
* how do I benchmark my performance here?
* what is the nature and scale of value being created?
* how is quality defined and measured here?
* what are customers experiences of this?
* how could different people or technology change this activity?
* what are the real barriers to entry / exit / change in this area?
* how do we optimise space and power in this activity?
* could I engineer out this activity, or embed it within another?
* what do my current contracts say, and what commercial options have I got?

There are many more questions. The trick is to keep looking with fresh eyes, challenging the status quo, and to create a culture where this is seen as positive and not another scraping of the barrel.

Sometimes savings can result simply from changing behaviours. One of the most successful initiatives I remember was called "think before you print". Using nor more than a snappy catch phrase, some carefully positioned posters and very small IT changes we reduced print costs by 45% in one large organisation. Always remind people that a penny saved is a penny of profit.


Wednesday, October 20, 2010

More sizzle on your sausage

Marketing people talk about how brands develop from competing in terms of product functionality, then differentiating through service quality, and eventually creating customer experiences aligned with brand values.  This journey has been humorously described as selling the sizzle rather than just the sausage.

Change managers often focus too much on the technicalities of the change, and on plans and analysis.  In delivering change it may be more important to create a compelling vision of the future and invite people to stand in it with you.  Only then will they give you the commitment and support required to really make things happen. So whilst the sausage is important, we must also sell the sizzle!

Does size matter?

Some people think that big projects are more difficult.  I have certainly had some very tough large projects.  However, I have also seen even more difficult small change projects.  I therefore argue that complexity rather than size is the key factor in assessing the difficulty of a change project.

Any change can be complex, as complexity in a problem is usually determined by numbers of:
  • people and organisations involved
  • processes changed
  • requirements identified
  • dependencies involved
  • components in the technology
  • degrees of freedom of those components

Many people do not recognise the characteristics of complex projects.  Some to consider include:
  • Leaders must "declare the future" and "model the way"
  • Resistance to change is magnified by complexity causing confusion
  • There are no simple optimisations, and no right way to do it
  • Early. access to and agreement of information is critical to success
  • Adding more people does not always help
  • There is never enough testing

I will address these and others in future posts.   The most important thing is this... Never believe that you can hold a complex change project in your head, plan every action and foresee every outcome.  Complex change requires strong teams backed by an organisation and process response.  Small project thinking and experience does not always translate.

Monday, October 18, 2010

Relationships are the foundation

Some change managers are strongly driven by results. This is good, but we must not ignore the simple truth that to get great results we must start by building great relationships.


             Results             
        Actions        
        Possibility       
        Trust       
        Relationships        


Relationships build trust, and trust creates the possibility for change. If we have many possibilities some will lead to actions, and some actions will lead to results.

This is a pyramid, the change manager needs a large strong base of relationships on which to build results. In the past change managers were "technicians", expert in planning and analysis. These are still necessary, but as complexity increases the best recipe for success is in building strong relationships across organisations.

The path less well trodden

Really complex change projects often do not have a clear critical path.  You may be able to describe the critical path at a high level, but the complexity of interdependencies and changing reality on the ground make it impossible to analyse in detail.

Such projects are characterised by having multiple possible critical paths, each with emergent behaviours.  During the time you spend analysing the plan, things have changed.  In these cases, trying to optimise the sequence of activities is foolhardy.

In these circumstances my strategy is to keep one eye on the strategic programme, whilst taking action to maximise the quality and volume of work available for each team and person.  This approach is based on the assumption that ensuring people are efficient and effective will ultimately protect any critical path that emerges.

Note the word "quality" here means ensuring work is well defined and with the minimum of constraints.  This is the project managers role; clearing the way and removing uncertainty.  Don't ponder on impossible planning options, instead ask yourself what small thing could we do right now that takes us forward?

It is important when adopting this strategy to manage your RADIO every day, for it will reveal the critical path, and point to the actions required to maintain progress.

Saturday, October 16, 2010

The "and" conversation

Often people say to me that time, cost, scope and quality are strongly inter-dependent concepts.  They argue that if I change one of these dimensions, another must change in response.  They say things like:  "You cannot make our project go faster without making it more costly", or "You can have either high quality or low cost".

This is a basic misunderstanding.  It is always possible to do change faster, cheaper and better.  The concepts are linked, but they are also dependent on your attitude and capability to manage risk and innovation.  You can break these links. What matters is the quality of your leadership, and the passion you inspire in others.

So don't have an either / or conversation.  Today, you can have an "and" conversation.

Friday, October 15, 2010

Opportunity

There is a tendency for change managers to become overly focused on risk. It is always easy to see many risks. This leads to pessimism and a loss of stakeholder confidence. To achieve balance and engage people, it is also necessary to look for opportunities. An opportunity can be defined as:

a potential event that has a positive impact on the achievement of project objectives.

Opportunity Management is the practice of identifying, evaluating and pursuing factors that can maximise the positive impacts, creating value. Opportunities may be about improvement (doing things better) or innovation (doing things differently).

There a numerous parallels between risk and opportunity management. In particular, you (change manager) are responsible for managing project opportunities, and opportunity management is part of everything we do. Good managers continuously identify, evaluate and manage opportunities.

There are four basic strategies that can be adopted for any opportunity:

Exploit - take action to build the opportunity into the project plan, ensuring it occurs, so that the beneficial outcome is certain (probability becomes 100%). 
Improve - identify actions with the purpose of increasing the probability of occurrence and or increase the impact (benefits) should the opportunity occur. 
Transfer - allocate management to another party who is best able to handle it, both in terms of maximising the probability of occurrence and increasing the benefits which may occur.
Accept (tolerate) - leave the situation to chance, if the opportunity occurs the project is fortunate, if not the beneficial outcome is not realised.

Just like risk, opportunity is a fundamental concept in project contracting.  Your suppliers will cost risk and opportunity into a job, and you must always know exactly how your commercial agreements handle opportunities.  Opportunities may take many forms:

Cost reduction - e.g. re-negotiating prices

Cost recovery - recovery of previously spent cash from a supplier for services/products already supplied.

Periodic cost improvement - activities in one financial year that has derived benefit benefits in future years, or agreements on costs that will reduce for future work.

Cost avoidance - avoiding cost that would have been incurred, by not doing things or doing things differently

Income generation - creating additional income in the course of the project.

Quality improvement - improving quality for the same cost or same quality for less.

Scope reduction - reducing scope while still meeting the business need, or eliminating functionality that is not required.

Capital deferral - savings generated from delaying capital expenditure.

It must always be borne in mind that an opportunity may create additional risks, which should be added to the risk register and managed in the same way as other risks.  Risk, opportunity and issue management are interlinked, and should be considered together. A risk may become and issue, or the resolution of a risk may reveal an opportunity. 

Many change managers only explore opportunities when faced with potential cost overruns, why not start earlier! Then you might surprise people, and finish under budget. Also, you may find opportunities that don't save money but do improve quality or customer experiences without additional cost.  These are also good.

Assumptions

Assumptions are items of information that are considered to be true or certain when planning a project without necessarily having proof of it in reality. Failing to manage assumptions is a common and often serious error in managing change.

Assumptions, are a necessary part of the project process. However, all assumptions have an element of risk. It is therefore critical that you recognise and manage this.

  • All assumptions must be captured and documented in an assumptions register.
  • Every assumption should be assigned an owner.
  • Make owners accountable for managing the risk associated with the assumption.
  • Regularly analyse assumptions and implement strategies to close out.
  • Review assumptions at stage gateways and prior to approval requests.
  • Assumptions on interfaces / dependencies are often critical and must be closed rapidly.

Keep a close watch on the total number of open assumptions, the number of open interface assumptions and the duration that assumptions remain open.  Whenever you say / hear / read something, ask yourself what has been assumed.

Interfaces / Dependencies

A dependency is the relationship between your project and any external person, organisation, product or service that it requires in order to complete (in part or in total).  Some people prefer the word interface to dependency.

Despite many learned texts speaking of dependencies only in terms of project planning, it is important to consider the above definition in the widest possible context. In particular dependencies may take many forms including:

Physicalmy generator is bolted to your concrete slab
Functional my sales order message is consumed by your order processing service
Temporalwe need access to this shared resource at this time
Commercial       your service must meet these contractual constraints

Dependency management may be complicated because the 3rd party involved may not be planning in a project environment, and hence the relationship cannot always be expressed by the linkage of tasks in integrated project plans.

In this definition of dependency the interfaces between IT systems are functional dependencies. These are often the most complex of dependencies and require formal definition. Do not however underestimate other types of dependency. 

In practice you will need to:
  • Define dependencies as completely as practicable, and maintain a dependency register.
  • Ensure dependencies are described and managed consistently by both parties.
  • Implement a formal sign-off process for dependencies in order to eliminate ambiguity.
  • Eliminate dependencies through design and implementation methods wherever reasonably possible.  This is known as de-coupling, and is critical in very complex projects.
  • Target risk, opportunity, assumption and action management at elimination of dependencies.  
 In my project reports I like to monitor the number of dependencies without agreed definitions, and an analysis of dependencies we have missed or recognised too late.

NEVER EVER assume that people will manage their dependencies correctly, challenge every implicit assumption, and define every aspect.  Also when contracting for products and services, analyse every dependency and ensure the contracts facilitate integrated working and management across these interfaces.

Seeking closure

The worst thing for a project is when tasks are left 99% complete, or issues are almost resolved. In particular dependencies may be partially completed such that other teams can progress, but are then left incomplete.

Change managers must ensure milestones / dependencies are complete and signed off. All partial completions represent significant risk to a project and must be closed quickly so that the team is not left with uncertainty.

Pause and ask yourself why a task is not closed out? Often somebody may be worried or concerned about an issue. Look at things from their perspective.

Spend a few minutes each day looking for these situations and driving actions for closure.

Clearing the way

Great change managers are always looking ahead; They focus on removing the blockages in front of the project, before these become serious. Their strategy is to maximise the quality of the work available to each team member, so that the project is not delayed by ill defined tasks, waiting dependencies, unresolved issues or questionable assumptions. This is particularly important when dealing with inexperienced or less capable team members.

Spend a few minutes each day looking ahead and target actions to "clear the way".

Interrupting the flow of things

Often difficult issues are not addressed quickly and this leads to big problems. So always know when to interrupt regular meetings and activities in order to focus on the really important things... Recognise when things are broken, and know when to "interrupt the flow". If you suspect a problem, declare it and focus people of facts and solutions.

It is important not to create a reactive culture, put problems in context of existing tasks and priorities, and always ensure people clearly understand what is broken. Note too that delegation builds trust - use it. Don't underestimate your management, delegate upwards too.

Often the problems we face are not so hard, they exist mainly in people's heads. Just try asking the question "In an ideal world what would make this possible" the listen really carefully.

Action oriented

Change management is not passive. The change manager must always be pushing for action, and inspiring others to take action. Remember that projects go wrong one day at a time. Therefore taking rapid action, and chasing actions hard is the best remedy.

As you spot things on your Radio, translate every item into actions. Delegate actions quickly and ensure people fully understand the importance of rapid action. Every time you speak with somebody, have their action list to hand, and follow up.

Great managers create a "lets get things done" culture, in which there is a sense of passion and fun around managing actions.

Measurement

It is often said that "if you cannot measure it, you cannot manage it". It is also said that "projects go wrong one day at a time". Therefore, the experienced change manager will seek to measure progress, cost and quality on a continuous basis. In every meeting, consider what is being measured, and what this is telling you. Good practice in measurement involves:

  1. Designing plans and tasks to facilitate measurements.
  2. Making multiple measurements of progress using different techniques
  3. Never rely only on statements by team members, always look for a physical measurement
  4. Understanding the nature of the uncertainties involved
  5. Seeking independent evidence to backup measurements

Measurement can be formal (run-rate charts on walls) or informal (discussions with team members), but in either case the important thing is to update your risk, assumption, dependency, issue and opportunity logs (RADIO) immediately your measurements tell you something.

Risk is good?

Many people think that risk is bad.  This is nonsense.  Almost every human activity includes an element of risk, and commerce is often about the transformation and translation of risk.  As a change manager you are in the business of risk, you must be an expert in risk management, and you should create an infectious sense of passion and excitement about risk.

A risk is simply the chance of something happening which has an adverse impact on the achievement of your project's objectives.

Take this sentence apart and it tells you that:

  • Risks have an opposite concept known as "opportunity" which concerns positive effects.
  • Risks are not certain, you can take action to mitigate or manage their impacts.
  • Be very careful about what you define as a project objective.  Think always in terms of business outcomes that people can experience, rather than abstract theoretical concepts.

When describing a risk always try to use a meaningful and concise description preferably employing language in the form  "a consequence may occur as a result of an event which is due to a cause".  One should always remember that:

  • You (change manager) are responsible for managing project risks.
  • Risk management is part of everything we do. Good managers continuously identify, evaluate and manage risks, and they embed the awareness of risk throughout the organisation, in such a way that every decision is risk informed.
  • Always know exactly how your commercial agreements handle risk.
  • Risks do not always need to be eliminated, they can be accepted and their impact managed.
  • Consider all forms of risk, including safety & security, environmental, commercial, financial, reputational and legal risks.
  • Risk, opportunity and issue management are interlinked, and should be considered together. A risk may become and issue, or the resolution of a risk may reveal and opportunity.

The process of managing risk is like many things based on a "plan-do-review" cycle:

PlanDoReview
Build control systems into project         Embed those controls           Build into governance
Hold regular risk workshopsTake rapid actionContinuously monitor
Analyse and regularly re-assess Update RADIO logsClose out / escalate

Huge and complex papers have been written on risk measurement.  They will be particular methods appropriate for your industry.  In addition I always measure:

  • Number of risks without credible action plans
  • Number of risks open more than 2 months
  • Number of risks that become issues
  • Weighted cost of risks as a percentage of the anticipated final cost (AFC)

The lessons of risk management are well documented elsewhere.  Here are some of the practical lessons I have learned:

  • People often talk of "thinking the unthinkable", the real trick in risk management is to "unthink the thinkable". That is to let go of the normal way we have always done things and respond to what a risk is telling us.
  • Some problems are best solved by "throwing people at them". Short term intense manual effort in a workaround or mitigation, may prove cheaper than engineering out the risk. Consider this.
  • Make risk management fun! This is an important way of protecting your outcomes.
  • Engage top-talent early. Always look for the cleverest and most experienced people to help address your risks. They will have been there before.
  • Do not try to include every risk in the organisation, be clear what influences project outcomes and when a risk should be owned by operational management.

Enterprise architecture

Enterprise architecture is not just a popular term used by technologists. It is the continuous practice of describing the organisation, processes and technology of a business, their relationships to each other and to their environment, in order to identify business opportunities and improve the management of change. A simple way to think about this is as follows:
  • Architecture is about "stuff". The stuff we have today, and stuff we may have in future
  • Enterprise architects help us to understand and optimise this "stuff"

Enterprise architecture is frequently mistaken to be an "IT" activity.  Information technology is just a sub-set of the technologies in a business environment. Technology architecture, Information architecture, Business Process modelling, Business Analysis, Security Architecture etc are all processes and tools used to help describe aspects of an enterprise, and as such are sub-sets of Enterprise Architecture.

Many enterprise architects make a great deal of noise about methods and tools. These are generally not very important. What matters is the quality of understanding of the business, and the quality of thinking about change. Visio and a spreadsheet can often provide everything else.  Generally an architect will consider the following dimensions of a problem:

  • Business context - strategy, goals, processes, organisation, operating models etc.
  • Information - models of the data and metadata that describe the relevant aspect of business process, organisation, products and services.
  • Systems - the IT applications / other mechanisms that are used by the business. The versions used, their interfaces, messages and data flows.
  • Technology - the technological components (in the broadest sense) that enable systems and process to execute. The versions used, how they are configured and their capacity and capability.

Of the above activities, understanding business context and process are critical.  However, the good change manager recognises that PEOPLE are really the most important factor in the design of change.

Design principles

All organisations have some design guidelines that are used to measure the quality of products and services. In general, such guidelines are based on six principles:

Valued      Innovative      Sustainable      Simple      Safe      Secure

The following describes each of these principles in terms of the attributes of services delivered (it can be applied to products or services). Even if your organisation or process does not adopt this approach, this list can be used to test design quality in almost any context.

Where a thing is built, or a change is implemented that does not satisfy these principles, then unless it is clearly recognised as a design compromise or temporary solution, it will represent some form of project risk. Update your RADIO and ignore it at your peril...

Valued
* Services must be designed from the stakeholders perspective
* Services should enable resource rationalisation and performance improvement
* Services should create and enable process flexibility
* Services should make business processes explicit and autonomous
* Services should be pervasive and support real-time business
* Services should enable transparency of all business costs
* Services should provide clear cost / benefit / process options
* Services must be based on a whole life-cycle cost approach
* Services must drive year-on-year unit cost reduction

Innovative
* Services should exploit the value of information as an asset
* Services must protect and exploit IPR and know-how
* Services should stimulate and support creativity and collaboration
* Services should enable information to be shared
* Services should recognise the critical role of the consumer in driving change
* Services must support the virtual extended enterprise

Sustainable
* Services should be easily maintainable, without disruption to operation.
* Service life-cycle environmental impact must be minimised
* Service total power consumption must decrease year-on-year
* Services should be based on re-usable components

Simple
* Services should be simple and intuitive to stakeholders
* Services should allow access to information through standard interfaces
* Services should be designed to minimise exposure to supplier strategies
* Services must be designed for upgrade and replacement
* Services should be designed for inter-operability
* Services must be built upon open standards
* Services should require minimal integration
* Services should be based on commodity components
* Services should be designed to control technical diversity
* Services must have little if any customisation
* Service complexity should be abstracted from infrastructure through virtualisation

Safe
* Services must be safe to operate and maintain
* Services must be safe to build and decommission
* Services should support and encourage safe behaviours

Secure
* Services must be secure by default
* Services should be sustainably sourced to minimise risk to supply
* Service change must have minimal business impact
* Services must support and enable regulatory and legal compliance
* Services must be manageable and designed for self-management

Listen to your Radio

To analyse the real state of a project or activity. The change manager tunes into these key areas...

Risks     Assumptions     Dependencies     Issues     Opportunities

Whatever you are doing, put it into this context. In practical terms this means capturing and updating risk, assumptions, dependencies, issue and opportunity logs at least once a day. As you make notes in meetings think in these terms, and update the logs shortly afterwards. Immediately analyse these and take action! Do not leave this to the next day.

Change management is about uncertainty, if the outcome and the journey were known, we would not need skillful change managers. Therefore this RADIO model is at the heart of successful management.

TUNE YOUR RADIO, LISTEN CAREFULLY AND THEN TAKE ACTION!