How procurement can create value for IT projects

We know this, in many IT projects we need to make use of services and software and hardware that needs to be bought.

Actually it often makes a huge difference, what kind of deals are made and how efficient the projects can work on this basis.

I will just briefly tell a few stories and tell a bigger story by that.

A common pattern is a „preferred supplier“. It is nice to be a preferred supplier and in the phase when the partner is chosen and the contracts are made, companies often offer their best people and services to show how good it will be later to have them as preferred supplier. And then, when the deal has been fixed, they send the juniors for the same hourly rate and make a lot of profit. Or the price has been made so low, that only the juniors can be sent. This can be a problem in the long run, because it might get really difficult to get enough really good people in order to progress with strategic long term projects and not just maintenance of the daily business. Another interesting pattern can occur, when the preferred supplier is very strong with their employees in a project. Now they are getting some money from the hourly rates and in order to make profit the salaries should be significantly lower than this. In order for this to make sense for the employees they can provide non-monetary incentives, like some kind of career steps. Being in a powerful position in the project, the preferred supplier has some possibilities to choose who is in the project and who gets more responsible positions. So there is a temptation to kick out people who are not from their company and to provide these attractive positions not to the person, who would be the best choice for the customer, but to those whom they want to give an incentive. This is on the expense of their customer. So in the end of the day it is usually good to rely on multiple providers for „external“ people. There are serious companies who behave professionally and correctly even when they have become a „preferred supplier“, but this is not always the case.

When the preferred supplier is providing software, for example a database, it may be possible to get a really good deal for five years. Then in five years the deal needs to be extended and becomes magically more expensive. Especially if the company knows itself in the position of a „preferred supplier“. And when this issue is discovered, maybe even a year before, it is already too late to migrate. And then the expensive software needs to be used for another four years until it is again too late… And being from a big, impressive company does not necessarily make the software good. Counterexamples exist. In the case of databases I have seen companies that follow a strategy of multiple databases and that require a good reason for using the more expensive solutions. And magically the position of the buyer becomes much stronger when the deal needs to be extended for another five years. Maybe the overly expensive database will even be kicked out at some time. And yes, this expensive database has some really cool and pretty unique features. Unfortunately they only come in some enterprise edition that would be even much more expensive than the regular one, while open source databases provide decent, but less sophisticated variants of these enterprise features for a price that is less than the base version of the expensive database product. But, since the DB product cannot easily be changed, it is important to make a wise choice and to consider different options, including the more expensive ones, when starting a project. And to pick what makes sense for the specific needs.

Some interesting observations where made, when some preferred supplier made a really tempting offer for operating all the servers of a larger company. The annual price was really low. Much cheaper than doing it with their own team. Now suddenly the need arose, to store some really large amount of log files. I mean, I am talking about what could be stored on a few USB-discs, that could have been bought in the supermarket for a few hundred Euros. But of course this was forbidden, because the servers had to be run by the preferred supplier and even putting Linux on a few PCs that were no longer needed and attaching a few cheap disks would have been ruled out by the cheap overall contract. But this cheap solution would have been absolutely sufficient for the purpose. Now the diskspace could be bought from this supplier. Or more precisely rented. It was not a few hundred Euros, but a few hundred thousand Euros a year. Yeah, trey needed to make some money somehow… And a few hundred Euros once every few years, or maybe even a few thousand Euros every year would have been totally acceptable to pay by the project. But there are limits. You cannot do certain things under such conditions. The deal kills important possibilities of the IT people. I am not going to write, how this was resolved…

Another story, with a really cheap preferred supplier: They actually ran an important database for a stunningly low fixed base price. And on top of that it was paid per query. So what did they do? They designed the software in such a way that it used an Oracle database as a cache for the pay-per-query DB2 database. So the same query had to be made only once to DB2 as long as the data did not change. And when the data changed, the Oracle database just had to be cleaned up. Since this happened only a few times a year, this technically stupid architecture saved really a lot of money every year. Big money.

Yet another example: The management had already bought clearcase licenses. They were really expensive and the money was already gone. Now the setup that was used for clearcase and that was allowed by the licensing was not really optimized for part of the team working remotely. To do that efficiently would have required a much more expensive license that no one wanted to pay. So every day synchronizing the software took like 30 to 45 minutes. And one team member had to work full time to maintain clearcase. There were some other pains, like it crashed when files contained only linefeeds instead of carriage return-linefeed and some other annoying details that I do not really remember. Just for the record, some of these issues have been fixed in later releases… And clearcase had a lot of really interesting features that were not at all used. The seriously useful features can all be found in git now, in a contemporary way, of course. But not in those days, when there was still neither git nor subversion. So some tests were performed and it looked like the free software CVS (which really sucks big time when compared with contemporary systems like git) would have worked much much better for the concrete project. But clearcase had to be used because it was so expensive and the money had already been paid.

