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 4

In this series, I have been writing about the problems that arise when a product (deemed very significant for the organization) are near release. In the last post (deferral of bugs near the release date), I talked about the rate of deferral of bugs in the end game, and how this time of the schedule means that bugs are evaluated much more carefully to review whether these need to be fixed or can be deferred (and there is a lot of review to ensure that bugs are not let through which could cause a risk to the release).
In this post, I will talk more about some of the measures that management should be having in the organization in order to ensure that there are no sudden surprises and information moves up the organization structure to the management chain about the current status over the period of time. If such a process is not in place, then the organization will keep on running into cases where they don’t know about problems that may be causing a risk to the release schedule of the application, and will be hit with those problems when they least expect it. And you certainly don’t want to be in such a position where the senior managers don’t know about potential problems and suddenly come to know about it. In such cases, the responses that you get from the management chain may be of managers trying to get a quick handle on the situation and how to address these problems, which is not at all a nice position for the team to be in.
So how do you prevent the problems that has been outlined in the previous post ? Well, the first and most important way is to ensure that there is a process for status discussions up and down the management chain to the level of the team involved in the actual execution of the application development. In addition, there should be a clear way for the managers involved in the chain of command to be able to highlight risk points and do this in such a way that more serious issues get moved up quickly up to the level of senior management. This starts right at the team level. The team should be having a regular status discussion where the current status of the application development (including the dependencies) is discussed within the management structure of the team and if there are issues that are deemed significant and could imperil the release schedule of the team, those should be raised up the team manager upto the next level of the structure, along with a background on the issue and potential mitigation steps. If there are no mitigation steps or is out of the control of the team (with external dependencies, or other issues such as resources), these also need to be emphasized along with suggested steps about what is needed to be done.
In addition to this, the team should be sending out a regular status report that is highlighted to senior management with a summary of the top issues and whether the team feels that there are issues that could cause problems. A combination of these steps at the various parts of the application could ensure that senior management knows about the issues and is not surprised when these pop up.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

More about this in the next post ..

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>