Over the years, I became more and more suspicious about the concept of a project. I have worked in several companies, at times working with products, at times working with projects. I have seen more waterfall projects, I have seen waterfall products, and I have seen both agile projects and products. What strikes me most is the amount of ignorance most companies have with regards to the effect that projects have in the longer run. Let’s see some stories.

The missed Valentine’s

A few years back I was involved in a large migration project. We worked on replacing an IT system, and needed to transfer accounts from the old system to our new system. The project lasted over the period of a whole year, and we managed to transfer about 1/10th of the accounts in that period.

I recall working 60 hour weeks in the final phase, roughly two months. I remember that all the decisions we made early into the project needed to be re-visited later. There were functionalities that we developed early that didn’t make sense, since we didn’t understand the requirements – no, not the requirements documents, but the requirements – to start with.

We finally managed to deliver the system on the birthday of the CEO of the customer, so to speak as a birthday gift. We celebrated that date. It was back in late November, right before the Christmas period.

There was a follow-up project coming up where we were supposed to transfer the remaining 10 million accounts into our system as well for the next year.

It took us until June to seriously get started with that one.

Why?

In hindsight, I would say that we were roughly burnt-out after that project that got a whole department of 40 people busy for a year. It put down further product development for a serious amount of time. There were some minor projects in between. We simply were not able to deliver them. I remember that it took us from late December until late January to analyze a project due for Valentine’s day. We missed delivering on that.

The split project member

Another project I remember kept one of my colleagues busy. He was involved with custom development for a customer. Overall there were several colleagues involved. The project delivered within two months to our external branch office in Italy.

We didn’t hear anything from that project for another half year. Of course, life went on, projects went on. When our colleagues in Italy finally started to use the software, they found out there were lots of problems that we needed to deal with.

Of course the colleague that was initially involved into that project was already working for another, more important project. Suddenly he found himself in the position that he needed to serve two projects: one that was important for the overall company, and another one that was important for our branch office, and suffered already from some cost of delay.

The sixth UAT

Another project was an internal project. A colleague and I were asked to join the project team. They already worked on the solution since August. We joined in early February. There already had been five appointments for an internal user acceptance test (UAT). They all failed since the solution wasn’t working – at all.

We joined three weeks before the sixth UAT. We eventually made that date, and received additional budget to continue the project.

For the project folks from three different locations were put together. These folks didn’t have any project, and needed to learn the product that steered the solution. The project was in place to create a demonstration platform for potential future customers.

The bottom line

What do these three stories tell you about projects in general? From the first story, I learned that project tend to dramatically sub-optimize. That is why it’s ok to work overtime. In German I like to refer to that as the “Schweinezyklus eines Projecktes”, the cycle of a project. In the end, work gets cramped in, and needs to be done before the deadline that was set months ago. After these acts of heroism, people need to cut short for a while. They need to recover from the stress, meet their families, and so on. Nothing gets done after the deadline. At least nothing serious.

From the second story, I learned that people will be assigned to projects, and those might strike back later. I learned that it will be hard to deal with long-term quality problems once the team members from the earlier project moved on. Usually that leads to people being thrown into multiple projects at the same time, with allocations of 20% and 80% or something similarly rubbish. Why rubbish? Whenever I needed to solve a technical problem, I didn’t care about “is my 20% timeslot for this project now used up?” If I really needed to solve that problem, I did it, and then moved on.

From the final story, I learned that projects make terrible decisions in the beginning, when everything is vague. These problems need to be dealt with later. It might feel great being the hero to rescue the project – and it shouldn’t be necessary to be that hero to start with. All of these three situations convinced me that projects make short-term decisions that will hurt you in the long-run. These include partial allocation caused by earlier sub-optimizations.

Personally, I have never seen such things happening in product development where a stable product team has to deal with the short-comings of today in a direct manner. The folks involved in product organizations are fully accountable for the quality they create today, and they are totally aware of that. In most organization that got rid of projects, I have seen people being more aware of bad decisions.

That’s why usually I don’t recommend projects to most of my clients. That said, I have seen projects work as well. I didn’t try to understand the dynamics in place when it worked. It seemed to have to do lots with the responsible project manager. On average though, projects failed more often than product development. Your mileage may vary.