So in the end of the day, when the procurement does make good deals, this can create a lot of value for the project and allow for efficient and innovative work and for solutions that make sense technically instead of finding tricks how ot bypass the worst parts of the contract.

So a good procurement team and a good communication with the technical staff that knows what is needed for their work is a big plus for everybody, for the project and for the company.

Share Button

How bad can a bad IT be for a company?

Just a funny story that happened some years ago…

I wanted to buy some lamps in a stored somewhere 100 km away from where I lived.

So I went to the shop, ordered them and bought something else already.

Now I went there again when the lamps were there. I had ordered six lamps, but actually wanted to buy one more. A bit of money I had already paid when ordering…
It was a bad day. They told me that the lamps were probably there, but they were not able to process the purchase or even find them because the IT was not running. I was kind of upset about wasting so much time and money to get there and so they paid me the train ticket..

Next time I went there. It took a long time until I was able to pay. And then it really took an hour.. Six lamps ordered, plus one more, minus the sales tax from the previous sale minus what I had already paid plus some other stuff that I had actually bought during this visit. So many numbers all had to be added together with the right sign… After about an hour and many false attempts they got it right. It took an hour from the time when it was my turn to the time I had actually successfully paid and my credit card did work correctly… Then I got a piece of paper and I had to go to another entrance of the building, quite far away from where I was. There they had another understanding about how many lamps I should get then what I thought I had paid for. So I went back to the lady where I had paid and asked her to come with me to help me get the right number of lamps. She did not want to help me in that way, but I got her to write a not on the piece of paper that she had given me, that this means that I was entitled to seven lamps and she signed it. Then after having spent at least two hours I was able to go home with seven lamps and whatever else I had bought.

Now the question is, what is wrong here?

Obviously the IT did not work too well… It did not work at all on the second visit and it did not help getting the job done during the third visit.

But was that really the problem? Or just the symptom?

My impression is that the top management of the company was really bad. The processes were bad. And they were not able to find good employees, to train them and to motivate them. And then the IT was showing the same standard as the rest of the company.

Fixing the IT would not fix the problem. The business has to be fixed, the processes, the management, the employees need to be trained well, selected well and most of all motivated to work well… Then, when there are decent processes, it is a good time to improve the IT to support these processes instead of retaining the bad processes by implementing an IT before understanding the business well enough.

Share Button

Processes

We all encounter once in a while people in the teams who really love processes.

Now processes are a good thing, because they can help us to work, clarify certain things and improve efficiency.

There are even processes that are absolutely mandatory, for security reasons, for example. It should be carefully chosen where to impose such a mandatory process, but then it should never be broken. Other processes are more like a tool, that we use because it helps us. Or because the majority of us or simply the boss think so. Or because they are just there. And have always been there in the last 9 months or so.

A well know example is the work of airplane pilots. When they take over a plane there is a checklist of things what to do. Each item of the checklist has to be followed. Each time.

I have introduced such a checklist for creating a release or of a software into many projects. It proved wrong to shortcut this or just do it somehow, because in the end the wrong or unknown version of the software was installed or something else went wrong. I introduced it also for creating USB-sticks that were used by non-IT-people to install a software on around 1000 devices physically located in different places throughout the country or by hardware people in their workshop. We were not stupid, what could be done via the internet was done via the internet, but machines could get hardware problems or get messed up or simply be set up for the first time. It took a bit more than an hour to do everything by the book and it never became significantly faster. But then again a failure was potentially much much more expensive than a few hours of work. And after this process had been introduced there were no failures at all with any USB-sticks prepared according to this process.

But of course we should always remember that processes are there to help us do our work better. So they should not become so extensive that they use up all the time or that they make work too hard, unless necessary for reasons like the ones mentioned above. So a good understanding is that a lot of things can be done if all who are involved or simply the boss agree to do so after thorough thinking. Do not stop using your brain because of processes.

Share Button

Not all projects are on ideal paths II (Tim Finnerty)

This is another story of a project, that did not go as well as it could have gone while I was there. From unsuccessful projects we can learn a lot, so there will be stories like this once in a while. The first one was about Tom Rocket.

Tim Finnerty

It was the time, when all the cool companies tried to introduce Java. And some of the new Java projects failed, causing the companies to go back to C, which again scared other companies from doing this step. But some companies did not get scared by this. They embraced the new Java-fashion at a time when it still was not clear whether or not this was a good idea. What could possibly go wrong?

