Principles as Attractors and Safety Mechanisms

Governing IT to generate innovation and value means having the business unlock resources for these purposes.

Safe-to-fail experiments — the hallmark of probing for opportunity — are a type of “project”, therefore, that will be run.

They will tend to come up faster than the typical portfolio prioritization cycle you’re used to. In essence, the Governing Board will be releasing activity in this area against a pool of resources set aside to provide for multiple activities during one plan cycle.

So how do you make them “safe-to-fail”? How do you limit the potential for wide-ranging damage triggered by one of these activities, be that expense commitments for items that didn’t produce good enough results or knock-on effects elsewhere within the more ordered elements of the portfolio?

Think back to how Governing Boards get started. The business leadership who sit on the board begin their work by devising principles to guide business issues, information issues, technology issues and the operations of the board itself.

Amongst those principles must be principles to ensure — and here I refer again to the Cynefin framework — that in the ordered domains of the simple and the complicated there are breakers to detect increasing risk of catastrophe or mind-numbing bureaucracy in the simple, or breakdowns of expert knowledge or the tyranny of the experts in the complicated, as well as situations where a shift between simplicity and complication should be made.

Likewise, there are principles appropriate to the complex domain (I leave the domains of disorder and unordered chaos out of this discussion, as neither is a domain you would typically want to spend any extended time in). These recognize impulses to excessive testing, to poorly-formed experimentation, and to pathways that are acquiring increasing order and thus should move to a more formal final implementation.

What this means is that a simple principle in one of the three categories of business, information and technology (which correspond to architectural elements) has to be developed to deal with each of the domains in which it is used.

This is why the Governance Board process calls for an annual reassessment of how well its principles are serving the needs of the enterprise.

Business leaders, when they first come to the board, are not generally well-equipped to build a comprehensive principle set — yet the process of building one is, in and of itself, a safe-to-fail approach (remember, the Governing Board is a complex domain structure for at least the first few years of each member’s tenure and thus requires complex domain approaches to build itself).

Some principles will prove to be easy to write on a wall, but hard to see how to use in practice. Others will turn out to lead the enterprise into rigidity and need to be relaxed. All of this must be worked out in practice: the practitioners cannot be handed someone else’s work as a prescription (that would be treating the problem as one of simple order) but must move toward refinement as they learn how to govern effectively.

At the same time, a body of experts (complicated order) can’t deliver a comprehensive set of principles, either: external forces acting on the enterprise cause periodic change to the effectiveness of the principles chosen, again, calling on a complex order solution to avoid excessive conservatism (a key failing of enterprise architecture today, as it is generally treated as a problem of complicated order.)

As a learning problem, the Governance Board can only move as quickly toward refinement as its members learn what’s needed through the unfolding of safe-to-fail activity around them (remember: complex order is one in which you probe through action, then sense (measure) results, and respond based on what you find). For most business leaders, used to simple order in most of their operations and complicated order otherwise (this is why they’ve abdicated leadership over IT value to the IT organization for years), unlearning expectations of order is important.

It’s also the key leap required to go from functional to executive general management and to be a useful non-executive director on a Board of Directors.

Posted in Governance, Management & Leadership, Value Generation | Tagged , , , , | Leave a comment

Governance models for the real world

Different types of order require different approaches to leadership, and thus different approaches to governance.

First, let’s get situated. If you’re not familiar with the Cognitive Edge Cynefin Framework, this post is going to lean on it heavily. Dave Snowden, Chief Scientific Officer of Cognitive Edge, will walk you through it in a short video here.

When we think of Chief Information Officers, we’ve known for about two decades that some are put into place to fix things, while others are in harness to take the organization (which is handling the basics well) forward into a more value-generating future.

In Cynefin terms, it could be that there’s been too much reliance on the ordered domains of Simple Order (and, to a lesser extent, Complicated Order): too much relative to the needs of the organization. That would be less of a crisis moment than finding the organization had gone over the cliff and fallen into the unordered domain of Chaotic Order.

Moments where an expert “fixer” like Charlie Feld (author of Blind Spot: A Leader’s Guide to IT-enabled Business) gets called in to take the reins are often an attempt to provide immediate action to get out of the Chaos and back to Simplicity, followed by a two-to-three year forced march to renovate processes and systems that match them.

