What solution is proposed?

 The idea seems to be to treat Management as a localised research project. If you have a theory on what is going on then note it down and treat it as a “thesis”. Think through what evidence you have that things really are as you perceive them to be. Think if there is evidence that doesn’t fit with your thesis. If all the evidence you have indicates that your thesis is correct then think though what action you might take to confirm or deny the thesis.  What challenges might someone else present to your theory? What other theories might explain the observations you make? Can you differentiate what is actually going on?

 If your theories, with modification as needed, seem to stack up then start to take some action. In doing so, however, remember that you are acting on a theory and look for on-going evidence of success or otherwise according to the theory. Thus a cycle of thinking and acting is created as the change is initiated and rolled out. It is still possible, and usually appropriate, to adjust the activities as the overall project moves forwards. The whole leads to a management approach that is more thoughtful, and hopefully more likely to be successful.

 This can be extended, however, in the consideration of IT. When applying IT to a situation and in the management of IT issues a similar approach can be applied. I spend some of my time helping to resolve performance problem, and here an evidence and thesis based approach can be near critical to success. The same can be true in other areas, however, such as debugging complex problems or approaching a novel design issue.

 All of this does have one issue though. Time doesn’t always allow a through evidence-based approach to every situation and circumstance. Thus, part of the trick is knowing when to apply the approach and when not. It is worth considering after the fact consideration of the situation even if it is too late to make a difference to the current situation. In this case, you are considering the need for lessons for the future rather than steering current action.

 I’d be interested in feedback on how often people use evidence in their management and IT based activities. I would be particular interested in stories of successful, or otherwise, use of evidence. Alternatively, if you would like to hear more let me know.

• Not being quite sure what the root cause is – management approach, technology etc.
• Having no clear route to a complete solution, as distinct from a temporary work around.
• Having to “try it and see” to solve the problem and continually adjust approach depending on the results.

Why do I assert that performance problems are often in this category though? There tends to be a definite issue that you can point to, and you will know when it is “solved” because the system will be performing well. The reason is that usually the defined performance problem is, in effect, the proverbial  tip of the iceberg. It may be possible  to just solve that fairly easily, such as add more hardware.  It is rarer, however, for this to be a complete solution as there is almost always implications and subtleties of stakeholder needs and expectations that this won’t address.

What to do then? There are  wide range of solutions. One important step, however, can be to form some form of map of the problems, potential solutions and how they are related. There are various defined techniques but start with something simple:

• Write on sticky notes all of the symptoms you can think of. (e.g. Too slow a response time.)
• Write on a different set of notes all the solutions you can think of. (e.g. Buy more CPU.)
• Write on yet another set all of the constraints you can think of for solving the issues. (e.g. Budget)
• Group these together and draw lines between them to show relationships.

This is based on a technique called “Causal mapping”, for which there is support software available, though I f. The process tends to help clarify what really needs solving, and how you might go about solving it. The examples above are about performance problems, but the idea can work for a much wider range of issues. Try it, and let me know what you think and how you get on.

10 Questions for Effective Networking

http://www.success121.com/index.php?option=com_content&view=article&id=45&Itemid=34

The article is written by a “professional coach” who discusses the benefits of value-based questioning when networking. It seems a better approach than the standard sales-lead approach, and may be useful in breaking the ice with potential clients for the future. I found it interesting, see if you do.

WIMMING YOUR WAY THROUGH A HARD JOB

http://blog.theitjobboard.co.uk/2010/03/wimming-your-way-through-a-hard-job/

Enjoy.

1. Product innovation, whereby a new product or service is brought to market or a current one improved;
2. Process innovation, whereby processes and procedures are modified to make them more efficient
3. Positioning innovation, whereby a product or service stays fundamentally the same but is sold to a different market or as a different proposition
4. Paradigm innovation, whereby an innovation is effectively disruptive and facilitates some form of fundamental change

This is an interesting way of looking at the possible innovations available, especially since it is likely that one company might be pursuing more than one of these approaches at the same time. On reflection, however, I found it more interesting to consider where one type of innovation is purported to be another type. It is clear that this happens in the IT industry on a regular basis. The release of Windows 7 is an example, whereby the change is quite clearly a Product innovation in that it has changed the way Windows works internally. The product, however, is still Windows. Looking at the Advertising of the launch, however, one might be forgiven for suggesting that Microsoft is trying to position the change as a Paradigm shift. I believe that this allows them to “spin up” the perceived value of the new Windows version to users. I would suggest that some of the “Green IT” initiatives (c.f. “Green wash”) are similarly positioning pre-existing products as environmentally friendly initiatives.

