Sunday 8 October 2017

Project management in waterfall environment

With the current hype to use agile methodology in software development it is easy to forget that it is not always possible. Let's look at those moments and the experience of being a project manager in waterfall environment.

Whether it is caused by project conditions or situation in company, there are times where waterfall simply is the necessary solution. You can try to make use of values and principles taken from agile methodologies, but you may fall short due to reality you live in.

I had limited exposure to this world but I dare to say it was rather extreme one. Everything was on fire, there was not enough time, budget, leadership, knowledge and skill. It was harsh and thankless job. It taught me that work of PM is way more difficult than I imagined.

The beginning

It all started with a project that was rather lengthy. It spanned across roughly 9 months and was part of major PR (public relations) campaign. Failure on our side as designers and developers would result in failure across entire company. Shamefully, leadership did not agree and therefore questionable people got on board with major responsibilities.

It did not take long for everything to go horribly wrong. Signing a deal without knowing what was part of it, agreeing on budget without having estimations or knowing the scope, promising miracles without realising it is not possible to deliver them.

There were red flags all over the place, but they were too hard to spot so soon into the contract. Minor slips in due date here, miscommunication there. It was suboptimal but doable. Although I tried to help with some of the issues I noticed, I was not in a position to do that, I was just some random designer.

I have had my screw-ups as well. Whether it was insofficient documentation and preparation for all possible scenarios of user journeys, and tool error messages. Many of these were at first caused by lack of time and later on by the need to handle other aspects of the project. I became a senior technical consultant with expertize on writing optimal backend and frontend code.

My involvement in technical development became neccessary after realizing that the website that was developed took minutes to load, reloaded after rendering and afterwards loaded completely differently. And so I became spread thin saving the product, because what is the point of having a good design when the end product is just unusable due to horrible code.

The explosion

It was not the perfect example of how to develop products, but it was kinda moving forward. And then it exploded. Not even halfway through the requirements of initial release that was supposed to be followed by 7 more, the budget ran out. Yep. Work was not finished, there were 7 more releases besides the unfinished one and there was no more money.

It was around this time I started to be ignored by leaders of the project. Luckily it did not last long. Leadership was soon replaced attempting to salvage the situation and turn it into a win. A new PM was assigned to handle the whole campaign. Shamefully, not enough resources were committed and so the situation remained dire.

Mistakes continued happening as it naturally is when your foundation is crumbling. And so despite objections, warnings and tons of whining, not much improved. Situation stabilized at unwanted levels of failure. Even though we started delivering, we did so slowly and costly. 7 releases were no longer a possibility.

One thing that kept me bugging was the lack of will to fix things. The more I pushed for improvements, the more I was told to let it be. There was fear that if we tried then it could fail. If its broken, let it be broken.

Luckily there was one person willing to settle the situation, a PM with skills and knowledge who either realized I need help or simply could not listen to my whining anymore. Either way he started to stir the water which enabled me to push for more.

The replacement

I was forced to leave the project for couple of weeks, but before that I became determined to save the situation.

First step was to find the correct people. So I tasked one of the best frontend developers with refactoring the code. With this deed she managed to reduce the file size of code by about 70% to 80%. The result was astonishing so I asked her to remain in team as lead frontend developer.

Second step was to find replacement for myself. I worked with very talented and smart mentee for half a year at that point, so even though it was on the last notice, I asked her to look over the project and put her in charge of a new major release.

Lastly I found a PM who had enough skills and knowledge to oversee the situation. It was the one who helped me stir some water before, so this whole enterprise could even become a possibility.

I did not engage him directly but I involved him in the project hoping he will step in if it became needed. And it did. He played major role in coordinating the team, even helped out with design and development.

Building the team was essential for a success. The fact some members of the old team, like the designers, could be relied on, helped a lot, as I did not need to assemble completely new group of people.

I gave out instructions and let the leaders handle the rest. I have soon found out that was a mistake. It turned out that assembling team of experts, giving out all tasks and trusting the leadership to oversee the situation, was not enough. I forgot to appoint someone who would hold hands of the old core team who was still very much in charge.

Overthrowing the old team

After I became available again, I noticed work is not yet finished but definitely on the right track. It became my strategy to help but keep the distance if possible. This still-not-so-well oiled machine was making progress that the old team simply could not.

It was important to me to thank each of those new people to make sure their understand their contribution in saving a project that would have failed otherwise, a project they could refuse so easily and yet they did not.

Although, despite the obvious improvement in progress of the project, it was not enough. I was asked by the new PM sent before to salvage the project to be his stand-in during his sickness. I accepted and took over, consulting with the PM who helped me stir water before my period of unavailability.

We had people, we had resources, skills, experts and will. Next we needed a plan – schedule of releases, list of all the features and their deadlines. Something that should have been there from the very start.

One meeting with clients and our goals were aligned. It was time to set out to work and for the first time in almost 9 months, actually deliver on time.

The stressful management

Even though I am tempted to call it a leadership, it wasn't. It was management. I was doing my best to remove obstacles, keep taps on the situation, keep everyone in the loop, discuss with the clients, discuss with the team. I was never leading them, I was managing them.

Looking back I do not believe anything else was possible. I tried to take on every responsibility that was not covered by someone from the team. I became coordinator, focal point for clients and major pain in the arse for the team.

I realized that I need to trust them and their judgement, that they need to work together and must not have any obstacles like missing information from clients or projects to work on from other PMs.

I have to say I am proud of the work they have done. They pulled overtimes I did not ask for because they believed in the project. I am happy to say the deadlines were met for the very first time. And not just one deadline. All of them.

We were truly successfully delivering on our promises for the first time in the whole lifetime of that project. And it would feel great, only if it was not for the stress.

The unhappy ending

The stress started taking toll. People started getting sick and emotionally unstable, me included. It eventually forced me to restructure the team – decision that was extremely difficult. I evaluated that stressed people can no longer work under such conditions and pulled them out. It was one of the most difficult things I have ever had to do.

I could have analysed it incorrectly, I could have doomed the project, I could have lost friends and colleagues who could potentially help me with other projects. It was painful. Nevertheless, I believed it was necessary if we wanted to continue successfully working on the project. One angry person exploding at the wrong moment can destabilize the whole team and that can quickly turn into a disaster.

With all the stress being constantly present I felt the need for some help or at least acknowledgement of the work I was doing. What I received was precise opposite. I was escalated to my superiors for not managing my time properly, focusing on responsibilities I was not meant to focus on, being sloppy and negative.

All of the sacrifices, hard work, sleepless nights, all ignored. It was at that moment I realized that this is a thankless job at times. The people who failed to act the whole time suddenly came out of woodworks to judge me and be generals once the war was won, providing hindsight advices on how it should have been done and how they would do it even despite the fact their ideas were contradicting themselves.

The lesson

My team was composed of the best people I could have hoped for. I am grateful to each and everyone of them for all they have done and the heart they put into their work.

I have learned a great deal about management, its downfalls, obstacles and challenges. I understand the need for usage of agile methodologies but I also understand it is not possible unless the situation supports it.

And for those people on top who decided not to have my back for saving their reputation and name, well, it was the last time I helped them. It became a time for me to embark on a new journey to find the next promise land. But that is a story for another time.

No comments:

Post a Comment