Those sorts of efforts and the strong CIO in charge go hand in hand. (Mind you, political capital is also consumed at a prodigious rate.)

Most organizations that have surmounted a repair job and now stabilized a CIO in place that can take them on the longer journey to enabling more value from IT have tended to trust to extensive use of experts that must find agreement on direction (this is an example of Complicated Order at work) coupled with periodic meetings of an enterprise-wide business:IT committee to vet directions and occasionally intervene in spending plans and projects that are not producing results.

The trouble with this is that both the transition to an “information first, technology second” IT approach and effective expert processes doesn’t generate results if approached this way. We don’t know enough about where the value is, for one thing, and convergence on good practice by experts coming to agreement is inherently conservative in any event.

No wonder a frustrated “rest of the enterprise” goes its own way sooner or later!

No, governing for value and the long term must be done within the framework of the fourth of the five Cynefin domains: the domain of the Complex.

The CIO has to be a chair, a “first among equals”, but not attempt to lead her or his business colleages in governing and directing IT across the enterprise. The business leaders involved are the real directors, operating by mutually-agreed principles that provide a safe-to-fail framework for their direction-setting decisions.

Projects from the portfolio become safe-to-fail attempts to find routes to value, and develop them. Policy approval becomes as much about avoiding an over-reliance on simple or complicated order as ensuring they run well.

This is the philosophical underpinning of the Governance Board concept: that leadership for value is actually grounded in the Complex domain. It is the necessary check-and-balance to an over-reliance on the strength of a person, or “getting all the processes right”, and induces a degree of necessary radical movement into what would otherwise be too conservative in structure to achieve long-term results.

Posted in Governance, Management & Leadership, Value Generation | Tagged , , , | Leave a comment

Rebalancing is an ongoing task

All asset portfolios in an enterprise must be periodically renovated, refurbished and replaced.

That’s certainly true for software assets. Software is designed at a point in time, and reflects work as it was understood then. Eventually the deviation between old practices and changed practices requires a refresh cycle take place.

What’s often overlooked is that the policies, procedures, etc. of the workplace suffer the same problem.

Take a bank teller’s job. Aside from serving the customers, they have one other mission in life: that, at the end of the day, their station balances. Starting float + received monies – issued monies = ending float.

Well, stuff happens. The next teller needs to break a twenty, takes four fives, but one additional note is stuck to them, making five. Result? Two teller stations out of balance.

After each “crisis”, another procedure emerges, to ensure “that will never happen again”. (This is the manual form of “yet another use case” in software development.)

Come forward in time. The bank installs money dispensers rather than maintaining cash drawers.

Do all the old procedures get updated, removing the ones no longer required, and lightening the accumulated load? Almost never. They remain “requirements” for future systems.

I once watched a teller go through no less than twenty-eight steps to handle a single transaction for me in 2005 that had taken only four steps in 1975. That’s adding bureaucratic barnacles and slowing the works up, eh?

The procedures the teller in a bank branch had to go through were, though, merely an annoyance. Other restrictions — in the name of compliance, or security, or financial control — can be far more damaging.

You see, not all work is ordered simply, where you can measure what’s going on, form categories for action, and tighten up here and there. Trying to apply those strategies to work it doesn’t suit actually makes things much worse.

Burdening the organization with an ever-increasing pile of controls and procedures does, too. Simple order breaks down under too many of them.

Odd things happen, too. An organization reorganizes, removing certain positions from a work team. There’s a greater reliance on multitasking, smartphones grabbing email, and the like. Suddenly invoices aren’t being paid! (It’s one burden too many for an overworked team that might not be overworked if they didn’t have so many procedures to follow without fail.)

That’s why, when it’s time to ask the periodic question you should be asking — “would we start doing this this way now, if we didn’t have anything in place?” — that drives reinvestment and refurbishing of the asset portfolio, the place to start is in the workplace. Use each cycle as an opportunity to scrape off old barnacles of procedures and checks for old problems now handled a different way. Make sure the work to be done is rebalanced to the time and resources available to do it.

