Category: IT Management

At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”. While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.

Enterprise architecture is a process. But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps. These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.

The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved. It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.

If you look for it, this generic process of standardisation is everywhere. Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation. It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.

Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc. It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed. So you have a payroll department rather than all business units separately designing payroll processes. It also makes sense that you’d want to standardise the way products are matched with customers. Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.

This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market. It also promotes efficiencies through specialisation and definition of labour. It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.

Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process. To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc. This is a process of standardisation.

The real value of enterprise architecture is recursive and somewhat tautological. Enterprise architecture is a standardisation of the process of standardisation. It is an attempt at defining how this on-going process of standardisation can be managed. It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.

Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved. For example, Technical layers allow for standardisation of platforms, infrastructure, etc. Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc. At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.

In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation. The special challenge of the Business architecture layer is twofold. Firstly, it provides context for the other layers. Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers. Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.

When is comes to business architecture the standardisation process revolves around ‘capabilities’. Remember, organisations will keep on operating regardless of what the enterprise architecture team does. So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.

Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different. However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore. The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.

One-Way Risk and Robustness of IT Projects

By mdegeorge

On September 5, 2010

In IT Management

The Agile Manager has a great post on One-Way Risk and Robustness of IT Projects. It calls for “more robustness in risk management” within IT projects. However, it’s critical of risk management that is “limited to maintaining a ‘risks and issues’ log, so it’s never more than an adjunct to our plan”.

I like the implication that risk management should be conceptually equal to the project plan within the management framework. The reasoning appears to be that the project plan is necessary but not sufficient for the success of IT projects because of inherent uncertainty in these types of projects. In particularly there is reference to project plans being treated to as “point projections – as opposed to probabilistic projections – of what we will do, when we will be done and how much it will cost”.

I would never criticise the concept of schedule management but we shouldn’t see risk management as just an ‘adjunct to our plan’ but rather something that should be managed as robustly as the schedule elements that are embedded in the plan. Incidentally, project management says this in theory too – but the practice is sometimes lacking.

Of course, I would also include architecture at the same level of schedule and risk management and not place architecture management as just an ‘adjunct to our plan’.

(Via The Agile Manager.)

Note to self: do ERP vendors benefit from the sunk cost fallacy and asset specificity?

By mdegeorge

On September 1, 2010

In Accounting Failures, Ideal Realised Strategy, IT Management, IT Vendors failures, Personal, Thought of the day

I’ve never really been very interested in ERPs – so I likely don’t know what I’m talking about…

But over the years there have been many times I’ve heard organisations saying they need to “leverage their investment” in their ERP. This is usually after they have spent far too much money implementing it in the first place so whenever I hear that phrase I can’t help but hear “we don’t have the expected benefits from this yet so we should invest more in it because we’ve already invested too much not to get any benefits from it”. This is clearly the sunk cost fallacy at work.

There has been talk of the end of ERPs for some time, and there are certainly many web-based alternatives, much-hyped redesigns, as well as web based versions of classic ERPs. But at the same time ERPs aren’t going away. Certainly the companies themselves are far too clever to not evolve.

But I’m more interested in why the benefits aren’t realised. Because from an enterprise architecture perspective there are certain elements of the ERP value proposition that make perfect sense. If you think of enterprise architecture as primarily being about finding the capabilities, services, and processes that you want to further integrate or standardise across your organisation (and I haven’t found a better definition) then taking disparate payroll, HR, procurement (etc, etc) processes and standardising them should delivery value.

I’m going to make a leap here and say that ERPs actually do deliver value. In fact, any critic that suggests otherwise probably has a skewed view of why we use information technology in our organisations in general. The problem with ERPs isn’t that they don’t deliver value – it’s that they are incredibly overpriced.

Given that organisations pay that price I have to wonder how ERP vendors are able to extract value from organisations so successfully. Going back to my limited experience with ERP implementations I see three ways ERP vendors extract value from organisations:

1) ERP people are over specialised. While development and support for software packages from mid-sized vendors, or custom software development can be implemented with a variety of method, tools, and resources, a SAP implementation for example must be staffed with ‘SAP people’. There are no business analysts, developers, or project managers. There are instead SAP Project Managers, SAP Developments, SAP Business Analysts. This of course creates a scarcity of quality resources and the subsequent high price of those resources.

2) ERP vendors force their customers to follow an Ideal Realised Strategy which says your implementation will be simple if you don’t customise your implementation. However, by virtue of the fact the everybody customises their implementation this doesn’t seem like a feasible strategy in practice.

