Project success?


The following questions are some of the questions that prompted this article:

  • How do we determine whether a project has been successful or not?
  • Is coming in on-time and on-budget a reasonable measure of success?
  • Do 70% of change projects fail?
  • Do 70% of IT projects fail?
  • Is there any relationship between project failure rates and business strategy failure rates (where the latter is purportedly anywhere between 80% and 98%)?

Let’s explore some of these questions, noting that:

  • we have not conducted any form of extensive survey
  • any such survey may have dubious results and be of little value

What is being measured?

It is important to explore and establish clarity about what we are seeking to measure.  Is success about:

  • the project activity?
  • the project deliverables (or output)?
  • the project outcomes?

Many articles and organisations seem to focus on measures such as project cost and timeframe (on-budget and on-schedule).  These are simply measures of project activity, and such measures prompt some interesting questions:

  • If a project exceeds budget, is that a good or a bad thing?
  • If a project exceeds budget, does this indicate poor project execution or poor project planning?
  • Is it worth making the effort to “deliver on budget”?
  • If a project was under-estimated and is delivered on budget, what quantity or quality of output has been forgone?

Project Model

The following model can be used to help understand the different measurements that can be used to assess programs and projects.

Project-model

A project takes inputs and delivers outputs which are used by the customer to achieve outcomes.  The project will proceed within an environment and be subject to appropriate governance.

Project measures fall into three broad categories:

  • Inputs
  • Outputs
  • Outcomes

When we measure costs and time, we are measuring inputs.  This tells us nothing about the quantity, quality, utility or value of the outputs.

When we measure products and deliverables, we are measuring outputs.  This tells us nothing about the utility or value of the outputs ie. the benefits and outcomes realised from using the outputs.

Implications

So, when we report that a project has failed because it exceeded budget and/or schedule, this is simply reporting on the quality of our estimates and on our management of inputs and use of resources.

Projects are undertaken to achieve outcomes.  Project success needs to be measured in terms of expected and unexpected outcomes that are realised.

When we start projects, we identify outputs and outcomes, and explore:

  • what constitutes success?
  • how would we recognise success?

These are the measures that we need to use, not at project completion, but some time after completion to allow time for the customer to start making effective use of what we have delivered.  Then we can evaluate the degree to which we have been successful.

Next time

… you hear about a project failure, take a closer look at what is being measured and decide whether the “real success” of the project is being measured or not

… you hear someone challenging myths about project failure, take a closer look at what is being measured and what they are proposing as alternate measures

… you are commencing a project, take the time to explore how you will determine whether:

  • you have adequately defined your targets
  • how realistic your targets are
  • you have a clear baseline against which to measure progress towards your targets

Then you will have a better basis for measuring project success.

 

Business model maturity

desel_051

The core model that most people use to explore and articulate the motivation, offerings and capabilities required to pursue an enterprise is the business model. This article explores our perceptions of the evolution of the business model artefact through four phases which we have named as versions (1.0, 2.0, 3.0 and 4.0).

Business model 1.0

This “version” encompasses the origins of business models, which were financial models reflecting the expected revenues for products and services being offered, the expected costs of producing, distributing or providing, and maintaining the products and services, and the resultant profits realised as a return on the investment made in establishing and operating the proposed business.

business-graph-with-arrow-showing-profits-and-gains_MyZdKgKd_L

This model would be reviewed and revised as:

  • opportunities or threats emerged in the market
  • product / service offerings could be extended, refreshed or reduce
  • improved efficiency and effectiveness needed to be or could be pursued

Business model 2.0

The next version emerged in the dot.com era and was formalised by Alex Osterwalder in his work and articulation of Business Model Canvas. This work established an ontology for the business model, in terms of the domains of information that required attention and articulation, covering:

  • Customer segments
  • Channels
  • Relationships
  • Key capabilities
  • Partners
  • Cost structure
  • Revenue streams
BMC

This ontology and associated tools have seen widespread adoption, with consulting services available to support startups through to large corporates in developing an expression of their business model(s).

Business model 3.0

This version takes the concepts in Business Model Canvas and extends them further based on a systems view of an enterprise and the environment in which it operates.