That way, what you provide as a new IT support solution will start cleanly again, ready for another cycle of “additions and changes”.

Posted in Asset Portfolios | Tagged , , , | Leave a comment

Getting past the impulse to order everything

There’s a constant temptation in management more generally, and IT specifically, to presume that everything not only can be ordered, but that it ought to be.

Perhaps, for IT people, it comes from the origins of the work. The original data processing systems were typically from highly ordered and well understood simple processes, replacing accounting machines. Then IT added support for routine clerical transactions: counting inventory elements, paying and receiving monies, and the like.

These are all very orderly, very simple, and very routine.

As IT started to move closer toward information flows — both real-time and near-real-time in manufacturing and distribution, and analyses looking for relationships — and as “automating processes” became a normal rallying-cry, IT added a second type of order to its understanding of the world. Expert agreement over what good practice would look like emerged, and with it the regimes of the relationship manager, the enterprise architect, the project management office and the like. Application development became “solutions”, awash in use cases for ever-more-obscure events.

Along that route, existing order was surpassed, and conformance to a model of order became the norm.

Now understand, at the same time, other aspects of management were doing similar things. Enron led to Sarbanes-Oxley led to compliance departments and the drive to establish controls. Pay equity, affirmative action and disability accommodation legislation led to expansions of the human resources mission and the drive to survey and “prove”. Increasing legal battles over patents, methods, contracts and partnerships led to the need to document, store, and recall everything. Oh, and shaky economic times, first with the Internet bubble crash of 2000-02 and the housing bubble crash of 2007-09 and all the fall-out since, have put a premium on the mechanics of management: budgets, spending controls and the like.

In other words, if a little disorder appeared to surprise, pressing down hard on the accelerator marked “more order” was the response. Governance became policy promulgation: “we printed it, so we’re governing it”. Processes elongated in time, to take all the factors into account — and to accommodate the differing groups of experts that had to come to agreement to get anything done. Life, in other words, became far more complicated, even as we attempted to codify it into rampant simplicity.

For IT, the wake up call came when the bring your own device movement and cloud computing in its many forms led to the construction of entire parallel “worlds of IT” that broke organizational boundaries six ways to Sunday.

So here’s the reality: these are signs that not everything is ordered. In fact, from the point of view of innovation, protection against crisis, and creating the future for the enterprise, that very unordered world is as important as all the order that exists.

A response that says “more order, damnit”, is one that will lead the enterprise right off a cliff and into chaos. If it’s lucky, it’ll land on its feet and have its crisis cleanly. If not, the swirling cavity of disorder and dissolution awaits — or the resumption of “waiting for the bomb to go off” that a leader forcing even more order in the crisis to restore “stability” will bring.

Architecture, policy, projects and processes can’t impose order on the unordered. They can at best create a space for things to occur safely, and where failures aren’t fatal.

It will be everyone’s challenge, but IT’s facing it now. And, yes, it’s a governance problem. So will you use simple order (the strong CIO imposing his will), or complicated order (a web of ITIL-approved practices managed by experts)? Or will you try a complex response, and go with a principles-led business-driven governance board to create the space for things to happen?

Your choice. Your future.

Posted in Enterprise Architecture, Governance, Management & Leadership, Strategic positioning | Tagged , , , | Leave a comment

Signs of an Organisation in Trouble

What are some of the warning signs that an organisation may be headed into trouble?

Start with how people spend their time.

We’ve known since at least the 1950s, with the work done by William Oncken and Peter Drucker, that management’s time is a key variable in organisational performance, especially in the long term.

Management time is the source of leverage — through what it’s spent on, and how much work is done by the people being managed.

Multipliers on work come with establishing and insisting upon free action by those below you. The term delegation doesn’t mean, in other words, telling people what to do and how to do it, or requiring endless check-ins and approvals, but making them responsible for outcomes and removing barriers to their ability to achieve, all the time guiding and teaching as needed.

One sign that an organisation is headed toward trouble, therefore, is when the management cadre is too busy to pay attention to new and needed initiatives.

Consultants see this repeatedly. Whether they initiated a proposal that was accepted, or responded to the request for one, there’s a project they’ve been hired to undertake that offers the organisation a payback.

