Tarun's Blog

Readings of the Week:

Grey – The fetish of change

Walsham – Chapter 10

Critique on Grey & Walsham papers

Questions & Comments:

“The most striking thing about change management is that it almost always fails” is clearly a line designed to provoke a reaction from the reader. The author seems to be insinuating because organisations are always looking to improve processes, a particular change management project is a failure. Can change management not be a success while still looking for something better?

Communication and consultation is a better approach to the change management process, especially in terms of attempt to secure commitment. According to Grey, communication and consultation is increasingly recognized in areas where fair employee treatment was applied. However we have to be careful of the use of communication and consultation as a change management technique as it is more likely that senior management will favour it in terms of production processes but not over shareholder dividends. There are many traps to be negotiated in the field of change. Today every organisation is confronted at some point with the necessity to introduce some sort of change, it is important to recognise the importance and the individual key elements of change. Do you think every organisation need to introduce change in its own way by considering its size, circumstances and goals?

In the ‘Fetish of Change’ paper Grey’s contention that change has been perpetual in human history and that every generation had to struggle with it, is correct. But though change has always been,there, what is different now is that it is only recently that a conscious effort on the management of change has begun within the organisations. Uptil now change was accepted more as an ‘act of fate’ on which humans had no control and against the tide of change humanity had felt helpless. And in the last few decades a proper understanding behind the dynamics of change has settle in and with it has come an urge or a drive to proactively manage the change. Change management is an evolving field and the frameworks & structures around it are still being debated. But to call change management a fetish would be puerile, it certainly is a new endeavour and an untrodden path which we as humans have only just started to grapple. Yes, the failure rate in change management is high at present but then this field is still evolving and like other human studies the field of change management is expected to become more mature and structured to tip the scales in its favour.

Minutes of the Class:

Recap on Last week

This weeks lecture began by wrapping up the discussion on agile and how it can be seen as a breath of fresh air for software development as it’s more suited to the often constantly changing needs and requirements that arise as a software development process evolves. This is in part due to software not scaling up very well, but as it does scale things can get riskier and more difficult. But there is a problem regarding agile in that we currently don’t have a lot of empirical studies available in terms of how or what happens when it’s introduced into an organisation. This results in the complexity of the implementation of agile becoming largely dependent on the implementing organisations current culture.

However, Seamas has seen some projects in action that show it can work very well. To understand Agile there is a need to know where it has originated. It emerged as a counter movement driven largely by engineers as opposed to project managers. The Agile manifesto values interaction and individuals over procedures and tools, working software over documentation and responding to change over contract negotiation. The reality is that project management is nice in theory but the realities can be quite different.

However, agile may not take root in an organisation if there are broader barriers regarding culture and politics in place to block or hinder it.

Theme of this week:

Difficulties associated with management of change.

Grey & Walsham week 9 readings review

This week’s lecture focused solely on the Grey reading. The sense from this reading was that Grey was saying something important but what exactly? This lecture hoped to offer some clarity on what Grey was trying to say. Some of this can be easy to misconstrue but in fact what Grey is targeting in this paper is the discourse of change, the ways in which we think, talk about and enact change.  Grey believes the way we currently speak about change is not helpful and that because of this, change can be viewed as a fetish. There is a propensity to obsess unhealthily about change. The way we think is formed by the era in which we live where globalisation and technology dominate. The current ‘fast paced’ world poses huge challenges to the stability of organisations. Because of this we believe we have to actively embrace and manage change, this is Grey’s summation of the ideology of change. The paper itself is written as a polemic and was published in a non-mainstream journal that led Grey to have the liberty and scope to write the article in a non traditional way. It’s a provocative paper that aims to elicit a response from the reader.

A lot of what Grey has to say is not generally heard in the normal discourse on management.

There are three main components to Greys paper and they are:

1. Are we living in times of unprecedented change?
2. He puts the popular dominant conceptions of organisational theory under the microscope.
3. He takes a critical look at why some of the popular explanations as to why change management fails and some of the panaceas associated with change management.

With regard to the first point, it seems that every era believes it exists in a time of unprecedented change. This is the conceit that each generation and one which we generally ignore. Grey uses personal anecdotes of his father and father in law to illustrate this. Grey is not making the argument that the pace of change is not now faster than ever but is merely asking ‘where is the evidence to support this argument?’. It is important that we look at the gradual changes that precede these so called revolutions in terms of change.

