Standards: two loops are better than one

To stop standards becoming a bureaucratic monster, spend at least 10% of standards effort on reviewing and changing the standards themselves.

I like standards. I like standards for processes, like ITIL. I like standards for outcomes, like system quality management.

I like standards because they make life easier. They provide guidance for unfamiliar situations. They provide a pattern of good practice that can be easily adopted. They are a great tool for improving overall capability.

Standards work by prescribing how the work should be done, often setting criteria against which work should be checked.

For standards to work, the organisation has to commit to this control cycle. Management must enforce the standards or the standards will wither away.

There is a danger, though, that in our enthusiasm to follow the standards, we let them become our masters. They turn from being a valuable tool of management, to a bureaucratic monster that has to be constantly fed with time and management attention, but gives little back in return.

To avoid this, you need two loops.

As well as committing to a process of following the standards, you have to commit to a process of reviewing and changing standards.

This outer process is not just there to make standards more rigorous, but to make the standards more valuable, more efficient, and more accepted. You should:

• Remove anything from the standard that does not add value.


• Make the standard more specific to your organisation, to provide more precise guidance.


• Move on. Change the standards to tackle tomorrow's challenges, not yesterday's.


• Institutionalise what you have learned.

The second loop moves standards from being solely a quality assurance and control activity, to being a vehicle for setting direction and organisational learning.

When you are reviewing and changing standards, focus on difficulties, even if this means ignoring the enthusiasts.

• Capture complaints. Even the common complaint that standards are bureaucratic is really important to consider. More standards die from being too bureaucratic than from being too simple.


• Ask what the standards deliver. Does it help you do things right, does it get things wrong, does it miss things out? Is it all obvious, anyway?


• See what competing processes and standards have been set up. Better to understand what drives them to be different, and bring them into the camp.

The aim of the review process is to understand what's really going on, and to fight both indifference and bureaucracy, not to reassert the purity and rigour of the standards.

Reviewing and changing standards is critical. The time and money you spent on writing or buying in standards will soon be lost unless you make sure the standards stay relevant and accepted in the organisation. You must build the review of the standards into the standards processes themselves.

Reviewing standards takes time and management attention. As a rough guide, if you add up all the time you spend on standardisation (promoting and enforcing the standards, and using them to check work), then reviewing and changing the standards should be at least 10% of this time. Spending this time on a second control loop for the standards themselves can stop the standards withering, and prevent them growing into a bureaucratic monster.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Standards: two loops are better than one

To stop standards becoming a bureaucratic monster, spend at least 10% of standards effort on reviewing and changing the standards themselves.

I like standards. I like standards for processes, like ITIL. I like standards for outcomes, like system quality management.

I like standards because they make life easier. They provide guidance for unfamiliar situations. They provide a pattern of good practice that can be easily adopted. They are a great tool for improving overall capability.

Standards work by prescribing how the work should be done, often setting criteria against which work should be checked.

For standards to work, the organisation has to commit to this control cycle. Management must enforce the standards or the standards will wither away.

There is a danger, though, that in our enthusiasm to follow the standards, we let them become our masters. They turn from being a valuable tool of management, to a bureaucratic monster that has to be constantly fed with time and management attention, but gives little back in return.

To avoid this, you need two loops.

As well as committing to a process of following the standards, you have to commit to a process of reviewing and changing standards.

This outer process is not just there to make standards more rigorous, but to make the standards more valuable, more efficient, and more accepted. You should:

• Remove anything from the standard that does not add value.


• Make the standard more specific to your organisation, to provide more precise guidance.


• Move on. Change the standards to tackle tomorrow's challenges, not yesterday's.


• Institutionalise what you have learned.

The second loop moves standards from being solely a quality assurance and control activity, to being a vehicle for setting direction and organisational learning.

When you are reviewing and changing standards, focus on difficulties, even if this means ignoring the enthusiasts.

• Capture complaints. Even the common complaint that standards are bureaucratic is really important to consider. More standards die from being too bureaucratic than from being too simple.


• Ask what the standards deliver. Does it help you do things right, does it get things wrong, does it miss things out? Is it all obvious, anyway?


• See what competing processes and standards have been set up. Better to understand what drives them to be different, and bring them into the camp.

The aim of the review process is to understand what's really going on, and to fight both indifference and bureaucracy, not to reassert the purity and rigour of the standards.

Reviewing and changing standards is critical. The time and money you spent on writing or buying in standards will soon be lost unless you make sure the standards stay relevant and accepted in the organisation. You must build the review of the standards into the standards processes themselves.

Reviewing standards takes time and management attention. As a rough guide, if you add up all the time you spend on standardisation (promoting and enforcing the standards, and using them to check work), then reviewing and changing the standards should be at least 10% of this time. Spending this time on a second control loop for the standards themselves can stop the standards withering, and prevent them growing into a bureaucratic monster.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Controlling departmental IT

