There are a number of models for handling change in situations of hard complexitiy and the Hard Systems Model of Change is one of them. Change situations that are characterized by hard complexity are usually easier to achieve. On the other hand; change situations of soft complexity, where issues are contentious and there is a high level of emotional involvement among stakeholders is usually less easy to achieve. We all know that during Sharepoint implementations these soft factors of change are often well presented. Therefore it is important to have some knowledge of both models to increase the success of change of Sharepoint implementations.
In a simplistic form both models can be seen as on one side the hard infrastructure side and software development part of the Sharepoint implementation and on the other side we have the human, business and politics oriented side with many more soft factors of change. The hard side is better to plan and manage where the soft side is very difficult to plan and manage and made visible. It is often this soft side of change that causes most problems.
The Hard Systems Model of Change is a method for designing and implementing change in situations that have the characteristic of hard complexity. These are situations where the problems are understood and agreed by most people. The quantitative criteria can be used to test options for change. The more simple systems prevail. There is often a unitary ideology of relationships that prevail. This approach provides a rigorous and systematic way of determining objectives (goals) for change. The goal setting is followed by the generation of a range of options for action which can be tested against a set of explicit criteria.
The process involved in the Hard Systems Model of Change can be thought of as falling into three overlapping phases. The descriptive phase (describing and diagnosing the situation, understanding what is involved, setting the objectives and performance measures for the change). Then there is the options phase (thinking about what might be done: generating options for change, evaluating options and there is the implementation phase (selecting the most appropriate option, putting feasible plans into practice and monitoring the results).
The reason why this Hard Systems Model of Change is brought forward here in relation to Sharepoint implementations is the fact that the same things have to be done related to the hard factors of the changes. When Sharepoint is implemented, then there are things that need to be done in the infrastructure and on the development side. These things are often well suited to approach in a planned and systematic manner, whereas the soft side of the Sharepoint implementation is not well suited for only systematic plans, schematics and metrics. So, Sharepoint implementations have a hard and a soft side and these sides are possible candidates for the Hard Systems Method of Change and the Soft Systems Method of Change.
Within the phases descriptive, options and implementation just given, a number of stages can be identified. They are:
Stage 1 – Situation summary
Ask yourself - is this situation characterised by hard complexity (difficulty), ‘closeness to certainty’, & unitary assumptions about stakeholder relationships. Or is it a ‘mess’ (soft complexity), a ‘far from certainty’ situation. If it’s a mess, using the HSMC will probably not work out. And here we see that many organizations neglect the signals of soft complexity and approach the Sharepoint project the hard way. This often is a major reason for project failure and that is why this stage is very important. Do the proper analysis of the situation and put the soft factors on the soft side, don´t work on them the hard way and put the hard factors on the hard side and work on them with for example the Hard Systems Method of Change.
Furthermore identify the components and boundary of the system that will be changed. Also identify the decision maker’s overall purpose in the change situation. And finally identify the factors that are having an impact on the system and how these causes inter-relate. How often doesn´t it happen that the system integrator or the general administrator is the Sharepoint goeroe while he or she doesn´t know jack about the system? Let alone that they know something about proper change theories and how they are related to Sharepoint implementations. If you know even a liitle about this interrelated area´s, then you understand that implementations of Sharepoint which start from the bottom without proper backup from middle and upper management, are doomed to fail and are doomed to eat a lot of money that could be used somewhere else. And who gets the blame? Sharepoint while of course the failurepoint lies somewhere else.
Stage 2 – Identifying Change Objectives
A key part of stage 2 is to identify the overall objective or goal of the change and the sub-objectives that contribute towards this. The objectives are normally, formed into an ‘objectives tree’ or objectives hierarchy.
It is allmost needless to say that the above paragraph is often totally ignored when implemting Sharepoint. Objectives? Sub-Objectives? Objectives related to goals, or even sub-goals? A proper chart of all these factors and how they are related to each-other and are related to a proper business case? Nhaaa, we don't need that? Do we? Yes, of course we need this as a start and doing your Sharepoint thing without this, or something a like, is calling failure on the phone. Be honest: how often does this happen? Well, I saw it a lot and again in many cases it was a lost change war. Soldiers were dead or gone and the project was blood on the battlefield.
The objectives tree should ‘read’ logically downwards, from the top objective to the lower level ones (and upwards from the lowest level objectives to the top one) in the sense that each lower level set of sub-objectives should contribute to the achievement of the next higher level objective they are attached to – and so on. They must be mutually compatible. This is, perhaps, the most difficult stage of the entire model. Don't be afraid for failures or incomplete objectives. It is better then nothing and it focus your mind on the right things. Don't try to do it perfect fromt he start. See it as work in progress. A very important thing to mention though, is communication and review. Communicate, communicate and review, review and review.
Strict application of the model requires each objective to be measurable in terms of its achievement or not. Objectives should be what the system must achieve to improve – it is the options for meeting the objectives that specify how the objectives might be achieved. Doing a Sharepoint implementation without having something like this, is a lost case.
Stage 3 – Performance Measures
Quantify each objective in the tree. Where this is difficult, use a rating scale.
• Costs in cash.
• Savings in cash.
• Waiting time in days, hours.
• Sales volume in dollar value.
• % Meeting quality standard, etc
Often this stage shows objectives that can be thrown away. Objectives with too few ratingpoints are not needed. When people try to do this and want to be perfectionists, they find themselved burried with objectives without a cause. Throw them away, combine objectives and only stick to the ones with proper value. This is an important stage and it is fun. Do it in a team with yellow papers on the wall. Throw some workshops against it and the results will be satisfying, solid, sound and save. It will save you also a lot of money down the road, guaranteed.
Stage 4 – Options generation
Often the lowest level objectives of an objectives tree become the options for change. That is, the means (or the how) of bringing change about rather than the ends (or the what) of the change. There will, however, almost certainly be more options for how to make the change than the ones that appear on the objectives tree. Generating options for change (having decided what the goal is) is a creative process and creative thinking techniques can be used to help with this.
Like being said in Stage 3, throw some workshops against it. Be positive and flexible. But, don't forget to be pragmatic and stay pragmatic. It's almost as bad as having no objectives to being a meeting and workshop tiger just for having the meetings and workshops without focus on the results. Avoid that. Keep it all kiss bss, keep it simple and stupid but smart and short.
Stage 5 – Options editing & Detailing
To make evaluation possible, some of the selected options may need to be elaborated or even ‘modelled’ – clarifying what is involved, who is involved and how it will work. This can involve: - Charts, diagrams, flow diagrams. - Cost-benefit analyses. - Computer simulations, scale models. - Experiments and trial runs. At first it seems that this all only takes time. That is not the case. It saves time. ignoring this phase or not giving it the proper attention and time will certainly costs you a lot of money and time down the road. It is like not setting up your testcases when developing. It will bite you and hunt you down. You will not win. Do the modeling, do the detailing and editting and talking. Make the testcases and redesign them when needed. The testcases in this case are the models, simulations and what not. Keep in mind that every meeting, every modeling sessions can save you a lot of money. Minutes can be translated to thousands of dollars. No kidding. Sharepoint is a complex change animal, allways keep that in mind.
Stage 6 – Options evaluating
Options that seem feasible are then evaluated against the criteria for making judgements which were set up earlier at stage 3 in the change process. Each option can be rated on an evaluation matrix (see overleaf). Options that are not mutually exclusive may be combined, if there are added anticipated benefits. If needed, go back to step 3. it is a recursive process. Recursiveness that makes money, not costs money. Failure in having subjects and options when they are needed, will be lost money and added time.
In problems of a defined ‘hard’ nature, implementation will usually not be a problem. However, unless some consultation has been carried out with those who must make the change, there is likely to be some resistance and something could go wrong. Implementation is frequently a test of how much people involved in the change have participated in the design.
We are talking about one model here, the Hard Systems Model of Change, but this stage shout for more. One stage model must be mentioned here and that is the stage model of Kotter's Leading Change from 1996. it's a book which will be analyzed in a later blog. But what can be said here is that the book goes about eight steps of change and every step tells you something of the phase of the change process and what had to be done. Well, step two of Kotters model tells us to form a guiding coalition. That's something llke a group of fans for your change. Important key stakeholders that will back you up when needed and that support the change. Another step of Kotters model is having a clear vision and constantly communicate that vision. Well, if you do both these steps, among others; having a guiding coalition and a clear communicated vision, then this stage 7 of the Hard Systems Model of Change will go more smooth. But, more on this will follow in other blogs.
Three alternative strategies for implementation:
Pilot studies leading to eventual change: help sort out any problems before more extensive change is instituted. Parallel running: The new system (e.g. new computer system) is run alongside the old until confidence is gained that the new system is reliable and effective. Big bang: Maximises the speed of change, but can generate the greatest resistance to change. Carries a high risk of failure unless planned very carefully. This has a lot to do about the speed and way of implementing the change. Are we going for the smooth incremental change, the bumpy change or the radical almost revolutionairy change? especially this paragraph will be handled in other blogs bacause other interesting writers wrote some great books about this matter and they will be analysed in future blog.
Stage 8 – Consolidating & Carry through
It is important that in all change situations that there should be continuing vigilance and there should be continuing support for those making the change. Two writers have to be mentioned here and they are Hayes (2010) and Kotter (1996), who both wrote about stage models of change and who both end their stage models with interesting final steps. Hayes says that you have to sustain the change after implementation. Kotter call it anchoring the change. What also is important is that it must be done thouroughly. Don't call victory too soon or the change will not be settled. The change has the biggest part of possible success when it is something of "the way we do things around here", if it is part of normal work and integrated in the culture of the organization. And let me tell you one thing: Sharepoint is soo freaking cool and immense and big and complex and usable and what not, that having Sharepoint in your organization on the level of "it is how we do things around here" is not a ttrivial task.
Issues when using the Hard System Models of Change
There are some issues when using the Hard Systems Model of Change in general and these issues are also existent when used with Sharepoint implementations. People who are likely to be affected by the change should be consulted as early as possible. They should be kept informed throughout the design and implementation period. Support from senior management is essential for any but the most localised, operational types of change
All the information that decisions makers ideally would like to have is not always easily and quickly available. Testing out options can be a time-consuming process, particularly if models have to be built and tested. It is possible, however, to go through the stages of the HSMC quite quickly to address key factors associated with the change situation and identify at least some tentative solutions.
Using what Paton and McCalman (2000) call a Q & D (quick and dirty) analysis can be a useful starting point for the change agents tackling a more complex problem. Even if if the problem situation is a messy one, where it is not possible to set quantitative criteria for evaluating options (as the pure method requires), it is nonetheless useful to construct an objectives tree as the first stage of a change process.
Almost every Sharepoint implementation has something to do with hard factors, hard elements like the infrastructure that has to be set up and the software components that has to be developed. Besides these two there are probably more hard elements concerned. What can be said about these elements is that they lent themselves probably for the Hard Systems Model of Change and this can be helpful when searching for a systematic approach to handle those hard elements of the Sharepoint implementation project.
The Hard System model of Change is not the only model that can be used in these circumstances and in other blogs more models will be described. It can be said though, that when no model is used during the implementation of Sharepoint for these hard facts, then it is likely that problems will arise and that those problems are not anticipated. The same is true for the soft system change, the more complex change which will be described in the next blog about the Soft Systems Model of Change.
To be well equipped with tools to make your Sharepoint implementation a success, it is important to at least think about models for hard elements of the change and the soft elements of the change. For every situation you can look and search for models that can be used for the situation at hand. Important to keep in mind though is: use something and don’t let it come as a (very expensive) surprise afterwards or during you Sharepoint implementation.
Hayes, J. (2010). The theory and Practice of Change Management. Palgrave Macmillan.
Kotter, J. P. (1996). Leading Change.
Senior, B., & Fleming, J. (2006). Organizational Change (3rd ed.). FT/Prentice Hall.