There is also a notion that we live in an information age, this is an argument that is difficult to make stand up. The information age has at least started as far back as the railway age. Seamas gave the example of the hanging file and the pocket watch leading to the timetable as truly effective and revolutionary components of the information age. The change in terms of todays world seems radical not because of the newness of things but because of the speed. However, what matters is not the rate of change but rather of perception of it. Because we enact the world as this crazy frenzied place, we then begin to talk about it like that.

The driver behind this enactment is anxiety, the fear of losing out to rival organisations, losing customers or thinking that customers want everything and they want it now. The main creators of anxiety are the tech industry and consulting companies.

Grey is also critical of the metaphors we use to understand organisational change, both emphasise control. They are the machine metaphor and the organism metaphor. We use these to see change as controllable in an organisational context. This is displayed through the Lewin Shine model where an organisation can: Unfreeze, Implement change and then Refreeze.

This generates a static view of organisations whereas for this module we have been looking at them as dynamic.

The organism view states that the organisation exists in a hostile environment and it has to adapt to changing circumstances or die.

We need to be careful with this view and the notion of adaptive change. Large change management initiatives almost always fail but yet this doesn’t stop or undermine our efforts to enforce change or our confidence in change management.

Grey also has a problem with benchmarking in that it leads to a homogeneity and overlooks the unique and individual facets of organisations. He also rails against the connotation associated with change in that it’s generally seen as good.

We then discussed the two dominant explanations as to why change initiatives don’t work. These are:

• Imperfect implementation: We were right to do what we did but the implementation let us down. The theory was right but the method was wrong- It wouldn’t work if we implemented it differently. You can’t say that if we did it in a certain way that something would have happened differently.
• Resistance to change: His point is that people often have a specific reason to resist change and often this can be a valid reason. If there are people that are offering rejections, they are often stigmatised as being resistant to change. Self-help manuals around managing change… there will always be a chapter on resistance to change. We need to educate these people and show them the error of their ways. Keane talks about managing IS implementation. He suggests that we do a counter implementation. A set of tactics for overcoming resistance, rather than silencing the voice in particular settings. It’s not saying that resistance doesn’t exist.

Leadership, communication and consultation: Chris’s book on studying organisations has gone on a tirade of this. The rigour of this at this stage is to understand why fault is always being found.

Next week:

Two ways which we can go about managing change. How we as managers should be approaching this, as managers who are constantly faced with implementation and issues around implementation.

Recommended reading/viewing:

• The Agile Manifesto
• A Very Short Fairly Interesting and Reasonably Cheap Book About Studying Organizations – Chris Grey
• What the theory of dispruptive innovation gets wrong. – Jill Lepore (New Yorker)
• The Victorian Internet – Tom Standage
• All Watched Over by Machines of Loving Grace – Documentary

Readings of the week:

Fitzgerald – Formalized systems development methodologies

Sommerville – Software process models

Hayes & Andrews – An Introduction to Agile Methods

Wastell – The fetish of technique

Presentation:

Managing the IS design & development process

Minutes of the Class:

Week 7 (continuation)

What is challenging in systems development?

Curtis Article is 30 years old and a lot of the same problems still exist.

“writing code isn’t the problem, its understanding the problem that’s the problem”

Fluctuating and conflicting requirements

• Fluctuating and conflicting requirements are an on-going, enduring problem in software development.

Why does this issue occur?

• Conflict-Organisations are pluralistic- Different groups have different needs and have different perceptions of what a system should do therefore hard to find common ground.
• Users not knowing what they want – we should abandon perception what the requirements are “out there”; instead requirements should be co-constructed through an on-going dialogue. Users often don’t have an understanding of the systems and underlying processes that they execute every day. Limited understanding of processes and practices that system is meant to support is a most common failure of information systems projects. To fix this issue process observation can be used. An example of an air traffic control project in London was discussed in class. The design team wanted to figure out how the controllers worked and figure out how the users interfaced with the system. To understand how air traffic control worked there was a ask analysis done. This is a detailed analysis of what you do under certain conditions. Done via interviews with controllers. The prototypes was that they didn’t quite fit with what was needed which in turn created issues. The air traffic controllers’ understanding of what they did was not at the level required to produce a system. On the job analysis where every single thing was observed was needed. As an example: air traffic controllers were walking over to the rack with the piece of paper with flight details but observing what the others were doing: (hard to analyse unless you witness it first hand).
• Sub conscious practices: Practical consciousness (parts of our life that we perform but often are not aware of or can’t articulate) and discursive consciousness (parts of our life that we are aware of and that we can articulate). In requirements analysis it’s both developers and users that learn in the process.
• If we want to develop systems to support work practices, how we can make sure that the system that we’re developing will support the practices and not get in the way?
• We need to see software development process as a learning activity.
• Politics: bidding for software projects, development estimates etc. A lot of guess work is involved in specifying requirements for any complex system. It is difficult to estimate until there is a full engagement with the requirements. There is a ritualistic element to the estimating and planning process.
• Getting to a stage in software development with no conflicting requirements is a dream that is unlikely to come true.

