This post is in responce to Kerri Rusnak's comment about my article on negative feedback.
I do think the six positive pressures are a result of traditional waterfall methodologies. On a traditional waterfall project, the IT managers will attempt to control change by getting the business sponsors to sign off on the requirements and then use a change control process. The aim of this is to transfer the risk (and blame) of the requirements change to the business users.
This is particularly important when the development takes place across a contractual boundary. The software vendor will demonstrate great amounts of effort (evidenced through thick and detailed documentation) to ensure the requirements are right before development starts. They will then charge for any deviations from the requirements. I have heard it said that some software developers respond to tenders by putting in a low, loss-lead, bid for satisfying the initial requirements, knowing that they will make the real money from the change control process. The nature of waterfall projects with their change control processes is that they do not care if the requirements are correct because the change control process will pick up any changes.
Change control processes are really change prevention processes. I know from personal experience that you want the business to sign off on the requirements so that development can start. As a project manager you are under pressure from your IT management, who set bonuses and pay levels, to deliver according to the published plan. When the users want to use the change control process, you always give them the choice of having the change or hitting the deadline (like there was any chance of that because your IT management already halved your delivery schedule). From the IT departments perspective, Any delays to the project due to change control are the fault of the business for changing their mind. IT have washed their hands of change by getting the users to sign off the requirements. The business do not see it that way. I remember one instance where I asked the business head to sign off the requirements. He agreed but said that he reserved the right to change his mind at any point.
Posted by chrismatts at August 21, 2004 7:24 PMI'm gonna step in here and ruffle some feathers. I think waterfall is totally built for change. What's wrong wtih change in a waterfall process? For example: Let's say a project is in what is typically considered the "construction" phase. The user tells the business analyst(BA) a new report is needed. The BA adds the report to the requirements. The requirements are reviewed by the designer who designs the report out. Then the report is added as a construction activity.
Posted by: Peter at December 10, 2004 8:11 PMI dont speake.
Posted by: ddleb at July 22, 2006 8:20 PM