Programmers are by nature solution providers. They like to help people and like to show results. "Look, it works!" Often they start coding as soon as they are asked for a solution; they even start planning structures while the problem is being Explained. Here are the problems with this approach: The person giving the requirements may not have all the information you need. There may be more stake holders in this project; do you know who they are? Is what you are picturing what they are picturing? When there are changes (and there always are) how will you deal with them? When does the project actually start? How will you assess your progress? How do you know when you are done? Unfortunately for the programmers, the stake holder asking for this solution does not care about any of these things, but the programmer (if he wants the project to succeed) is required to. A set of planning meetings can solve this problem. Programmers hate meetings almost as much as they hate system crashes; Programmers should consider these crash prevention meetings. When assigned a conversion project, try to gather as much information as possible right there. Who else does this affect, who is authorizing the time, who knows the most about the system, etc? These kinds of questions prepare you for the next step. Set up a meeting. In this meeting you should prepare a conversion plan as best you can with the information you have gathered from these people individually. You should make the point in the meeting request that if they do not attend, they are agreeing to whatever you decide. Make sure you have filled out a conversion worksheet which you can get from our tools. There is sometimes a temptation to change the format of the sheet - resist it. This worksheet, and its twins developed around the globe, have been honed through years of experience and countless conversions. Every alteration to the worksheet that I have seen has led to problems with the conversion it was altered for. Send a copy of the worksheet to everyone who is invited to the meeting two days before the meeting, then a send it again the day before the meeting. When they arrive, the will probably be reading the worksheet for the first time as they come in the door. Discuss the conversion by asking them what they want it to do? Once you know what they want, you just might be able to give it to them. (That's success.) Continue to have meetings until everyone signs the sign-off page. Once you have sign-off, then the project starts. Be pro active, be ready to show something within days of the project start. The easy way to do this is build the structure in the Package Builder and populate all the Note properties. Use the Package Builder to generate documentation at anytime in HTML. This documentation is fully indexed, has all the Objects listed as steps, and the value of the Properties in it. Print it out and you have a list of all steps with notations. This can be use for reference and progress reports. From our experience we have learned to Plan half as much time to testing as it will take to create package. If it will take two weeks to create allocate at least 1 week to testing. Issues and new ideas invariably come up that will use some of this time to implement and retest. When you complete all the steps, your conversion is ready for final testing. Once your conversion is complete, deliver the package, and the generated HTML documentation to the customer / boss / department head for future use.