I don't know about you, but I've been on multiple conversion projects where the scope changes – especially during development. It's not that the requirements were not gathered properly; the requirements changed!

The business changes and people change, so the requirements can change on large conversion projects. I like to create scope documents for any project I am doing. Within this document I like to state exactly what business questions I'm solving for in this conversion. Even more, I like to state what I am not solving for in this project.

Here are some examples:

1.  This project will convert history. If so, how many years of history? Converting historical data from one system to another is some of the hardest data mappings/programs to write. Has this information been explained and expectations set for our business users and project stakeholders?

2.  The project stakeholders are extremely important. Are they aware of the project? Are they involved in the project?

3.  Include what value this project brings to the business (as a whole). Does this project blend well with the goals for the company?

4.  Does the project team contain people who know the company? Do they know where the data and systems reside? Is the team complete with designers, developers and data quality personnel?

5.  Does this project include fixed bid efforts?

6.  What areas in the company does this conversion project affect?

7. Is this project small enough to be successful? Is it too big to be successful? Can the project give value to the company in iterations?

While a small document, scoping is a very important function for any project.