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.

A 100 years Plan for Space.

Today I printed off the brilliant diagram from Rockwell International (discovered thanks to sc-ifi/sw tweep @StevePoling)100 year space plan  that shows the time line stretching from 1983 forward a hundred years. Its a vision of interdependent events leading finally to interstellar travel.
I put the diagram (after sellotaping it together in A4 pieces) on the corridor wall at work . Each time I looked over, someone new was studying it. Some projects that people had actually worked on were identified, and highlighted, and of course the rovers, were of great interest. Most importantly for me was that someone however madly optimistic they might have been, had tried to articulate something, that even now we are struggling to describe - a global space future.

You Are Here.

The problem for many of us working in the space industry is that the "You are here" relationship mapped to the rest of the project or industry in general is not immediately obvious. It is possible to work at one desk for many years with out really getting a grasp of what the people working in the bay next door are up to, or the where the project is currently heading. Although we have much better communication tools and technology it is not clear that gaining understanding of inter-dependencies and production complexities are any better addressed than they were 20 years ago. In fact there's a strong possibility that due to a number of factors, it could be much worse.This is an opinion of course ;) but in the space community there appears to be a "clicky" culture in that you will belong to one group or the other either by nationality,discipline, gender, culture or all of them. If you're not in a group you're on your own and in general this is not a good place to be in space even if you're quite self sufficient. As a female software engineer I am used to being a bit of an outsider, but its also possible to identify many other outsiders not defined by gender.

Nice To Have, Difficult to handle

I tried to do a bit of investigating on why this happens, and there is a lot of research on-line on building effective communities based around -bit of a jump here - "diversity in schools". It appears that by bringing in different more balanced quotas of genders,race,class, culture or nationality does not necessarily bring an integrated community, in fact it can increase gang membership and bad relations in the community. mcgraw-hill article To counter this behaviour it was found that it was effective to build infrastructures where individuals could collaborate cross-community, this consisted of projects specifically set up to increase the possibility of socialising and working across the different community groups. Great care was taken to ensure that these collaboration projects were supported and given a high priority in the day-to-day planning. None of this information is rocket science of course but for some reason in the industry there still a belief that community interaction is a "nice to have" and not a necessity.

Heros and Villains

For the community in space there is an added element to the understanding cross-cultural behaviours, there is often the need to explain something complex a concept, details or other difficult elements to the other group. Language, behaviour and attitude in the cross group relationships becomes an essential part of the outcome. One aspect that is difficult to ignore is the stress. The space industry like many other industries is often underfunded for the almost impossible requirements,that now need to be satisfied, to achieve our new space project objectives. Some people behave well perhaps even heroically in a stressful situation and other do not.  If looking for a good project outcome it is advisable to prepare with some kind of "health check" for both behaviours!. 

How many lifetimes?

Anyway back to the 100 year plan - when i look across and see the effort made by one small group of people to explain a vision of the next 100 years and its complexities it helps to put things into perspective. Each of us has such a short time to contribute to this vision that requires many lifetimes to fulfill. Following in the footsteps of engineers that started this task, it is humbling to see how much was achieved with so little. I believe that much past achievement was realised by teams of engineers working closely together. I hope working against the current cult of the individual, we too can achieve this high level of collaboration required to face the challenges ahead in space.

Tough Without a Team

A few weeks ago, I was having my hair cut in "Ayshes" in the Stevenage indoor market when there was a power cut, not all the market, just the shop units on one side, which included the hairdressers. Its an old-style hairdressers womens side on one half of the shop, men on the other -around 6 chairs on each side. In the dark without hardly any discussion, (apparently this had happened before) they picked up the chairs and I found myself seated in a "bus like" arrangement in the middle of the market place with my grey nylon cape and wet hair.
Sitting surrounded by the quiet industrious hairdressers in the market place made me think how much I missed working in a team.
A team of individuals
In the sort of environments I work in, usually the "team" really is a group of individuals with different and sometimes conflicting objectives. Improving the team spirit is difficult as the individuals on the team are highly competent, and educated, and often do not see the need to collaborate, and some feel that they will be be slowed down by working in a collaborative way. For some this of course may be true.
It is interesting that there is often a focus on a modern advance or tool which appears to be a desire to leapfrog a community or discipline to avoid interacting or consulting whether this is a secretarial or administrative group or technical group usually proposed as a cost saving exercise. Under the pressure  to make quicker decisions the decision-making groups  round the table are smaller and less diverse and more increasingly compliant to senior management sentiments.
Skeleton team
Increasingly due to costs, the skeleton team is now a mainstream approach which means you may be in highly skilled team but there will be only one member from each discipline. In the current crisis there is a resistance to take on trainees or lesser-skilled people as there is no time designated for people to train them. The lack of a technical community to discuss your problems can be stressful, also,when arguing cross-discipline it helps to not be the only one in disagreement. If no-one else understands your point of view you can be seen as obstructive or difficult. Having your work peer-reviewed by your own community helps build your confidence and promotes discussion. Processes are difficult to enforce on the wider community ie. adhering to naming conventions/configuration control if you are the only one in support of this sort of basic quality, improvement initiatives, you may just be seen as being  "picky".
Pushing the Limits.
With a tough isolating work environment that is currently evolving it is also important to have good emotional support at home, family pets etc. (easier said than done!). Its now common to build technical community networks that transcends a place of work. Techies usually belong to interest groups on the internet, although this is a great source of support for an individual, it is not always possible or desirable to use this a replacement for the workplace social environment. As technical work becomes more complex, the levels of finance low and the expectations increasingly high, it maybe that a return to working in teams becomes once again becomes more desirable due to the limits of the human individual and not least because of the deep human need for people (scientists,engineers & hairdressers ;)) to work with each other.