3) ERP implementation partners take control of both IT change and business change. However, rather than take the approach that business change is about delivering benefits and increased productivity they appear to take the approach that ‘business change’ is all about making sweeping changes to work practices rather than making small changes to the product. i.e. by owning business change they are using it to the vendor’s advantage not the client’s advantage.

Long-overdue rant complete.

David Heinemeier’s ‘Unlearn Your MBA’ talk at Stanford

By mdegeorge

On July 12, 2010

In Collaboration Architectures, General MWT, IT Management, Personal

This is nice.

My favourite section:

“There’s no management when we’re three people. There’s no management when we’re 15 people. We still don’t have any managers hired in 37signals. Every single one of us are producers.

I’m still a producer. I still write code. Jason still designs. We still do all the stuff and management is sort of the offshoot of, “Oh, yeah. Sometimes we have to deal with issues that they come up.”

Problem is when you have actual managers, whose sole job it is just to manage, they make up [stuff] to manage because you’ve got to fill an eight-hour day.

And in the beginning, there’s 40 minutes of management every three days. That’s what you need for management. You do not need eight hours of management, which is how you get policies and all this other bull that crops up when people don’t have anything to do.

Idle managers are absolutely the worst.”

– http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2351

(this is cut-and-paste from the transcript so I can’t remember what particular exploitive they are editing when they say [stuff])

Agile Manager on the risk of a Lean IT Financial Crisis

By mdegeorge

On April 29, 2010

In Accounting Failures, IT Management

Interesting:

“Accounting rules dictate that inception has to be funded out of SG&A. What this means is that before we can spend out of a capital budget, we must spend some SG&A money first. It’s also important to bear in mind that the same is true at the other end of the delivery cycle: last mile tasks such as data migration can’t be capitalized; they also must be funded out of SG&A.

In effect, our SG&A budget (also known as operating expense, or OpEx) is leveraged with capital expense (CapEx). A contraction of OpEx proportionally reduces the CapEx accessible to us.”

And then the likelihood and mitigation:

“This “perfect storm” is more common than you might think. Mitigating exposure is done through a variety of different mechanisms.

One is to hedge the project portfolio by bringing several investments into the early stages of delivery and then putting them into operational suspense. This creates a deliberate OpEx expenditure at the beginning of a fiscal cycle (before risks of OpEx impairment are realized over the course of a year) to multiple project inceptions, and then rendering some of those investments dormant. This diversifies the IT project portfolio, allowing IT capability to shift among different projects should one or more of those projects be cancelled.”

– http://www.rosspettit.com/2010/04/mitigating-corporate-financial-risks-of.html

Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion

By mdegeorge

On February 15, 2010

In Accounting Failures, Collaboration Architectures, General MWT, IT Management, The New MWT Hierarchy

There is some wisdom in Jim Vaughan’s article and the related comments:

The poor performance of the project usually has less to do with the project manager or the project team and more to do with the systemic failures of the organizational culture to provide the proper tools and governance to allow the projects to succeed. These systemic issues really become the moose on the table that no one wants to talk about. As a result the PM and/or the project team are blamed for the failure.

via Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion.

IT Outsourcing – How to avoid it or make it work for you

By mdegeorge

On September 20, 2009

In IT Management, IT Outsourcing, Multisourcing

I often read a lot of bitter comments on news articles – such as this one – when a new IT outsourcing arrangement hits the press. The reader comments often appear to miss the whole point of outsourcing and in turn what could have been done to avoid it. I’ve always taken the approach the IT Outsourcing has value, isn’t in any way morally wrong, and is here to stay – so I’ve eventually learnt to understand it and therefore understand the opportunities in the industry.

Firstly, it’s important to understand that almost all cost savings provided by outsourcing are through increased visibility of spend and therefore more careful selection of which initiatives are pursued. It may be that certain outsourcing relationships offer access to specific capabilities, or that certain outsourcing relationships can be managed as a source of differentiation or innovation. But that’s not generally the value of outsourcing; that’s just outsourcing as a pillar to strategy and innovation management.

Outsourcing is often a last ditch effort to get costs – or visibility of costs – under control. It’s a recognition that portfolio management processes aren’t working, nobody fills out their timesheets, it’s very difficult to get IT departments to think in terms of business services or capabilities, it’s very hard to ensure documentation is kept up-to-date, and in general that mismanagement of IT has burnt out IT resources.