This encourages greater attention to the enterprise-as-a-system and the enterprise-as-a-part-of-broader-systems. In doing so, attention is given to:

  • the broader value chain of which an enterprise is part
  • the potential for enterprise suppliers to provide services directly to enterprise-customers (circumventing the value proposition of the enterprise)
  • the creation of new market dynamics through adoption of market platforms, shared economies and other market disruptions

This evolution explores these dimensions as they apply to the dynamic relationships which exist in the market environment, as shown in the following figure.

Systemic-business-model

Business model 4.0

The fractal application of business model might entail development of the business model for:

  • an organisation
  • a marketing capability
  • a production capability
  • a supplier chain capability
  • a corporate wide capability (eg. people management)

exploring the dynamics arising from the application of business models to enterprise-subsystems, enterprises-as-organisations, and multi-organisational enterprises.

Fractal-business-model

In practice, this requires an iterative approach:

  • to the application of business models and operating models
  • each component of the operating model being considered an enterprise-in-focus to which the next level of business model and operating model is applied

which effectively constitutes an objective – strategy cascade where:

  • business model establishes the objective(s)
  • operating model establishes the strategies

Maturity

Use of these models can be considered in terms of maturity, starting with a simple financial model (level 1) and eventually maturing to integrated application from individuals to the Board (level 4).

At what level of modeling maturity:

  • do you operate as a leader for your role and your team?
  • does your organisation operate?
  • does your industry or region operate?
  • does your nation operate?

This outlines the essential elements of the manner in which business model development is applied in any circumstance that we encounter.

 

Architectural sufficiency

This article is a republishing and updating to reflect some thinking which emerged in the comments when the original article we published in early 2016 – here is a link to the original article

One of the questions that I posed in the opening posting of the series that I started at that time was:

How would we go about describing the current or intended architecture of our enterprise?

Common models and views

In another posting about conventional practices, I indicated that the development of organisational charts and position descriptions were one of the current practices undertaken in many enterprises.  What other models and views do we develop to describe the current or intended architecture of an enterprise?

The next most common model and associated views is the process model.  This can be prompted by a range of motivations, including:

  • A continuous improvement program which encompasses the progressive development of process models for various subsystems within the enterprise
  • A quality management program, potentially in conjunction with adoption of standards within the ISO 9000 series, where the Corporate Management System or the Business Management System provides shared access to the processes developed to ensure a consistent approach to deliver of quality products and services
  • An information systems or IT system program which is establishing improved processes and/or IT enabled processes which need to be described to support the design and realisation of the proposed system

In the latter case, it is likely the information models and views will also be developed to reflect the way in which the shared information is to be organised, managed and accessed.

Key dimensions

What other dimensions of an enterprise are part of its architecture description? Various models suggest the following dimensions are encompassed:

  • People / roles / organisation units
  • Process
  • Information
  • Assets (offices, plant, equipment)
  • Finance
  • Information and communication technology (ICT)

These seem to be the primary:

  • resources
  • integration points

which can be encompassed within an architecture which has a focus on elements and relationships which are fundamental to the enterprise-as-system.

Other elements

There are other elements which are not owned and controlled and hence not designed and architected which feature in architecture descriptions, as there is a need to understand relationships, flows and interactions, both internal and external.  Hence, architecture descriptions will reference external entities, including:

  • Customers and consumers
  • Suppliers
  • Partners
  • Competitors
  • Regulators

This is an important feature of architecture descriptions and enterprises.

An architecture description includes reference to entities and relationships beyond the bounds of the enterprise

This has proven to be a point of considerable debate and confusion surrounding what I perceive to be the failure to appreciate the distinction between the scope of the enterprise and the scope of the architecture description.  The latter must convey information about the enterprise-as-system “in its environment” and necessarily includes entities beyond the scope of the enterprise.

Sufficiency

Do we have a sufficient coverage of entities and relationships to encompass the description of the architecture of our current and intended enterprise?  Are these sufficient?

The ultimate test, based on ISO 42010, is whether these provide all the necessary elements to address stakeholder concerns arising in considering the current or intended architecture of an enterprise.  In my experience, these have been sufficient.  I leave the question open as others may find my list incomplete.

