Management : There are always late changes

	Gieno  Management : There are always late changes
	I hate late changes. Walking on water and developing software from a specification are easy if both are frozen. But late changes break it. Many traditional project management approaches are designed to limit and control change, but others embrace it. All project management approaches must nonethelessdeal with change. Imagine building a new chair to replace one that wore out. It is clear what is needed, who needs it, what they'll do with it, and what kinds of stresses they'll put on it. You can find people who have made chairs very similar to the one you're about to make. Software isn't like that. In most software projects, no one has created exactly this product before, and even if others have, the people on this project haven't. Additionally, the people who will use this software haven't use it before. Even though they might have a good idea of what they want, they don't know to specify requirements because:  They don't know all of their requirements. Their requirements will change as they try early versions of the software or competitors' products. They will discover new ways to use the software and imagine other uses they wish they could make, but can't(yet). Different stakeholders have different needs, which are often in conflit. No one document can articulate all of the conflicting and potentially conflicting requirements and balance them. Moreover, as components and tools are built and skills are learned, the expected costs to provide a given benefit will change, making it more or less easy to satisfy someone who wants that benefit.