This is a general description of the phases of a project. These are not specifically tied to business intelligence projects, but could apply to any IT project.
This section was initially developed as supporting information for an article about Problems associated with the IT cycle. This perspective has led to some stages being consolidated, though there are other reasons for this approach which are also covered in the text below.
See also Appendix B – Resources required during different project stages.
1. Feasibility
A business need is articulated by management, identified by IT, or (ideally see Business is from Mars and IT is from Venus) a combination of both. Initial strategies for meeting this are drawn up – e.g. extend existing system A, build system B, buy system C, or integrate systems D and E. Sometimes more than one path can be taken to meet the need and which is the optimal one is not immediately obvious. Resource is required to evaluate options and pick the best. Even when the way ahead is clear, it will still be necessary to consider a reasonable level of detail about the tasks involved; only in this way can the cost, duration and payback of the project be estimated. Normally during this time, a business sponsor is identified, assuming they were not the person who brought the need to IT’s attention in the first pace. After this preliminary work, normally carried out by a relatively small team, management will be presented with a proposal and a decision will be taken whether to start the project or not.
2. Preparation
Once approved, the staff required to discharge the project can be hired, or transferred from other teams. This process can take some time, often several months. Some work can commence with the resource dedicated in the feasibility stage, but this is likely to be at a low level during the early stages of this phase, increasing as more resource is applied. Typical tasks undertaken as resource is ramped up might include: –
| • | Drafting of project mission statement / charter |
| • | Establishment of project office |
| • | Agreement on make-up and responsibilities of steering group |
| • | Development of project communication / marketing strategy |
| • | Review and refinement of project plans and cost / benefits drawn up during feasibility |
| • | Agreement on initial project milestones |
| • | Recruitment |
| • | Induction of new staff |
| • | Building of extended business teams to be involved in various project stages |
| • | Validation and extension of business requirements identified during feasibility |
| • | Further analysis of design / development aspects of project |
| • | Selection of development tools / methodology |
| • | Consideration of technical architecture and infrastructure |
| • | Deliberation on eventual deployment / training approach |
| • | Liaison with other relevant parties |
At the end of this period, most project staff will be in place and have a fair degree of experience. A roadmap for the project will be in place and understood by both the project team and steering. The main development stage of the project can begin. Sometimes, project re-approval may be sought at this point.
3. Development / Testing / Deployment
This is probably the stage that non-IT people would be most familiar with – banks of staff cutting code, having this tested, fixing bugs, writing training manuals, giving internal classes in how to use the new system and so on. As has been commented in the main text, this stage would normally be split into its three component parts. Although these are different, there are two reasons for considering them as one: –
| a) | New best practice in IT methodologies suggests that development, testing and (to a lesser degree) deployment are seen less as sequential activities, but as an iterative process of improving the facilities in the hands of the users. As such, some of the distinctions between the different task have blurred. |
| b) | Although what the team does may change somewhat during this stage, resource will not vary dramatically, so when resource issues are paramount in the discussion, splitting up the components serves little purpose. |
Tasks going on during this stage would include: –
| • | Regular steering group meetings |
| • | Project communication |
| • | Ongoing project management |
| • | Completion of analysis |
| • | Design of application and data model |
| • | Technical specification of system |
| • | Initial build of database |
| • | Build of prototype applications |
| • | Refinement of prototypes |
| • | Unit testing by programmers |
| • | System testing by in-house QA |
| • | Bug fixing |
| • | User acceptance testing |
| • | Selection of training approach |
| • | Creation of initial training plans |
| • | Development of training materials, class scripts, manuals, on-line help etc. |
| • | Establish help desk |
| • | Pilot |
| • | Respond to pilot feedback vis à vis application |
| • | Respond to pilot feedback vis à vis training approach |
| • | Revise training plan |
| • | Deploy application |
| • | Carry out training |
| • | Provide initial hand-holding |
| • | Hand over system to support team |
At the end of this stage, the new or improved system has been deployed and successfully used for a period of time. All major bugs have been ironed out and there are no significant enhancement requests to be met.
4. Maintenance
It is seldom that an application attains full maintenance status, there will always be things that need to be done which are above and beyond simply making sure the system continues to function. However, often these types of changes become fewer with time and focus remains on such thing as: –
| • | making sure performance is not compromised as the application database grows |
| • | archiving old transactions |
| • | ensuring that interfaces work day-in day-out |
| • | taking account of changes in systems integrated with the application |
| • | administering user access |
| • | dealing with the support of new products or the production of revised documents (at the level where only minor application development is required) |
| • | adding new branches or countries (again at the level where only minor application development is required) |
| • | coping with upgrades to the operating system or development environment |
| • | fixing bugs (these tend to be less business critical the older the system is) |
| • | keeping user guides and other documentation up to date |
This stage will persist until one of the following occurs: –
| a) | a major change to the system is proposed and accepted as offering good business value |
| b) | the system is replaced with a newer application |
| c) | the system is no longer needed by the corporation |
Eventually the fate of all systems is that they are either replaced by something else, or are no longer needed. However many systems can be long-lived. It is not atypical for some systems to have life-spans in excess of 15 years..
[…] by, amongst other things, different resource levels (these stages are described in detail in Appendix A – Description of project stages, and the levels of resource required are described in Appendix B – Resources required during […]