Is it also possible, however, to position a change the other way? If you have a change that fundamentally changes the way that a business works then might there be value is positioning it as a simpler product or process innovation? In doing so the threat that the change poses to stakeholders might be downplayed and so allow a change into the environment that would otherwise meet excessive resistance. I can see that there might be good reasons for doing this, but would this be unethical? That is a difficult challenge that I suspect would need to be dealt with on a case-by-case basis. I don’t believe that the process has to be inherently unethical unless you really are getting an organisation to take on more cost and risk than it would otherwise be willing to do. This, in the final analysis, is the ethical challenge of any form of spin. When does “spin” spill over into out and out lies?

In more practical terms, it may be worth considering this as a checklist when introducing a change which is innovative, and in IT most of our significant projects are effectively innovative change to someone.  Once the innovative direction is considered then there will be consequential considerations that need to be taken into account. In the case of process innovation, for example, there will be a need to focus on the people who will be receiving the change and engaging them as early as possible. In a product innovation scenario, however, it is much more likely that simple communication about the changes will be necessary.

If you wish to read the article it is: “Francis, D. and Bessant, J. (2005), ‘Targeting innovation and implications for capability development’, Technovation, 25.”

The field of business strategy has looked at this issue of an uncertain future and come up with a number of approaches for managing considering it. One of these is called “Scenario Planning”, and basically consists of building a set of different future scenarios which are considered plausible. They are not attempts at predicting the future, only of painting plausible futures. It is then possible to consider how these scenarios may play out according to the decisions you are taking now. This allows a form of sensitivity analysis on the decisions that you are making.

A process for approaching this would be to:

1. State the architecture decisions that need to be made.

2. Identify the major environmental forces that impact on the architecture.

3. Build four scenarios based on the principal forces.

4. With the scenarios in hand, identify architecture opportunities within each scenario.

5. Examine the implications of the decisions across the range of scenarios.

As an example, lets assume that you need to decide between two architecture design patterns, A and B. For the example “A” provides a highly resilient and fault tolerant solution but involves significant additional hardware, operational administration and development costs over “B”. The decision that needs to be made is whether the extra capability of “A” is justified. If this is a new system then it may not initially require large processing volumes, and may be able to accept a system outage. The scenarios, however, could be used to examine under what circumstances the additional capability would be justified. If the system catches on, for example, how long might it take for the system to become business critical? Would you have time to re-engineer it? This may lead you to decide the additional capability is justified now, or would allow you to understand what changes in the environment might lead to the additional capability being needed.

In terms of the Architecture Roadmap then, the Scenarios developed and decisions taken may then be included in the roadmap. With this in mind a Planning Scenario is chosen. This defines the assumption set on which the roadmap has been built. In doing so, however, the other scenarios are not discounted but used as alternatives to which to architecture should be resilient. Where the architecture isn’t resilient to a scenario, then the roadmap will be able to indicate symptoms that will indicate that the architecture needs to be revisited. These then become business risks that must be managed based on the selected architecture.

All of this seems relatively complicated, so why bother? The answer is that architecture decisions are taken on a regular basis under the in the knowledge that the requirements of the system are known and understood. This may be true of the explicit requirements elicited from users, but these are based on assumptions about the future. In reality the future is generally much more surprising than we would like to believe, and so taking the time to consider what this might mean for the decisions you are taking can be worthwhile. An exercise like this can be considered surprisingly quickly, and may significantly help decision making.

Table of contents for Project Estimation Model

1. Project Estimation Model
2. Project Estimation Model Example
3. Project Estimation using Scenarios

Defining estimation scenarios

The first stage in the steps to estimating a project was defined to be the definition of the scenarios to be supported in the solution.  The scenarios should be defined at as low a level of detail as possible, with the following diagram showing the example scenario definition.

Scenario definiton

Definition of the scenarios sizing

In the spreadsheet the light blue fields are those that you would normally fill in. The light purple fields are intended to fill in automatically based on the calibration parameters. If you prefer, however, it is suggested that you replace the calculated value with your own value where a better value is available. In this case I would suggest changing the colour of the cell so that you know this has been done later. I use bright highlighter yellow for this.The purple values are filled in from the “Calibration” sheet based on the complexity selected in the drop-down within those cells. The values represent typical operation counts for scenarios of the defined complexity.Scenario sizing calibrationThe scenario sizing information is drawn from the following part of the calibration sheet:Scenario calibration

As for all the calibration, the provided values are likely to be useful but the optimal values will depend on the business context of the estimator. It is suggested that the calibration should be adjusted from project to project until the most appropriate values are found. For a more rigorous approach a function-point counting style could be adopted on a specification of some suitable scenarios. The idea is to count the number of entities (c.f. database tables) that need to be managed by each scenario.

