To manage quality for the long term, you need a system quality management process that takes quality management off the critical path of business change projects.
In IT, we consider quality very broadly. We consider software quality, such as modularisation and commenting. We consider operational quality, such as conforming to operational standards and resilience. We consider risk management quality, such as security and disaster recovery. We consider technical quality, such as technology viability and scalability. Taken together, these system qualities have a huge impact on the cost and risk of delivering IT change and IT services.
When new systems are created, it is relatively easy to create a quality solution. It is much harder to maintain the quality of the solution throughout its life.
Quality degrades. It tends to degrade every time we change a system. It degrades even when we do not touch the system, as changes to other systems, to technology, to regulations, to security threats, cumulatively undermine the qualities of the system.
We try to maintain the quality of systems when we change them, but this is difficult. It is almost impossible to make a business case for quality improvements, and there is never any time. Inevitably the quality issues that have grown up in the system are not fixed.
We understand this better in other industries. Imagine you went to the garage to have parking sensors fitted to your car. You would want the garage to do a quality job of fitting the parking sensors, but you would not expect them to spend your time and money on checking the brake pads at the same time.
You need to do something similar in IT. Instead of managing ongoing system quality as an add-on to the business change process, you need to manage it as a process in it its own right. With a car, you manage ongoing quality with periodic inspections and services, and, here in the UK, an annual MOT test to check that the car is legal. You need to do something similar with system quality. You need periodic assessments to look for general decline, and to check that the systems are compliant with the ever-changing landscape of regulation and policy. You need a system quality management process, as well as a business change process.
This is really important for justification. You would justify parking sensors because by the increased capability they give - easier parking, and a reduced risk of damage. But disk pads, and other quality issues, can not be justified by obviously increased capability. They maintain the performance of the car, increase its useful life, reduce risks, help it run smoothly, avoid future problems, maintain its value. You can not be sure that each aspect of a regular service is strictly necessary, but you know, overall, that it is valuable to have one. The justification for ongoing quality management is different from the justification for business change.
Even though it is critical, system quality does not sit happily on the critical path. It needs its own process and its own justification. You have to have a separate system quality management process.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 25 March 2008
Tuesday, 18 March 2008
Growing pains
Building an IT business from scratch is a long and challenging process. Seeing your products come to market and succeed is the most exciting and most rewarding part of all.
Like a lot of people who work in IT, I decided a few years ago to leave the sheltered life of a salaried employee, and strike out on my own.
I needed a strategy. The big opportunity that I saw, and still see, is the waste in large-scale IT. My interest in waste is not a moral campaign, it is simply good business. There is a lot of value locked up in IT waste, a lot more money there than anywhere else.
The second part of the strategy was to do more than just sell time, but to create things of value (products, business models, brands), and to trade from these.
Because this strategy involves creating things of value, we have had to spend time exploring and developing ideas and products. One of my main vehicles for this has been this newsletter. The self-imposed discipline of writing every week forces me to keep exploring ideas and pushing them forward.
The ideas have moved on. When I started, I had a few ideas: reducing unnecessary demand for IT, and looking more closely at how IT delivers value. But we have added more: the importance of a system view of IT, and the importance of managing the qualities of systems. I understand much better how these ideas fit with each other, how they fit with other ideas in IT, and how they can be used to cut waste out of IT.
Commercially, we have had to think of competition, and of marketing and sales.
The big issue with competition is how to compete with larger companies. Because our overheads are low, we can divert more of our time into developing ideas and products. By being focussed, we can do as much development as a business many times our size. We apply our own methods to our own products, which helps us create solutions at a fraction of the cost needed by other businesses.
Presenting our products in the marketplace has been the greatest challenge so far. Our ideas are unique, and our products new, and there is no defined market for us to play in. We have test marketed our products a number of times, and learnt from each time. We are making progress: we have gone from being ignored, to being interesting, to being credible.
The bulk of the exploration and development work is now done. We have a unique proposition: how business can save up to 40% of IT costs by unlocking their IT waste. We have a credible story to back up our claims, and the products and services to help our customers make these savings.
However compelling we believe them to be, opportunities, ideas and products are only part of the process. Our customers are faced with competing demands for their time. We have to grab their attention with compelling offers and follow through with effective processes. We can never take success for granted, which is what makes this part of the process so exciting, and ultimately so rewarding.
Do I miss my sheltered previous life? Not for a moment.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Like a lot of people who work in IT, I decided a few years ago to leave the sheltered life of a salaried employee, and strike out on my own.
I needed a strategy. The big opportunity that I saw, and still see, is the waste in large-scale IT. My interest in waste is not a moral campaign, it is simply good business. There is a lot of value locked up in IT waste, a lot more money there than anywhere else.
The second part of the strategy was to do more than just sell time, but to create things of value (products, business models, brands), and to trade from these.
Because this strategy involves creating things of value, we have had to spend time exploring and developing ideas and products. One of my main vehicles for this has been this newsletter. The self-imposed discipline of writing every week forces me to keep exploring ideas and pushing them forward.
The ideas have moved on. When I started, I had a few ideas: reducing unnecessary demand for IT, and looking more closely at how IT delivers value. But we have added more: the importance of a system view of IT, and the importance of managing the qualities of systems. I understand much better how these ideas fit with each other, how they fit with other ideas in IT, and how they can be used to cut waste out of IT.
Commercially, we have had to think of competition, and of marketing and sales.
The big issue with competition is how to compete with larger companies. Because our overheads are low, we can divert more of our time into developing ideas and products. By being focussed, we can do as much development as a business many times our size. We apply our own methods to our own products, which helps us create solutions at a fraction of the cost needed by other businesses.
Presenting our products in the marketplace has been the greatest challenge so far. Our ideas are unique, and our products new, and there is no defined market for us to play in. We have test marketed our products a number of times, and learnt from each time. We are making progress: we have gone from being ignored, to being interesting, to being credible.
The bulk of the exploration and development work is now done. We have a unique proposition: how business can save up to 40% of IT costs by unlocking their IT waste. We have a credible story to back up our claims, and the products and services to help our customers make these savings.
However compelling we believe them to be, opportunities, ideas and products are only part of the process. Our customers are faced with competing demands for their time. We have to grab their attention with compelling offers and follow through with effective processes. We can never take success for granted, which is what makes this part of the process so exciting, and ultimately so rewarding.
Do I miss my sheltered previous life? Not for a moment.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 11 March 2008
KeePass
If you do not use a password manager like KeePass, you should.
How many passwords do you have? 5, 10, 50? You probably have more than you think. To my surprise, I found I had 106.
How do you remember all your passwords? If you are typical, you have them written down. Probably not all in one place: some on a list, some on scraps of paper, maybe some in a spreadsheet. You have probably forgotten or lost many of them.
You need a password manager like KeePass.
A password manager is a database of user names and passwords, secured by one master password. They have been around for years, but are not as widely used as they could be. I started using KeePass about six months ago, and now I wouldn't be without it.
The obvious objection to password managers is that they might not be secure. KeePass has impressive security features: it uses strong encryption, prevents brute-force "dictionary" attacks, encrypts program memory, protects passwords from key loggers, can be integrated with Windows security, and can use a key file as well as the password.
KeePass has many other advantages.
There are risks with any password manager. If anyone gains access to the password manager, all your passwords are compromised. If you forget your master password, or the database is deleted, all your passwords are lost. You have to remember one strong password to keep the database secure, and include the password database in regular backups. But the risks are much greater without a password manager: writing passwords down, forgetting passwords, or using the same password for everything.
KeePass has a place in the corporate environment. It does not replace security infrastructure such as directories (LDAP or Windows Active Directory), or advanced features for high security systems. But in all except the most locked-down installations, many passwords fall outside the official, managed security infrastructure. For these, KeePass is a simple, effective solution that greatly reduces the risks associated with bad password practices.
If you do not use a password manager, look at KeePass.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
How many passwords do you have? 5, 10, 50? You probably have more than you think. To my surprise, I found I had 106.
How do you remember all your passwords? If you are typical, you have them written down. Probably not all in one place: some on a list, some on scraps of paper, maybe some in a spreadsheet. You have probably forgotten or lost many of them.
You need a password manager like KeePass.
A password manager is a database of user names and passwords, secured by one master password. They have been around for years, but are not as widely used as they could be. I started using KeePass about six months ago, and now I wouldn't be without it.
The obvious objection to password managers is that they might not be secure. KeePass has impressive security features: it uses strong encryption, prevents brute-force "dictionary" attacks, encrypts program memory, protects passwords from key loggers, can be integrated with Windows security, and can use a key file as well as the password.
KeePass has many other advantages.
- There is no need to write your passwords down, they are all kept securely in one place.
- There is no danger of forgetting or losing passwords, and all the inconvenience and security risk of password reminders and resets.
- It is easy to use. KeePass has a neat feature to paste passwords into the required application, and then to clear the clipboard automatically.
- It is easy to adopt good password policy. You can avoid guessable passwords, or using the same password for multiple systems. You can use a unique, long, unguessable password for each system.
- You can use the same password database across multiple platforms. KeePass runs on Windows, and has been ported to Linux, Mac OS X and many other platforms. You can easily run KeePass from a flash drive (I use the PortableApps version of KeePass).
- It is free, open-source software.
There are risks with any password manager. If anyone gains access to the password manager, all your passwords are compromised. If you forget your master password, or the database is deleted, all your passwords are lost. You have to remember one strong password to keep the database secure, and include the password database in regular backups. But the risks are much greater without a password manager: writing passwords down, forgetting passwords, or using the same password for everything.
KeePass has a place in the corporate environment. It does not replace security infrastructure such as directories (LDAP or Windows Active Directory), or advanced features for high security systems. But in all except the most locked-down installations, many passwords fall outside the official, managed security infrastructure. For these, KeePass is a simple, effective solution that greatly reduces the risks associated with bad password practices.
If you do not use a password manager, look at KeePass.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 4 March 2008
Governance, not portfolio management
Portfolio management is so strongly associated with projects that it can not be applied to other types of portfolio.
Recently I asked whether system governance should be renamed, for example to system portfolio management (see Governance or portfolio management?). I asked readers for their views, and many of you were kind enough to give me comments or vote on my poll.
The results were fairly clear. 50% of the respondents thought we should keep the name "system governance", 33% thought we should use both "system governance" and "system portfolio management", and the remainder thought we should use a different name. Nobody thought that "system portfolio management" was a good name by itself.
We did not get enough votes for these numbers to be conclusive. What was interesting was to read between the lines.
A large number of people turned up at the poll page, but only a few voted. This shows that the vast majority of people have no clear preference.
I got a number of comments which, because I used the term "portfolio management", assumed that the method must be a type of project portfolio management, even though the method was never presented as a project management method. One reader was kind enough to highlight the Project Management Institute's new, broader, standards for portfolio management. But even these broader standards only go as far as including other types of work (such as support work) into the project portfolio. I have to accept that, in IT, "portfolio management" is synonymous with "project portfolio management". (Personally I think that applying the term "portfolio" to projects is misleading - see Projects are NOT investments for why.)
I got a small number of comments that implied that use of the term "governance" is inappropriate, and that it should be reserved for high-level activities such as establishing accountability for budgets. Our system governance method can be applied at both a high level and an everyday level. The concern applies to the using the term "governance" to everyday IT activities.
There are plenty of precedents for applying general words to everyday IT activity. The words analysis, architecture, design, testing and support all existed before they were adopted to describe IT activities. System governance is another everyday activity that sits comfortably alongside systems analysis, system architecture, system design, system testing and system support.
In conclusion, we can not use the term "system portfolio management" for what we do, simply because "portfolio management" is considered synonymous with "project portfolio management". Although I might disagree with this definition, there is not point trying to buck the trend.
We should retain the name "system governance". What we do is definitely a contributor to IT governance as it is generally understood. But, in the same way that we use the prefix "system" to describe many everyday activities (like system design), we can also present system governance as an everyday IT activity that can be applied outside of a broader IT governance initiative. We should use the same name for both the high level (the systems parts of IT governance) and everyday (governance applied to individual systems), because the method is the same for both.
I should stop worrying about the name, and concentrate on promoting the method.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Recently I asked whether system governance should be renamed, for example to system portfolio management (see Governance or portfolio management?). I asked readers for their views, and many of you were kind enough to give me comments or vote on my poll.
The results were fairly clear. 50% of the respondents thought we should keep the name "system governance", 33% thought we should use both "system governance" and "system portfolio management", and the remainder thought we should use a different name. Nobody thought that "system portfolio management" was a good name by itself.
We did not get enough votes for these numbers to be conclusive. What was interesting was to read between the lines.
A large number of people turned up at the poll page, but only a few voted. This shows that the vast majority of people have no clear preference.
I got a number of comments which, because I used the term "portfolio management", assumed that the method must be a type of project portfolio management, even though the method was never presented as a project management method. One reader was kind enough to highlight the Project Management Institute's new, broader, standards for portfolio management. But even these broader standards only go as far as including other types of work (such as support work) into the project portfolio. I have to accept that, in IT, "portfolio management" is synonymous with "project portfolio management". (Personally I think that applying the term "portfolio" to projects is misleading - see Projects are NOT investments for why.)
I got a small number of comments that implied that use of the term "governance" is inappropriate, and that it should be reserved for high-level activities such as establishing accountability for budgets. Our system governance method can be applied at both a high level and an everyday level. The concern applies to the using the term "governance" to everyday IT activities.
There are plenty of precedents for applying general words to everyday IT activity. The words analysis, architecture, design, testing and support all existed before they were adopted to describe IT activities. System governance is another everyday activity that sits comfortably alongside systems analysis, system architecture, system design, system testing and system support.
In conclusion, we can not use the term "system portfolio management" for what we do, simply because "portfolio management" is considered synonymous with "project portfolio management". Although I might disagree with this definition, there is not point trying to buck the trend.
We should retain the name "system governance". What we do is definitely a contributor to IT governance as it is generally understood. But, in the same way that we use the prefix "system" to describe many everyday activities (like system design), we can also present system governance as an everyday IT activity that can be applied outside of a broader IT governance initiative. We should use the same name for both the high level (the systems parts of IT governance) and everyday (governance applied to individual systems), because the method is the same for both.
I should stop worrying about the name, and concentrate on promoting the method.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)