You can achieve the alignment and flexibility of departmental IT, and still keep control and co-ordination at the centre.

End-user developed systems, or small IT departments within business departments, are often criticised by the central IT organisation.

• Support is ill defined.
• The architecture is "hopeful", often based on supersized office applications, not properly designed, documented, tested or kept up-to-date.
• Data is parochial, not normalised to the broader needs of the organisation.
• Data is ill-controlled: sensitive data leaks out, data is not properly backed up.
• The systems may be developed and supported by uncontrolled external contractors.
• Worst of all, the central IT organisation has to pick up the pieces when it breaks or when key staff move on.

But there are a lot of advantages to departmental IT.

• IT is clearly owned by the business, and closely aligned to needs.
• IT is responsive, and does not have to wait for the central organisation in order to meet new business needs.
• Cost are properly accounted for - the costs are born directly by the departments who use the systems.
• Resourcing pressure can be removed from central IT.

These advantages - ownership, alignment, responsiveness, accountability, resourcing - reflect some of the major problems in IT. Is there a way that we can have the advantages of departmental IT, without the disadvantages?

I think there is.

The obvious solution is to make sure that departmental IT is managed to standards that prevent the most significant problems. However, it is hard to enforce standards without co-operation. The detailed technical and process standards used to run central IT would be seen as too difficult, too technical, and disconnected from business needs, and would not be accepted. If we want to use standards to help manage departmental IT, we need a different approach that does not prescribe how people should work, but limits itself to the most important aspects of what has to be achieved.

Specifically, we need to:

• Focus standards on a small number of important points.
• Explain the business rationale for each part of the standards.
• Express standards at a management level, not a technical level.
• Express standards as outcomes, not processes.
• Provide a simple framework for communicating standards.
• Assess against standards in an open and consistent fashion.
• Provide justification for all work required to meet standards.
• Show that standards can evolve to reflect changing business needs.

I have been working on system quality management methods, and thinking how these could be used to control departmental IT. It certainly seems to fit: system quality management is aimed at the high-level management outcomes needed to ensure IT is meeting objectives, rather than detailed technical and process standards needed to run IT day-to-day.

Of course, it takes a lot of political skill to control departmental IT effectively. But there is a big prize to be won: the ownership, alignment, responsiveness, accountability and resourcing of departmental IT, combined with the control, co-ordination and economies of scale of central IT. A simple and effective standards framework, like system quality management, could bring this prize much closer.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Linking quality to decision making

Quality management is only effective when it is linked to decision making. To link it, you need to clarify your IT objectives and your decision-making processes, and build a balanced body of information about your IT.

You can split IT work into two: the focused execution of project and service delivery processes, and "other work". Other work covers many specialist and management roles, such as database administration, information security, project office, compliance, architecture, and so on. A large part of these other roles involves managing or checking the quality (in the broadest sense) of the execution processes, or of the products of the processes. We could loosely classify these as "quality roles", distinct from "execution roles".

Although quality is an important factor in process execution, execution roles have a different focus from quality roles. For example, project management focuses on the delivery of projects on time, to budget, and to specification. Long-term quality issues, and the quality of the overall IT environment, fall outside the scope of the project. Specialist quality roles look at different aspects of the solution, and have a brief that is broader than individual projects.

This difference of focus can cause problems. There is an inevitable tension between the execution focus and the quality focus. Specialists in quality roles may feel that their recommendations are not given enough priority by management, who must focus on day-to-day execution. Worst of all, some quality roles morph into self-serving monsters, making unreasonable and unjustified demands that add significantly to costs and timescales.

All this can be a significant waste of resources. Many IT organisations are keen to create roles to improve quality, but then are reluctant to back the recommendations for improved quality that come out of these roles, or burn time and money feeding the monster they have created.

The root of this problem is that we do not fully define how quality management connects to decision-making processes.

I have been putting together methods for system quality management and thinking about this connection. I have some suggestions.

• Start by clarifying objectives for IT in your organisation. Think how you need to balance the immediate needs of of project and service delivery processes with your broader obligations and requirements for long-term risk and cost control.
• Understand when and how quality issues can impact your main execution processes. Are internal IT requirements allowed to feed into the workplan? What quality checkpoints are there in projects?
• Think what information you need to support decision making. What do you need to know to make a decision on a quality recommendation to change a project or the overall IT workplan?
• Adopt ongoing evaluation of systems and projects to consistently identify quality issues. You need a balanced view to make sure that resources are directed to the real priorities, not just to the areas that shout loudest.

This top-down approach identifies quality issues from your organisations' IT objectives, decision-making processes and situation. It focuses specialist resources on the areas that matter to your organisation and where quality issues are able to make a difference. It provides the necessary link between quality management and decision making.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

The new umbrella

We need a way of managing things that do not sit comfortably under our project management and service delivery umbrellas.

