Category: Capability Engineering Page 1 of 2

In that perverse type of functional organisation that has a functional business unit for each profession, there is a predictable progression for each function.

The function cannot succeed until it is centralised
The function cannot succeed until it has the sponsorship of the CEO
The function cannot succeed until it has its own “Chief xxxx Officer”
The function cannot succeed until everybody understands that the function is “everybody’s responsibility”
The function cannot succeed until it has the resources to engage with “everybody”
The function cannot succeed until there is a dedicated business unit that makes the function part of the business-as-usual process
The function cannot succeed until it has input into the strategy of the organisation
The function cannot succeed until it is part of the organisation’s culture
The function cannot succeed until it reports to me

Shifting to a Data-enabled Organisation – from I.T.’s Perspective

By mdegeorge

On February 21, 2018

In Business Architecture, Capability Engineering, Data Governance, Enterprise Architecture, Information Management, IT Management, Technology-Enabled Business Transformation (TEBT)

I.T. gets a bad wrap in some information management initiatives. I prefer to take the approach that many IT disciplines are helpful for better information management. The shift from I.T.’s perspective often looks like this:

More capability-based planning goodness

By mdegeorge

On February 14, 2018

In Business Architecture, Capability Engineering, Enterprise Architecture

Good capability-based planning article: http://fia.workem.org/index.php?option=com_content&view=category&layout=blog&id=14&Itemid=111

Re: A Pattern is no Best Practice Yet!

By mdegeorge

On February 17, 2017

In Capability Engineering, Christoper Alexander, Innovation, IT Management

Great article on patterns by Kris Meukens here.

My slightly self-indulgent reply is below. I’ve always been fascinated by how our understanding of IT and organisational design in general seems to follow the same path of Christopher Alexander’s works on the design and architecture of the built environment.

—

I think it’s interesting to see the parallel and delayed timeline between “patterns” as they evolve in built architecture theory, versus patterns in IT.

I’m not an expert in either but I see the history of patterns in built architecture through the lens of Christopher Alexander:

Notes on the Synthesis of Form (1964, year 1). Starts to describe what later came to be known as “patterns”.
Notes on the Synthesis of Form – Preface to the first paperback edition (1973, year 9). Already starting to rebel against those who focused on “design methods” as a meta study and assets “I reject the whole idea of design methods as a subject of study, as I think it is absurd to seperate the study of design from the practice of design”.
A Pattern Language (1977, year 13). These are fully formed patterns with the notion that they can be combined to create designs. It’s not a simple mix and match – still leaves room for a design process.
The Nature of Order (2003, year 39). Doesn’t exactly reject patterns but focuses on wholeness, a set of qualities, and a set of structure preserving transformation that help designs unfold.
The Battle for the Life and Beauty of Earth (2012 – however focuses on 1985, year 21). This focuses on two world views that he saw as in battle – one of which was opposed to his style of building.

Reading “Battle” in particular makes you feel our current understanding of patterns and our obsessions with Agile, Design Thinking, etc mean we are in the equivalent of year 25.

Reading the above article feels like we’re heading towards the equivalent of year 30. I mean this as a compliment.

The IT Department of the Future… doesn’t exist

By mdegeorge

On February 15, 2017

In Business Architecture, Capability Engineering, General Management, Information Management, Innovation, IT Management, IT Outsourcing, Transformation

Good article, including the simple fact:

In the industrial company of the future, there won’t be a separate IT department.

From: http://www.strategy-business.com/article/The-Thought-Leader-Interview-Bill-Ruh?gko=9ae51

Avoiding the B.A.I.T. view of Business Capabilities

By mdegeorge

On August 15, 2016

In Business Architecture, Capability Engineering, Enterprise Architecture

Reference material added here:

Breaking free of B.A.I.T. -based Capabilities

The No ICT Strategy Organisation

By mdegeorge

On April 15, 2016

In Business Architecture, Capability Engineering, General MWT, Information Management, IT Management, Technology-Enabled Business Transformation (TEBT), Thought of the day, Transformation

