Lock for Tickets

Hi all,

from my pov Tickets are not a requirements and scope management. Hence I wouldn't "missuse" this for this purpose.

If we have requirements, we collect them and assign them to a target version. But as every body knows, scope is dynamically and so in the course of our change management, we have to add new or to change or to reject requirements. Locking the target version is possible most of the time in a very late point of time - mostly during sign off process before go live. Locking requirements is very good as it is already implemented.

Means, for us the proposed suggestion doesn't bring any value - even it seems a good approach

Please correct me if I'm wrong.

Klaus

"My proposal is to fix the list, because scope is first list of items. It seems to me more accurate than "locking" tickets : with locking tickets, a ticket could be added in the scope..."
- This is exactly what I am talking: the list is fixed (and approved) but it can be silently modified by modifying the content of the items in the list (Tickets). So, you cannot add ticket because the list fixed in scope but you can modify the one of the tickets, so the scope actually will change!!!

It is in the approved document (project proposal)