Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

What happens when your product is not stable close to release date ? – Part 6

This is a series of short posts about the scenario where a product that decides the future of the company is being released, and how it can be difficult to make a decision about release vs. delay when there are suspicions that the quality of the product may not be as desired. In the previous post (bug closure during the end game), I was talking about the bug closure rate near the end, and how the pressure near the end can be problematic for the people in charge of approving or deferring bugs.
In this post, I will talk about a horror situation where the management is not connected with the team (not connected enough to know about the current situation) and the pressure forces management to take hard steps which eventually blows up in their face, enough to shake their own careers. This is not a fictional situation, it has happened with several companies, and there are other cases where it has almost come to this, but the senior management has managed to turn things around and prevent the situation from going out of control.
Consider a case where the product that is going to be released is very significant for the company and there is a huge amount of market, stakeholder and executive pressure. The career of the key senior management stakeholders can depend on how well the product release has been handled, whether they have shown the necessary guidance and overall management to take their entire team along, and similar goals. So what happens when the pressure forces them into such a place that they get so committed to the release of the software, enough to ignore the pressures of the teams working on the software, and are only exposed when whistle-blowers in the team go right to the top to make their point known that the software is not yet ready for release.
An example of this happened a few years back in a large company (I will not take names deliberately, since the idea is to show what happened rather than only point out a specific example). The senior management felt that they had a good control of what was happening, and the pressure on them to ensure that the release happened on schedule was enough that they forgot the part about the release also being of good quality. So, at some point you had a situation where many members of the team had huge issues with some of the open items that were potential customer problems, while the executives felt that the team did not have the big picture, and these issues would be closed in time (and that some of them could be ignored since they impacted a minor section of the consumers).
This continued for some time, with the interaction between the senior managers and the more vocal of the team members not really reaching a conclusion, and the team members started feeling that their valid concerns were not being addressed (and since they had been with the team for many years, they were also deemed as significant stakeholders). And then the matter got raised to the CEO. This resulted in the senior managers (or rather, the key senior manager) being let got after some time because of the huge amount of communications gaps that were showing up, and because the situation that was fraught with huge risk was not handled in a way that seemed like the logical way to proceed.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>