With these foundations, we can now explore the models and views which seem to prove most useful across the range of architectural engagements in which I have been involved.  This draws me back to elaborating further on a number of the models that I listed in the posting about the elements of architecture descriptions, including:

Postlude

A key message in this posting on current practices is exactly what Doug McDavid said in a comment.

Executives and Managers create various elements of the architecture description already.

They are prescribing and describing the architecture, whether they realise it or not and whether they call it architecture or themselves architects, or not. What I have not said explicitly, but is implicit in this series, is in line with his linked article, is that aspects of the architecture become evident in various enterprise documents, and therefore can be discovered and, if necessary, made more explicit.

For example, principles are often implicit in business language and business documents, but few enterprises make the principles underpinning their enterprise explicit. Similarly, language and key concepts, commonly found in enterprise documents, may well reflect important elements of process and information architectures. A couple of colleagues have experimented with tag clouds as a tool for more rapidly identifying elements of the enterprise ontology.

A number of articles will be written over the next few weeks, expanding on key principles underpinning the practices that I have found most effective in supporting Directors, Executives and Managers to better architect their enterprises.

 

Organisations and enterprises

Many words have been written and many said about organisations and enterprises, and the extent to which they are the same or different.  This article is prompted by a current “debate” over the meaning of “enterprise” and a suggestion that “enterprise” is distinctly different to “organisation”.  I am not so sure about that!

So, this is part of my “normal process” of “thinking out loud” – an approach where I:

  • outline what I currently “think”
  • refine what I think in order to express it in a clear and coherent manner
  • expect to be challenged
  • am offered the opportunity to refine my thinking, based on the questions and challenges arising from articulating my thinking

For me, this is the way I have become better at understanding, articulating and practicing the disciplines of architecting enterprises, governing enterprises, becoming more systems savvy, and of recent times, becoming more brain savvy.

Organisations

In using this term, it is important to distinguish between organisations and legal entities.  Oftentimes, when I think of organisation, I am thinking of:

  • a commercial firm
  • a government department
  • a community entity

This pertains more to the legal status of the entity and to the basis upon which it is constituted, managed and governed.

In this discussion, whilst it includes all of these types of organisations, I am including other forms of organisation, including:

  • an organisational unit
  • a cross-functional team
  • a multi-organisational operation
  • a community
  • a region
  • an industry
  • a profession
  • a project
  • a program

Each of these groups have:

  • membership
  • bounds
  • shared interest and purpose
  • varying degrees of linkage and relationship
  • an existence for some period of time
  • some form of means by which they are “organised”

So to the definition of organisation

an organised group of people with a common purpose

Enterprise

A number of blogs have been written on this topic already, including:

In summary …

an enterprise is most easily understood as an undertaking or an endeavour

Context

Given a systems view of organisations and enterprises, it should not be surprising that there is a need to consider system context, including:

  • the market or environment in which the organisation, enterprise or system exists and operates
  • the economy, community and society within which the market and environment exists

Any organisation, enterprise or system will need to:

  • give attention to entities in these broader contexts
  • understand the relationships that exist or should exist, both
    • across the organisation / enterprise / system boundary, and
    • amongst entities in the external environment
  • adapt the structure and behaviour of the enterprise, both
    • in light of changes in the external environment, or
    • in order to shape and prompt changes in the external environment

These activities are evidenced as an inherent part of organisations through:

  • governance processes (attending to accountability and strategy)
  • intelligence processes (informing the organisation of activity in the external environment)
  • marketing processes (understanding changes and opportunities in the external environment)
  • supplier, partner, customer / consumer, regulator and other stakeholder relationship management processes (providing direct knowledge and understanding of key external relationships)

These represent the means by which organisations attend to life-beyond-the-organisation and about which organisations develop enterprise models to enable them to understand, architect and realise their intended business models and operating models.

In this respect, the business model is the key artefact which prompts understanding and articulation of the balance required between internal and external affairs (so to speak).  Further articles outlining key thinking and practices in this area, include:

Enterprise concept and views

