Home > Project Management
This document aims to provide some guidance on project managing the implementation of consolidation software and other small systems. Small projects are often not formally managed because applying the normal methodologies used for large projects is too time consuming.
Large software projects are normally broken down in to phases such as planning, analysis, design, build, testing and implementation. Formal documents are produced by each of these phases and are reviewed and signed of before proceeding to the next phase of the project. For the implementation of financial packages, and the development of systems using Rapid Application Development tools such as Visual Basic this approach can be very inefficient. The formal documents are time consuming to produce, are generally difficult to understand and often do not give the user a full understanding of the system being developed.
Despite this we believe that small projects can benefit from formal project management. The key, as with large projects, is to divide projects in to phases and clearly define in advance what will be achieved in each phase. Phases allow progress to be monitored and changes to be identified and managed. This prevents the scope of the project expanding, which often causes problems. However, time can be saved by not preparing detailed written specifications. Instead system outputs and testing can be used to determine if a project is ready to proceed to the next phase. Phases, tasks and deliverables for a typical consolidation system implementation are given below.
Assuming you are purchasing a new package:
- Prepare a list of all the tasks involved in operating the system. Some ideas are given below:
- Install at subsidiary sites.
- Input results at subsidiary sites.
- Transfer results to head office.
- Consolidate subsidiary results.
- Eliminate intra group investments and reserves.
- Eliminate intra group transactions.
- Create a new subsidiary.
- Purchase a subsidiary.
- Transfer a subsidiary.
- Sell a subsidiary.
- Print reports.
- Make a list of the packages available. The Directory page lists the main consolidation software suppliers.
- Produce a shortlist based on your key selection criteria e.g. functionality, price, supplier market share, local support availability etc.
- Perform a more detailed evaluation of the short-listed packages. We would recommend performing some hands-on evaluation. Ideally, install all the short-listed packages on an evaluation PC in your office. Suppliers will probably be reluctant to allow this. A typical objection will be that training is required to use the package to its full advantage. However, their real reservation is usually that it gives you a better chance to understand the product and reduces their control over the sales process. We would also recommend you verify all key assurances given by suppliers.
- A document recommending a consolidation package.
- Determine what information is to be collected and reported by the new system. Try to produce a comprehensive list. Adding data after this phase requires more time and can reduce the quality of the final system. Existing systems are generally the best source of this information. Any existing system is useful even if it is spreadsheet or paper based. The system's current users should know if any additional information is required.
- Configure the package with accounts/lines to be collected.
- Business users should review the system and if possible test individual subsidiaries.
- Print outs of the system configuration showing the lines of data to be collected approved by users.
- Build a full prototype system that performs all the tasks identified in the planning phases.
- Business users should review the system and if possible test multiple subsidiaries and the key tasks identified in the planning stage.
- Approval of system functionality in prototype by users.
- Build the final system.
- Write all documentation.
- Write all training materials
- Design rollout procedure.
- Final system for formal testing.
- Training materials.
- Rollout procedure.
Testing is very important. The quality of the final system is determined by the quality of the testing and this is very time consuming. Plan to devote as least as many man days to the testing phase as to the design and build phases combined.
- Prepare a detailed test script that covers all the functions that the system must perform. The list of functions prepared in the Planning phase can be used as the basis of this.
- Perform tests to confirm that the system can perform all these tasks. If possible the people who will eventually use the system not the people who are implementing it should perform these tests. This is because they have the best understanding of their business requirements and its helps uncover any misunderstanding between users and developers.
Though this phase is at the end of the project an outline of the test script can be prepared during the planning phase and can be used to help select a package.
- A completed test script showing that all the tests have been successfully performed.
- A document from the system's users accepting the system and authorising rollout of the system.
- Rollout system to all operational unit.
- A fully operation system.
Most people associate project plans with Gantt charts and imagine a specialist package such as Microsoft Project is required to produce a project plan. However, a project plan for a small project can be produced using a spreadsheet. Indeed the use of specialist project management software should probably be avoided as days can be wasted learning how to use the software. To view/download a project plan prepared using a spreadsheet follow these links xls/zip.