Communication and co-ordination breakdowns

• Source of these breakdowns include large number of groups, geographic separation, cultural differences, outsourcing, off-shoring etc.
• Documentation was often seen on a project as the main source of communication. Incomplete documentation often created issues. The bigger the project, the greater the volume of verbal communication (Minzberg: Fallacy advising that complex issues can be captured in a document). It is dangerous for the project when there is no continuity between project teams (i.e. analysis and design).
• Not having a single point of contact for the customer can be an issue. Communication practices are the most important aspect of effective communications.

Conclusion:

• Large development projects should be treated as a communication process and as a learning process.
• Requirements analysis should continue throughout the whole lifecycle of the project. Tools and practices should focus on:
• Spreading the domain knowledge more evenly across the team to avoid reliance on software gurus – i.e. refactoring, business embodiment.
• Practices that support on-going change
• Practices that support communication within the team
• Personal attributes and human relations activities provide the greatest opportunity for improving software development process.

Key aspects to successful software projects often come from:

• Negotiating with the customer
• Resolving conflicting requirements
• Mediating between conflicting groups
• These are rarely recognized as contributing factors.

Week 8

Responses to challenges- Most common is around methodology. To what extent does methodology cause/explain these challenges?

Worshipping of methods and seeing them as a silver bullet to all software development issues but it is not advised and can be seen as dangerous.

Fitzgerald’s paper is a nice distillation of the pro and anti methodology argument. Ones of the key points discussed is how organisations use their project method as an argument to win business from those without a recognized system development process.

• Methodologies are seen as a systematic ways of breaking down complex problems and making them easier to manage and control.
• Methodologies produce various kinds of visibilities (e.g. milestones, scope, cost tracking). This in turn contributes to reducing risk
• Standardisation: advantages to a standard process make it easier for people to work together on the project
• Benefits of linear/phased approach: specialisation can be used in a project (using most valuable and most expensive people only during certain project phases).
• Pressures by particular agencies to enforce particular way of developing software (e.g.
• CMMI, ISO)
• Is increasing quality about systematizing the process?
• Danger associated with radial systemisation: we need to consider how methodologies are used in practice? The key is to understand how methodology is used in practice.
• How should you know which practiced to use and avoid in a particular project? – It takes skill and experience to select the aspects correctly.
• Key to project’s success are the people that will work on a project and their experience. Expertise always supersedes method. Methodology often provides a sense of safety due to the fact that it provides systemisation. In software development people are the most important factor (their ability to use method smartly).
• If you become overly reliant on a few good people then you’re in trouble. Success comes from cultivating successful practices in an organisation.
• Why is it that we assume that complex processes can be systematised in methodologies?
• Danger is that it is often assumed that methodology can be taken off the shelf and introduced to a good software project.

Case against systems development methodology:

• Goal displacement – methodologies used appropriately may be very beneficial but we should always focus on methodologies in use.
• There are thousands of different methodologies – what do we mean when we talk about methodology?
• A lot of judgment is involved in how to use methodology. This makes a difference between a novice and an expert. Be careful of falling into the trap that the main way of making software development better is through systematizing the process!
• Methodology addresses the need for security and calming anxiety (David Wastell). Danger: doing the process right becomes the end in itself. Organizational rituals are important in reducing anxiety. Methodologies can give sense of security that success will be achieved. Anxiety is related to personal issues as well as organizational & political issues. Bureaucracy can be a method to hide behind and reduce anxiety. Reason: Too rigid – Too much QA- Trust in the methodology and it will work out in the end is the incorrect way to think.
• Organizations as a ‘psychic prison’ – Huge danger of using software development technologies just to calm anxiety. Consultants charge a lot of money for reducing anxiety.

Readings of the Week:

Curtis, Knasner and Iscoe – Field Study Software Development Process

Lyytinen & Robey – Learning failure in ISD

Chaos report summary 2009

Questions & Comments:

