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.

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.

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