The idea of business / IT alignment is completely at odds with the challenge of business agility. You can never align all-of-the-business with all-of-the-IT. You can only ensure that the business capabilities your organisation’s operating model depends on sufficiently utilise information technology in order to ensure competitive levels of productivity, optimal customer experience, and coordination with other business capabilities.

The idea of business / IT alignment is admirable when it implies that in model business operations there is a concept of “business” concerns and their is a concept of “IT” concerns and that they are peers. The process of business / IT alignment then would be a messy and complex process that might eventually work. However, business / IT alignment never gets implemented as a process that assumes business and IT are peers. Even if it was, it’s foolish to break your organisation along the lines of business versus IT – there are other ways of cutting up the organisation that eliminate the need for business / IT alignment altogether.

This is further exacerbated by the shift of IT budget to business units. Once budget that had traditionally been thought of as IT budget gets shifted into, say, marketing, it would be ridiculous for the marketing department to then raise a concern about the business / IT alignment challenges they were having when spending their new increased budget. Once you’re responsible for both why complain about alignment? If you own the budget you have nobody to complain about business/IT alignment to.

I’ve written before about how much of what people in the so-called “business” think of as “IT issues” are really related to information, complexity, or simply willingness to spend time on the details. When a business process is automated – does it then become an IT problem? It is a sign that our understanding of the dynamics involved in the implementation of information systems – which it is now trendy to call “digitisation” – has certainly outpaced our popular understanding of how organisations are designed and governed when these simple questions still have complex answers.

We have a number of real problems governing our organisations. Business and IT concerns aren’t ever broken down to specifics, the whole concept of splitting business and IT places barriers to true organisational agility, and there still isn’t an understanding that in the modern world the high-level concept of “the business” and “IT” don’t exist. This separation is make for the convenience of executive leadership and have limited organisational value.

I’ve previously proposed the simplest change might be to stop creating ICT strategies. I’m not saying an overall strategy for certain aspects of IT isn’t required. I’m simply saying that an overall strategy for the organisation is more important. If you have a business strategy and an ICT strategy is it any wonder you have business / IT alignment issues? Of course you have alignment issues! You have two seperate strategies.

This is exacerbated by the fact that your business / corporate strategy probably doesn’t contain the sorts of things the folks developing your ICT strategy expect to see anyway. They probably have to go to individual business unit strategies to get the information they need and ultimately the ICT folks are left to try and align the inconsistencies that will inevitably exist between all of these business unit strategies.

A strategy development and strategy deployment process grounded in business capabilities is of course the answer.

Interesting Times at Westpac – Dave Curran, CIO

By mdegeorge

On October 9, 2014

In Capability Engineering, Financial Services, Information Management, Innovation, IT Management, Technology-Enabled Business Transformation (TEBT), Technology-enabled Markets, Thought of the day, Westpac

I would have loved to have seen the presentation that’s been given some positive press here. Westpac are putting some meat around their transformation agenda after having learnt from the experiences of other banks.

Many of these large scale transformation programs (think ERPs, CRMs, core systems replacements, etc) have a tendency to teach the organisation about a product. The whole organisation will learn how to implement that product – they’ll learn it’s strengths and weaknesses, and the right and wrong ways to successfully exploit them. Those in the organisation who aren’t part of the solution will at least learn that they have an opinion about these things.

Now, the actual benefits of these programs aside, this is a strange way to for your organisation to spend a few years. These programs become a distraction that take up executive, management, and operational attention. But what if you changed the conversations so that rather than learning about a product, you completed the same program but what you where really doing was learning about your customers and how to better orientate your organisation towards their needs?

I think the approach Dave Curran has managed to convey (again, based on the reporting – I wasn’t there) starts to do that. This approach means that effort is first and foremost about the customer. Now I’m the first to say it’s not that simple. There is still a lot of work to make that vision operational. But it completely changes what the organisation will primarily be learning during program.

The key lessons now will be about customers – what Westpac knows about them, what they don’t, what decisions they are making every day, and how that might be understood by Westpac staff when making their decisions. The other lesson they will be learning is how technologies they already have, combined with technologies available in the market, can be used together to support various customer scenarios. Not trying to find “the best” solution without any context, but trying to design solutions across a well informed view of what is important to customers.