Lyytinen & Robey conclude that “learning from experience can be a long and tortuous adventure” but it is entirely necessary after providing four key reasons why organisations fail to learn. In their offering of methods to overcome those barriers to learning, they speak about knowledge management but give fairly generic advice on how to help on the issue of organisational intelligence such as ‘performance metrics’. Is this really going to overcome the learning problems they write about in their paper? Would a more concrete knowledge management methodology (for example, a transactive memory system) be more useful to help them address those issues?

Both the readings from Curtis et al as well as Lyytinen & Robey tries to understand the problems faced during IS implementations and suggest frameworks to avoid the obvious pitfalls. While these frameworks promise no magic cure or silver bullet but do provide a means to understand the complex landscape of IS implementations. But is it enough? The IS implementations by their very nature remain complex proposition, difficult to fathom, almost impossible to predict and would invariably go off track. That is a given, academic research should focus more on the ways to bring these off-track projects back on track instead of creating frameworks on the implementation landscape as such. Perhaps the wisdom is that by understanding the IS implementation failures somehow managers can learn to avoid the highlighted shortcomings. But it would help much more if research can be done around projects which went off track but then by either sheer devotion and risk taking by an individual or a steering group were brought back on schedule & under budget. Such examples would provide more useful insights to the project management field and help come out with action plans or frameworks to resolve the mystery of large IS implementations. The examples of MCC, Taurus or CompuSys just highlight that fact the in spite of talented managers around & available resources things will go wrong. What does it take to bring things back in order, control the slippages and reign in the projects back on track? I think that is the question academicians and practitioners need to answer.

The three most salient problems, in terms of the additional effort or mistakes attributed were the thin spread of application domain knowledge, fluctuating and conflicting requirements and communication and coordination breakdowns. They explore the causes and consequences of these problems at five levels—individual, team, project, company, and milieu—and observe that problems caused at one level may have repercussions on another. Do you think these are applicable in case of the agile projects? These should vary for the project development teams and product development teams?

Minutes of the Class:

On the topic of Evaluation, Seamas continued from the previous week’s class discussion

The key notion is that Evaluation is a “valuation” exercise

• It is based on what you “value”. Even if this is a legitimate value, the evaluation is still a value judgement
• Foucault said that we can never step out of a discourse. How we evaluate things will always be affected by the way we value things
• Therefore evaluations can never be truly unbiased and we must always be sceptical when reading evaluations (critical consumers)

Evaluation Process as a political tool

• We need to know and understand the politics behind the veil of rationale
• Sometimes an evaluation is used to justify something. In last week’s papers, an evaluation was used to justify something, rather than actually evaluating something
• But sometimes it is used as a calming tool when meeting uncertain outcomes or risks
• Human behaviour has a tendency to lean towards league tables and rankings. But this only focuses on certain features to highlight
• Evaluations is a ritual that one follows – to perform due diligence

The language used in evaluations has the power of control

• The Metrics, KPIs, Graphs all combine to convince readers. Although on the face of it, it appears emotionally detached, however we know it is based on value judgements

The idea of the Overt and Covert perspective

• We should be cautious about what evaluations highlight but also what was hidden
• Metaphors are always coming from perspective. Drawing attention to one thing but always draws attention away from something else. Therefore, we should always be very critical consumers of evaluation, especially when reviewing things that are highlighted – to look for what is covered or what we have been drawn away from

When is the best time to conduct an Evaluation?

• Key notion here is that with the passing of time, things can change, and an evaluation done in the past might not hold up in the future – “Something that looked really good at one point can look really bad in another point”
• “It’s too early to say…” if something can be deemed great
• Seamas suggested to read Joseph Stiglitz’s essay on the US Administration – describing the short-termism of the administration’s view, freely admitting to delivering policies that are impactful only in the short-term, without knowing or understanding the impact of the medium to long term. The estimated time-lag of implementing something and seeing a fruitful outcome – approx. 17 years, so it didn’t make sense to do something long term because it will be long forgotten
• However, note the example of Bill Clinton and his awareness of a long-term legacy
• There will always be pressure to make a (short-term) marker in an organisation. But something that may look successful now may not do so in the long term (and vice versa, in that something that looks bad now can be of huge significance in the long term). Therefore managers need to be aware and think in the long-term

Interpretative approach to evaluation

• Recast evaluation as an on-going dialogue, rather than reduced to a nice dashboard
• Admit to the politicality of the process
• Need to actively create the reality, to appreciate the value that is set. To then generate commitment and actions from an evaluation
• Need to be sensitive of what’s going on, to understand the idiocy of what the current evaluation process is. To find spots of resistance and work at ways to get buy-in, through promoting and shaping the interpretation, to motivate into a collective action
• Aware of multiple views and multiple parties involved – Need to understand how different groups can interpret an evaluation differently with different assumptions and different meanings. To seek these groups out (RSGs) and listen to their views
• Can’t always have consensus but it doesn’t mean it is not valuable to engage in a dialogue process. Can find that doing this can make the eventual executive decision more palatable to everyone (the Harmony perspective)

