Maja Selmer Megard, project leader and department manager at Kantega, prepared the presentation From Heaven to Hell which was intended to be presented at conferences in the spring of 2020. In this presentation, she shared her experience from a project that at first sight seemed to be a perfect fit in all regards, but ended up as the most exhausting, conflict-ridden project she has been in.
In her presentation, Megard stated that many of us know that projects are complex, but we still tend to behave as if they are complicated. She mentioned that we must acknowledge that problems and challenges in projects are complex, there is no easy fix, and there is not one and only one solution. She considers that maybe she is not alone in noticing how hard it is to change the tendency to look for easy fixes, even though she knows she has to and wants to.
Red flags were raised by the developers quite early in the project, but were not picked up as Megard mentioned:
Initially I wasn't listening properly and unfortunately interpreted reported problems as a storm in a teacup.
The project continued while they made several efforts to improve the situation. They had several retrospectives, set new goals, documented more, and wrote more status reports with clearer messages, Megard said. One thing they did achieve was building a really good team that supported each other. One of the reasons for this might be due to the perception of there being a common enemy.
After the project was over they had a retrospective where they came up with a very long list of red flags that they had to remember and watch out for. As the list was so long, Megard started thinking about the essence of their problems and searched for something she could easily remember and that was generic enough:
In this period, my colleagues and I discussed a lot about complex/complicated topics that helped me realize the following. To avoid behaving like challenges in projects are complicated and not complex, I try to focus on three small words: listen, take time, and be brave.
Listen: it can be difficult, you must be focused and open-minded. Our listening skills got better and better during the project, and we learned to listen in order to discover patterns instead of clear messages.
Take time: it is very hard to prioritize spending a lot of time trying to make things better because we all are so busy. And I think we tend to forget that also problems are complex, there is no easy fix, and there is not one and only one solution. And on top of that, you have to use the "build, measure, learn" technique and be patient. Maybe your effort didn´t make any positive change.
Be brave: Stand your ground regarding red flags! A toxic blaming environment will often make us question ourselves and our abilities. It makes us fearful. Trust your gut feeling regarding those red flags, listen to the team – and be brave! Don’t make compromises that you will later regret.
The problem with problems is that nobody wants them; you are seldom met with open arms when all you have is trouble, Megard said. When you escalate problems, your managers also must prioritize them and they can take up a lot of time.
InfoQ interviewed Maja Selmer Megard about her experience from the project.
InfoQ: How did the project start? What were the expectations at that time?
Maja Selmer Megard: We won a tender to develop a solution to replace existing software. It seemed like a nice little project and the setup was perfect. We had a highly-qualified motivated cross-functional team, an agile procurement contract, and we were co-located on-site with the client.
The aim of the project was to deliver a simple web front-end solution integrated with an existing back-end. Five people, five months, a manageable scope.
My job was to follow the team closely, support team members when needed, and make sure that agile principles were implemented and followed (team coach). As head of the department, my schedule is tight, but I was looking forward to getting some hands-on experience for a couple of hours a week to keep me grounded.
InfoQ: In your talk, you mentioned that along the way things didn’t go as smoothly as expected. How did you notice red flags and how did you handle them?
Megard: I would hear things from my team like…
- "What exactly is the value again of this project?"
- "We cannot meet the client’s expectations without significant changes to existing backend …"
- "I cannot deliver good work."
- "Decisions are not made, so I cannot start coding/Without these clarifications I cannot start coding."
- "The client keeps making subtle remarks questioning our competence, like, ’It can’t be that difficult, can it?’ Or, ’Don´t you have anyone in your company who actually knows how to do this?’ "
- "The client does not seem to understand the situation."
- "The product owner is never present, busy with other tasks."
- "We are not allowed to talk directly to stakeholders and end users."
- "I won’t have my name on this code."
- "This project is doomed to fail!"
We also started to experience what we interpreted as signs of rising client distrust. It was a constant pressure to cut corners and a lack of understanding that we needed to interact with end-users.
We felt that the client had a hostile patronizing way of communicating their point of view. When new challenges appeared, they assumed this was due to our incompetence, and not the complex nature of the project ("don´t you have anyone in your organization who knows how to fix this?"). We failed to communicate the complexity that we had discovered.
As the project experienced its first delays, disagreements escalated and lawyers started to get involved.
Unfortunately, when pressed by the client, both the development team and I buckled and tried to make the best out of a difficult situation. We made compromises that we never should have made in an attempt to make the client happy and the collaboration between the client and us less toxic.
InfoQ: What’s your advice for people who need to be brave and take action?
Megard: It is hard to give advice. But it is an interesting topic to discuss.
I have to rethink my own way of receiving problematic messages from my team, not accept their withdrawal when pressed. Be aware that people generally don’t want to cause trouble, so when they raise a red flag it is usually justified. I must fight the urge to readily provide a solution, and tolerate (and accept) the stress it causes me.
Being a person who enjoys fixing problems, it was difficult to challenge our client to find solutions together with us. The constant challenging climate and the client’s distrust eroded my (and the teams’) self-confidence, to the point where I felt I could not do my job properly. In retrospect, I see how this caused me to not communicate challenges clearly and that I had problems standing my ground. I hope next time I will recognize this for what it is and be able to stand in confidence with the discomfort longer (be braver).
My three mantras, for the moment, to better stand in discomfort, are:
- Don´t take things personally
- Use your sense of humour
- Take breaks (get fresh air and breathe)
So simple yet so difficult at the same time.