I think too that if this is done right, the discussions won’t be broad sweeping generalisations. They won’t be “is this one monolithic system really customer focused?” Likewise, there shouldn’t be that tendency to continuously revert to “yeah, but what is a customer?” That conversation seems out-of-the-box but is typically only asked because the people in the room have never met a customer (!) so they revert to broad open questions rather than use their experience.

Done right, this approach will draw out rich, informed conversations that admit that we have to bring components together to support specific customer scenarios. It will draw out conversation about what we don’t (!) and ensure we find out. Done right, this approach keeps up the sustained momentum these programs need to do the hard work that will truly transform the organisation.

I have a few grounding concepts that I think are relevant here. They are quite simple in their nature but powerful as the basis for governing change. I’d suggest these should be established for the program.

The Customer Advocacy Office

We talk about the importance of customers all the time but often the question we don’t ask is “what is the business unit in our organisation that advocates for our customers?” I don’t mean lets give somebody the responsibility for customer and then split the role into “Contact Centre” and “Web site”. I mean real, serious thinking about customers. Being able to understand and back up with facts. Being able to offer targeted operational changes – backed by evidence – that will improve the experience of customers.

Customer Experience Campaigns

Your organisation is probably comfortable with marketing campaigns. But what if the concept of a campaign was expended to include any situation where your customer had a defining positive or negative experience with your brand? Customer Experience Campaigns apply the basic concepts that are used to manage a marketing campaigns to all of the individual experiences of your customers. This is actually really difficult, and really important. And it’s what we mean when we say we want to be customer focused – but do we actually do it?

Customer Information Management

There is a lot of work required to get a single view of a customer. There is even more work required to repurpose that view so that it highlights the information required for different groups to make decisions (i.e. single core data, multiple views). But that’s still not “customer information” – that’s just consolidating and presenting data effectively. A true responsibly for customer information management means knowing what you don’t know about your customers, and understanding the value of finding out. It also means understanding how modern technology allows us to understand and predict the complex decisions that our customers are making by using big, social, cheap, integrated data to act as a proxy for intimacy when you can’t always get inside your customer’s heads.

Customer Return on Operations

Things like Net Promotor Score (NPS) are great but they are the tip of the iceberg when it comes to using customer-driven metrics to improve your organisation. These “voice of the customer” metrics are great but they are “lag” indicators until you do the correlation required to make them “lead” indicators. Measuring you customer return on operations combines how your customers think you perform with how you think you perform. It’s hard, it takes a prolonged effort, but who could argue that it’s not important?

Competency Centre -based Business Transformation

Many transformation programs are top-down. This means they are limited to the types of transformation that you can achieve top-down. The Westpac approach will required a middle-out approach. There are many functions within the organisation that will need to be transformed to execute on the vision. Thankfully, competency-centre based business transformation is an excellent alternative to top-down transformation – if your transformation team “gets it”.

This approach also includes the question of which type of “core” you want your organisation to have (accounting, versus product customisation, versus customer hub). When you’ve done the right homework, you can then make clear and informed decisions on whether something is differentiating or not differentiating. This decision drives standardisation but it is so mixed up in a tight bundle or current power struggles it needs an informed third party to arbitrate.

I’m not saying just talk about the concepts above in the executive management team. I’m saying that in addition to the other governance required for this sort of program there are executive roles for each of the above areas. There are charters and terms of reference for each of the above areas. Each of these areas should be managed as a business capability where the executive in charge is responsible for working across functions so that the people, process, information, and technology all work together to support the capability.

By the way, I’m not sure I get the title “Dancing About Architecture” that the article I link to above uses. I’m assuming it’s a reference to the “Writing about music is like dancing about architecture” quote that I, like everybody else, mis-attributed to Elvis Costello until I just looked it up. It’s a nice image – the idea that you might use something other than architecture (such as your customers) to guide the direction of your architecture. You dance around (or “about”) your architecture so it knows where to look. Though by alluding to the music quote the author seems critical of the approach. Anyway – looking forward to part 2…

Analytic teams need their own IT… but should they?

By mdegeorge

On March 18, 2014

