Appendix A – Description of project stages

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
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
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..

One thought on “Appendix A – Description of project stages

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.