A Learning process

• Use evaluations to find ways of understanding things. To see the evaluator as a collaborator in a teacher/learner relationship
• Work on shaping this into reality and changing the current process / view of the process. The outcomes of which are drivers of actions
• Evaluation as an ongoing sense-making process
• In Finding ways of mobilizing; Finding ways of understanding things; Finding ways to get consensus; Finding ways to get collective action
• Genuinely discuss what the best course of action is and create an environment to let people speak candidly
• Involves huge amount of skill to do this. It is a Social Shaping skill

The discussion evolved into a discussion on Communication Skills e.g. Alex Ferguson managed Manchester United through a million conversations

• Committing to dialogue as a way of management
• Developing a sensitivity and shape how people make sense of things
• Framing language to get buy-in and mobilize collective actions

Need to develop the relationships to allow people to be candid

• Otherwise very toxic if everyone are false and say things they don’t mean
• Need to promote honest dialogue, that produces actual meaningful action
• Listening / Giving feedback is a very powerful skill

Week 7 Readings and Key Learning’s from the Group Presentation

Problems of IT Projects

• Complex and time consuming, requiring good Stakeholder Management skill
• Communications is key and need to manage up/down/across the organisation
• Politics / Culture / Language issues encountered
• Scope management/scope creep

Conclusion

• No silver bullet – use different development methodologies where it makes sense
• Building relationships is key, and requires a good balance of hard and soft skills
• To learn at all levels – creating an learning culture / a collaborative environment, with candid dialogue and a supportive management
• Confidence to know what is going on, to step back and say something different

Seamas’ view on problems of IT Projects and issues with Software Development

Notion of “software crisis”

• Very similar issues are enduring down the years. One explanation is that software development is different than other projects (such as building a bridge). There is a lot of flexibility in s/w development and easily influenced by various stakeholders / senior management. The success / failure rate as shown in the Chaos Report is therefore expected and normal
• However the other side of the argument says that it shouldn’t be much different, in that there is specialist knowledge required, and much of the issues mentioned matches that in other discipline

Key factor of success

• The problem is managing the size of the project. It is said that s/w projects don’t scale well. If we want to minimise risks in s/w projects, the key lesson is to set a limit of 6 people per project part. Above this scale will be problematic
• The Chaos Report said there are more successes in recent years due to smaller agile projects, a decrease in waterfall projects and a decrease in project size. This reflects the above point of the size of projects and how managing each smaller part is crucial

Domain knowledge

• There is a thin spread of application domain knowledge. For s/w projects to succeed there is a need to know a lot about the domain in which the s/w will eventually operate. This knowledge is therefore critical
• If the knowledge is scarce in your project, be very careful as this is a very risky project – “Writing code isn’t the problem, understanding the problem is the problem”

“Project Gurus” (Domain knowledge experts)

This existence of these experts are very real in practice, They are extremely familiar with the application domain and often integrate several knowledge domains. They are the focal point in a project and often adopt an unofficial management position, with most things needing to go through them

Pros

• They can be helpful to identify something that is not written, to see problems not noted or are about to happen. To turn things around from going down a wrong path and know what would not work right away
• Usually a very technical person (even if not a coder) and therefore can communicate well with software development teams
• Large amounts of time is saved from their learnt lessons that are gathered with time and experience. They are also very giving about their knowledge

Cons

• They tend to internalise problems of the project, taking issues personally
• Major risk factor for a project – if leaves the project, communications and the project itself can completely breakdown
• They may have their own power/political agendas that can hold project progress, or prevent things being done
• They may dominate the design discussions – which can be good or bad
• Application domain experts are very rare and very specific to their domain

What can be done?

• Educating new people – through shadowing / listening, to get the knowledge spread around. How to develop the current learning process to bringing people up to speed
• To have these lessons taught to a core group – make changes to facilitate this, to mitigate risks tied to certain individuals
• Appreciation for the practices that exists, regardless of the s/w is elegant or not
• The solution is not very efficient and clear – but there is a need to learn from the expert, likely over a prolonged period, with trials and error

Readings of the Week:

Mintzberg – Rise and fall of strategic planning

Wilson & Howcroft – Power politics IS evaluation

