In summary an example creative problem solving approach may consist of stages, such as:

1. Exploring the problem by opening up consideration of the problem space.
2. Narrowing down the problem again by defining it based on the new understanding.
3. Opening up to a set of ideas for possible solutions.
4. Narrowing back down by selecting a subset of the possible solutions.
5. Opening up to the potential approaches to solution implementation.
6. Narrowing this down to an implementation plan.

The creativity techniques can then be used to apply many people’s minds to each of the stages. The most commonly know approach is brainstorming in step 3. There are many such techniques, however, all with different properties and needs. It is the application of many minds to the problem in a way that isn’t often achieved in traditional meetings that really gives this value for IT. Choosing the people to bring into the problem at each stage carefully will allow a much better problem solving approach. It will also mean that they will tend to buy into the solution that is eventually chosen, which can help when it comes to implementation.

So next time you have an IT problem, and most of us have many on a regular basis, consider whether a way to apply moiré creativity to it might help. If the answer is “Yes” then consider how that might be achieved – even if you can’t get out the finger paints. If, of course, you need help in doing so then feel free to contact me at sales@sarquol.com or call +44 7887 536083. The ideas can be surprisingly effective when applied appropriately.

What Garner have done it to convert this trend into a pseudo-scientific analysis method, and then to look at various technology areas in this light. The result is a set of reports that looks at areas of technology and state where on the curve the various technologies are, and predict how long it will take before the technology gains mainstream adoption. The reports make for interesting reading, but should people use Gartner’s opinion within them in order to develop their strategy. To say the least the idea of the hype-cycle has its negative side, as illustrated by this article.

The challenge is that the hype cycle is basically a Gartner opinion about the future, and any opinion about the future is likely to be wrong. This needs to be borne in mind if you are planning to develop a strategy based on the hype-cycle. So what could this hype-cycle be used for? My own though is that it is reasonable to use it to consider which technologies are most likely to be of use to you in the future. That is, to prioritise the application of you own analysis.

The reports contain a summary of each technology, and this can be used to consider whether it would be applicable to you if worked fully.  The position in the hype-cycle and the length of time Gartner predicts to full acceptance, however, should be considered in the light of the potential benefit of the technology to you. To make a decision, if the technology has sufficient potential value then it is worth trying to build a serious case for whether it is worth being on the bleeding edge of this one. In doing so, however, be aware that working on the bleeding edge has its own management challenges that need to be considered and mitigated.

So why isn’t this being done, especially by smaller companies? The main reasons I have come across are:

• The implementation investment is too high.
• The introduction of standardisation will damage current delivery.
• All our projects are different, so the value is low.
• Lack of management buy-in.
• Cost-benefit isn’t proven yet.
• We don’t have many project failures, so why would we change.

Given time each of these arguments can be deconstructed, and usually the result is that the benefits from standardisation of process can far outweigh the investment.  The main issue is the perception that the process standardisation must be a massive task with everything defined in a single process manual written and signed off at the beginning. If that is the approach taken then the result is likely to be a problem.

Agile development is quite common in software development. The same principles can be applied to the process development. Start small and iterate; then prioritise the development and implementation based on need. The CMMI approach may be too heavy weight for your organisation in its entirety, but it does identify process priorities with well reasoned arguments for why each area is a priority. (There is a link to it on the Sarquol web site if you would like to know more.)

If you would like to discuss an appropriate approach for your organisation then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

The difficulty is that early on in a project there is little that is well defined and known. The management of capacity and performance is considered to be a scientific discipline and so needs to be concerned with correct, hard and provable data. If the input information is anything less than ideal then the output result is incorrect – from a “garbage in, garbage out” principle.

My assertion is that this is analogous to stating that an organisation’s balance sheet must only contain correct data. The fact is that accountants use judgement to provide the figures on an organisation’s balance sheet. There are different methods, techniques and approaches to doing this – and the approach used needs to be “true and fair”. The figures do not represent an absolute truth, however, only a model. Modern organisations could not function effectively without these judgements.

Thus, my suggestion is that it is necessary to use appropriate judgement to build and calibrate a performance model early in a project. This judgement will turn out to be incorrect and so the assumptions, logic and estimates the model is built on should be documented. Thus, the process and results are open to scrutiny and discussion – which can be an opportunity for learning itself. Done well the resultant modelling should amply demonstrate its value during the course of a system’s lifecycle. If you need more detail please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

I have been left wondering why this should be so in a number of organisations who are all highly professional in every respect. An explanation that depends on short sightedness or lack of strategic thinking is insufficient, as the organisations in question succeed in highly competitive and complex environments.

My belief is that it relates to the stakeholders within the different parts of an organisation and their input to the development process. It is very difficult to deliver a business change programme, and the time scale is always as short as possible. Most organisations roll-out new software technology in an incremental fashion, and so they believe that they will buy time to fix any performance issues as they occur. The project delivery is primarily driven by stakeholders who wish to drive the change as quickly as possible with as low a schedule risk as possible.

When the system is in production there is usually a warranty period, and then the system transitions to an operational state. In the operational state the stakeholder drivers are to minimise maintenance costs. Thus fixing the issues that haven’t appeared yet will not be a high priority – especially since there are usually plenty of issues that are a high priority to work on.

So what is the answer? Unfortunately it depends on the organisation and their culture. In a highly structured and procedural culture the answer would be to make sure that there are identified procedures for following through the need to complete performance assurance. In a less structured culture the answer would be to make sure the operational stakeholders have sufficient power and understanding to put in place protective measures. If you need advice please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.