In Analytics, Capability Engineering, Collaboration Architectures, IT Management

As per linchpin project #9 (“Project 9. IT federation: shrinking corporate IT and embracing shadow IT”) we need to view our success in terms of capabilities not functions – and remove any roadblocks to maturing our capabilities.

So this is happening:

Big data: Why IT departments mustn’t be a drag on analytics | ZDNet: “‘Technology functions are still finding it difficult to keep up with business demands. Working in analytics and being responsible for analytics, I can’t let that happen,’ said RBS chief analytics officer, Customer Solutions Group, Alan Grogan.

‘I can’t turn around to my CEO or to my customers — or even just if I want to retain staff — to say ‘I’m sorry, we just don’t have the scalability, the flexibility or the control on the domain’.'”

At the same time, there are efficiencies in building a federated IT capability. When Analytics teams need to manage their own IT they aren’t evolving the IT function. And when Analytics teams manage their own IT the IT function has to evolve. There is a joint responsibility to manage this process.

10 linchpin business performance improvement initiatives you should be running right now

By mdegeorge

On December 5, 2013

In Business Architecture, Capability Engineering, Collaboration Architectures, Enterprise Architecture, General Management, Innovation, Technology-Enabled Business Transformation (TEBT), Thought of the day

It’s often difficult to understand how your portfolio of projects is actually helping your organisation deliver to its strategic goals. The problem is that the projects in the portfolio often don’t play a part in ensuring the overall portfolio is easy to navigate and cohesive. You need linchpin projects in your portfolio to hold the others together.

Linchpin

Linchpin projects are different to other projects in the portfolio. Linchpin projects don’t have a business case in the traditional sense – because they are strategically placed into the portfolio to hold it together, identify risks across the portfolio, and steer cross-project decision-making.
Linchpin projects are value-seeking initiatives that raise the value of the entire portfolio. In fact, linchpin projects represent the new normal for combining operations and program management in the digital economy.

Your current portfolio

Your current project portfolio is probably made up of three types of projects:

That subset of projects that had a strong enough business case to make the cut at the expense of other projects
Projects that your organisation almost left too late, so are now critical – or projects that unanticipated changes in your operating environment have recently made critical, urgent, or “must haves”
Big, chunky, game-changing programs that have been initiated following a strategic analysis & planning process. These are often more of a top-down prioritisation of investment rather than a fully formed project, until a more comprehensive analysis of the full impacts is performed

The decisions that initiated each of these projects aren’t always perfect. But you have no choice but to plunge ahead with the projects. However, each of these types of projects presents challenges to the management of your portfolio as a whole:

You selected some projects at the expensive of others – but when and which of those forgone projects will become your next critical projects?
Critical projects that have now become urgent will need to take shortcuts – but what ensures these projects understand the shortcuts that are available, or to plan the follow-on work required when the projects are complete?
Strategic projects represent investment priorities which will have the greatest impact on your customers, asset utilisation, and business performance – but how do you incorporate the best knowledge you have of what influences these into the strategic project’s planning and execution? (Without putting all other projects on hold!)

Major projects versus linchpin projects

It’s a mistake to think of your major projects, or your strategic projects, as your linchpin projects. Major projects are often run as exceptions, so the transformational impact of these projects is often limited or followed by organisational fatigue or regression. Linchpin projects on the other hand inject specialised disciplines into the portfolio and in many cases don’t need to be large investments.
However, there is an opportunity for your major strategic programs to host a number of linchpin projects to get them started. The trick is knowing which linchpin projects you need…

Which linchpin projects do you need?

Regardless of your organisation, the following linchpin projects should be in your portfolio. The characteristics of your organisation and current strategic direction will only impact the size and approach for each of these initiatives.

Project 1. Business capability based governance
Our organisations shouldn’t have a primary governance model that divides the organisation into functions and then constantly proliferates the need for cross-functional teams. Social enterprises don’t require this approach – so your organisation’s primary governance should be mapped to business capabilities, not functions. This is also the first step in ensuring “business/IT alignment” – by stripping back the historic and arbitrary separation that is the root cause of misalignment.

