Approach change with extreme caution. All projects will change; the final product will differ from the original spec, but the better the project plan, the less change is normally required. Treat late-in-the-day, good ideas with considerable caution. Once you are seen to alter anything, everyone will want to add their two cents. If you allow change to proceed unhindered, it is only a question of time before you will find yourself going round in circles.
Where an idea is of radical significance, consider its effect on your architecture, functionality, procedures, scheduling, and budget. Get everyone to sign off on the consequences before you make a move. The best practice is to leave those ideas for a subsequent version.
Note Management often feels it has the right to make changes, and so it does. However, by the same token, everyone else has a right to demur.
If circumstances beyond the company's control have altered substantially since the plan was agreed upon, it is not a good idea to introduce arbitrary changes. The most therapeutic thing you can do is bring all the affected parties together, explain what has happened, and ask for help. After all, everyone involved shares the same objective. Between you, you should be able to work out the best way to handle the changes. This is far better than announcing summarily that fewer programmers are going to be employed without allowing the remainder extra time. Pressured managers don't always appreciate the side effects of their decisions.
It is much better to sit down together and talk through the implications. There may be an acceptable way to take out the thorns. If there isn't, agree only to what you honestly believe you will be able to deliver. If, for any reason, you are overruled, be courteous, calm, and log your reservations. Explain how it may compromise delivery; then hope like hell that you are wrong.
Was this article helpful?