Urgent vs. Planned

April 27, 2007

Have you ever managed a product that is a mission critical application for your customers? EDA (Electronic Design Automation) software companies like Synopsys, Cadence, Magma, and a bunch of smaller ones (like the one where I work) are pretty good examples . Their products dealing with physical implementation of chips are extremely mission critical for many big chip makers, e.g. AMD, ATI, nVidia, Intel, Broadcom, NEC, … Anything goes wrong with the product (crash, inaccuracy in calculations, inability to handle complexity of new generation designs) the whole chip implementation flow is stuck and the chip maker is loosing 100’s of thousands of $$ every day. Designers jump in to continue the design work manually (which is error prone and takes much longer), the situation suddenly becomes extremely stressful. And who is to blame? Of cause the software vendor. So the pressure is up for the EDA vendor, the critical bugs must be fixed ASAP!

Now, imagine you are a product manager or a development lead at such a software company trying to implement your agile iteration (or a waterfall release plan). You planned, prioritized, estimated, and started to work but here comes a stressed out and unhappy customer with an urgent problem. Lets even say you have such urgent requests every day from several customers. How do you cope with all these critical requests without jeopardizing the content and deadlines of your agile iterations and incremental releases?

Some people may say if you get so many critical requests that your team does not have time for any iteration/release work then may be your software is still very immature and you should postpone any new feature development for a while. I would actually agree with that. There are periods of product life cycle when you do work in such a mode, addressing only the most critical issues every day. And it may continue for a while. But how about a case when your industry specifics are such that even with a reasonably mature product you still get a flow of critical requests? May be it is not overwhelming all the time but it is present and always affects your planned work.

I am wondering how your team deals with a situation like this and if you have a process in place to deal with it? Please share your thoughts.

Bellow I am describing an approach that seems to be working pretty well and I know a number of companies that use it successfully. Our product management solution YOXEL SW also includes support for it.

1. You need to have a “shield”, a support team or a professional services team. These are the people that hear about the customer problems first and try to filter out those that can be addresses by acceptable workarounds (without involving your development team). They have to be technical experts and somewhat good negotiators when it comes to the urgent customer requests. They are the people that connect your product management and the customer when a commit date or a certain priority is requested by the customer. Such a shield together with PM makes sure that critical priorities are not abused and required support time from your development team is kept at a reasonable level.

2. You divide all incoming requests into two flows: critical customer urgency and non-critical customer urgency. Critical requests are the absolutely urgent ones for your customers, they have been filed by your support team after proper assessment of the situation and in agreement with PM. The non-critical requests are the rest of requests with high, medium, low urgency for your customers. Once you have done this division each category of requests is dealt with in a different manner.

3. For the flow of the critical requests you set-up a special process, usually a meeting (weekly or every other day) and a web/wikis page with all the critical requests listed by product. Key representatives for your development, PM, support teams attend the meeting and work out the tactical details of how to handle these requests. The outcome of the meeting should be the exact order of execution for the list of the requests. The web page is updated with that exact order too. The development folks should be able to look at the page and be clear which request they should work on next. This work takes priority over any other scheduled work.

4. The other non-critical requests are scheduled for iterations/releases. The trick here really is to monitor the resource load required for critical requests over time and figure out what it is on average. It could be that a developer responsible for component A gets into this urgent support mode %50 of his time, developer for component B never gets any critical requests, and other developers have to do it only 10% of their time. Once you have figured out this, you can factor in these %’s for your estimates during your iteration/release planning.

Of cause the flow of critical requests fluctuates all the time and load associated with it sometimes reaches 100% but from my experience this technique has been pretty helpful. Of cause provided that you are not understaffed.

In agile terminology the #4 step is pretty similar to figuring our your team velocity, only, you monitor the load from the opposite angle (planned work). After a few iterations you start to see how many of those planned requests your team is capable of delivering in a typical business situation.

2 Responses to “Urgent vs. Planned”

  1. […] out my other post on this topic: Urgent vs. Planned I guess what SCRUM calls ‘velocity’ should help you deal with these situations. You […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: