Linking transformation projects to strategic intent

I spent a fascinating morning yesterday with the head of transformation design in a UK government department.  Like most government departments, the transformation is about cutting costs while improving outcomes.  The lever for achieving this is technology – in particular, digital technology.

The transformation program has been funded and has been underway for a year or more.  The problem we were discussing had two parts to it.  First, how can the leaders be sure that the transformation projects that are underway will deliver the strategic intent (cut costs and improve outcomes)?  Second, since some projects are over spending, how can the leaders decide which projects to cut out or cut back?

Step one in dealing with these questions, of course, is to get really crisp about the strategic intent.  I thought that the department had done a good job – here I am simplifying a little to maintain confidentiality – but there appeared to be good clarity about the objectives of cutting costs and improving outcomes.  The department had also done a segmentation of types of citizens that it was interacting with, and it had sub-divided the overall transformation program into sub-programs and then into projects.  So what was the issue?   The sub-programs were not aligned either with the strategic intent (e.g. sub-programs for cutting costs and sub-programs for improving outcomes) nor with the types of citizens (e.g. sub-programs for citizen group X aimed at both cutting costs and improving outcomes and sub-programs for citizen group Y, etc).  Also, the sub-programs and projects had not been prioritized in terms of their expected impact on the strategic intent.

The head of transformation design asked for advice on whether a different transformational methodology would give more accurate strategic alignment. One approach that had be suggested to him was to use “capabilities” as the connecting tissue between strategic intent and projects.  By listing the capabilities needed to deliver the strategic intents (level 0), then listing the capability components for each capability (level 1) and then the requirements for each capability component (level 2), etc, it should be possible to connect projects to intent.  I felt uncomfortable with this approach, because I could not see an easy way of breaking “cut costs” or “improve outcomes” down into a MECE (mutually exclusive and collectively exhaustive) list of capabilities … and, even if this were possible, developing MECE lists at level 1 and level 2  would be difficult … and, even if this were possible, connecting level 2 lists to projects would probably also be difficult.

So I suggested another way of linking strategic intent to projects: chunk up the department into smaller pieces each of which should be trying to “cut costs” and “improve outcomes”.   Here the value chain map tool is powerful.   So my suggestion was to start with the citizen segmentation (again I have simplified a little to protect confidentiality) and to develop value chains for each segment and for each product or service provided to each segment.   Then lay out a simple value chain for each of these segment/service combinations (probably around 100 in total).  Then apply the intent – “cut costs” and “improve outcomes” – to each of these 100 value chains.

This will provide a MECE list of the changes needed.  This list of needed changes could then be set against the list of transformation projects to see if the projects cover all the needed changes.  If not, the intent will not be delivered.

By rank ordering the 100 segment/service combinations based on their strategic importance, and then ranking the needed changes by likely impact on “cutting costs” or “improving outcomes”, it would be possible to rank order the projects by their likely impact on the strategic intent.  This will then make it possible to decide which projects to drop or cut back.

The conversation reinforced a concern I have with the capability mapping approach to operating model design (see previous blogs).  The head of transformation design also explained that the differing languages of design and Portfollio management sometimes clashed. Whereas my experience is that leaders readily connect with the value chain language and visual representations used to support it.

Of course, in some ways, it is just a different use of words.  What I call a value chain could also be called a capability chain or a process chain.  But, in other ways, there is a huge difference.  The value chain mapping approach encourages you to chunk the organization up into “segments” each of which is aiming to deliver value to a target customer or beneficiary.  So your focus is on what the organization is trying to do for its stakeholders and to a presumption of decentralized units each targeted at a different segment.  The capability mapping approach encourages you to chunk the organization up into capabilities.  The focus switches to being more internal, and to a presumption of centralized functions in charge of these capabilities.  These are very different ways of thinking about organizations.  The former is more likely to help you connect with strategic intent.

Advertisements

About andrew campbell

