How do limit the application behaviour for change

As chanage is inevitable, how would you prevent change in a specific period in order to make project completed.

Comments

[Benny Leung]

1. Make some prototype ensure no difference between you and client
2. If user want more function, place in Prase 2
3. If user want add into current prase, trade off some a little bit hard function, because you not enough time estimate new function how difficult

Sorry of my English

[Ben]

Do you mean we should force user to accept the function as soon as possible?

[Benny Leung]

No, make sure user know the business logic + calculate formula then accept, because some business logic only they know, they will help you too much, and they will know why need more man day

[Ben]

In Most Cases, Users do not know what they want to do so. It is the worst case. You may say User must know it and thus the project can be completed.

However, in real case, the situation is far from ideal.

[Benny Leung]

Yes, you can ask user some real situation
Then new system, will bla bla bla, because bla bla bla
Don't let user think they should use which function before know business & system operate, they will create some useless / conflict logic waste our time.
Not everybody has systematic and logical mind set

[Francisco Quintero 🇨🇴]

By saying: "if we change this now, then.."

• we'd have to delay X requirement delivery
• it'd need more time to be done
• this other things also would change

Both the customer/management and development need to embrace and accept change. Sometimes it keeps them from asking changes, sometimes they just don't matter.

It's my approach.

[Kristian R.]

Depends upon how your project is managed and how you interact with your customer(s) I suppose. In an agile understanding, it would be good to embrace change early - as it might be better to change a project rather than completing something that apparently might not meet changed requirements anymore. I'd really try going through small iterations, coming closer and closer to what the customer needs and, in each iteration, talk about requirements, effort needed to implement them - and whether feature X or Y is really required or worth the effort. But again this really depends upon your customers expectations and your contract. ;)