(Ha! There's a profound statement!)
Release dates change, hardware configurations change, performance results change. This is all just fine - within reason it's just part of doing business (and not just software - happens in other industries, too!). This is fine for the team that's involved in the work. They know the project in great detail and are constantly immersed in the current state, current spec, current date, current performance. But....
There's a whole other group to consider: those who are peripherally involved in a project. Think upper management, support, sales, other development groups, etc. They need to know your dates, configurations, performance results, but they're not constantly immersed in it. I've noticed that in general these groups tend to remember the first thing they hear. So things change, and you tell these groups, and then a week later, you hear, "wait, I thought it was on [the old date]?"
So how do you keep people who are partially involved up to speed?
I don't know of a foolproof way to do this, but there are some things that help:
- No verbal commits. Make sure it gets written down somewhere.
- Keep things in one visible place. Have a project page available to everyone and make sure it's kept visible and current. Having a meeting with upper management? Use the project page as your notes. Having a meeting with support? Walk through the project page.
- Keep a separate history. Once things change, the second question is "why?" (right after question 1: "What is changing?"). Make sure your project page contains a discreet list of what changed and why. I've gone as far as having a page with:
Release Date: March 20 (why?)
And the "why" is a link to a page showing the history of the old date, the cause of the change, and the new date. It helps show that this is change for a reason rather than change for change's sake.
- Get your story straight. Make darn sure you know what you're talking about before you spit out a date or a number. And make sure the entire core team agrees with you. Inconsistencies will simply be rejected and not remembered, or thrown out as a probable mistake.
Ideally, your first reporting remains accurate to the end of the project. In reality, that doesn't happen very often at all. Make sure that as things change you're keeping everyone on the same page, and doing it in a way that encourages the core team and other affected people to know and remember the most recent state.