Ashridge Strategic Management Centre Focus on strategy and organisation Currently working on group-level functions and group-level strategy
This entry was posted in Capabilities, Transformation and tagged , , , , . Bookmark the permalink.

25 Responses to Linking transformation projects to strategic intent

  1. Peter Murchland says:

    Andrew – a really interesting scenario …

    If one were to use capabilities, then these would be used to express the sub-programs arising from segmentation of the market and the activities required to deliver services to the market segments. Applying capabilities to the transformation sub-programs is focussing on the means, rather than the ends, and will not aid any consideration of the relative outcomes / transformation investment ratios.

    It is not the “technique” (process) that is wrong – it is the “application” (practice) that is poor. In fact, your description of value chain mapping is doing exactly what good capability mapping does – just using some different labels!

  2. andrew campbell says:

    Yes Peter, as I say, at one level it is just labels. But, at another level, it is a very different way of looking at organizations. Yes, sometimes a value chain is evident in a capability map. But more often it is not. And I can never recall a capability map with tens of value chains represented. Maybe you should send me an example.

  3. Peter Murchland says:

    Andrew – several thoughts for your consideration:
    a) there are good and bad capability maps – value chains will not be evident in all capability maps
    b) the worst capability maps are those that are a set of boxes with labels with no rigour applied to their formation – much like the result of a brainstorming session
    c) the best example that you might conceive is to consider the APQC PCF (process classification framework) which goes to four or five levels – for each process at each level, there is a corresponding capability and in each lower level, there are sometimes a value chain – it requires analytical thinking to ascertain those that are a value chain and those that might require refinement into a value chain
    d) there are likely to be a smaller set of value chains than 100 required – depending on the size and capability diversity of the organisation you are considering – as often, there can be a common value chain for more than one product / service
    e) the detailed value chains are likely to be elaborated in the planning phase of each project in a transformation program, so one does not need to do all the analysis “up front” – it can be progressively elaborated
    f) the following are all potentially common patterns, depending on the quality of their content:
    + value chain
    + capability map
    + results chain
    + business process model

    I will take a look at what I might be able to send to you – most examples are client confidential. Most are high level, more likely to contain 20-40 capabilities within a smaller number of value chains.

  4. andrew campbell says:

    Peter, The other thing that has been going through my mind is that a capability is a kind of value proposition. Let me explain. A good value chain (or value stream) is a sequence of work steps aimed at delivering a value proposition to a target customer or beneficiary. The outcome of the value chain is the vale proposition. So we could say that the value chain is a capability: a combination of people, process and technology that delivers a beneficial outcome (value proposition). As I understand it, a capability is best described by its beneficial outcome – so it is a form of value proposition.

    Thank you for engaging on this. Andrew

  5. Peter Murchland says:

    Andrew – I think we are finding the common ground. Yes, “capability” is an attribute of an activity system and it describes “part” of the value proposition of the nominated system. The nominated activity system may offer more than one value proposition, thereby being seen by different people as part of different value chains, even though the activity system is the same. One of the values of “capability” is that it allows the strategist to consider changes to both means and ends (since it is a purposeful system – cf Ackoff) ie. exploring what other outcomes / value propositions could be sustained with the same activity system (capability) or considering what alternate capabilities could be used to achieve the same outcome. Teece and others provide reference materials in relation to dynamic capabilities, strategy, etc.

    In this regard, my definition for capability comes from Stephan Haeckel (Adaptive Enterprise) – Capabilities are organizational subsystems with a potential for producing outcomes that contribute to the organization’s purpose – and I have integrated this with the thinking of Teece and others. To ensure that my capability map is rigorous, I consider the underlying system that it is representing, which brings far greater rigour than a brainstormed list of “abilities” that some others consider an acceptable capability map. One of the simplest tests of any capability map is a request for the next level – it soon becomes evident as to whether there is rigour around the scope of each capability!! (This applies as much to value chains as it does to capability maps – as it is often the hidden or duplicated or clashing lower level capabilities that are the source of additional time and cost in delivering the proposed capability as part of a transformation program.)

  6. andrew campbell says:

    Yes Peter. I think we are in agreement, least in part. Because it is possible to interchange words like work step, activity and ability or outcome, value and value proposition, those of us who understand the nuances can use whatever combination of words works for us. However, these frameworks and word definitions are not for our benefit (well not for our benefit once we are clear what we are talking about). We need to create a language to help others, particularly those who who are not expert.

    So where we possibly disagree is about what we should teach young business architects and analysts. I am firmly of the view that it is best to teach them to focus on the value chain first. In this way they understand, first, the value creating backbone (or backbones) of the organization they are looking at. They need to understand this first because the default organization should be to structure by value chain. Of course, this default is rare because there are normally “capabilities” that cut across the value chains that can perform better if managed as a shared capability (lower costs or higher skills or better asset utilization or …). But without starting with the value chains, understanding the logic of the default position and then thinking about where and why to move away from the default, the analyst can easily get lost in a world of capabilities …. and cause their organizations to become over centralized.

    Thank you for the challenges – it is helping me think out why I feel uncomfortable with the capabilities approach. I recognize that I am pushing against a huge body of knowledge. But also, I am running with the wind of senior manager attention.

  7. Peter Murchland says:

    Andrew – there is so much loaded language around already – you don’t like capability – yet it is a well developed term in systems engineering used successfully in designing, building and maintaining space shuttles, aircraft, naval vessels, transport systems, to name just a few. There are some key terms and ways in which they inform how we conceive of and realise systems. I find it better to provide feedback to those with whom I engage, rather the prescribe and impose my language set on them.

    Were it possible to create a simple, clear language set, there would be far less books (like yours) on these topics and perhaps no need for Business Schools!

    What I have outlined here is the basis upon which I have successfully trained new and experienced analysts and architects, as well as other change professionals.

    There are multiple ways to introduce the consideration of value. I start with the business model (which precedes operating model) and prompts an exploration of outputs, outcomes, stakeholders, channels and value propositions. The fractal application of business models and process models can generate value chains without ever mentioning the concept. On the other hand, if a person is familiar with Six Sigma and lean thinking, I know they already understand the basics of value chains and may engage from a different starting point. Another way is through a design thinking mindset. Each will generate what you would recognise as value chains, with the appropriate discipline applied to the conception and formation.

    With respect the bodies of knowledge, you often seem to reference IT understanding of capabilities, which is far less well formed than the field of systems engineering, and strategic planning. They are better starting points for a conversation around capabilities.

  8. andrew campbell says:

    Peter, I don’t think I have a problem with the word capability. But I do have a problem with the way capability maps are used (by the average user – not by the expert user) in the process of business design. I suspect that I would be completely happy with the way the word is used in space shuttle design: but I would be interested to know whether the concept of capability map is used in space shuttle design.

  9. Peter Murchland says:

    Andrew – good!! So, the issue is about the competent and mature development and use of capability maps, not capability models / maps per se.

    If you are interested in exploring this area further, I recommend that you consider:
    a) Capability maturity model integration (which offers insight into the relationship between capability, process, value chains
    b) Capability based planning
    c) Capability management in business (see Wikipedia)
    d) Enterprise systems engineering (SE BoK)

  10. This is a very interesting discussion, so thanks Andrew and Peter, firstly. You’ve both talked about a couple of topics that I’d like to comment on; the nature and value of capabilities and linking capabilities to strategy for transformation.

    In the change areas where I’ve worked, there has rarely been a clear link between the programmes and projects that are ongoing and what part of the business strategy they are supporting; often because the business strategy is not defined or poorly-defined.

    I’ve used capabilities to define what the organisation I was working in actually did. Designing the capability models, I could propose a common language across various business silos and assign owners, applications, costs, etc. They have been a great help in creating a consistent, stable starting point for transformation work.

    I see capabilities as that high-level view of the organisation as a whole and what it does (not how). I drill down into capabilities until I get to a point where I am describing an end-to-end process with a start, a finish and some defined value at the end. At that point, I can go into a detailed process map, showing variations by product, business, location, etc. I am very clear about naming conventions, so everyone knows what is a process and what is a capability.

    At the other end, I’ve defined business strategy in terms of goals and objectives and been able to then link programmes and projects to those objectives. I use the capability map, as well as product catalogues, customer segments, customer journey maps, etc., to define the context of the changes proposed and the potential impact. By doing this up front, we (as architects) get a view on projects across the organisation and can identify possible overlaps and opportunities for consolidation and cost-saving.

    I just wish more companies would take the time to define their strategy better.

    • andrew campbell says:

      Great comment Thushan. Thank you. Another example of an expert successfully using capabilities to help with transformation. So clearly the capability modeling process can work. The question that I have been wrestling with is whether it is the best (meaning easiest to link with strategy and easiest to teach and easiest for senior managers to understand and easiest to link with transformation projects) … and maybe there are some other criteria.

      Because most strategists have been brought up on Michael Porter, they understand value chains and segmentation well. Hence I am judging that a value chain mapping approach will be easier for strategists to connect with. A strategists view of capabilities is more connected with “sources of advantage”. The same appears to be true for senior managers.

      But there is another reason I am concerned about the capability approach. I think it leads to too much centralization because it encourages designers to bundle like capabilities together rather than having them distributed under the command of value chain leaders.

  11. Peter Murchland says:

    Andrew – you raise some interesting questions in my mind.

    1) On what basis do you say that most strategists (or senior managers) have been brought up on Michael Porter? I presume you mean any strategist who has done an MBA (or equivalent)? I suspect that there are plenty involved in business strategy that do not have that background in the markets in which I operate.
    2) On what basis do you say that too much centralisation occurs? One of the values of capability analysis is to be agnostic to various factors and to enable analysis of different modes of realisation. Given the ability to disaggregate and distribute capabilities with some technology enablement, perhaps the problem is in relation to the manner in which options are formed and assessed? Or perhaps there are other critical enterprise outcomes that are not being adequately addressed through design?

  12. andrew campbell says:

    Peter, It would surprise me if anyone had the title of strategist and was doing competitive strategy work who was not familiar with Porter’s five forces tool and value chain analysis. But maybe you meet different strategists than I do. I have run a network of strategists in Europe for nearly 30 years – so I feel I know my audience on this one.

    The centralization issue is more a matter of orientation. At a strategist I start with the presumption that each value chain will be a separate organization unit with a good deal of autonomy. I then move away from that in a design only where there are significant performance gains from doing so. The capability approach does not start with the same presumption, and, when used by less expert designers, typically starts with the opposite presumption – like capabilities should be together. In every reference capability map that I have seen this is the case. If you take a capability like marketing, it is typically broken down into different kinds of marketing – on-line, advertising, direct mail, etc. It is not broken down into different types of value chain – standard products marketing, special products marketing, products sold through direct sales marketing, etc.

    • Andrew, with the marketing example you’ve given, I would take a slightly different approach.

      From my non-marketer’s perspective, I think marketing involves identifying your markets, defining your marketing strategy, creating a message about a product or service that your company wants to sell, delivering that message and tracking the results.

      These would be my marketing capabilities; Market Research, Marketing Strategy, Campaign Delivery, Marketing Analytics. Each of these capabilities might be decomposed further, but you can broadly describe these with an end-to-end process.

      I see the examples you’ve given as different variations in the processes within “Campaign Delivery”. The top-level “Campaign Delivery” process might be “Create marketing campaign in line with marketing strategy” -> “Identify campaign target audience” -> “Deliver campaign to target audience” -> “Collect campaign feedback”. There would be different ways of doing “Deliver campaign to target audience” based on the method; online, advertising, direct mail, etc. Similarly, the way you collect feedback might vary based on the campaign method.

      The processes contain the variations rather than the capabilities. I only split out variations in new capabilities if that top-level end-to-end process is completely different. However, in the marketing examples you’ve given, they are all quite similar at a high-level, so I would keep them as process variations.

      One question I’ve got about strategy is how do you embed good practice in defining the strategy when the business use goals, objectives and courses-of-action interchangeably?

      • andrew campbell says:

        Thushan, You make my point much better than I did. Your break down of marketing is the typical way in which a capability is broken down.

        The value chain approach gives a different starting point because it has marketing for value chain 1 and marketing for value chain 2 and marketing for value chain 3, etc. Once you are clear that each value chain requires some marketing, you then consider whether it is better to have the marketing decentralized so that you have 3 or 4 or more marketing departments or centralized .. and of course it may differ for different parts of the marketing mix (you may centralize “formulate brand values” for shared brands, but decentralize “communicate through social media” etc). The important difference is that your approach develops a set of capabilities top down – breaking the activity of marketing into sub-capabilities. The value chain approach starts with a presumption of decentralized marketing and a presumption that the marketing capabilities are likely to be different in each value chain. The designer only combines across value chains once he/she is convinced that the activities are similar enough that there is a low risk of “misalignment along the value chain” and in addition that there is a big improvement in performance resulting from centralizing (low marketing costs, higher skill, etc).

        Hence my view that the value chain approach leads to less centralization and more focus on the uniqueness of each value chain.

  13. Peter Murchland says:

    Andrew – Ahhh!!! Here is one of the key differences in assumptions that we are making. The approach that I am taking in relation to audience is outlined in my recent blog – https://enterprise-modeling.org/2017/07/18/engaging-enterprise-architects/. That means that I view every CEO as being part of the business strategy capability, and for many smaller organisations where there is no formal full-time strategist role, this capability will be provided through the CEO and the Marketing Executive (if the latter even exists). So, my aim is that the models and approach that I describe can be used by a sole-trader through to a global enterprise of more than 100,000 employees. That means there will be many people (see the stats in my article) who do not have the background and training that you are assuming.

    The same thinking applies to your comments on centralisation. I do not and cannot assume that each value chain will be a separate organisational unit with significant autonomy. That does not work in smaller organisations – as I see it. This brings me back to the value of a capability model – it is agnostic of organisation structure – whereas the manner in which you are describing things seems to indicate a tighter relationship to organisation structure. In using the capability model, I will talk to clients about the elements that they might do themselves or those which might be better outsourced and consumed as a service. These types of considerations require attention before settling on the structure.

    Yes, there are problems when capability thinking (shall we call it) is not used well. It requires skill, understanding, practice and experience. But, I would not characterise good capability thinking as starting with the opposite assumption at all. For any capability (which I view as being underpinned by a “system”, I consider the underlying process and typically apply lifecycle thinking (which automatically invokes value chain thinking). I also use business model / operating model fractally, so with a “component capability”, I treat this as an enterprise in its own right and apply the business model at this level – who are the stakeholders, what are the services / products, what might be the channels, what is the value proposition. By applying business model / operating model / capability model fractally, the full range of considerations are brought to bear at each level, providing higher confidence that the capabilities (systems) will integrate to realise the intended operating model / business model and enterprise aspirations.

    In effect, there are some basic patterns that apply at what ever level one is operating, that bring important questions and considerations to bear, no matter the point-of-interest at which one operates. So, “value chain thinking” is inherent in applying “business model thinking”, and it leverages multiple ways of expressing the activity – whether trained in Porter on strategy, or SIPOC on Six Sigma or Business Model Canvas / Value Proposition Canvas (which is increasingly being used with startups in my market) or end-to-end process that others may have been taught.

    • andrew campbell says:

      I am enjoying this thread: pushes me to understand better my own thinking and helps me understand yours as well. If trained in Porter or SIPOC or BMC thinking, then a value chain approach – in fact an Operating Model Canvas approach – is a simple extension of this thinking. A capability approach is an additional concept that does not fit so well with these other theories. In Porter thinking capability is a source of advantage. In SIPOC it does not exist. In BMC is a capability a value proposition or an activity or a resource or a channel or ??.

      The point you make about SMEs and the need to start with a presumption of centralisation or at a least an agnostic presumption (by the way I no longer believe that the capability approach is giving an agnostic influence on organization design even though it claims to) and the discussion around the marketing example reinforce my experience that current methods of “business design” are leading to too much centralization.

      I think I need to take this thread and make an article or blog out of it – see if I can present both points of view … difficulty is that I am still finding it hard to see the value added of the capability concept. In my experience, it is just easier to do without it … and you do better work.

      • Peter Murchland says:

        Andrew
        a) Yes, I would encourage you to develop an article – that would start to bring thinking together into a cogent presentation, rather than scattered through a series of posts / responses
        b) Yes, a value chain approach does align well with SIPOC, BMC, IDEF, to name just a few. Your difficulty with “capability” is because of the mindset that you hold in relation to “capability” – it will be necessary for you to adopt a different worldview than the customary one that you bring to this thinking – without doing so, you will continue to encounter difficulties in recognising and reconciling the value of a capability perspective – for which there is ample evidence in numerous endeavours (as I have indicated previously). It is the “Porter” thinking that is your undoing – limiting capability to a source of advantage, rather than appreciating that capability may simply be a critical dependency, which delivers just as much value (if not more) than a differentiating capability.
        c) I would be intrigued to hear of the evidence that capability does not offer an agnostic view – since I have seen it used to evaluate a variety of options which entail different “structures” successfully.

      • Peter Murchland says:

        Andrew

        Just to fill in a couple of the gaps:
        a) SIPOC is based on a process view of a system – ie. the process is the expression of how the system transforms inputs to outputs. Since, capability is an attribute of a system (its ability to deliver suitable outputs to realise an outcome), SIPOC has a natural relationship through SIPOC = SISOC = SICOC, each being a different perspective of the same entity (a process perspective, a system perspective or a capability perspective)
        b) In BMC, the activity is the handle for activity system which has a capability to deliver outputs of the activity. It is not as well formulated, since BMC largely is a list of elements under the key categories, whereas a capability model brings system, system relationship, and system composition to bear, as a more rigorous form of analysis. There may also be systems / capabilities underpinning resources, dependent on how they are sourced and managed. Of course, partners and channels operate around capabilities (but there are external to the enterprise and not subject of consideration in terms of management and development).
        c) I would encourage you to consider a sole trader growing to a 10 person enterprise growing to a 50 person enterprise – and tell me how this entails too much centralisation – when each phase of growth entails further distribution of decision making and operation – precisely the opposite to what you are suggesting.

      • andrew campbell says:

        Peter, Intrigued by your SIPOC=SISOC=SICOC. But not sure what SISOC or SICOC does for you that SIPOC does not do. Maybe I need to understand this before judging that SIPOC is enough.

        I see your point about BMC, which is why I have replaced “activities” with “value chains or value streams or high-level processes or capability chains” depending on your preferred language (This turns Osterwalder’s lists into something more useful). But probably need to understand more about “brings system, system relationship and system composition to bear”. In fact, I probably need to understand more about systems theory – assuming there is such a thing.

        Finally, I get your point about a 1, 10 and 50 person organization. I am part of a 9 person organization that has grown from 2 persons. But I would still contend that a value chain approach will lead to more decentralization than a capabilities approach – mainly because it starts from the other end of the telescope .. and this is bound to affect judgements at the margin. For example, one of my colleagues has long argued for hiring a course marketing “capability”, who would do our course marketing for us. But I have argued that the courses are sufficiently different and the people most motivated to do the marketing and most knowledgeable about the participants and the course content are the course directors. So we have left them in charge of the marketing of their courses. They are clearly not as capable in terms of marketing skills, but their desire to have a full room and their superior course knowledge makes up for their lack of capability. If you start with a capability approach, you would be unlikely to leave “course marketing” in the hands of a bunch of amateurs, in part because you would have defined “course marketing” as an important capability in your capability map. Of course, I could be wrong. Maybe a centralized course marketing team would do better .. but every time we have moved in that direction, it has been worse.

      • Thush says:

        Few comments on your specific question about capabilities and their relationship to the Business Model Canvas, Porter Value Chain and SIPOC diagram.

        I use Key Activities on the BMC for capabilities, even to the extent of increasing the size of the KA box on the canvas. I see KA and Capabilities as the “what we do”.

        I’ve not used the Porter Value Chain in anger, but looking at the classic diagram, the Primary and Support Activities align very neatly as level 1 and level 2 capabilities. Interestingly, as an aside, the Primary Activities feel like they should be slightly different for a service-based business rather than a manufacturing one.

        I’ve used SIPOC diagrams to document the lowest level of capability (which can be described with an end-to-end process). The Suppliers and Customers would be detailed as part of the process model, most likely as swimlanes in a diagram. The Inputs and Outputs would be described as objects and documents in the process diagram also.

      • andrew campbell says:

        Thushan, This is the only comment that I have from you that was outstanding. Sorry for the delay in approving.

      • Peter Murchland says:

        > In fact, I probably need to understand more about systems theory – assuming there is such a thing.

        Andrew – please take a look at systems theory, systems science and systems thinking – these are large bodies of knowledge which underpin a range of concepts that I have been referencing here, and on which the systems engineering discipline draws. It is this latter field that I have referenced as having a well established, researched and evidence based approach to capability systems engineering – that will provide you with quite a different perspective than that which you may encountered through the IT lens. I had taken it for granted that you would be aware of and familiar with this body of knowledge.

        INCOSE – the International Council for Systems Engineering is a well established organisation that advances both the discipline and the profession of systems engineering. Their International Symposium for 2017 was held in Adelaide three weeks ago, which gave me the opportunity to immerse myself in this to a far greater degree than had previously been the case. It has only served to strengthen my understanding and articulation of relevant concepts in this space.

        You might like to look at the following in relation to systems theory or the SE Body of Knowledge:
        https://en.wikipedia.org/wiki/Systems_theory
        http://sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)

  14. Peter Murchland says:

    Thusan – thanks for elaborating and using the marketing example. You outline similar lines-of-thinking that I would apply. I would add, though, that I would have done a heatmap at the higher level, because if the marketing capability is operating sufficiently well, we might not bother “digging deeper” for the time-being, and direct attention to more pressing capabilities requiring closer attention and greater improvement if the enterprise is to be realised successfully. To reinforce a point that I made to Andrew, the consideration of different approaches – direct mail, online, etc – can be explored by using the BMC on campaign-as-an-enterprise – as these are effectively channel considerations. So, if one has taught the use of BMC, it can bring out these questions / options at multiple levels within the overall organisation / enterprise.

  15. Peter Murchland says:

    Thinking further on the differences in approach, Andrew, it seems to me that you are coming from the “wrong” end, but that this is reflected in the types of organisations with whom you engage.

    If you consider an entrepreneur and startup, everything in centralised. What must be developed, considered and supported, is effective decision making about what to decentralise – not the other way around – at least, not when looking at SMEs and their aspirations for development and growth.

    Perhaps the issues that emerge are because of poor decision making in relation to growth, distribution, and decentralisation of decision making and subsequent capability development.

    I have found Managing Corporate Lifecycles (Ichak Adizes) provides some helpful and insightful thinking here, as does The Fractal Organisation (Patrick Hoverstadt).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s