Common traits of failing projects as seen by a bottom-tier SES engineer
Being at the bottom means having fewer responsibilities and more peace of mind, so you actually get a pretty good view of your surroundings. So, this time, I'd like to introduce some of the characteristics of failing projects as seen from the bottom!
Bottom-tier credentials
First, I'd like to introduce myself to prove my bottom-tier credentials.
Working as a fourth-tier contractor for over 10 years
Never once worked with a senior colleague from my own company
As a rookie, sent solo on a 'business trip' to work on-site in Kansai
By my fifth year, all my seniors had quit, making me the most senior member
Hired mid-career with a liberal arts degree and no experience
Former part-timer
See? I'm definitely at the bottom! Well, I've been working with a background typical of those black-company SES firms, but thanks to that, I've become an engineer with nerves of steel. Thank you, bottom-tier life.
Definition of a failing project
I felt that the definition of a 'failing project' might differ from person to person, so I'll define it here for now.
A failing project is
a state where the schedule is delayed, resources are insufficient, and the problems to be solved exceed the project's capacity.
In my experience, things usually start to fall apart around the integration testing phase. To be precise, it's already falling apart during the development phase, but in that phase, people often just use empty implementations for uncertain parts and call it done. It's a way of making it look like there are no schedule issues. Liars!
And then, they try their best to make the lies come true, but it's already too late. Oh, it's scary, isn't it?
Common traits of failing projects
Now, this is the main topic. I'd like to introduce the common traits of failing projects as perceived by me, a professional bottom-tier engineer!
Reluctance to make decisions
In failing projects, there is a tendency to postpone things that absolutely must be decided, such as specifications and policies. Even people who should have decision-making authority start saying things like, 'I'll consult with my boss first.' Very Japanese, isn't it! By the way, this is a phenomenon often seen when both the client and the development vendor are long-established companies. Approval processes, approval processes everywhere!
Love for meetings
Mysterious meetings with no clear purpose become the norm. Be especially careful with meetings labeled as 'regular meetings.' They are events for middle-aged men who can only meddle in upstream processes to feel good about themselves, and there is no substance to them.
Strangely, in these types of meetings, there are often no minutes created. Perhaps it would be problematic if the content of the discussions leaked out? Since the agenda is decided only after the meeting starts, well, it can't be helped.
Noticeable lack of skill among those in charge of upstream processes
Upstream processes are supposed to be a very important part of the system development flow, but for some reason, they are sometimes handled by unskilled older guys.
And surprisingly, it's not just a few people who lack the skills. A significant percentage of the staff is unskilled.
So, after a certain amount of man-hours have been consumed, talented mid-level engineers join in to clean up the mess. I sometimes wonder if the business model is to have these unskilled older guys delay the schedule as much as possible to make money.
When you join a new project, it's interesting to look at the requirements definition, basic design, and the age group of the people working around you; you can kind of see the future.
Passionate obsession with document formatting
You can see a passionate obsession with things that have nothing to do with design, such as fonts, font sizes, printing, and borders. Unfortunately, pointing out such things in a review does not improve the quality of the system. There are still projects where the culture dictates that people who excitedly point out these things are considered correct.
I don't see people printing things out to check for borders or text overflow as much anymore, but I suspect it still exists in projects with an old-fashioned culture. What a waste of paper.
The writing of people who communicate with other teams is garbage
Normally, external communication should be handled by people who can communicate smoothly. However, in failing projects, there are people everywhere who confuse the recipient's brain with mysterious writing that makes it impossible to understand what they are trying to say.
When you join a project, try looking at the QA sheets; you can generally see how chaotic the project is.
By the way, this point is highly related to how long the project will remain in a state of failure. Conversely, if this part is solid, even if the project does fail, you will be able to resolve issues smoothly.
The people who should be programming are managing
Failing projects tend to try to solve things by just adding more people. However, the engineers sent to projects in this state are often unskilled. It's good if they can write code by copy-pasting, but in some cases, they can't even do that. After all, you need to be able to read code at a minimum to copy and paste.
And yet, in this state, engineers who originally have the skills to be lead engineers are managing development progress. They could probably produce better quality and work faster if they wrote the code themselves. But they are assigned management tasks to keep the mysteriously increased personnel moving.
This is something that managers with little development experience tend to do, and if a project is in this state, it probably won't go well in the future either.
For some reason, there is a tendency in Japan to look down on programmers, but if good programmers write good code, the risk of consuming man-hours on bug fixes is reduced, right?
If assignments are being made without understanding this, be careful.
Unexpected deliverables are born
Originally, you decide on the deliverables first and then make an estimate, but sometimes unexpected deliverables emerge during the project's progress. Well, I feel like this happens often, but there is a limit.
When this becomes the norm, you end up with people in positions where they haven't been assigned main tasks and, from an outsider's perspective, you don't know what they are doing. That person is probably a victim. Be kind to them.
I am an engineer raised by failing projects!
I've titled this 'Common occurrences in failing projects' and listed the characteristics of such projects, but personally, there are quite a few parts where I've been helped by these failures.
The reason why a liberal arts graduate with no experience who used to be a part-timer has been able to survive this long is probably due to the low hiring hurdles unique to failing projects, and the fact that I was able to experience development at a relatively early stage is also partly due to this.
Of course, there were times when I worked over 350 hours a month or got furious and had a real fight with a secondary contractor's manager, but those are good memories now. Probably. When I think about it calmly, I was like 25 back then; it's hilarious how crazy I was.
However, I don't want my juniors to have such experiences, and now I am in a position to teach engineering work to those with no experience. I think the path I took is generally the wrong one.
In recent years, the culture of the IT industry has changed significantly, and exorbitant overtime has visibly decreased, and even at my company, which treated me roughly, there is now a structure where newcomers gain experience under their seniors. Boss! You really should be grateful to me! Everyone else is quitting!
I grew up in failing projects, but I must behave in a way that prevents failing projects from happening in the future.
I would like to close with that resolve.
Thank you to everyone who read this far.