And with that I mean that a large amount of IT support effort and costs are required due to shortcomings in project delivery.
There is of course always a certain amount of IT support required. For example, maintaining and replacing existing equipment and cabling. Or smaller software enhancements that would not require a project. And even though end-user computing becomes easier and you might have the vision that end-users should be able to purchase their own equipment and connect it to the network, reality is that many people in this world cannot setup their own iPhone.
However, a significant part of IT support is due to failures in projects. Implementation of business applications is a typical example. Bad software coding as part of a first project can lay a horrible foundation for any future changes you want to make. Once you have a system that is built with spaghetti code and/or using the wrong technology, you will find that each enhancement or bug fix you put in place will create a large number of new problems. Software development support is then going to cost you a multitude of what it could be.
A good project will deliver a system that will run basically unattended without bugs until the business need has changed and enhancements are required. These enhancements can then be implemented fast, quickly and with minimal effort.
And if you have scoped your project right, these new enhancement requests will not be trickling in a soon as the project is completed. They come only if the business actually changes. Many enhancement requests are due to incomplete requirements or ineffective design during a project.
I have seen over time two instances where an enterprise grade business application was developed using PL/SQL and with a small layer of Java on top of it for the user interface. PL/SQL is not suited to build enterprise applications. Maintenance and new development will constantly run into many problems. You feel that with every fix you put in place, two new problems are created. Developers have problems estimating the work and new development takes forever. Let alone that the testing process is a nightmare because the number of issues you find never seems to end.
In one of those cases I had the opportunity to rebuild the system (thanks to a great team) and basically achieve after that the ideal situation described earlier. Once the bad situation is in place and the system is in use, it is not easy to obtain the funding to replace it. It won't be cheap but will be necessary if the respective system is core to the business.
So to minimise IT operational expenditure, you need to run projects effectively. There is of course a big challenge in running projects effectively. If you separate out the team that runs projects from the ones that provide support, you easily run the risk that the project people will focus on achieving their specific targets. Delivering on time and within budget. Yes, quality is also mentioned.
But some quality can only be measured over a longer period of time after the project has ended. And, oops! The project team is not there anymore and is not accountable anymore!
For example, when you buy a car, you assume that it will keep on running for the next 10 years with a certain amount of maintenance. I am not a specialist in cars, so I will rely on the reputation of the car maker and the dealer that they will provide me with a quality product. When I test the car, I cannot test durability. I am not checking under the hood, list all parts and check the quality of each part. My test will be limited to a test drive and some other visual checks on the surface.
When I create software, I will test whether the functionality meets the requirements. You do not look under the hood. Looking under the hood will be to check the source code. Of course you can do that. But who will give a neutral assessment? The project team will always find that they have done it according to best practices. I can contract an external party, but we all know that software developers never agree with each other. And if you have outsourced the development, then it is a competitor that would do the quality check and that is not a neutral party.
So the only option is to have an internal capability to verify the source code. If you have a large organisation with multiple development teams on the same technology platform, you could let those other teams do that. You probably will also be able to build continuity with those teams and build centres of excellence. (And don't outsource your incompetency!)
Not all organisations (and even large organisations) have the means to achieve this scenario.
The way I addressed this, was to make sure that the project developers were also responsible for the support. My philosophy is that if you make a problem, you fix the problem. And since most developers like to work on projects with new technologies, their reward of delivering good work during projects was that they needed to spend less time on software support and could spend more time working on new development. (Please note that in this case I was responsible for both projects and support.)
The key factor is to understand peoples rationale: "What's in it for me?"
If there is no incentive for a development team to deliver a quality piece of code, the application might look good on the outside during project delivery, but there is a risk that many coding issues have not been resolved under the hood and they will become a problem in the future. And there is always pressure on time and budget, so project managers will also drive to cutting corners and removing non essential features (that later would become enhancement requests).
Many projects in a matrix organisation where the project management function is separated from the IT support function, rely on sourcing project team members from the IT support organisation. Besides providing the resources, the IT support organisation also needs to provide the IT practices to assure that work is done through a quality mechanism. The "project" is in these cases just a project manager from the PMO who does not have all the skills and expertise. He will rely others to bring that into the project. In other words, the project relies on the IT support manager to be successful.
The question is then "What's in it for the IT support manager?"
Consider this line of thought. If the project is successful, IT support will be less. And if IT support will be less, the IT support team will need less people. And if the IT support manager manages less people, he will be less important and will earn less. When managers are applying for a new job, the first thing they are being asked is the number of people and the size of the budget they managed.
Though the IT support managers might not think that way on purpose. (Though it might cross their mind. It did cross my mind.) They will be working hard on trying to resolve all the problems they have to deal with. But there is a high risk that they are less driven to make the project successful because their key objective is fighting fire and to put processes in place to assure that any issues that popup are dealt with most efficiently and effectively. Their personal KPI's often will not contain anything relating to project delivery. This is not their fault. It is a consequence of the way we have organised ourselves and it is one of the key reasons why projects in a matrix organisation are so difficult to do right.
It is not always practical and advised to integrate the IT support/operations role and the IT Project function (e.g. PMO). Therefore, in my opinion, it is necessary that IT support is strongly linked to project success and vice versa through individual KPI's and clear descriptions on responsibilities and accountabilities. Projects deliver new business capability to stay in business, to achieve growth and achieve strategic objectives. IT support is a cost that you want to minimise.
As I mentioned earlier, I had the opportunity to drive both support and projects and in the end I was successful in minimising the IT support activity and having the team primarily focussed on assisting the business with their improvement initiatives. So it can be done, but this is not always easy and definitely not always easy in all contexts.
There is of course always a certain amount of IT support required. For example, maintaining and replacing existing equipment and cabling. Or smaller software enhancements that would not require a project. And even though end-user computing becomes easier and you might have the vision that end-users should be able to purchase their own equipment and connect it to the network, reality is that many people in this world cannot setup their own iPhone.
However, a significant part of IT support is due to failures in projects. Implementation of business applications is a typical example. Bad software coding as part of a first project can lay a horrible foundation for any future changes you want to make. Once you have a system that is built with spaghetti code and/or using the wrong technology, you will find that each enhancement or bug fix you put in place will create a large number of new problems. Software development support is then going to cost you a multitude of what it could be.
 |
| Photo by Sebastian Muller |
A good project will deliver a system that will run basically unattended without bugs until the business need has changed and enhancements are required. These enhancements can then be implemented fast, quickly and with minimal effort.
And if you have scoped your project right, these new enhancement requests will not be trickling in a soon as the project is completed. They come only if the business actually changes. Many enhancement requests are due to incomplete requirements or ineffective design during a project.
I have seen over time two instances where an enterprise grade business application was developed using PL/SQL and with a small layer of Java on top of it for the user interface. PL/SQL is not suited to build enterprise applications. Maintenance and new development will constantly run into many problems. You feel that with every fix you put in place, two new problems are created. Developers have problems estimating the work and new development takes forever. Let alone that the testing process is a nightmare because the number of issues you find never seems to end.
In one of those cases I had the opportunity to rebuild the system (thanks to a great team) and basically achieve after that the ideal situation described earlier. Once the bad situation is in place and the system is in use, it is not easy to obtain the funding to replace it. It won't be cheap but will be necessary if the respective system is core to the business.
So to minimise IT operational expenditure, you need to run projects effectively. There is of course a big challenge in running projects effectively. If you separate out the team that runs projects from the ones that provide support, you easily run the risk that the project people will focus on achieving their specific targets. Delivering on time and within budget. Yes, quality is also mentioned.
But some quality can only be measured over a longer period of time after the project has ended. And, oops! The project team is not there anymore and is not accountable anymore!
For example, when you buy a car, you assume that it will keep on running for the next 10 years with a certain amount of maintenance. I am not a specialist in cars, so I will rely on the reputation of the car maker and the dealer that they will provide me with a quality product. When I test the car, I cannot test durability. I am not checking under the hood, list all parts and check the quality of each part. My test will be limited to a test drive and some other visual checks on the surface.
When I create software, I will test whether the functionality meets the requirements. You do not look under the hood. Looking under the hood will be to check the source code. Of course you can do that. But who will give a neutral assessment? The project team will always find that they have done it according to best practices. I can contract an external party, but we all know that software developers never agree with each other. And if you have outsourced the development, then it is a competitor that would do the quality check and that is not a neutral party.
So the only option is to have an internal capability to verify the source code. If you have a large organisation with multiple development teams on the same technology platform, you could let those other teams do that. You probably will also be able to build continuity with those teams and build centres of excellence. (And don't outsource your incompetency!)
Not all organisations (and even large organisations) have the means to achieve this scenario.
The way I addressed this, was to make sure that the project developers were also responsible for the support. My philosophy is that if you make a problem, you fix the problem. And since most developers like to work on projects with new technologies, their reward of delivering good work during projects was that they needed to spend less time on software support and could spend more time working on new development. (Please note that in this case I was responsible for both projects and support.)
The key factor is to understand peoples rationale: "What's in it for me?"
If there is no incentive for a development team to deliver a quality piece of code, the application might look good on the outside during project delivery, but there is a risk that many coding issues have not been resolved under the hood and they will become a problem in the future. And there is always pressure on time and budget, so project managers will also drive to cutting corners and removing non essential features (that later would become enhancement requests).
Many projects in a matrix organisation where the project management function is separated from the IT support function, rely on sourcing project team members from the IT support organisation. Besides providing the resources, the IT support organisation also needs to provide the IT practices to assure that work is done through a quality mechanism. The "project" is in these cases just a project manager from the PMO who does not have all the skills and expertise. He will rely others to bring that into the project. In other words, the project relies on the IT support manager to be successful.
The question is then "What's in it for the IT support manager?"
Consider this line of thought. If the project is successful, IT support will be less. And if IT support will be less, the IT support team will need less people. And if the IT support manager manages less people, he will be less important and will earn less. When managers are applying for a new job, the first thing they are being asked is the number of people and the size of the budget they managed.
Though the IT support managers might not think that way on purpose. (Though it might cross their mind. It did cross my mind.) They will be working hard on trying to resolve all the problems they have to deal with. But there is a high risk that they are less driven to make the project successful because their key objective is fighting fire and to put processes in place to assure that any issues that popup are dealt with most efficiently and effectively. Their personal KPI's often will not contain anything relating to project delivery. This is not their fault. It is a consequence of the way we have organised ourselves and it is one of the key reasons why projects in a matrix organisation are so difficult to do right.
It is not always practical and advised to integrate the IT support/operations role and the IT Project function (e.g. PMO). Therefore, in my opinion, it is necessary that IT support is strongly linked to project success and vice versa through individual KPI's and clear descriptions on responsibilities and accountabilities. Projects deliver new business capability to stay in business, to achieve growth and achieve strategic objectives. IT support is a cost that you want to minimise.
As I mentioned earlier, I had the opportunity to drive both support and projects and in the end I was successful in minimising the IT support activity and having the team primarily focussed on assisting the business with their improvement initiatives. So it can be done, but this is not always easy and definitely not always easy in all contexts.
