Catherine,

Your decision to pull back and concentrate on your core product line is wise. Companies often run into problems when they attempt to grow their products too quickly. It's very common in business to find oneself in the position of having to set aside, at least temporarily, plans for new products.

Enough has been said, rightly or wrongly, about the Stones and the expectations which were set but not met. I'm sure you feel, to some extent, unfairly treated by some of your customers. That's only natural. You had high expectations of your own and are probably wondering where things went so wrong.

As I see it, one problem you've repeatedly had is the desire to end development and push out a release when the product really is not ready for public use. The episode with the Stones is an excellent case study.

From your comments, I gather the kernel of the project was planned long ago. Originally, it was planned to be a display item; but at some point you decided to switch to a puzzle and prize. That should not have been a problem except, during the late stages of development, I gather, you decided to make further changes.

The fact that you considered any change at all, so late in the development cycle, indicates that the project had not sufficiently progressed even then. While that change certainly pushed the development process even further behind schedule, it seems apparent the process was running late even before the change. I say this because features, which you discussed early on, even with the additional week, were not ready. In addition, as you admitted, there were additional problems with the Stones, even up to the last minutes before released. In fact, it sounds like you finally had to decide to ship "as is" simply to come in prior to Midnight, barely avoiding another slip in the schedule.

This is an example of what we call "feature creep". It's not an uncommon phenomena, and it often causes problems. In the case of the Stones, there seem to have been several problems even before this last-minute change.

The way most try to prevent feature creep causing undue problems is to set a "feature freeze" date, usually about 1/2 to 2/3rd of the way through the development phase. This allows the development team time to complete any required changes made prior to the freeze: allowing all features to be ready when the product goes into testing.

My recommendation is that you take a hard look at how projects are scheduled and the tasks considered in those schedules. You need only look at the Stones to see the results of setting schedules too aggressively.

I suggest you take stock of the episode, use it as a learning experience, and look for ways to improve your internal processes and procedures to to ensure the schedules leave sufficient time for programming delays, testing, and quality assurance.