Walsham – Chapter 8

Questions & Comments:

Mintzberg paper:

Mintzberg’s concern with strategic planning is a valid one but I feel he hasn’t offered any alternative solutions. Would the group agree that formal planning is still completely necessary in organisations, even if the understanding and implementing of it is, as Mintzberg argues, not very well executed?

The conventional organisational strategic thinking as well as planning is heavily influenced by the old military strategy treatises with emphasis on military style of control and directions coming from the top. Mintzberg attacks this mind-set and sees strategy as consequential effect of the trials & errors from the activities and experiences of the middle management (Fallacy of Detachment). And this does make sense with shift to new economy breaking older norms and conventions. But the ground reality is that most of the CEOs are still convinced that strategy can only be a top down affair and only grudgingly relax the tight controls put around strategy formulation. In most cases CEO and an elite cadre sitting in boardrooms are responsible for devising strategy for the whole organisation at the exclusion of others. In fact collaborative environments are considered as a move towards chaos and resented in strategy formulation. Why is it that even in innovative companies like Google & Facebook strategy is still formulated in the company boardrooms by a select few rather than within the office corridors with full participation of middle and lower management?

Walsham paper:

In Walsham [ch 8] I think there clearly was merit to a lot of what Brown did, when in charge of Sky. His overall business approach of more autonomy for branches, while harvesting data centrally and maintaining a lot of control centrally is a plan which is very common in such institutions these days. When he was evaluating IS systems, the chapter says that he suppressed stakeholder conflict, and dominated evaluation proceedings. I think there is no harm at all in allowing some conflict among some stakeholders when making large IS decisions, and doing evaluations. The caveat to this, is that remains true as long as there exists clear exit criteria, and indeed the conflict is not allowed spin out of control. I think in this instance Brown went too far in suppressing all conflict and ensuring his way was the only way. I also think a lot of people would naturally take up a position where all conflict is bad. But my working life tells me that when two [or more] people or teams are really passionate about something [even when they have conflicting positions], the synergy from ensuring those passions work with each other and not against each other generally gives the process and project a far better end result.

Wilson & Howcroft paper:

Melanie Wilson, Debra Howcroft article discusses the requirement to attain stabilisation in various IS implementation stages. Using the Zenith Nursing Information System case study, Wilson and Debra explains how evaluation can be used in attaining stabilisation. Evaluations are important resources for supporters of an information system to enrol new users and consolidate support from those already enrolled. Varying concerns of the different relevant social groups (RSGs) are attended to in a specific manner by the supporters of the system in such a way that the technology is constructed as an ‘answer’ to their problem. Systems evaluation is consistent with the conceptualisation of systems design and implementation, as a process of social contention and political, as well as technical and determination. Technology can stabilise in circumstances where relevant social groups see their problems as having been solved by the technology. How can we interpret this as the problems and solutions associated with a technology present themselves differently to different groups of people.

IS evaluation is always a political process and is subjective to the power dynamics within the dynamics. The IS system is never objectively evaluated but is always reviewed through different lenses by groups within an organisation. And furthermore evaluations are done by senior management with some representation from user groups but in all likelihood most of these evaluators won’t be the end users of the system. I’ve been part of evaluation process of a number of core banking solutions at Tier 1 banks across Europe and in my view the enrolment of new user groups is never easy or smooth. It is always fraught with thorny issues of shoddy planning, ineffective quality measurements, lack of training, fear of unknown & other communication challenges. A typical example was AIB’s implementation of next generation banking platform from Oracle of which I’ve first hand insight as I was representing Oracle. The product was chosen after a year long evaluation and almost 2 million euros were spent on the evaluation itself which consisted of number of product demo sessions by Oracle teams and multiple visits from AIB’s seniors to Oracle facilities at Mumbai & Bangalore. But the very first enrolment session held after the product procurement at AIB Bankcentre was a disaster for both the bank and supplier. This was the first session where end users were given a demo of the Core Banking product. Within 5 minutes of demo session start, there were murmurs of front-end being ‘ugly’ and resentment on the ‘Indian accent’ of the Oracle representative giving the demo. The resentment within user groups could not be managed during subsequent phases and the whole implementation was a failure. It resulted in a court suite which was settled out of court at the cost of 20 million to Oracle and significant cost to AIB also. AIB divisional politics and power of mainframe group within AIB was one of critical factors in failure as with new platform this group was afraid of losing control. It resulted in significant monetary loss as well as loss to the bank of next generation banking platform. Why is it that the end users are not provided proper representation during any new IS system implementation? Is it the power politics or is it that in general the right emphasis is missing within organisations on the Human–Computer Interaction (HCI) to validate usability considerations during evaluation processes which then leads to failure in enrolment and finally project failures.

