Being done with a task is simple, straightforward and easy to tell, right?

To an architect, being done may mean having the plans drawn up and approved so the construction work can start.

To a business analyst, being done may mean seeing the results of an accepted but uninstalled system.

To a developer, being done may mean completing the unit testing and passing it along to quality assurance, and maybe working a few defects.

To a software development manager, being done may mean completing installation in production and releasing any contract resources working on the effort.

To a business owner, being done may mean getting through the first month of production and seeing a stable, tuned system supporting the staff that is required to use a new or newly modified system.

To an operations manager, being done may mean skilling up the help desk, desktop support and operations staff in the operations of the new system and having a full suite of operations documentation customized for their operational environment.

To a financial analyst, being done may mean when the ROI has been achieved.

To a risk manager, being done may mean having a full disaster recovery test plan executed and all issues discovered remediated.

To an accountant, being done may mean the system is fully depreciated and off of the books.

To a project manager, being done may mean all tasks on the project schedule are completed, the project documentation is archived and all administrative work complete.

To a lawyer, being done may mean any and all liabilities in applicable contracts have been relieved.

So maybe coming to agreement on what being done means to a development effort deserves some discussion in the early stages of the effort. I think it’s invaluable to help guide the progress and manage conflicts during the effort.  What do you think?