Outsourcing solves a number of these problems by simply putting a contract process in the middle of everything. Outsourcing basically means that in order to get anything done you need to procure a service – which means you have to justify the spend, assign it to cost codes, and be clear about the outcomes right up front. All of these things can be achieved without outsourcing but they simply aren’t. There isn’t enough discipline to do things consistently so the management team simply can’t run the IT department ‘like a business’ because they don’t know what is going on.

By putting a procurement process in the middle of everything it forces proper allocation of costs for everything. The outsourcing partner gets to choose between doing things for free, or being paid for it and thereby having to commit to certain outcomes and to be part of a managed procurement process which gives visibility of spend. Eventually, outsourcing partners decide they want to get paid for services. Eventually, things get better…

Unfortunately, being able to come to a contractual arrangement, to actually procure services, is a capability of the client organisation. It requires an ability to define outcomes, to cost and transfer risks as appropriate, and to perform service definition and orchestration. At the new finer granularity of the services to be procured the client organisation that has just outsourced may not have these capabilities.

So outsourcing arrangements suffer from an inability to come to contractual arrangements. And the reason they do is that they have never had to do those sort of contractual arrangements before. All of the portfolio management disciplines, solution and enterprise architecture processes, cost allocation, and even basic IT strategy process, haven’t been working. The fact that they weren’t working is the very reason the outsourcing had to occur. But they are still required in order to come to contract agreements once outsourcing is in place.

A common mistake is to try and roll-back the disipline in coming to contractual agreements. Because the supporting capabilities aren’t in place it’s very time consuming to come to agreements. The cost of spend visibility is seen as too high. But rolling back the requirements to come to contractual arrangements shouldn’t be the solution. Also, the contractual arrangements also allow the flexibility to procure ‘outcomes’ once the diciplines are in place to know what outcomes you actually want to procure.

In theory, you can avoid outsourcing by putting certain things in place to ensure full visibility of costs to the executive team. In theory, you can implement all of the portfolio management processes, enterprise architecture processes, cost allocation, etc and avoid the need to outsource at all. But in practice you can’t because there will always be comparative advantages in different countries / regions, and advances in communication and collaboration technologies that make off-shoring a valuable strategy. And while your company could build their own off-shore capabilities there are political and cultural considerations that make this a risky strategy. To off-shore you generally need to outsource.

So in the end, outsourcing is here to stay. The only thing you can do is understand how it delivers value so that you can understand how work is different in an outsourced environment. Here, the key messages to the ‘retained organisation’ are: things will change, new people will not have the same experience with your systems, new people will take longer as first. Most importantly, the message to the retained organisation is that for most people outsourcing isn’t actually for them – outsourcing is for the CFO or CEO.

The key message to outsourcing service provided is simple. Get much much better at providing the services you have been procured to provide.

There will be a number of new skills that you need to aquire when you first experience outsourcing. However, it’s worth learning them because this isn’t going away and some of them are skills you may have been missing for a long time.

Technocracy and Politicisation

By mdegeorge

On June 3, 2009

In General MWT, IT Management, Personal

I’ve mentioned one of my theories before:

I have a theory that whenever a single specialisation becomes the dominate or controlling specialisation it turns the coordination into a technocracy. I might be using technocracy in the wrong sense but I’m using it to mean that a single specialisation (i.e. a single branch of technical knowledge) becomes dominate.

It is in this sense that I believe organisations are largely technocratic if they are run by technical specialists called ‘managers’. In another example, I think this is part of the process that has occured to create the current ‘crisis’ in the financial services industry:

In this case, rather than financial knowledge acting as just one input into decision making, and as just one service available to individuals, financial knowledge became the single dominate knowledge used in decision making. This in itself was a problem because it interfered with true and proper determination of ‘value’. But it would also have the effect or corrupting the body of knowledge itself (perhaps not in the textbooks, but ‘in use’).

Eventually, the knowledge of finance not only supersedes all other knowledge, but the finance knowledge actually disappears as it is replaced with what is convenient or beneficial to those in finance. This process could be a simple as people entering financial jobs even though they have no passion or knowledge of such things because that is where the money is (literally in this case, but it doesn’t have to be that way).

There are two sides to this coin that should be understood. The fact that control by specialists is the dominant coordinating mechanism in a society (or an organisation) is bad for the society itself. This is basic technocracy. On the other side of the coin – this control by a particular specialisation is bad for the specialisation.