Minutes of the Class:

Despite the year in which the Mintzberg article was written it remains remarkably current. It is not the date that matters but the issues they raise and how those issues are raised.

Strategy:

Mintzberg – What’s he trying to do? What’s his main point? What’s his target?

Strategy and evaluation are intimately connected. Strategic planning can be locked up in an Ivory tower which isolates it from stakeholders which have an everyday involvement in that which is affected by said strategic planning. Strategy and the process by which it is produced. What does he mean by strategic planning and strategic thinking? Why the distinction?

The strategic planning movement:

David Nights draws on Foucault to look at the genealogy of strategy and how the term strategy has come into common business parlance. Up to the 1930s there was a sense that the invisible hand of the market held sway. A lot of the language around the development of management as a discipline originated in business schools which started in early 20th century.

The professionalization of management happened at the start of 20th century. The scale and scope of organisations were growing. Globalisation started to become a reality. Organisations became so big that owners/managers could no longer manage them. This resulted in the hiring of a professional class of manager. Previous to this the owner/manager didn’t have to justify decisions to anyone. Key issues following this development were trust, and a loss of control.

The idea developed that a body of knowledge began which grew around management could be learnt. In the infancy of a new school of any discipline a new language develops. When justifying decisions to the owner there was a particular vocabulary/language developed and used. Business schools services were started to service the need for professional managers. This class of professional managers had to have a particular type of knowledge that not everybody had access to. When you train as a manager there is a certain way of seeing things and reacting to things. Strategy is very central to what being a manager is about.

Strategic planning has its origins in WW2 and was developed further during the 1960’s. This period is often referred to as the systems rationalism period of management. It was heavily influenced by the development of management techniques which were influential in shaping the 2nd world war. Mintzberg criticises is the development of the Strategic planning function in organisations and how it was originally conceived. He is mindful of the fact that strategic planning is a product of this way of thinking – a very formal rational approach to how one manages an organisation.

A key feature of this form of strategic planning criticised by Mintzberg is the separation of thinking and doing or the separation of planning from implementation. Strategic planning in organisations in the 1960’s departments recruited the brightest and the best. These people would analyse data, look at the analysis, try and understand the environment and produce strategic plans on that basis. These strategies would produces in a separate department and passed on to the doers for implementation. Often, the strategy process retains some of the aspects of this approach. Mintzberg is wary of this approach and its possible shortcomings.

Mintzberg notes that this is not what strategic thinking should be about. He says that this model of strategic planning is very far from strategic thinking. He assumes that strategic planning can often spoil strategic thinking by causing managers to confuse real vision with the manipulation of numbers.

Mintzberg talks about 3 specific problems/fallacies which occur in strategic planning:

1.) The Fallacy of Prediction – This rational betrays the notion that if we understand the world mathematically and analyse data in line with that understanding we will be able to predict how things will go in a particular market. Mintzberg thinks that this is fallacy. It’s a very deterministic view.

2.) Fallacy of Detachment – This objectification of the planning process and not involving the the organisation. The problem with this is that the context of each company varies. Mintzberg’s argument is that understanding comes through engagement with that context over an extended period of time. Number crunchers who have never been involved with the business coming up with the best way of doing things is a fallacy. In order to have a feel for how things are going you need engagement with the business and the environment over an extended period of time. Mintzberg says you’re always very limited if you’re not someone who understands the business and the context. If understanding context comes through engagement (and there are different kinds of engagement) how do we tap into this knowledge that resides around the firm? The answer lies in different types of engagement with different aspects of the business.

3.) Fallacy of formalisation – Dreyfuss argues that human expertise at its best can never be codified/formalised into a set of rules. The concept that a set of rules that are distributed to the doers to be carried out is very problematic in practice. There will always be exceptions. They will catch you out.

Karl Weik writes about high reliability orgs, e.g. Nuclear power plants or aircraft carriers. These are places which are safety critical and very small deviations from the norm can result in huge consequences. In organisations like this there is strict protocol implemented. When there is a major accident/disaster (e.g. 3 Mile Island), where happenings conspire to render the protocols useless, a severe audit occurs. This severe audit is a conspiring of circumstances which exceed the capacity of the protocols to deal with them.

