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.