Your worst enemy is scope creep. The learning curve works for you and it works against you. It works for you because people start to function as a team. It works against you because as people learn about the functionality of the system or other solution you are putting in, they get ideas.

And they generate questions and suggestions for improvements and changes that they didn’t think of in the requirements definition and scoping phase. Don’t laugh, it will happen to you, too.

It is also true that life goes on outside of the project, business conditions change, people leave, others arrive and the organization has to deal with this. It can’t be ignored and won’t go away. You may have to accept changes, but formalize the process.

Make it clear what is out of scope and the consequences to the project time line, budget or whatever if the proposed changes have to be made. Start using change orders right from the start.

You are especially vulnerable if you take a slippage. You will hear things like: “While we are doing this thing A, it would be silly not to do this other thing B, too.”

Fight back. Every change you make introduces the possibilities of further errors and new problems which will consume time and resources to resolve.

You have to work towards keeping a defined and contained scope so that it is clear what you will be delivering.

If you fall into the accommodating pattern of indiscriminately agreeing to changes, you will be doing yourself and your sponsor a disservice. You will also be late.

dot Require a formal change procedure to change scope and get sign off by sponsor