Sieuthigiga

We Buy Your Business

Getting out of business is a process. The length of time required to complete the process is directly related to the complexity of the business, and the circumstances underlying the decision to get out. Planning how you exit your business is just as important as how you started it.

The exit process, timing of events; and tasks associated need to be tailored to the type and complexity of the business. Each case is individual because reasons for dissolution differ, and problems that arise are unique to each circumstance. The following checklist contains key elements that should be evaluated as early in the exit process as possible to eliminate pitfalls later on.

The process for exiting a business should include evaluation of the following points:

1. Engage Professionals & Consultants as Team Members.

2. Prepare a List of Assets & Perform a Physical Inventory.

3. Perform a Valuation of the Business.

4. Prepare Detailed Plan & Assign Responsibilities.

5. Release Announcements & Notices.

6. Conclude or Transfer Contract Obligations.

7. Dispose of & Transfer Assets.

8. Settle Accounts Payable & Debt Obligations.

9. Prepare Final Financial Statements & Tax Returns

10. File Articles of Dissolution.

11. Prepare & Issue Special Filings, Notices, Informational Returns, & Taxes.

12. Receive Tax Clearance Notice.

13. Close Bank Account.

14. Store Business Records

Software configuration management is intended to control the configuration of a software product or system throughout the life cycle of the product and that includes the project that builds it. Software development organizations that have been certified as CMM or CMMI Level 2 or above will have a robust Software Configuration Management process in place; all you need to do is to determine the activities, tasks, milestones, and deliverables your project must plan to be compliant. Project managers who don’t have the advantage of an established Software Configuration Management process will have to implement one as part of their project. The advantage of doing so is twofold: you maintain control of the applications, networks, and manuals that are compiled for the system and you establish a re-usable process that can maintain control of the system throughout its lifecycle. The process you leave behind can also be used by other projects. Not implementing some sort of configuration management process will lead to problems when you try to produce builds and patch the software. Typical of this type of problem is the software bug that was fixed by an earlier build recurring in a subsequent build, or the 1 hour build that takes days.

There are 2 ways to approach the issue of configuration management where there is no existing process. You can either make the definition and implementation of a process part of the scope of the project, or you can implement just enough to satisfy the needs of the project and leave the implementation of a proper process for another project. I suppose a third option might be for the implementation of a CMMI Level 2 program to coincide with your project but very seldom will the project and program schedules permit this. The purpose of this article is to provide some tips and tricks that will give your project insurance against sloppy configuration practices without overburdening it with unnecessary overhead.