Sunday, April 13, 2014

IT Support is a waste of money

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.
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.




Wednesday, March 5, 2014

Understand the priorities given to your business stakeholders

As an IT project manager, you usually receive the direction from your steering committee that your project is very important and that you need to drive active participation by the business team.  You explain that they have limited time available because they already have so much on their plate. However the steering committee responds with the fact that they should make the time available.


The problem here is that those steering committee members (and/or sponsor) are usually the (direct) manager of those business team members. And you should not be surprised that when they speak 1:1 with those team members they give them a whole series of other high priority tasks which results in your project moving to a lower position on their priority list. There is clearly a misalignment between the various communications on priorities.


It is important for a project manager to find out if this is the case and bring this to the attention of the steering committee because otherwise you will only be criticised by not being able to deliver your work on time and you basically have no hope in hell to control your schedule. When you are aware of this, it is valuable information for other team members because this can avoid friction. For example a Business Analyst who is not able to get enough time of the business stakeholders to complete his work, could otherwise get agitated and come in conflict with those stakeholders.

If you explain the competing priorities as given to the team members to your steering committee and if they are taking the project serious, this can result in a radical change in behaviour from the respective business team members and suddenly your project flies.


The conflicting priorities could be addressed with effective portfolio and resource management but this is not always in place. That is a story by itself.

Wednesday, September 18, 2013

We all need to predict the future

Sometimes, I find it frustrating to get work estimates from colleagues. It is even more difficult to ask for completion dates. It is indeed a difficult task and basically you don't always know what is involved and it is even more difficult to predict what other work will interfere. However forecasting is a necessary task we all have to do at times.

Not everyone is comfortable with making business decisions, since basically that is what you do. I also found that people sometimes misunderstand the context in which these forecasts are asked. Quite often I have to explain that we are in early stages of a project and that a high variation is acceptable or that giving an estimate is not a commitment to deliver any work by a certain date.

I found that the more technical/operational people are, the more reluctant they are to provide estimates. If they give an answer, they want to be exact and accurate. And that is simply not possible when making forecasts. Specifically when high level estimates are required in the early stages of a project. Technicians prefer to give you an answer when they have completed the job.

However, the more frequent people are involved in estimating, the more forthcoming they will become with volunteering estimates. For example, I had a case where a DBA was very reluctant to specify the tasks that needed to be performed. The project manager came to me in despair saying that the DBA was not willing to contribute.

The way I resolved this was by using my little knowledge of what was required. I wrote this down on the white board and asked for confirmation that this was it. As a true techie, the DBA could not stand any inaccuracies and started correcting me. Initially just the minimal information was contributed. Each time I tried to fill in some gaps of information, this was which again corrected. After a while I had a good list of tasks and started adding the expected effort to each tasks. Again these would be corrected. In later planning exercises the DBA was much more forthcoming and learned to contribute and make his how plans.

Identifying task completion dates is another challenge. In some cases you simply get the answer that there are so many unknowns that it is basically impossible to predict. Even project managers at times tend to come with these arguments in order not to give any form of forecast at all. I disagree since you can usually give a best case and a worst case scenario. For any form of planning this is crucial information.

And don't forget that our CEO's, senior management, sales and marketing people have to make predictions of how our business will go, how much money we will earn and how much expenses we have. The uncertainty and consequences they have to deal with is much higher. If they would stop forecasting, just because they can't predict the exchange rate, what the Chinese or what the government will do, we all would be out of a job in no-time.

So, just make a best guess and know that this is not bad at all since you will use much of your experience whether you are fully aware of it or not. The more you do it, the better, or at least more comfortable, you will become.