This might seem like it’s purely about optics, but I do think being familiar with some terms to communicate the need to understand out the system you are working on as a consultant or employee while being professional about it can help a lot.
A couple of such terms that I use[0] are “knowledge transfer” and “[initial or in-depth] audit”.
Typically I’d be communicating with a non-technical decision maker on the other side, and if there’s an existing codebase (or third-party systems that need integration into what I build) I may request:
1. An initial audit before I agree to the larger body of work. Audit will require access to systems in question and the ability to talk to the people in charge of or using them. Initial audit may already warrant an NDA, but whether I can accept further work will ultimately depend on the outcome of this initial audit. The deliverable of the initial audit may be a brief document or a scope/statement of work.
2. Knowledge transfer or in-depth audit. If knowledge transfer is impossible, during the previous step I’m supposed to get a good understanding as to why (does the previous owner refuse to communicate? which factors have caused this situation?), and instead of knowledge transfer allocate billable time for an in-depth audit. There would be a separate deliverable of this step as well, which would include some diagrams or documents describing the systems in question. A separate deliverable is useful both to myself and to the customer (if they choose to hire someone else to work on this), and makes it clearer what the customer is paying for.
[0] If there’re better alternatives, I’d be curious to hear (though I’m not holding my breath, responding to this thread 2 days late).
A couple of such terms that I use[0] are “knowledge transfer” and “[initial or in-depth] audit”.
Typically I’d be communicating with a non-technical decision maker on the other side, and if there’s an existing codebase (or third-party systems that need integration into what I build) I may request:
1. An initial audit before I agree to the larger body of work. Audit will require access to systems in question and the ability to talk to the people in charge of or using them. Initial audit may already warrant an NDA, but whether I can accept further work will ultimately depend on the outcome of this initial audit. The deliverable of the initial audit may be a brief document or a scope/statement of work.
2. Knowledge transfer or in-depth audit. If knowledge transfer is impossible, during the previous step I’m supposed to get a good understanding as to why (does the previous owner refuse to communicate? which factors have caused this situation?), and instead of knowledge transfer allocate billable time for an in-depth audit. There would be a separate deliverable of this step as well, which would include some diagrams or documents describing the systems in question. A separate deliverable is useful both to myself and to the customer (if they choose to hire someone else to work on this), and makes it clearer what the customer is paying for.
[0] If there’re better alternatives, I’d be curious to hear (though I’m not holding my breath, responding to this thread 2 days late).