On-time, thoroughly tested, and on budget: pick two

I'm sure many of you in the the corporate would know the age-old conundrum of the post subject. It's difficult to deliver all the right fixes on the original schedule and budget for pretty much any project. No matter how much we expect the unexpected there will always be even more unexpected issues to derail the schedule.

So how do you decide when to ship? We are performing a major rewrite of a component for our upcoming release and discovered an existing issue that would be very costly to fix. Now, we have three options: (1) fix it poorly, likely breaking something else in the process, (2) fix it correctly and delay the release, or (3) don't fix it in this release but slate it for future work.

My manager and I have opted for number three after careful consideration. The driving factors were the value of the other improvements to the component even without this fix and the time constraints on other work included in the release. As soon as slipping the timeline became a non-starter we were left with one very dangerous choice and one safer. Since we're working with patient data and using the information to drive patient care, safety wins almost always.

How do your teams decide when to hack around, when to slip, and when to delay?

Comments

Popular posts from this blog

Managing to Lead

Process Consensus

Cert-ifiably IISane