Big data? well, try to get little data right first

National Australia Bank reminds me of a football team mate of a long time ago. When he asked you if you wanted a beer and you said no, he would give you one. If you said yes, he would give you three.

NAB sends a banks statement by mail even if we said we don't need one and will get them online. If  we say we want one, we get two. They just can't get it right. Somewhere in their computer system they have missed the concept of the shared account. We have tried to rectify this a few times, but without success.

The dutch ABNAMRO bank is not much better. They have problems creating a new account for my son because his details sit somewhere deep in the system. Staff can't find him when you call their helpdesk or visit a branch. But the account can't be created. We'll give it one more try.

If companies can't get their basics right, they should be careful with trying to be smart with big data. Of course a single error does not matter too much when driving market trends or bother people with so called targeted personalised advertising.

But even the specialist organisations can get things horribly wrong. The dutch bureau of stastics (CBS) sent my son a survey relating to his driving experience one and a half year before his legal driving age. I won't repeat what I said when I saw this letter.

The problem with the bank examples are probably bad user interface design or bad information architecture. Besides this, probably a bit of uncaring employees who don't want to go all the way to provide a good service, both during building and maintaining the system as during customer service.
 

Cultural differences, rules and frameworks in IT

Having moved back to the Netherlands from Australia, it is fun to see again that the cultural differences are also reflected in how the profession is approached. Just as businesses are different and have different corporate cultures you see this also on the national level.

One of the first things you notice when you arrive in Australia, is that first of all driving in traffic is a bit more relaxed. You don't have all the bikes and almost everyone keeps to the speed limit. In the Netherlands it is all much more aggressive on the road. The rules on the road in the Netherlands are a bit more logical to me as it is in Australia. For example, I found it rather illogical that each time the left lane (the slow lane) disappears. This makes it that people are constantly merging while this would not be necessary. I had to laugh when they finished the M2 upgrade in Sydney, at some point they first showed a sign "keep left unless overtaking" and immediately following a sign "left lane ends". Sydney roads are just a mess. Of course no-one keeps left. Everyone drives in the middle lane.

In the recent years, ITIL has become very popular around the world and has become the defacto global standard for IT Service Management. Though it is a UK developed standard, it is not a surprise that the Dutch were the early adopters. The same thing applies to Prince2. Whereas PMBOK seems to be more popular in the US and Asia including Australia, is it all Prince2 over here.

Now that I am back, I am confronted with two additional frameworks created in the same spirit as ITIL: Application Services Library (ASL) and Business information Services Library (BiSL). If you have the experience, they are pretty straightforward. The question is of course whether you need to master these frameworks in order to do a good job. Not necessary according to me, but I have seen enough situations where they would definitely add value.

And do the Dutch manage their IT better then the Aussies? From what I hear not be definition. In the end most of it is common sense and if you have quality people who understand IT (and information) and how to manage this effectively, you would do the same thing.

The risk with too much process and procedures is that you become slow and bureaucratic. Not that these frameworks intend anything of this. It is a different way of running your business or your country. Being more lean can make you more agile, supports growth better and can increase profitability. However you have a higher risk that you do things wrong and inefficient. Having more rules and more focus on doing things right, can avoid that but has a risk that you increase the bureaucracy and that you slow your business down. Ideally you have only top professionals who know exactly what to do so you can cut out all the bureaucracy and be lean and agile. But unfortunately that is not always achievable.





 

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.

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.