Vijay PanditaManaging Director| OptSoft IT Busniess Solutions Pvt. Ltd.New Delhi, Delhi, India
Every time right after the successful project closer, client/customer will come back with their new wish list. I wonder why this wish list is not evident when we execute collect requirement process. Is it the nature of business or performing organisation is missing something and need to learn. Saving Changes...
Last minute change requests could happen for a lot of reasons, and I think the reasons would be mostly be with the requesting organizations and not so much with the performing organizations.
As for how to address them, I would take them on a case by case basis, and evaluate what makes most sense - accept the change now even if it delays the project; postpone the change, deliver on the pre-planned scope and deliver the change as a later phase; reject/cancel the change; or some other hybrid approach Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
You have to take into account two different types of requirements: project requirements and product/service/result requirements. What matters for the project manager, what you have to take into account into collect requeriments are project requirements. What you are dealing with I guess are product/service/result requirements. Project requirements are the basement to determine project scope. Project requirements are derivated from product/service/result requirements but this ones are in the field of business analysis, not project management. Saving Changes...
Vijay PanditaManaging Director| OptSoft IT Busniess Solutions Pvt. Ltd.New Delhi, Delhi, India
Thank you Sergio and Samuel for your valuable comments. I believe "wish list" Syndrome will never stop, no matter how good we collect the Product/Project requirements. Saving Changes...
Nearly all projects will see some change. If you are able to assess the impact of change, and make a rational decision in a timely manner, it can make a difference.
In some occasion changes are accepted without any challenge, that may lead to cost and schedule overruns.
Stick to the scope that was agreed. Validate it with client, and handover.
After project closure, you may introduce change, in subsequent releases time to time. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Vijay: the best thing I ever read to explain this are the "Lehman's laws of software evolution". While they are created because of software you can apply them to each type of product. Saving Changes...
Adding my two cents. Be mindful of the change requests which are disguised as issues/discrepancies. If you don’t differentiate them well enough they can result in scope creep. Saving Changes...
After Project Closure, but before project acceptance by client.
All depend on industries, nature of the change and specific factor.
Many question come to mind.
Was the project base on filling a requirement (result ) or a determine scope? (see Sergio Reply)
Is it a change in legislation?
Is it timely feasible? Cost?
Is it legitimate request?
Should it be a new project? Saving Changes...