It’s not that the people who are part of the elite and elevated specialisation don’t have any power. They do have power, and they can have certain privledges. However, the actual specialisation itself is hurt. The knowledge in that specialisation is corrupted.

Not only is the knowledge in the specialisation corrupted, but the group of specialists is itself politicised. I don’t just mean it becomes a ‘hot topic’ but that it becomes focused on power relationships. Now I’m not saying anything new if I’m just say that management is political. Everybody knows this. But there are deeper, but related impacts of this politicisation process.

In addition to the corruption of knowledge, the politicisation of a group effects the way the group is entered or exited, the amount of diversity tolerated in the group, and ultimately the ability to make non-incremental impovements in performance.

If you understand that open systems (i.e. low political / legal barriers to entry and exit) are good over time, and that diversity is good (again, over time), and that operational innovation is good (if you can even tell when it’s occuring!) then you can see that politicisation is bad for the group and the organisation it supports.

Example from software testing

To use an example that not simply about general management – let’s look at testing. I’ve spent some time over the years setting up testing capabilities – either for individual projects or across organisations. I’ve also watched others do the same. One of the mistakes that is often made during this process is to not hold the testing team to the same standards as developers.

As background, a testing capability provides an independant verification of the software that has been developed, often also ensuring it works with other software developed by other groups. The purpose of this process is to find issues with the software, but more fundamentally to manage the completeness of the project.

Fundamentally, test management isn’t so-much about finding defects as it is about continuously asking ‘Are we finished?’ and then ‘If we don’t know if we’re finished how can we find out?’ and then ‘Are we finished finding out?’ and then ‘Are we finished?’…

In order control this process there are a number of rules the testing organisation needs to place on developers. These rules ensure the software doesn’t change in an uncontrolled manner while it’s being tested. For example:

developers should check their own software first, then we’ll check it
once the testing team is checking your code, you can’t change it
the testing team will tell you if you have to change your code, and we’ll say it was a defect
once you fix the defect, you have to check your code again before we check it

These are good rules. And they work together to provide an element of control and governenace over the software development process. They provide a gatekeeping mechanism at the end of a project that, if used effectively, will reduce issues with live production systems. Though the process itself is very expensive (but that’s a different issue).

The problem occurs when the testing team doesn’t hold itself to the same rules. Examples of this include the case where a defect is raised in error because the test being perform was itself incorrect. This is still a defect – in this case a defect in the test itself – but the testing team doesn’t like to see it that way.

A more subtle version of this is that the defect is never raised but rather the test is changed without a defect being raised. In this more subtle example the testing team is not holding themselves to the same stardards they hold the development team because they are changing something without a defect.

The testing team sees these decision as ‘saving time’. But the governance issue is that the testing team are not being ‘tested’. These means that the testing team have no objective criteria for performance management. They have been elevated above the rules.

By elevating the testing team such that they have special privledges – i.e. that they don’t have to follow the rules – the group becomes politicised. People who want the special prevlidges enter the group, the knowledge of testing becomes corrupted, and operational innovation is restricted as the group uses its power to focus on changing others and not themselves.

All of these ‘problems’ are not problems if you are in the group. However, the testing group will be different group then had it not be politicised, the performance of the group may not be as it would have been, and the overall performance of the organisation that the group is a part of may also suffer.

This is melodramatic in many ways. Because these things will only occur over time, and only if all others things are equal. In reality other groups and specialisations will compete for power and the dance continues…

No wrong way to slice the pie? (and do you even know?)

By mdegeorge

On May 7, 2009

In Collaboration Architectures, Enterprise Architecture, General MWT, IT Management, Multisourcing

Management, as a discipline, has a problem it can”t solve. It needs to coordinate separate but related activities caused by the division of labour. And it needs to be able to do this regardless of how labour is divided.

Project management, in particular, has this problem. I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries. This is why project management is necessary but not sufficient in managing outsourcing.

Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.

Unfortunately, the accepted tenets of management simply do not scale. Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.

The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour. It takes it as a given that labour is divided and then attempts to coordinate that.

Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities. Good so far, but if the division of responsibilities isn’t right there is a problem. The problem might even get bigger if the managers are better.

But there are right and wrong ways to divide labour. Some activities are autonomous and some aren’t. Dividing management responsibilities and activities has its own additional challenges.

Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour. However, architecture must be domain specific. In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.

(by the way, if you think a ‘strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)