In the scenario definition sheet these filled in values are then summed at the bottom of the page, and each operation type is multiplied by a weighting factor to produce a total size. This can be seen at the bottom of the scenario definition sheet in the example:

Scenario sizing

The scenario sizing calculation

As can be seen, a standard “Operation Weight” is applied to each of the operation types within the columns of the estimation spreadsheet.  These are drawn from this section within the calibration sheet:

Scenario operation weight

Operation weighting calibration

This process is similar in principle to function point analysis, but the constants have not been adjusted to provide a function point count. It would be possible to complete this and hence to provide an estimate very close to the true function point count of the solution. This, however, is left as an exercise for the reader since I don’t have access to a library of function point analysis data which would make it worthwhile.

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.

The CMMi has been developed and integrated with other approaches and become the CMMi. This process has increased its apparent complexity, as well as its flexibility. The information on the SEI web site (link) has split into either detailed manuals of CMMi and presentations that primarily seem to say “Why you need to buy in our consultants…” The CMMi has been adopted by large players and so there is a strong consultancy market surrounding it, including training and appraisal of your organisational level. The manuals are reference material and not intended to be a thrilling read. The presentations do well at selling CMMi benefits but don’t offer much in the way of a “how to guide”.

The best links that I found to describe the CMMi to allow a quick “Is this for me assessment were:

Tutorials point:

http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm

Wikipedia:

http://en.wikipedia.org/wiki/Process_area_(CMMI)

These sites provide an overview of CMMi at a level more suitable for someone who needs simply to understand the core nuggets of wisdom contained in the CMMi. The still are quite long though, so here is a quick summary of the summary…

CMMi is structured to allow consideration of how an organisation does things, for simplicity I will assume it is software development that is being performed. The CMMi assumes that the road to improvement means ending up with a standardised approach for doing this which can be measured, optimised and customised to the situation in a controlled fashion. It has this in common with many “Quality” processes including the international quality standards. It asserts that there 5 levels of maturity:

• Level 0 – Incomplete – We can get there, we’re sure we can. Not sure how though, and sometimes it don’t quite work right.
• Level 1 – Performed – We can do it as long as it is about the same as the last time.
• Level 2 – Managed – We can do it, and we can manage the process.
• Level 3 – Defined – We can do it, and have a definition of how.
• Level 4 – Quantitatively Managed – We can do it, and can provide numbers about how well. After all what you don’t measure you can’t manage!
• Level 5 – Optimising – We can use the numbers as a basis for continual improvement of how well we do it.

The idea of CMMi is to move up between the levels, and the way to do this is to develop various process areas in your organisation at each level. The areas form a structure, so it is very hard to fully benefit from a higher level process until the lower level ones have been addressed.

The processes organised by level are:

Level 2:

• Requirements Management
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Measurement and Analysis
• Process and Product Quality Assurance
• Configuration Management

Level 3:

• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Integrated Project Management
• Risk Management
• Decision Analysis and Resolution

Level 4:

• Organizational Process Performance
• Quantitative Project Management

Level 5:

• Organizational Innovation and Deployment
• Causal Analysis and Resolution

It is likely that if you are having quality or delivery problems that by looking at these process areas in turn and considering whether you “Do that” you can start to gradually improve. The CMMi manuals have a lot to say that can support you, or you can start looking on Google etc. for ideas that might help you improve.  If you need help then seek outside help – it can be value for money. If you need to be certified to a certain level then the game is very different and outside input becomes a necessity.

How to be a Problem Solver

http://www.digitaltonto.com/2009/how-to-be-a-problem-solver/

The advice in it is interesting, but it also caused me to reflect on the dual nature of problem solving, and how the two aspects need to be handled almost separately. The article above more or less discusses the stakeholder aspect of problem solving with the original raiser. In fact managing the stakeholders of a problem goes further than this, as there may be a whole set of people involved with any given problem that need to be considered in solving a problem. An example is the person who is in the role “at fault”. If they are not engaged in the solution then they might consider your “problem solving” to be a threat to them, and so block progress of your solution.

The other major aspect of the solution of problems will tend to be technical. I have proivided advice on a technical process for considering solutions previously. In that article I didn’t consider the stakeholder management aspects of solving problems. It is likely, however, that at each step of resolving the technical issue it will be necessary to engage the different stakeholders to the problem, to make sure that they are bought in to the solution. A failure to do this will result in blocking behaviour, which will hamper the progress of the solution.