Where there have been near misses it has been shown that disaster has been averted by human experts using an intuitive feel for what’s going on, overriding these protocols and doing something strange or out of the ordinary contrary to the guidance of the protocols in place. It has been suggested that to avoid disasters of this nature, a culture of constant alertness should be cultivated. This is referred to a collective mindfulness. People are in constant discourse about what’s going on around them. If you want to avoid these disasters you need more than the protocol.

Hubert Dreyfuss argues that human expertise at its best cannot be codified, that to go beyond a certain level you have to use an educated intuition. A key aspect of Dreyfus’ outlook is that there is no learning where you can’t make mistakes. If no mistakes can be made it is impossible learn. However there must be a distinction between bad mistakes and good mistakes.

Mintzberg suggests that strategic planning and analysis should support strategic thinking as opposed to providing answers by themselves. Though it should be remembered that it is calculative analysis and they cannot replace strategic thinking. Mintzbergs critique of strategic planning is that it is analysis done without feeling for context.

Despite that, strategy is still formed in boardrooms isolated from other stakeholders. Mintzberg’s critique of this phenomenon applies very well to Big Data and Predictive Analytics. It has huge parallels with strategic planning. It could be argued that we are moving further away from strategic thinking, and further towards strategic planning without context. It is suggested that some insights can be captured by algorithms without any human input. However, as the questions of these algorithms grow more complex the results grow less reliable. Rather than seeing the data as telling us what to do, the key thing may be to use this data to provoke conversation and challenge assumptions. Analytics could be very helpful in providing questions, rather than providing answers.

Mintzberg says we should abandon strategy formulation. Strategies are formed over time by accident and chance events. “Strategic formation walks on two feet, one deliberate, the other emergent.” Mintzberg talks about management as improvisation. Strategy is about responding to things on an on-going basis.

A strategic management process will often produce a document. The document may be perceived as important to some. The learning gained by people involved in the process is more valuable than the actual report. The document shouldn’t be confused with what the process produces.

Mintzberg says the most successful strategies are visions not plans. People buy into visions. A vision orients you to your environment. The alignment of different aspects of orgs is an ongoing accomplishment. A Constant realignment and choreography.

Evaluation:

Strategy is an on-going process – partly delivered and partly emergent – constantly in formation. If we see strategy as an on-going learning process then feedback from evaluation is important.

What did we learn about evaluation? We can’t get away from interpretive design and bias. An objective evaluation is impossible. Evaluation is a measured process. Statistics and metrics are important to evaluation because they are quantifiable/measurable. Quantification is important and lends credibility to the process.

If someone wants to produce a successful report they will often concentrate on what was successful and steer clear of the failures. Measurements, statistics and where it was successful are likely to be emphasised. Methodology is often emphasised and evaluations are generally written in a passive voice. This is so people can understand the process and observe what was considered (and not considered) with ease.

The first issue of evaluation is that it is all necessarily political and it cannot be objective. Value is a central feature of evaluation. It is a valuing exercise. It depends on what is valued and how you value it. Evaluation is, by its nature, tied to values. A key thing in any evaluation report is to get beyond the pseudo objectivity. There is a sense that there are scientific processes that can produce these objective reports but all observers are always looking at something from a certain perspective.

Foucault says we can never step out of discourse. We are always constituted by the way we look at things. In other words discourses are crucial. Common discourses that tend to be important in evaluation are cost, efficiency etc.

Evaluation is always about taking a perspective (which renders objectivity impossible). We should always be cautious about being taken in by this faux objectivity. We should always look for the underlying, covert assumptions.

Evaluation removes variables…to a certain extent. There is something about us that craves evaluation. It is the sense of security that it offers. Experts offer an opinion as to which option might be is best. It provides comfort. We like to disambiguate things. We should be sensitive to the dangers of this way of thinking. For instance university league tables are changing the way universities are run. Universities are changing to move up the league tables sometimes to the detriment of the quality of education received.

The literature on evaluation is marginal. Most of the literature is about refining techniques and producing objective evaluations (which is impossible). Instead of focusing on the outcome of the evaluations, one should focus on the process and the politics of that process. You will always see the overt but we concentrate too much on the overt and need to search out the covert.

Evaluating reports from authoritative institutions is a ritual. A report can validate a decision but may be pure fiction. Rituals comfort people. Rituals make fear and uncertainty less prominent. Social ritual calms anxiety and alleviates fear. An important aspect of evaluation is learning and change but this function is often subverted to other functions like the political function of using it to legitimise something.

The readings try to draw out the political nature of organisational management. Often there is a veil of rationality and that there are much more important things going on in the background. This undermines the ostensive rational workings of the organisation.