Well, in those days the experienced guys did not want to move to Java. It was slow, it was unreliable, not mature,… Maybe for Applets, maybe more generally for GUIs to get rid of VisualBasic, but Java on the server was considered a bad joke. For the server real people used real C, of course on Unix or maybe Linux, which was not really such a bad idea in those days. But there were the young people. Or the ones who had stayed young. They often just had finished their education and firmly believed that by just using technology „xyz“ everything would become great. xyz can be a development method (spiral model in those days, agile today), an architecture (microservices), a paragdigm („OO“, „functional“), a framework („enterprise edition“), a tool or a programming language (yeah, Java).. Often this first enthusiasm ends in a disaster: The money has been spent, the developers are leaving and the software is further away from being useful than anybody would like to admit. In lucky cases there is still some money left to do it right. Maybe even to do it right in Java.

That is were we are coming in. I do not really know the earlier history, but according to the management it was a total disaster. Now Tim Finnerty (real name known to the author) was the new technical lead, team architect or whatever this role is called. He embraced the new technology, but promised to not overstrech it. A bit of old school. Sounds good, because it is exactly what managers want to hear. No more risky experiements, but this time it needs to become a success.

So Tim Finnerty defined, how we had to work. He knew Java, he knew databases and especially Oracle, he knew the web, he even knew Perl. And he knew OO. Better than anybody else, so we did the real thing. Great head start. And everybody had to program according to Tim’s rules.

Of course we were using Java enterprise edition. That meant, that we were programming against some Weblogic application server, that was hard to install, hard to run, required a few minutes of startup time for each minor change of the software that we were writing and forced to a very archaic and primitive programming model. But that was cool and it was the future, which unfortunately proved to be true. Even though it has at least become usable by now. So far nothing to blame on Tim, because it is kind of the stack that everybody used.

Now to the OO and the database. Each database table represented a „Business Object“, with a name like XyzBO. So most of the time, we wrote a class XyzBO plus a few more to fulfill the greed and need for boilerplate code of the old J2EE-world. XyzBO was a enterprise java bean. A stateless session bean, to be accurate. Which meant, that we wrote methods of this EJB, which were basically procedures of the pre-OO-world. But within we could of course use the whole OO-toolset. Which we did. So the class to represent any data from the database was actually called Data. It was a minor subset of the standard Perl data structures, which meant that Data was a list of hash maps, which could behave just like a hash map if it had only one entry. Database queries returned Data, or of course null, if nothing was found. Nobody would ever want to use an empty collection. Pretty much the opposite of what we are now doing the hard way by introducing Optional or Option to avoid the null. But it was easy to just write
if (data == null) { data = new Data(); }
at least for the ones who new this trick.
So data resembled the content of the database or of the query result, with the column names as keys and the values as objects. When working with these, it was really easy. Just know the attribute name accurately. Get the value from data. See if it is null. If not, cast it to the real type, and voila….

The database was designed according to Tim’s advice, he had to review every table. It was mandatory to have as unique key and as first column a string of around 700 characters, which was called HANDLE. Each table had a business primary key, which was always consisting of several columns. Because the system allowed multiple instances of the software to run on the same database, there was always one column called „SITE“ in this logical primary key. But there were no primary keys defined in the database. The unique HANDLE was enough. It contained the name of the BO, like XyzBO, followed by a colon and followed by the concatenation of all the logical primary keys, separated with commas. The date had to be converted to a string using a local US format, not ISO, of course. All foreign keys were defined using HANDLE. In the end more than half of the DB space was wasted for this stupidity. But each single handle value started with an XyzBO:, to remind us that we were programming OO.

And now booleans. It was forbidden to use the boolean type of Java. All booleans were strings containing the words „true“ and „false“. This went like that all the way to the web interface.

At that time web frameworks did not yet exist or were at least unknown. So the way to go was to write JSPs, which contained kind of dynamic web pages and to write servlets to control the flow and access the EJBs. Now according to Tim it was too hard to learn servlets as well, so it was forbidden to use them and instead a connection-JSP had to be written, which did not display anything, but only contained a <% in the beginning and a %> in the end and the code between.

A lot of small and larger stupidities, that were forced on the team. Most people were new to Java and to OO and did not even realize that there was anything wrong, apart from the fact, that it was kind of hard to get stuff done. Some stupidities were due to the fact that the early J2EE really sucked, but mostly it was Tim, who forced everyone to his level. This story happened a long time ago. Tim has already retired. I would say he is one of the guys, who retire as a Junior.

There is (almost) nothing wrong with stupidity. And there is (almost) nothing with arrogance. But the combination really sucks. Especially if it it taken serious by the manager or has to be taken serious by the team.

Share Button

Not all projects are on ideal paths I (Tom Rocket)

It is nice to write about positive things, how things have been done well, how they should be done well and how good we are and how good we could be if we were just applying the right technology and methodology and process and management…

Tom Rocket