The executive sponsor may even have some degree of urgency in mind, if the numbers are meaningful enough.

But the managers involved don’t have schedule space to work with the consultant. They’re overloaded, according to their calendars. Meetings are proposed, then cancelled.

The staff are ready to go. The sponsor’s looking for progress toward completion. The consultant is there. But the manager can’t make the time.

There are crises that erupt. Some other project is in trouble, and needs to be put back on track. Delegation turned into a disaster with this staff member, and not only the pieces need to be picked up, but time has to go into that person’s learning, while it’s fresh.

There are also cyclical issues to deal with: it’s budget time, or plan time, or staff evaluation time.

Still, there’s an ironclad finding that’s often overlooked: management time is best spent where it produces the greatest leverage.

That consultant — who, depending on the financial arrangements, may or may not be costing you money — is a superb source of leverage. After all, you hired a consultant to do the job to get exactly that.

Finding the hours needed to get the project up and running, allocate internal resources, set intermediate checkpoints as needed and then stepping back should be a natural move. It increases the overall return on the manager’s time.

But too few see it that way. Instead they focus on the routine, the cyclical and the meetings that protect against harm (at the cost of great outcomes, by restricting staff freedom) and push the things that would make a difference now to the margins.

Do that often enough, broadly enough across the management cadre, or space too many gaps between involvements, and two things happen.

First, costs go up and benefits don’t accrue: not only do you delay achievement of the efforts (and getting the expected returns from it) but you also drive the cost of the project upward. (If you want people to bid hourly rates rather than value-priced fixed fees to do work, and then come to the cubicle assigned them in your offices and do little to nothing all day on your nickel while they wait on you, this is a good way to go about it.)

Second, if you’re that fully booked, you’re also not doing the job of a manager in looking over a longer time horizon than the immediate at challenges the organisation may face, or opportunities it may miss.

If you want to know why so many organisations end up failing, here’s one of your answers. Watch how managers spend time — and what they can’t (so they say) make time for.

Posted in Management & Leadership | Tagged , , , | Leave a comment

Portfolio classes for the greater recession

In an economy that doesn’t move forward easily if at all, the traditional classes in portfolio planning aren’t enough. A Governing Board needs to establish a mix designed to deal with a long period of malaise.

That would be now, in case you missed the past five years. Organizations have made many one-time moves to try and buttress results: there’s been ever more offshoring, outsourcing and shifts in locales of operation.

Those games are playing out. Now we actually have to get serious about an environment that’s slow on growth and fast on cost rises.

The traditional portfolio divisions used by IT were a very few percent dedicated to transformation, a larger block of money (upwards of 1/5 of the total) to growing the number of capabilities in the portfolio, and the balance used to run, operate, maintain, replenish and handle compliance issues in the existing portfolio.

Top-flight organisations also set goals to shrink the portion absorbed by the “handle what exists” block, trying to get it down to 65-70% of total needs.

“Handle what exists” has a tendency to grow over time and slowly absorb much of the other spending. Vendors raise licence fees, labour costs rise (if not via salaries, then via benefits costs or government mandates), minor changes get more expensive as skills fall out of the mainstream, to take but three examples.

Today the Governance Board has to have a fourth category: one directed at the explicit reduction in “handle what exists”.

Projects here will be getting older software up to date, removing mods as the changes are made (otherwise retrofitting them is a permanent expense to the organisation). Other projects reduce duplication in the portfolio (mergers, acquisitions and departmental systems turned into corporate assets create these, as do vendors by expanding the range and reach of their products). Some products will be replaced because the local labour market is moving against them: I recall one enterprise that had a heavy investment in Visual Basic, but other organizations in their city did not use the product, and so finding contractors when needed was becoming expensive and problematic.

The goal here is to shrink the cost of the asset portfolio over time through a conscious and deliberate program of reinvestment. Decisions as to whether to use an outsourcer or -as-a-service cloud provider thus take on a much-improved economic profile before locking in a contract.

The other major thing that needs doing is to put more money into the “transformational” category — what some would call R&D (wrongly, in many cases) — and less into “growing functions” in the traditional sense.

