One part of The Avengers movie (don’t worry I won’t throw any spoilers on you) turned out to be a very interesting anecdote and allows me to highlight the way Making Sense wants to do its job. In the movie, the council didn’t believe in the Avengers as a solution and decide to ignore (and cast aside) Nick Fury’s ideas and hopes. When the council ignores Nick’s group, he takes drastic measures. He takes a risk which could cost him his career and ruin the entire operation by launching a rocket that brings down the council’s plane.
What could be a better way to show trust in our group than risking everything by throwing out a rocket and defending our team?
This is, weapons aside, the kind of relationship we want our team to have – and the kind of relationship we want to build with our partners. This is something that happened to us several times before. It’s easy to trust when everything is cool, so I wanna share with you my favorite anecdote which took place when things weren’t so cool…
The Tough Days
We were working on a Project which had several complications related to politics and bureaucracy. It was the kind of project where there must be results – but there were no certainties to rely on.
Despite that fact, we managed to work on the communication that existed between the different roles and people involved in the project, which turned out to be more than acceptable. We shall call the superior in our customer’s company Nick for now. Nick had absolute trust in our work and didn’t worry about how the tasks were evolving. He knew that we were working hard on our project and that if we had a problem we would reach out to him. Here I was, making various types of analysis for our team – business, requirements, coordination and project management.
The rest of our team gave some good technical suggestions which identified integration problems that needed to be solved, and they did an amazing job in the process of product integration.
Months passed and the project finally came to the final stage of line code. This is where we get through the QA stage and search for bugs or strange behavior based on the data. A few weeks later, this stage (happily) ended and the UAT (User Acceptance Test) stage began. This is where original users will try out the system, letting us know of issues and the value to them in using the finished product.
The UAT Process
In the UAT rounds, many unexpected things may occur. The most wonderful and expected panorama would be for the users to try the system, feel satisfied with what they see, give a formal acceptance and then the system would finally pass to the production field. This happens easily when the final user is actively involved in a constant form, which happens in agile developments.
In traditional developments, the user finds itself involved in the beginning of the analysis process and disappears from the picture until UAT starts. Hence, with a cascading life cycle, surprises may rise due to the changes in the context of the real work that takes place during the development stage. This may come in the form of new needs, misunderstandings that just weren’t noticed before and various expectations that the user has as time goes by.
Anything can happen.
So you will understand why many companies bet on the agile development where the chances of this happening are slight – and when they do, the impact is minimal.
The Difference
Sadly, the happy panorama didn’t take place in our story. Many features of the system weren’t the ones expected by the users. We had worked hard on the documentation of every little requirement, based in the officially approved papers to state that many of their expectations were clearly new requirements; hence, they must be left aside or added in the near future.
There are many reasons why giving up perfect quality might be a realistic and feasible option, as counterproductive as it sounds. Your intuition may say that making the user happy is the best option, but is not the best decision to make when a company decides to invest time and money and leaves other priorities behind. When it comes to big companies, users may not be familiar with the other priorities that are waiting at the IT department, and, of course, they expect their project to be the highest priority. I don’t blame them. It is their way to protect their investment which came out from their own department, the same that invested time and money to get a software product developed specially for them.
In this particular story, there were bigger priorities waiting for us to finish this project. It was our task to finish as soon as possible and if a particular task required an hour of work, we could only use five minutes to make clear that we weren’t going to solve it. Of course, everything that was filed as original task must be part of the job and if there was anything missing it should be done as soon as possible.
One particular feature turned into a polemic. For almost three weeks, users insisted that it was part of the agreement while I insisted that it wasn’t. I read again the documents and it didn’t specify anything about it. Unlike any other features, users insisted, and when I realized the discussion wasn’t going anywhere, I decided to take the problem to the next level.
I contacted my boss and coordinator, our own Nick Fury (with whom he casually bears some resemblance). Without hesitation, our Nick pointed his rocket propeller and declared that if it wasn’t written it shouldn’t be done. He stated that if there were changes or issues to discuss on this subject they should be taken to the executive level – which we would do in order to get a workable solution. He didn’t need to read the documents himself – he knew he could trust me.
And it was then – or in the next fifteen seconds – where I found an old email, buried under months and months of oblivion, with two or three paragraphs in it.
The Surprise
While I was still connected to the phone meeting, I came across an old email and realized my worst fear come to life: it was the order of requirement that we were discussing. A forgotten email – not even answered. One phrase in the email mentioned the feature we were talking about – but one is all it takes.
I was glad I was on the phone so they couldn’t see how ashamed I was. I must confess that I felt the temptation to delete it and pretend nothing ever happened. But the result of that would turn out to be an unfinished product, unhappy users and even more arguments. Worst of all, we would be betraying the trust that the client had in us. No matter how I analyzed it, there was just one solid truth: I was dead wrong.
I interrupted the conversation and as calmly as I could I said:
“I’m sorry, I was wrong.”
An intense silence took place on the other side of the phone. I could only imagine the faces of the people there and the looks they might be sharing. Nick asked a little astonished:
“What?”
“I was wrong,” I replied. “They had asked for that in an email long ago and I lost it in my inbox. I don’t know why it happened, but they were right: this feature should be applied. If we start right now we should have it ready in 3 days.”
The conversation was shortly over. We hung up from the call and many of the team left the room. I called my supervisor and in an attempt to calm the situation I said:
“You now have the right to yell at me for the next 15 minutes.”
“It’s ok. Anyone can make a mistake. Just be sure that the product is ready soon so we can continue with the rest of the work that is left.”
Long-term Results
Besides the awkward situation – due to my own actions – I think that what we did was right, and the trust bond with our partner became stronger that day than ever. I became more careful and organized, and they are still giving us the same level of freedom and trust that they first had in us, and perhaps a little more due to knowing that we learned a valuable lesson.
We are still working together, in even more challenging and complicated projects – each of them with their own story, to be shared in other posts.
Even the users were happy to hear the truth from me, to the point that many of them contacted me privately to congratulate me for being honest. These are the same users who accepted our suggestions which went against their perceived requirements during subsequent projects. That, again, is material for another anecdote.