Let’s leave that for today and write about some projects that did not go too well. I picked an example that is more than ten years ago and I am not going to mention any names. Maybe someone who knew this projects as well will recognize something, maybe not. There would be more than one article to write about something like this, and I guess almost anybody who has been around in IT for a couple of years would agree. If not, enjoy being so lucky. 🙂 I change all the names, of course. Otherwise, I hope it is enjoyable to read about others who did funny stuff and to find some anti-patterns between the lines.

So project dinosaur was taking place in the same rooms where I was working. I had some low volume consulting task for this team, but was mostly absorbed by totally different projects.

Tom Rocket is the project manager. There are some more project managers who represent the customers side, but Tom Rocket is running the show and is present in the room. It is easy to recognize that he is the boss, because he calls his team members like the way somebody treats his doggy, who happens for some unintelligible reasons to have a dog, even though he does not particularly like dogs. The team is very engaged, they work hard. Not every day very motivated, but who can understand that. Of course some parts of the development is done by another team of the same company, at another location. The managers of both locations are not really best friends. Donald Peak, the manager of this location, does not care too much, as long as he can sit in his office, smoke cigars, enjoy his newspaper, do some strategy work and manage his car collection. Having been a communist in his younger days, he still knows very well how to be a capitalist. He has his people to deal with the operational issues. They are the bosses of Tom Rocket. And they do not like the other office, where they seem to do interesting and good work. Anyway, to put the pieces together, a complicated server and firewall infrastructure is needed. The other team can dump its code in some neutral zone (DMZ) from where it is fetched and integrated by Tom’s team. And the really cool stuff is done by Tom’s team.

It was a bit before web applications where the thing, at least in a time when people like Tom Rocket did not know and did not care about web applications. The client was developed in MS-Access-Basic. This resulted in interesting opportunities concerning the data. It was possible to store some part of the data in the client database and some part of the data in the server database.

The project was really important. A big company in the country where this happened did an advertising campaign for their end users concerning the services provided by the product developed by Tom Rocket. It was seen a lot in cinemas, in news papers, on the streets. Everybody knew about it. It was coming, it was there already.

We know, there are some organizations that use IT and that actually perform backups. Tom Rocket and the company where he was working did not belong to this group. Backups were not yet introduced, but talking about the possibility of having backups had already begun.

Some IT development projects use source code management. We are talking about the times of source safe and RCS. CVS was already on the horizon, but not yet widely adopted. But Tom’s project did not employ source code management. Whenever a bug in production occurred, they had to get their current development version ready for production, fix the bug there and try to get it installed. Certain end of month operations were causing big pressure on the team each month, because they did not really work fully automatically. The data quality was kind of poor and it was hard for developers to find anybody responsible for this and Tom Rocket was not at all helpful. So they tried to find workarounds that allowed the software to kind of work with such poor data quality, but this was very hard and not really a success story. The introduction of source code management was on the radar, but since the whole team always worked overtime to get the most urgent things done, this never became a serious priority.

A new developer was added to the team. They tried to copy the sources to his home directory, but that did not work. So the solution was, that the senior developer had to give his login and password to the new colleague in order to let him participate in the development.

There was a happy end to all of this. Most if not all people in Tom’s team left the company. The project was stopped, even though it was a bit embarrassing after all the advertisements. And the mother company bought another company in the same country. They somehow merged these too operations. Since the newly acquired company was obviously managed much more professionally and it was much larger, we can make guesses which of the two management teams took over.

Lessons

We can look at this story from different angles. As a distant spectator it is kind of funny, maybe even as a spectator working on something else in the same room, if you have that kind of humor.

As a team member: It might be hard to enjoy working in such an environment and it would not get better by itself. So options are to see if something can be done about Tom becoming a better team leader or being replaced by a better team leader. Or as most of the guys did, just find a better job.

As a project leader in a project that is so deep in the mud? Treat the people working for it even worse, so they will be encouraged to work harder and solve the problems, that can’t be solved at their level? I guess, it is important to admit the situation and either get enough air to put the project on a good track or even risk that it is abandoned. In the end that happened anyway.

As a manager of the company or the office where this took place? I think beyond all cigars, car collections, stock options and strategy it is important to know what is going on in the company, how people are working, how people are feeling, how people are treating each other and how chances are to get to a success that will encourage customers to do another project in the same way. Just ignoring this or demanding „just a bit more“, because the project is in danger and it is no time for addressing any long term issues did not work out. The teams are the real value of an IT company, not the hardware, the furniture and the rooms. Burning the real values like coal, as the word „resources“ might suggest, might not be the recipe for long term success. I would mention in favor of Donald Peak, that I have good reasons to assume that he was a decent and probably good manager in earlier times, but the time of Tom’s project was probably not one the best years of his carreer.

As a customer? I think it is important to have an idea about the team, how they are working and what kind of people they are. In this case it was most likely the right decision to stop the whole thing.

So, as far as I know there was a happy end, at least for the team members and for the mother company.

Share Button