Here, what the Governing Board is moving toward is getting out of process myopia. The “growth” category reflected more use cases or reports, typically. It assumed the client organization in the enterprise for whom the work was being done knew what they wanted and could therefore provide requirements.

Who knows how to handle the analysis of external information? Who knows what’s relevant in a social media analytics program? Who can say where the next value opportunities lie?

Who, in other words, can recognise the need (and specify) a Sony Walkman before anyone ever thought of the idea of a device on your belt that played music while you walked?

The “transformation” part is less about traditional IT R&D — trying out new technologies — and far more about trying to put together prototype solutions. These can be used for areas of enterprise differentiation (which will in almost 100% of cases be a matter of home-grown code, not a package: you are solving problems for which there’s no market, yet!), testing concepts, working with the client community to refine ideas.

The enterprise in a time of economic turmoil punctuating grinding periods of slow to no growth can afford to do without small expansions on what exists. It cannot afford to do without finding ways to leapfrog into new markets, new opportunities or new ways to sustain products at good price points.

Left ungoverned, enterprise planning will continue to put up a backlog of “growth” projects, ignore “transformation”, fail to invest in reducing “handle what exists” and thus drive the cost point higher with no value generated. It’s what we know how to do, and what our processes are designed to do — because economic growth masked the effect.

That’s why enterprise Governance of IT matters: to change what we know how to do.

Posted in Governance, Project Portfolios, Strategic positioning, Value Generation | Tagged , , , | Leave a comment

The kill decision

Probably the hardest decision to make in any organisation is the decision to kill a project that’s underway.

Time, effort and money has been sunk into it. There are expectations of its completion — successful completion is preferred, but, when the chips are down, bare completion will do.

Egos are involved. Reputations, too.

No wonder so many enterprises have trouble with this.

Yet killing a project that cannot succeed is an act of mercy in many ways.

A project is in trouble when it starts slipping off the projections made for it. Projects are funded, approved and released for execution because the enterprise expects a certain result to obtain in a certain timeframe.

As a project absorbs more resource, more money, or more time than planned, the point at which benefits starts to flow recedes into the future. Meanwhile the costs are current, eating into the results obtained in this quarter.

Well, no plan survives contact with the real world. A good plan should have buffers built into it to deal with change.

But what if the reason the project isn’t proceeding well is because there are fundamental disagreements in the business about core aspects of the business? (This happens far more frequently than you might think.)

What if the process isn’t anywhere near as simple as it looked, and new marginal use cases are proliferating? (This happens when work is not drawn from the simple order, but a simple, process-centric solution is being imposed.)

What if the business area refuses to let go of the past, imposing major modifications to preserve it? (This often happens with package implementations: one of the reasons so many organizations are salted through with heavily-modified packages left over from the Y2K period is because the business area could insist, and the deadline was fixed.)

In all these cases there is no reason to continue to implement the project. It should be stopped and the underlying issues be sorted out.

In today’s world of delivery-as-a-service and outsourcing partners, there are other reasons why a project might be killed and the whole issue rethought.

I know of one organisation with a hard deadline for change: every year, they require a change freeze while a major annual activity takes over the business.

This year they decided to engage with a new outsourcing partner. Promises were made to win the business. While price mattered, commitments for when things would occur mattered more.

That vendor, having won the day, calmly ignored all their promises. It’s now a race against time as to whether everything can be done before the freeze comes on.

In this case, a lot of night hours, and a lot of screaming, probably brings things home — just. In many other cases, there’d be one too many items to close the loop on in time.

Then there’d be payments for old and new in parallel for weeks, while the freeze unwound.

There, too, a kill decision would have been in order. (If the vendor wanted to pay for the old services to keep the business alive, that would be a point of negotiation.)

Kill decisions, in other words, not only free good people up from projects that will potentially damage their futures, and free the organisation up to deal with its underlying issues, they can also lead to a much better vendor relationship.

One of the key jobs of the Governing Board is to make kill decisions. That way, it’s not one person’s call — with all the political ramifications — but an enterprise decision.

So make them.

Posted in Governance, Project Portfolios, Value Generation | Tagged , , , , | Leave a comment