IT is not a single activity. It is made up of a long list of different parts: strategic planning, architecture, computer operations, help desk, analysis, design, security, compliance, continuity planning, testing, programming, and on and on.

To help us manage these very different activities, we have two big management umbrellas.

• We collect the activities to do with change under a project management umbrella.
• We collect the activities to do with running IT under a service delivery umbrella.

These umbrellas are more than just a classification. They provide management focus, methods, budget, organisation, and so on. They keep the activities that shelter under them protected from the worst of organisational weather: management indifference, lack of co-ordination, lack of funding, lack of control. Without the umbrellas, IT would be unmanageable.

Useful though these umbrellas are, they don't cover everything perfectly. Some activities, such as regulatory compliance, tend to get left out. Some, such as security, are stuck in between. Some, like application support, tend to scuttle from one umbrella to the other every few years, as management preference changes. These areas are not well covered, and our overall IT management suffers as a result.

Perhaps we need a new umbrella to shelter the things that do not fit well under the other two, such as:

• Software and information quality
• Compliance
• Viability
• Policy and standards
• Ongoing performance, scalability and capacity
• Security
• Documentation
• Continuity planning

This may seem like a random list. But these are all to do with the ongoing evolution of the IT itself, and are neither the step change of projects nor business as usual service delivery.

In a broad sense, all of these are to do with the qualities of the IT systems themselves. We could reasonably call this third umbrella system quality management.

Both of the existing umbrellas have a dominant management focus and way of working. Project management focuses on projects, and has processes for running projects from start to finish. Service delivery focuses on services, and has processes for delivering them consistently every day.

In the same way, we can define a focus and way of working for system quality management: a focus on systems, and processes for identifying, justifying, executing and controlling the activities required to maintain and improve the qualities of systems.

Introducing system quality management as the third high-level umbrella is not an arbitrary reassignment of responsibilities from other areas. Effective project execution is hard, and consistent service delivery is hard, and both are made harder by extra activities that have to be done at the same time. Really important parts of the overall IT management are inevitably left out because they do not sit comfortably alongside the dominant focus. You can see this with problems like getting project delivery to rework documentation, or getting service delivery to make application software changes to improve performance. Putting these under a new umbrella would not only deliver them better, but would help project management and service delivery achieve their objectives more effectively.

If you feel some things are not completely covered by your current management structures, perhaps you need a new umbrella.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Effective technical evaluation

Most technical evaluations are unnecessarily difficult and do not deliver good results. Making evaluation easier and more effective is common sense.

We do a lot of technical evaluation in IT. We evaluate software before we buy it. We evaluate as part of quality assurance, to understand compliance, and as part of general fact-finding.

I have had many frustrating experiences with evaluation.

• When PCs were new, I was involved in evaluating PC software. We used simple check lists and awarded one point for meeting each requirement. Unfortunately, three-quarters of our requirements were user interface standards, so we would buy anything as long as it looked nice.
• In one selection, one person's outspoken (but unexplained) dislike of a particular web server was allowed to override all other issues, and we were driven to adopt a solution with many worse problems, including the fact that the software had not yet been developed.
• Nearly ever evaluation asks stupid questions, such as asking a software vendor "Is the system included in the disaster recovery plan?" That's a reasonable question for the purchasing company to ask itself, but not one for the vendor.
• Getting sales brochures, not answers. If I have bothered to word my questions carefully, I expect some carefully worded answers, not brochures.
• Letting technical evaluation lead business evaluation. On the few occasions I have been involved in well-run technical evaluations, the clarity of the technical conclusions have overridden business decisions.

These problems can disappear with a little common sense.

• Start by thinking about how you will make a decision. Agree what is important, what is good, and what is bad before you write the questions.
• Spend time writing good questions. Phrase every question in the imperative. Do not ask "Is the system secure?", ask "Describe the security mechanisms within the system and explain how they ensure that the system is secure."
• Check the questions. Think through what a good answer would look like, an acceptable answer, an unacceptable answer, and any special cases. Check that every question will make sense to the vendor.
• If you have a scoring scheme, break it down into groups before you weight individual questions. "One point per question" means that you too might just be picking pretty software.
• Think how you are going to analyse the answers. I use a mixture of a weighted scoring scheme, and looking for specific issues. This lets me say where solutions are generally weak or strong, describe the issues that would need special management attention, and identify "show stoppers" that would rule out an option.
• Make it clear to vendors that they will be ignored if they do not answer the questions.
• Separate technical evaluation from business evaluation. Technical evaluation is about understanding the issues and costs of a solution. Business evaluation is about opportunity and value, which is totally different. Focus business evaluation on opportunity, effective support of business processes, and commercial issues. Be cautious of scoring software against long lists of features, as it diverts attention from overall business fit.

All these are common sense. The small effort involved in structuring an evaluation right is paid back many times in the ease and effectiveness of the decision making process.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.