Project 2. Customer journey design & customer experience campaigns
If you can’t point to artefacts which describe an idealised view of how your customers experience your organisation, then you haven’t done enough thinking about your customers – and you have nothing to orient your organisation towards customer outcomes. Equally, if you can’t point to specific customer-facing processes, technologies, and metrics that continuously direct the resources of your organisation towards reenforcing positive customer experience and recovering bad customer experience – then your customer journey design is just sitting on a shelf!

Project 3. Asset life-cycle, utilisation, yield, and pricing
Airlines, hotel chains, mining companies, and farmers understand yield. They understand that large expensive assets must be effectively carved up to service the right customers, at the right time, and for the right price. In the digital economy this same process must be applied to every organisation’s assets. If you don’t understand the utilisation on your major assets, and how projects can impact this, then you are running a business that provides a higher cost product – or your are running a unsustainable business.

Project 4. Core shared data strategy, information asset governance, and decommissioning
Unmanaged, the information in your organisation can get out of control. We have access to so much technology – information technology – that is supposed to help us manage information. So why are there so many copies of the same documents? Why can’t we rely on information we receive from other departments? And what is cut-and-paste if not investment in the problem instead of the solution? The solution is to systematically discover and invest in information assets across their end-to-end lifecycle – focusing in particular on the “core shared data” that is key to coordination across business units. Oh, and don’t forget you can’t ever throw data away unless you know what it’s worth (i.e. Business value) – but some data you can’t afford to keep (i.e. Privacy Act).

Project 5. Combined process, information, and user forums – fit-for-purpose scorecards
Your employees know what is wrong. But there are few mechanisms for feeding that learning into operational improvement initiatives. Lean and Six Sigma ™ come to mind – but that’s just details. Whenever your process team talks to people who should be following processes – capture the reasons why they’re not! Whenever you find yourself questioning a decision an employee has made – capture the missing information that caused the wrong decision to be made! Whenever somebody throws their keyboard across the room – ask them why! Better still – combine all of this into a single session which uncovers what is wrong around this place.

Project 6. Innovation funnel, lean business case, and start-up support
Innovation, or rather an entrepreneurial culture, starts with hiring entrepreneurs. But what if you can’t keep them? There are three reasons you can’t keep them: 1. You don’t recognise the good ones – because you don’t have an innovation funnel. 2. You frustrate them – because there are too many barriers to implementing business cases for change. 3. They can get better, cheaper start-up support in the market. These things are easy to fix and can be funded to the extent that you value innovation.

Project 7. Voice-of-the-customer operational alignment – Customer Return on Operations
It’s pretty easy to gather basic voice-of-the-customer data. For example, you can just asked the simple “How likely are you to recommend us to your friends? And why?” questions at the heart of Net Promotor Score (NPS). The hard part is doing something about it. You need to systematically determine what parts of your operations have the most impact on your customers. Management of “customer return on assets” will tell you most of what you need to know about how your projects are impacting your performance – from your customer’s perspective.

Project 8. Competency centres and change levers – The Machinery of Business Transformation
There are two ways to transform your organisation: you could run a heavy transformation program, and then an even heavier organisational change management initiative – and hope you get both right. Alternatively, you can manage to a transformation agenda – vision – and a portfolio of integrated competency centres – collaboration and continuous improvement towards that vision. If you know your own organisation’s portfolio of competency centres, their service catalogs, their customers, and the most effective channels and levers of change for your particular organisation, then implementing your whole project portfolio, and avoiding unintended consequences, becomes much easier.

Project 9. IT federation: shrinking corporate IT and embracing shadow IT
Even with your primary governance now focused on business capabilities (see Project 1) you still need to manage IT. But the difference is you need to manage all IT, in the only way you can in a post-Cloud, outsourced, and BYO world – federated IT. Learn to manage IT without ignoring what is out of your control and you’ll revolutionise productivity within your organisation while spending less than you did on IT services, architecture compliance, and generally inconveniencing your stakeholders by trying to be the cost and standardisation tzar.

Project 10. Who are we: purpose, culture, communications, and performance
Engage, decide, communicate. There is always another opportunity to reinforce what makes your organisation unique. There are ways of doing this that improve performance. Try them.