There are a range of benefits that I see arise from taking an enterprise view of an organisation, including:

  • organisation tends to prompt a people / role based view
  • enterprise encourages a purpose and process view
  • enterprise allows the balancing of multiple views including:
    • strategic views
    • process views
    • role / responsibility views
    • information views
    • facilities / location views
    • service views (composite of internal and external sourcing)
    • integration views
  • enterprise provides an abstraction from the connection to organisation and the threat that arises in considering organisational change
  • enterprise enables views that are agnostic to a particular dimension

For me, there is incredible value in taking an enterprise view, but none of the value derives from viewing organisation and enterprise as distinctly different.  Perhaps the following is a reasonable way to summarise?

Enterprise is an abstraction that is orthogonal to organisation

 

Bringing it all together

STORYB~1.JPGOver the last two and a half years, I have written and published over 50 articles which relate to architecting and transforming enterprises.  These have been published on LinkedIn and an index of all articles maintained in the article “Architecting Enterprises“.

About twelve months ago, I started copying these articles across to this blog site.  As I did that, I published a post on LinkedIn which proved to receive far greater views than many of my original articles.  In parallel, Interface Consultants started holding public Lunch’n’nLearn events where I was using content from these articles in sessions on:

  • Curious about being more brain and systems savvy
  • Bootstrapping a systems savvy enterprise
  • Cultivating capabilities
  • Diversity, coherence and assurance (for Boards)

Reflecting on the development of these sessions and on feedback from these sessions, it became evident to me that participants in these sessions and readers of this blog need a sense of:

  • the whole story and how the fifty (or more) articles fit together
  • how to find the pieces of the puzzle that are missing without need to read all the pieces that they already know and understand

This is how the process of “bringing it all together” started.  It has led to:

Further content is being developed and will be released.  I hope this becomes an increasingly convenient, easy-to-use, valuable resource for those involved in transforming their enterprises and looking to advance their mastery of this highly rewarding activity.

Feedback on the articles and on this initiative to “bring it all together” is always welcome.  Please feel free to post comments or to contact Interface Consultants or Peter Murchland if you wish to respond privately.  These articles are also used to prompt discussion in the related LinkedIn Group – Enterprise Modeling

 

Enterprise design mantras

mantra-om-mani-padme-hum_zkPVd0Lu_L

What mantras do you find underpin your AE practices? Are there particular principles or guidelines that you remind yourself about or that you share with others in your team and amongst your stakeholder community?

Here are some of the mantras that I find myself repeating …

  • Keep the end in mind
  • Business process not system process
  • Continuum between autonomy and control
  • What is the system-of-interest?
  • What constitutes success?

Keep the end in mind

Many of us are trained to determine our objective and then explore the strategies for achieving the objective – determining the ends and exploring the means. So what is important about this mantra? Isn’t it a natural part of our daily practices?

Many years (actually decades) ago, I read “I’m right, you’re wrong” by Edward de Bono. I gained a number of insights from that book, but the most frequently referenced insight was:

creative ideas are logical in hindsight

This insight is important to solving problems and to learning. Once solved or learned, the problem seems simple. This can also mean that a solution can be more easily understood by working backwards rather than forwards.

This simplicity is often overlooked when we present the problem and solution to stakeholders. It all seems logical to us but can seem puzzling and difficult to our audience. This applies in many different scenarios, including many of the business improvement or business transformation undertakings I have encountered.

It was recently brought to mind and reinforced by a colleague sharing that they read books backwards – last chapter first. Another practice is that of describing what I aim for meeting participants to have gained at the end of the meeting – shared understanding, agreed actions, etc. This often helps construct are more effective sequencing of the agenda.

clarity in relation to goals, deliverables, and outcomes

has proven to be a valuable practice – keeping the output and outcome in mind as we design and plan our way forward.

Business process not system process

I have lost count of the times that I have encountered IT projects where the focus is on the IT system and not on the business objectives which the IT system should be designed to support.

Indicators of an inappropriate focus include:

  • A project scope expressed in system function terms rather than business terms
  • A “process” diagram which is focused on the interactions with the system and the “system processes” without attending to the “business processes and practices”
  • A project with system deliverables and few or no business deliverables
  • A project which regards business change as “out of scope”

