Saturday, 22 September 2012

When a Project Fails.

I guess if you work in any industry long enough eventually you will work on project that fails. I have worked on two which failed in different ways. Both were painful to leave, but it was only by leaving  that some remnants of sanity was retained.
The first project was first the one that I worked in related to the space industry. I was around 33 and had had quite a few varied jobs (at least 10) before starting work there. It was a huge culture shift from being the oldest in a dept to becoming the 2nd youngest. In my last job my colleagues had gone on holiday to the usual overseas destinations, in my new team Wales and Devon were the most common destinations, and office romance was not an option here.

Up until then I was used to coding a good few pages of modules every day.when I arrived in the office my PC had no compiler on it and I had to sit for three weeks with documents to read - pages of abbreviations and document trees to learn. I started  to look for another job immediately but home life was difficult at this time so I stuck it out.

Over time I got to interact with the teams, there were two other women in the dept and approx 18 men. Everyone seemed to want to code but most were doing documentation. I didn't want to do code at this time but ended up getting the job leading a small cross-site team designing and coding simulations. The project was a precursor to a bigger project so politically it needed to succeed in case we lost the follow-on.  The project was large and complicated by legacy systems and they recruited a contractor to create a large UML model of the system, UML was a new methodology at this time and due to a colleague going on holiday - I got to go on the training session (with his nametag -he was a Dr.!). I was the only one to get the training which caused some problems reading the model.

The model grew and was managed by the contractor located at the other site. The network link to the other site was slow and the model grew harder to open. Eventually the model was so large no-one could open it. It was at this point they decided they should start the coding up in c++,we discovered that there was no-one at the other site that could code in this language, they decided to send some of the team on training. The project did not want us to code these functional modules at our site even though there was expertise there.

As it turned out that there was no money ring-fenced for the simulations work, and we had no equipment to put them on, luckily the other part of the site had upgraded their pcs and we took these pcs out of the skip, I was coding in visual basic using a free cover version from pc world we couldnt get the project to pay for a licence at our site.

We had a meeting at the other site and discuss the critical design review. The engineering manager was not present, he had starting to disappear on a regular basis and made excuses to not turn up to meetings. The contractor that had created and managed the UML model had a serious breakdown and left the project. I hadn't noticed, but the disintegration that was becoming contagious. I told our dept head i thought our team leader was having difficulties. The dept head told my team leader what I had told him. My lead wouldn't speak to me he was having family problems, he became increasingly off-sick and eventually went into extended therapy.
My dear friend and colleague who was a c coder was asked to do some c++ started to not talk to anyone about anything and became increasingly agitated. After a family bereavement he couldn't get it together was off sick for a long time, as he was a contractor he had to leave the company. The oldest chap in the dept. was starting to drink at lunchtime and slept all afternoon, he was one of the most experienced in the equipments but difficult to work with. In spite of the setbacks we managed to create a simulator product that simulated 100s of equipments with the help of three excellent sw engineers. Then the project was canned.

We had a meeting, the engineering manager had caved in and somehow the information got to the customer there was an "uncertainty" about our deadlines. This was most unfortunate because we all believed that we could have pulled this off, these were some of the most experienced and brightest engineers I had ever met. My sleepy colleague would start the morning with the times crossword and the telegraph one would be finished by 10 O clock. Then the brain teaser puzzles would be sent round by email. I was always playing catch-up.
The young debutant project manager gathered us together and gave us the bad news. The subcontractors would be let go and there would be a review for possible deployment of the permanent staff.
So what did I learn from this project?. Even now I don't know what I could do to make things go better, I think the recognition of the disintegration the small things that hold people together when things get stressful are important. This turned out to be the morning tea break where everyone squashed into the kitchen. Also the start of working in pairs. We implemented this on the next project to stop managers being able to put the blame for the delay of a complex item on one engineer - insinuating a capability problem. I also would say my trust in the wisdom/integrity of elders or senior members of staff is not as easily given.


Ultimately there is a limit to everything, no-one pushed the team harder than they pushed themselves -good management should have managed this culture before it imploded. There were people in the team that hadn't taken a holiday for years, this should never happen in a well managed company. In recent years I speak about breakdown and stress where I can, at work, in team meetings/general conversation. I know some people find this irritating, but 12 years on we are still no more sophisticated about mental health and stress working in this industry than we were then, we still don't consult psychologists/doctors in the workplace. I still hope things will improve, I believe talking about it in the workplace community, in particular putting it on the agenda at the company decision-making levels will be a start.

No comments:

Post a Comment