If you’re developing a product, for yourself, and you’ve created your own requirements, chances are you’ll change what it’s required to do, whilst you’re actually developing it. This is only natural. As you spend more time on a project, you should gain a better understanding of what you’re trying to achieve and how best to achieve it. This holds true when the product requirements come from somebody else. Developers are often asked to develop a product, based on a set of loosely thought through requirements, only to find that the requirements change, when more thought is given to the idea (often as a result of the developer asking for more information because the original requirements don’t make sense).
Because requirements always change, it is not reasonable to use this as an excuse for late product delivery. In fact, the original release date should have had time built into it to accommodate these changes. In reality though, it is extremely difficult to accurately predict how much time to factor in for change. Therefore, the real problem is not that requirements change, but that requests for change are poorly managed.
It should be fairly obvious that as requirements change the delivery date for a product may be affected. Even seemingly small changes can have a large impact on a delivery date. It is vital that you understand what impact a change would have and be able to communicate that to whoever the request originated from. Of course, at this point you’ll be able to produce your project plan, which will identify what needs to be done, when, and by whom, and will form the foundation upon which negotiations will be made. You do have a plan, don’t you? If not, you need one. I’ll discuss project planning in future posts, but for now remember that when requirements change, once you’ve already committed to a delivery date, it’s a VERY BIG DEAL, and you need to manage it carefully.