Practices which have proven to prompt greater clarity and quality include distinguishing between:

  • business objectives, system objectives and project objectives
  • business scope, system scope and project scope
  • business processes and system processes

The first two areas typically apply in the initiation stages of a project, where as the third arises at various stages in the project, and hence is the distinction that is more frequently made (and needed).

Balancing autonomy and control

For any situation where alternate processes or means are being considered to achieve an agreed objective, consideration often needs to be given to the nature of the circumstances and the type of action or response that might be needed.

For example, if the situation entails lots of variability and unknowns, then it is likely to need a person to determine the nature of the situation as well as the appropriate action. Significant autonomy should be given to a person to determine and take the appropriate action. This is typical of situations that are described as being “knowledge work”.

There are other situations where it is possible or it is necessary to be prescriptive and for specific consistent action to occur. Situations such as ensuring consistent counting rules are applied to an information set, or where financial transactions need to be processed in a consistent manner. These situations call for appropriate control to be applied, with no need for flexibility or autonomy.

Redesign of processes requires careful consideration to the areas where autonomy versus control is required and how to design a process to achieve the appropriate balance and combination of these responses.

Be clear about the system-of-interest

Enterprises are complex. Enterprises can be viewed from the perspective of being a system-of-systems.

If one considers a system-of-systems, we have the situation where:

  • the whole is a system
  • the parts are each systems
  • some parts may be systems-of-systems

In addition, there are human activity systems (social systems or soft systems) and technology based systems (machines, computers, etc or hard systems). Given the pervasive use of IT systems, many times “system” is taken to be a synonym for “IT system”, making it more difficult for some to consider the “system” being a social system or socio-technical system.

If systems based views and techniques are to be applied successfully, it is important that those engaged are considering the same system – that the system-of-interest is clear, as it may be part of a containing system, and it may be composed of parts-as-systems. Oftentimes, I have found that the differing views or confusion being experienced in analysing or diagnosing systems has arisen because different stakeholders are holding a different system as the focal point.

Being clear about the “system-of-interest” or the “system-in-focus” ensures that the differences emerging arise from different perspectives, perceptions and conceptions of the system-of-interest, and not through a difference in the point of focus.

What constitutes success?

This is a valuable question that I learned as a Director on a Board, but is equally applicable in other settings. Similar questions are sometimes asked such as “What does good look like?”

Such questions draw us to being clear about outcomes such that then we can consider the differing outputs that might be required to realise the outcome and the alternate processes (and strategies) which might be pursued to deliver these outputs.

Exploring enterprise lifecycles

Wherever an enterprise engages in architectural activities, there are three key lifecycles which come into play:

  • enterprise operations, managing the entire lifecycle from prospective customer to satisfied customer
  • enterprise development, managing strategy, innovation and change, delivering and embedding new or improved capabilities within enterprise operations
  • enterprise architecture, managing the structures and principles through which enterprise operations and development are effected

Enterprise-development-1

Any engagement needs to assess:

  • the current position within these three key lifecycles
  • the maturity of the organisation with respect to each of these lifecycles

in determining where to direct efforts to deliver the greatest value to the organisation.

EM_journey_v0-15

In this respect, the approach shown above for architecting enterprises provides an effective mechanism for managing each of the lifecycles, prompting an assessment and appreciation of:

  • vision
  • future directions
  • capability gaps
  • initiatives addressing gaps
  • program (roadmap) of activities in train

This could lead to three inter-related capability development cycles for maturing the enterprise architecture capability, enterprise development capability and enterprise operations capability.

Enterprise-development-2

Where is your organisation placed in terms of its architecture, development and operations maturity?

To what extent does your strategy development take account of your maturity in these three domains?

To what extent does your program planning and execution explicitly take account of these differing levels of maturity, including:

  • delivery risks arising from varying maturity levels?
  • adaptive approaches which allow for the necessary enterprise learning required for successful delivery?
  • synergies which can be pursued to leverage investment and effort towards enhancing maturity in all three domains?