Confucius is quoted as stating: “In all things, success depends upon previous preparation—and without such preparation there is sure to be failure.” This is the basis for all project planning.
A project may be defined as a temporary endeavor undertaken to accomplish a unique purpose, involving several people performing interrelated activities. In IS terms this would normally involve the bringing together of a variety of user and IS skills to work together in order to develop new or improved information systems. IS projects cover the specification, supply, and installation of “off-the-shelf” sys- tems and the development of bespoke software (i.e., software uniquely developed for a specific purpose). As with any other project- based development process, the primary focus is the development of a quality system, as specified by the user, on time and within budget. Each individual project will be unique in as much as the system being developed will be unique and individual combination of resources put together to achieve it will be unique. The project may be seen as a finite, pre-defined set of activities to lead to a specific out- come. It is finite in that it has a fixed beginning and a fixed end. It is predefined in that each individual face of the project can be planned in advance and allowances made for changes during the development process. It is a set of individual activities that can be individually con- trolled but which must be coordinated in order to ensure that all areas fit together appropriately so that the project may achieve its specific outcomes.
Computer projects, either involving the development or acquisi- tion of new systems or the maintenance of existing systems, consume resources in terms of money, manpower, materials, machines, and methods. Many of these resources will be drawn from cross- departmental boundaries and will involve a mixture of skills and disciplines.
Although project control is designed to minimize the risk of non- achievement of the project objectives, there is always a degree of uncertainty throughout the project. At the commencement of the pro- ject, this uncertainty will be high because the final outcome may be seen only in outline. As the project progresses, the degree of uncer- tainty reduces overall and specifically for the next phase of the pro- ject. In order to ensure that delivery risk is minimized, a project sponsor is required to handle the primary role of direction setting with a project manager handling task scheduling and performance monitoring. These form the fundamentals of project management. Aligned to these are the processes and practices. “Soft” issues, such
as teamwork and leadership tend to be emphasized less partly due to the small size of many IS projects. Typically these processes and prac- tices are formalized in a specific methodology. Originally these methodologies were predominantly focused on technical issues, while nowadays they focus more on the organizational benefits and man- agement activities.
Managing people, information, and resources as they proceed through the project development cycle involves tasks such as:
■ Aligning the development of the project strategy with the spon- sor’s (and other stakeholders’) business strategy
■ Defining the requirements (in a testable manner)—these lead to specifications and solutions being designed and developed ■ Defining and managing the project scope, schedule, resource
requirements, and budget (ensuring this represents optimal financing)
■ Installing and progressing project control systems ■ Procuring/inducting resources into the project ■ Building effective project teams
■ Exercising leadership
■ Ensuring effective decisions and efficient communications
In any project management activity the most critical component is an effective project manager who works with the project sponsor and others in determining and delivering the scope and objectives of the project. In determining the scope and objectives, the project spon- sor largely dictates services and performance required. These will serve as measurement criteria to determine the effectiveness of the development process. All projects consume resources and the quan- tity of resources in terms of manpower, skill levels, costs, and timescales may place limiters on the degrees of effectiveness achieved. In other words, the requirement for efficiency will have a mitigating effect on the degrees of effectiveness of the project as a whole. It is the balancing of the need for efficiency while maintaining an effective development process that is the project manager’s most difficult task, because it is in this area that trade-offs must be negotiated between the project sponsor and the suppliers of resources. Because projects develop over time as business requirements change and skill levels improve, resource budgeting is an iterative process whereby nearby
expenditures should be predictable in detail but long-term expendi- tures of resources can be led by as much as 100%.
In essence, project management is “the application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholder’s needs and expectations from a project.”1
IT projects normally follow a common development cycle. Partly because of the special challenges posed by the intangible nature of software, and the importance of getting user involvement in a struc- tured manner, this process tends to be both consistent and dominant. There are various versions of this: the spiral, the waterfall, and the vee. In his definitive work in 1976, Archibald2defined the project life
cycle as having identifiable start and end points and passing through six distinct phases, namely:
1. Concept 2. Definition 3. Design 4. Development 5. Application 6. Post-completion
This led to the development of the waterfall cycle in Exhibit 11.1 where it can be seen that each activity “cascades” from the previous activity to lead ultimately to fully deployed information systems. In this model the difference is that the major activities overlap signifi- cantly. The major difficulty with this model is software development’s need to progress iteratively is not catered for because each project remains with the identifiable start and end points.
In 1988 Boehm proposed an iterative spiral model for the devel- opment and enhancement of computer software.3 Boehm’s spiral
involved four major functions, namely: next stage planning; deter- mining objectives, alternatives and constraints/evaluation of alterna- tives; identifying and resolving risk issues; developing and verifying the next level product. These functions started with the development of a baseline product and then moved through several iterations until the final product was implemented.
An alternative development based upon the waterfall cycle was suggested by Fish4 and is known as the vee cycle, and it follows a
tates the formulation of business requirements, which will usually incorporate explicit user requirements. These then lead to the defini- tion of systems requirements and specifications. These allow the for- mation of the architectural design of the software and coding then creates the individual components of the system, which is then tested “up” the waterfall against the different levels of specification. From a control and audit perspective this form of systems development is considered the easier to audit because at each level there are standards to match against as well as there existing a separate audit stage.
Within an IS environment, this approach would typically involve: ■ Discovery is the point in the process when the IS or user area finds there is a market for a specific system. This phase is brief; there are few decisions to be made.
■ Requirement is when the user can write an outline system speci- fication that states: “We need a system capable of the following functionality A, B, C . . .” At this stage a feasibility study may include an assessment of the technical feasibility of this system, its costs, and potential benefits.
EXHIBIT 11.1 Waterfall cycle
System Requirements Software Design Analysis Program Design Coding Testing Operations
■ Functionality is when the user can write a detailed business spec- ification that states all of the business, operational, and control requirements. At this stage the feasibility study may be revisited to re-assess the technical feasibility of this system, its costs, and potential benefits.
■ Design results in the detailed system specification that specifies file layouts, screen design, the required hardware and software environment, networking requirements, and any potential limita- tions or requirements for new hardware and software to be acquired.
■ Sanction is the phase wherein board approval for design and expenditure is sought prior to the commitment of resources to the longest part of the process.
■ Construct is the purchase or development of the software includ- ing the coding, unit-testing, and documentation of the application systems.
■ Check is used to verify that what is installed is what was intended to be installed as set out in the design documents. Also, that installation was done according to those design documents. This verification is a critical element of the ISO 9000 standard. ■ Review involves testing sub-systems, usually with a test material
to ensure that the intention of the system has been met. This phase
EXHIBIT 11.2 Vee cycle
Discovery User Requirements Functionality Design Sanction Close-out Audit Review Check Construct
tests collections of hardware and software (systems) against the design intent and the interaction of integrated systems.
■ Audit is the verification stage, which may be deemed to be com- plete when the system can meet the functional, operational, and control stipulations of the detailed business specification. ISO 9000 defines this as validation, where tests are applied to see if the customer’s requirements are addressed in reality.
■ Close-out is the stage wherein the cycle is completed by ensuring the installed product matches the need identified during the dis- covery phase.
As can be seen from this model, the left-hand side of the vee shows the planning stages, while the right-hand side indicates the implementation or “doing” stages.
Over and above the methodology selected, project managers require competencies in multiple areas. From a task management per- spective they need to be able to manage the project scope, cost, dura- tion, and quality. At the same time they need to be able to manage their human resources with good communications while simultane- ously ensuring risk is controlled and that the whole project is ade- quately integrated.
Many of the quantitative tools discussed in Chapter 9 such as Gantt charts, PERT charts, and critical path analysis are used by man- agement to control time and budgets. Overall the management areas of planning, leading, and controlling remain fundamental to the development process.