1.         Introduction

This document describes the steps to be considered for the development of a new computer system. Not all steps are necessary but all need to be considered. The processes are depicted in the sequence that they should be undertaken. Emphasis has been placed on aspects of system development in an in-house development situation. Some comment has been made on the procurement and use of software packages and the outsourcing of activities is included.

2.         Definition of a Computer Project

A project is the activities carried out for the creation of a computer system and involves people and limited resources that are planned, executed and controlled. Each and every project is unique in that it has never been done before. The activities required for project development include the application of knowledge, skills, experience, tools and techniques to create a system that meets the needs and expectations of the stakeholder and users of the computer system.

A project is a temporary activity (only done once) that has a lasting result. The project has a definite beginning and a definite end.

3.         Overview of Steps - SDLC

SDLC stands for Systems Development Life cycle and these are the main activities that are undertaken for the development of a computer system.

3.1            Submission

The stakeholder presents an idea to the Steering Committee involving the development of a computer system.

3.2            Steering Committee Agreement

Nominee provides a presentation to the Steering Committee. The Steering Committee decides GO or NOGO and where the project fits in with other priorities for other projects. Appointment of Project Manager takes place, if other than the I.T. Manager. The decision whether to seek a package is made.

3.3            Function Specification

The stakeholder or User representative, working with a knowledgeable computer development person (Business Analyst) documents the scope of the system required. This is written as a system definition of wants. This is a key document as it indicates the scope of the project and any special characteristics that are needed. The Function Specification is a non-technical document and indicates what the computer system will do and the interaction with the users

3.4            Steering Committee Review

Reviewed by the Steering Committee to acquire confirmation to proceed. The functional specification indicates scope, cost elapsed time and operational affect on the organisation.

3.5            Requirement Specification

This is completed by I.T. (Business Analyst) using the function specification as the scope of the system. The requirements are complete in all detail and indicate user processes as well as what the system is to do. Every data field is described. Every calculation is set out. The technical designer works from this document alone and if anything is not mentioned in the requirements will not be in the system when completed.

Following this step their is a further refinement in the accuracy of estimation and deemed to be in the order of 25 %. This task takes up a further 15 % of elapsed time and about 15% of the cost.

3.6            Technical Design

Carried out by the technical designer and reviewed with the Project manager, Requirement specification writer and the users of the system. On completion of this stage, the screen designs are completed, report structures are drawn, program specifications are completed and data base design documented. Accuracy of estimations are now plus or minus 15%, and a further 10% of project time used along with about 10% of the total cost.

3.7            Programming

Completed according to standards. The programmer does not write test data to check the program. Completion is when the program is syntax free. Usually many programmers can be utilised at the same time. This reduces the overall time on the project. Accuracy for completion now down to 10% and this step uses up about one third of the elapsed time and 45% of the cost.

3.8            System Testing

These are the tests that the designer carries out. The designer carries out system testing as each program reaches a syntax free situation.

System testing is for the designer to ensure that files are updated according to specifications and that data appears on screens and reports appropriately. Appropriately means that the figures and detail shown look in the right ballpark. The designer is not meant to test the system out exhaustively, that is the job of acceptance testing. The designer does not spend any time on cosmetics regarding screen layouts or print layouts. Naturally if the screens and printer formats are very bad they will need to be fixed, but not minor variations.

Special test data is used.

Should there be any errors the designer decides whether to fix the program or pass back to the programmer to fix. In any case the programmer requires feedback.

3.9            Acceptance Testing

3.10          User Procedures Guide

The user procedures guide is best developed during or immediately after the testing process and consists of documentation required by Users to be able them to operate the system. The User Guide includes business rules and policies.

3.11          Implementation

3.12          Post Implementation Review

A post implementation review is normally conducted some months after implementation to identify aspects that are not working or being used as planned. The opportunity is taken to identify possible improvements to the system.

3.13          System Development Life Cycle (SDLC) Diagram

4.         PROJECT Initiation

This is the entity that provides the resources for the project. Usually this is a Senior Manager of the organisation with the project being endorsed by an entity such as the Company Steering Committee. Resources mean money and incudes such matters as the cost of purchase (of software, hardware) or the cost of the use of people (staff and contractors). The sponsor has a responsibility to consider costs and compare the cost with the benefits of the system taking into account any risks involved. These risks could be from a development practicality point of view (pioneering) and/or the risk to the organisation once the system is implemented (organisational change). The sponsor, prior to development of the system, needs to be aware of and consider all operational implications especially those that affect personnel.

There needs to be sufficient information for the Steering Committee to understand, in the broad, what the system will do and consider the level of risk to the organisation and any risks in the development process, such as pioneering the use of new hardware or software. The submission indicates the benefits to the organisation and indicates that the user can provide the necessary support for the development of the project. The Steering Committee decides whether to proceed and whether to develop in house or to search for a suitable software package.

Changes to the way the users work will also be indicated under the heading of operational implications.

The document can be prepared as what is wanted without indicating what the solution may be. That gets "fleshed out" at the function specification stage.

The estimate of cost at this stage is in the order of plus or minus 50% accurate.

5.         Function Specification

The content of a Function Specification is the responsibility of the sponsor. The Project Manager or I.T. Manager often provide assistance in the development of the specification The Function Specification depicts what the system is to do in some detail (WHAT not HOW) and effectively sets the boundaries (or "blue print") for the project. Should the system be outsourced to a third party for development, the Function Specification is a vital part of the contractual arrangement. Performance standards may need to be incorporated in the Function Specification, especially if the development of the system is outsourced.

The above forms assist in the level of detail required. On completion of the function specification the I.T. Manager or Project Manager should be able to estimate the cost to an accuracy of 35% plus or minus. At the completion of this step about 25% of the total project time has been used along with about 12% of cost. Getting the function specification right is crucial and takes some time.

6.         Internal or External DEVELOPMENT

6.1            Contracts and Outsourcing

There are different levels of outsourcing and each requires different treatment. However, no matter what level of outsourcing the Project Manager keeps tabs on progress on both the outsourcing entity and the work that is carried out internally. Sometimes the whole project is outsourced. However, using the completed system is not outsourced! It would be wise and patently sensible for the receiver of the system to test it prior to implementation. Outsourcing the testing task is not practical. The contents of the function specification should not be outsourced either, and indeed, this document is useful as part of the contract.

In summary, it is unlikely that the following tasks would ever be outsourced:

·         Submission

·         Function Specification

·         Testing and Acceptance

Which leaves the following tasks that can be outsourced, in part or in whole:

·         Requirement specification

·         Technical design

·         Programming

·         Implementation User Guide

·         Training

and also, if applicable:

·         Hardware procurement

·         Software acquisition

·         Package software acquisition

Outsourcing does not absolve the responsibility for a project away from the Company appointed Project Manager (who, of course, need not be an employee of the organisation).

7.         Package or Tailored SYSTEM

7.1            Make or Buy Considerations

Should a company develop its own computer system or buy one "off the shelf" (a package). There are pluses and minuses with both approaches in terms of cost, time and applicability.

The main motivation for purchasing software is to save money, shorten implementation time and, dare I say, reduce the thinking needed as to what should be included in the system. "Why reinvent the wheel" is a common catch phrase. But then we might want a pneumatic tyre rather than the first type of wheel invented?

Are the above motivations for the acquisition of a package borne out in practice?

Sometimes.

The cost of a project has two main parts, one the development cost (including new hardware and software, if needed) and operational costs. Care needs to be taken that if the package does not quite fit the organisation that the additional operating costs to accommodate the system do not significantly outweigh any perceived savings over an in-house developed system.

The time for those activities marked with an asterisk below is not saved with the purchase and implementation of a package.

Submission *

Function specification *

Steering Committee review *

Requirement specification/Reference Manual

Technical Design

Programming

Testing *

Training *

User Guide

Take On *

Implementation *

Cost of changes for the life of the system (as the organisation changes)*

Overall the package should be a lot cheaper as the development cost of the system by the vendor is amortised over many purchasers. Even allowing for the vendor profit margin. From the purchasers point of view some items will be more expensive if the package route is chosen over an in-house developed system.

These are:

Time taken in the review and the checking out of various alternative packages. In other words, the first package found (if any) does not necessarily stop to review of packages process. Where many software solutions are investigated, this takes elapsed time and each has to be learned and compared with what is desired. Some compromise is always needed and some evaluation process is conducted.

Implementation costs are likely to be higher than an in-house developed system as the package is likely to operate in a different way from Company preferred practices (i.e. minimum disruption). If the package is parameterised so that it can operate in many different ways, the tools for this need to be learned and the appropriate coding undertaken. Sometimes this is a non trivial task, especially for a non-trained I.T. person.

Cost of Change will usually be higher for a software package. That is assuming that the vendor of the package is prepared to change the package for the company's unique requirements.

There is another area that needs to be considered. If the package is to operate alongside tailored systems, some data interface is usually required to be written. This can be complex. Should the I.T. department wish to upgrade the operating system version some negotiation (and cost) is incurred with the software vendor for them to upgrade their software to accommodate the new operating system

These matters need careful consideration prior to the decision to go "off the shelf" package route.

As far as elapsed time for the project is concerned, when one takes into account evaluation time , parameterisation and learning, then possibly not as much time is saved as is expected.

Of course, the software package is likely to have ideas in it that might not otherwise have been thought of. These can be very beneficial to an organisation.

7.1.1         Activities Saved by Package

Requirement Specifications

Since we are dealing with a system that already exists there are not likely to be any requirement specifications, but should be a reference manual that doubles as requirements and User guide (without policies and business rules).

Technical Design and Programming

This is all part of the package. Screen layouts and style are preset, and may not be the same as other systems in use.

Testing

The system should work as specified. The user department should, however, check the system out with their own data. No mistakes should be found in the system as written, but problems may be encountered in misinterpretations of the processes of the software package. The testers would no doubt want things to be changed here and there, but this would not be possible.

Preparation of Training

The vendor would have all the training material ready to be used.

User Procedures

Part of the reference manual. The user would need to add policies and business rules.

7.1.2         Activities Created by Package

Software Evaluation

Having prepared a function specification the search for a software package can commence. There is no guarantee that what is wanted will be found. Some tolerance is needed in that it is unlikely to get an absolute match. Of course if the software sought is common and somewhat discrete (such as Payroll or General Ledger) many packages will be found. If however, the requirement is a one off then it is unlikely that a software package will be found. Time and money is expended on the search with no certainty of a desired result.

Changing Company Processes (probably)

As indicated above a direct match is unlikely and Company processes may need to change. On top of that if integration is needed with other systems that the Company uses some addition connecting software will need to be written.

7.1.3         Activities Unchanged by Installation of Package

Submission

The need for the system will have to be demonstrated as for any other type of system.

Function Specification

This will be needed to define the system being sought.

Testing

To make sure the package performs as understood and documented.

Implementation

Training and Policy manual will be needed along with training and so on.

Hardware Procurement

May be necessary.

8.         Planning

As part of the planning process each process step and activity in the development process is ascertained. Staff allocation for each task is determined and estimates of actual and elapsed time are worked out. This plan shows task dependencies, i.e. the requirement to complete a task prior to another one being able to start. Also planned task overlaps are established.

The project is broken down into logical discrete parts each with a clear beginning and end. Often this is on a sub system basis. It is important to consider sequence of development to facilitate testing process. The overlap of tasks is necessary so that the project gets competed in the shortest possible elapsed time.

There are many ways of documenting such a plan. A critical path network computer program is very useful to indicate all the tasks and their dependencies along with times. Software usually includes facilities to produce Gantt charts and to forecast completion date based on percentage completions. These kind of charts can be compiled manually, but this approach is very time consuming.

8.1            Accuracy of Cost Estimates

As the project progresses and more is done and more is known about the HOW of the system the level of accuracy of the estimates for the project gets more accurate. The diagram above gives some indication as to how "rough" the estimate is at the submission stage. Plus or minus 50% is a large margin. But this is reality and those charged with the responsibility of giving GO or NOGO accept that the cost can vary by this amount. As the project continues the cost is refined and those with the authority are informed so that a GO decision might be revised to a NOGO situation.

By the time the Function Specification is completed the parameters of the system are clearly defined. The estimate cannot be completely accurate however and there are several circumstances that can affect this. If new hardware or software is being acquired there is an unknown factor as to how it will perform and operate. Learning is involved and the ease of use is unknown. Therefore some contingency factor in the estimates is included and could be as high as 35% plus or minus. Accuracy of estimates can be affected by the level of knowledge of the team being assigned, or the availability of key user persons for testing and user guide preparation. Another matter that affects cost is the speed at which "management" are prepared to make decisions. Lengthy delays or procrastination cost money.

After the requirement specification is completed the contents of the project are laid bare. The activities that can make estimating difficult are the quality of the designer and programmers and the speed of acceptance testing by the users. 20% plus or minus should be achieved easily.

When technical design is completed the likely cost accuracy is at the 10% level. Programmers experience and acceptance testing can improve or drag the estimate out.

Once programming is finished the project is almost completed. Estimate to plus or minus 5% at this point is to be expected.

8.2            Percentage Cost of the Activity

By this is meant how much of the total cost is likely to be spent on each section of the Systems Development Life Cycle. These percentages vary from project to project but provide some guide.

Function specification - 12%

The amount of time spent on this activity is directly correlated to the decisiveness of the person responsible for deciding content. The more decisive and knowledgeable the responsible person is the quicker the function specification gets completed.

Requirement specification - 15%

There is a lot of detail needed in the requirement specification and a high level of decision making in how the system operates from the user point of view. The system detail is cohesive and complete with all contingences of actions (potential and real) catered for. Time is spent with the users as alternative methods are conceived and discarded. This all takes time.

Technical design - 10%

For the most p[art the designer can work exclusively from the requirements. There are no further system decisions to be made. No alternative content methods are debated. In practice there are always some things that can be improved as the technical designer works through the requirements. These are controlled by the Project Manager else costs and time can "run away". Users are involved to the extent of approving the screen design (on a screen based system). This is usually not a big task as the user interface methods would have already been worked out in principle.

Programming - 40%

No further system content decisions are made at this point. The programmers work from the content of the program specifications and the standards set down. The programming task is laborious and demanding. Many programmers can be employed at the same time. Programming can commence as the programming specifications are completed to save on elapsed time. This is a high cost activity.

System testing - 4%

Minimum system is carried out by the system designer and is limited to ensuring that data files are updated when they should be. The technical department should not get "bogged down" with testing. With adequate standards and methods the system will be in good shape by this stage.

Acceptance testing (and corrections) - 10%

This is a user responsibility and they have to be vigilant. A separate book is needed to describe the art and science of effective testing.

User Guide - 3%

Not a step by step book but one that explains principles and business rules for the use of the system.

Implementation and Training - 6 %

This activity needs careful planning and excellent execution for the new system to be used affectively.

8.3            Percentage Elapsed Time of Activity

The percentages for elapsed time do not correspond with costs. This is because (as in programming and testing) more than one person is on the activity and another is that elapsed time is used up when waiting for user management to decide content and so on.

Function specification - 25%

Requirement specification - 15%

Technical design - 10%

Programming - 33%

System testing - 2%

Acceptance testing (and corrections) - 10%

User Guide - 3%

Implementation and Training - 4 %

The above percentages are included as a rough guide only and varies from project to project.

9.         Hardware Needs

10.       Software Needs

11.       Requirement Specification

12.       Technical Design

13.       Programming

14.       Testing

14.1          Testing

Testing is a complex and exacting task. There is a proper process to be followed and normally testing cannot be left solely to a User department and will need help. However, users need to be involved and it is at the completion of testing that the User accepts the system. The proper approach is for an experienced system tester to lead user representatives through the process. Test planning can commence as soon as the Requirement Specifications are completed, and should start then.

This is the process to ensure that the system, as developed, performs to the needs as laid down in the functional specification plus any agreed updates. This is where the system is checked out for complete accuracy. Someone experienced in the task leads the testing operation and the involvement of Users is desirable.

All testing is carried out on specially prepared data, not live (real) data. Live data tends to check the same path over and over whereas special test data is designed to check out every "nook and cranny" of the system.

Testing is done as a dedicated task. Testing in conjunction with a normal days work is ineffective because errors are made and the testing results are too slow for the I.T. group to maintain continuity of system knowledge.

Testing involves the development of scenarios. Testing is more than testing that data is processed properly. A whole series of events is conceived, test data prepared and input and results checked out.

14.2          Types of Test Data

Special data is used, designed to test all likely “paths” of operation of the system. Testing is meant to check out a variety of probabilities. The test data should be designed to check out simple things first concentrating on the system being used as planned. The data should get more and more complex with the final testing aimed to “break” the system by the input of unexpected data.

Screen layouts and operation are checked very carefully. The common user interface across all programs is checked out. This is important.

Printed details are checked out. Real data or converted data is not used except for a final speed or volume test. Special data is prepared with predetermined results.

A parallel run with an old system is not recommended. A parallel run doubles the workload on a user department and more attention will be paid to the old system (real) than the new system and errors will not be found. Reconciliations would be difficult because usually the operators have input different data to the two versions of the system. Parallel runs are not encouraged.

14.3          Source Material for Test Data

1.             Functional Specification (needed for test plan)

2.             Requirement Specifications (needed for test data)

3.             Screen Layouts (needed for test results, input screen layouts could be needed if data input structures are complex)

4.             Print layouts (needed for test results).

5.             Computer that has target programs (and required support programs) for testing, but no data).

14.4          Test Plan

A list of things and scenarios that need to be tested is written down and is developed from the Function Specification. The test plan is used as a checklist for the development of detailed test data and results.

14.5          Test Data in Detail

Data to be input and the results expected from the computer system are fully documented. Different time frames are tested to check brought forward details in the system from one day to the next. If there are special end of day, week, month and year these activities are checked out. Programs are most likely to go wrong when ”end” values are input. For example if different logic is used depending on the value input, the program is most likely to fail either on the maximum value and then the minimum value. All data is written out on special input forms and adhered to. Results are pre calculated manually. These are compared against what the computer produces.

Inputs

Input details are identified using the Functional Specification and the Requirement Specifications. Forms are developed and all data entry is written down. The objective here is to provide sufficient data to cover all aspects of the system catering for the different ways the input operators are likely to conduct their activities.

Screen Inputs

The screens are thoroughly checked to look and behave the way that was expected in response to inputs. This includes:

Position of data on the screen

Error messages displayed

Help messages provided

Mandatory field checking

Etc.

Screen Enquiries

Information displayed as required with correct totalling and right data.

Reports

Content is checked to be correct

If automatic checked to make sure that the report is produced automatically.

Etc.

Downloads

Downloads are checked to be correct based on any selection criteria and in format wanted.

14.6          Testers Responsibility

The tester has to say whether GO or NOT GO for implementation and use of the system.

Test data and results are not retained at the completion of testing. This data serves no useful purpose. In the event of future testing for changes fresh data is prepared.

The test data and results may be retained if auditors have decided to check out the testing programme.

14.7          Fault/Improvement Reporting

Any queries are provided to I.T. during the testing phase indicating the following:

a.             What is wrong?

b.             What (the results) should be?

c.             Steps taken (keystrokes, data entered) leading to the query

d.             Evidence of the problem

Any error found is logged on a sheet along the lines of the example below. These are provided to the systems analyst (the requirement specification writer) who reviews them prior to passing onto the technical designer.

Following correction of the system, often the data that was input previously leading to the problem to be corrupted in some way and deleted from the system. Therefore, it is not unusual for testing to commence at the beginning again and again. In any case, following corrections the item that has been corrected is testing along with other “connected” areas as the correction may have caused errors elsewhere

15.       Data Conversion

16.       Take-on

17.       Training

18.       GOING LIVE

18.1          Criteria for "Going Live"

The criteria consists of a set of factors to be considered and agreed to prior to going live with a new system. All those involved in the project should be prepared to accept part of the responsibility for the "going live" decision. The Project Manager allays any fears, if any, with the participants to the decision.

The table below indicates a possible scenario for this decision process.

18.2          Going Live

This would include any take-on and training.

19.       Procedures Guide

20.       Project Management

The Project Manager is responsible for getting the required system completed and operational by the due date. There are many activities to make this happen, the important ones being; planning, monitoring progress and resultant action, product quality and being decisive to project needs in a timely fashion. Other qualities and activities are covered in depth in this document. The Project Manager is the controller for the development of the project, usually from project start through to completion.

This aspect of Project Management is vital. Without an effective system of monitoring there is little chance that the Project Manager has any real grasp of when each group of tasks (phase) of the project will be completed and hence when the project as a whole will be completed. Without monitoring, scheduling would be an ad hoc process. Control of the development process would become chaotic and non-existent. Decisions to remedy slippage would not be able to be taken in a timely manner.

The component parts of monitoring are:

Firstly, the separation of cost and elapsed time occurs. These two items are not the same.

Cost is the amount of actual time spent on an activity and elapsed time is the duration and actual calendar time of the activity. Each needs to be monitored.

Elapsed time is used for scheduling and establishing, on a regular basis, when a project will be completed. Cost is just that, the actual cost (usually in dollars) of the project. These components are used to develop the plan against which the monitoring takes place.

In the development of the plan some knowledge is needed of the people that are available as "permanent members" of the project (for the duration of their involvement) and their skills and aspirations. People like the opportunity to develop their skills so in the planning, wherever practical, people’s’ skill boundaries need to be pushed. In the planning process if the skills available are not known the Project Manager uses average level of skill.

The plan looks for continuity of a person's activity. Stop-go for an individual is avoided. Involvement needs to be continuous and useful.

The plan shows tasks/activities in the sequence of development and indicates as much overlap as is possible to keep the overall elapsed time of a project to a practical minimum. Time is allowed for management decision-making in respect to content, or any other matter. Recreational leave is built in. Some contingency for sickness is worthwhile. Where gaps do occur in an individual's activities on a project, non-critical work is created for that person. This could include such items as research or personal development.

20.1          Cost Monitoring and Actions

Each task/activity to be monitored for cost needs two items of information. One, an estimate of how long is likely to be needed (in hours not calendar dates) for the task. The other, a record of actual time taken by ALL THOSE involved in that activity (not just the person allocated to the task). To get this information the members of the project fill out timesheets. For planning purposes each eight hour day 6 hours of effective work is accomplished. Thus, a timesheet for each "normal" working day is unlikely to exceed six hours on specific project duties. This “lost” time is due to such activities as coffee/tea procurement, non-specific communication between staff, toilet breaks, telephone interruptions, attending to Email, enterprise needs (meetings and general communication), human resource matters, unexpected technical difficulties, informal assistance to others and so on.

Thus, the estimate of cost prepared at the outset of the project (as updated, perhaps, as the project progresses and more information is known), can be compared (weekly or fortnightly) with actual cost. To do this the Project Manager needs to know what has been spent plus what additional time is needed to complete the task. This is achieved by asking the member of the project what further work needs to be done on a task and agreeing with that member the likely further time needed to complete the task. The project member is not permitted to subtract the time spent so far from the original estimate. This is a natural temptation and is not useful in the monitoring process. The monitoring concept is not there to penalise anyone for taking longer than the estimate but for knowing how inaccurate the estimate is. If there is a significant variation the whole planning schedule may need to be revised.

If, based on this monitoring process the cost looks like it is going to be exceeded, obviously putting in extra time is not going to reduce the estimated cost (time spent plus estimated time to do). The cost will probably increase even more because more mistakes tend to be made resulting in re-work, as the working day gets longer. If the cost estimate is crucial to be maintained then costs can often be controlled by putting a more experienced person on the job. A Project Manager should never flinch from replacing one person with another in these circumstances. However, the management of this action needs to be done with care. Sometimes inspecting methods can reduce costs for future activities and get the overall cost back on track.

20.2          Elapsed Time Monitoring and Actions

This is the process of establishing the actual calendar time when a task will be completed and is based on what is to be done not what has been done. Matters that can cause a variation from the estimated completion time is when the actual time is expended. If a person starts late then the task is unlikely to be completed on the data as planned. Sickness of a project member can cause the cost to be unchanged but the task fall behind on a date basis. Should a task fall behind schedule this is likely to have an impact on dependent tasks.

What action should be taken if it is established that the task is likely to finish late? Note that the reason for the monitoring process is to provide early warning of a potentially late finishing task. It is not useful to find the task is completed late after the estimated completion date for that task is past. It is too late to take corrective action.

Behind Schedule Actions

Just what are the Project Manager’s options to get the task completed as predicted and announced?

First of all it should be noted that the schedule of task completions are often based on estimates at the beginning of the project. If the development is behind schedule the most likely cause is the estimate is wrong. However, this cannot be used as an excuse to delay the predicted completion of the project. The Project Manager is really stuck with the overall completion date, Therefore castigating the individual for not meeting a time schedule imposed by the Project Manager, probably based on scant facts at the time, is not the way to get the job done as planned. A characteristic of estimating is that some jobs will be underestimated and some will be over estimated. But care is taken not to assume if some early jobs have been underestimated that others will be over estimated and thus "catch up" on the overall completion date. The Project Manager weighs up these matters (and others) prior to deciding whether to take any action or not. No action is a decision in just the same way as taking action.

What are the Project Manager's options?

More hours – additional work in (previously) unscheduled time. This usually means evening/night work or weekends. Evening/night work is dangerous as the person works alone and is probably tired. Mistakes are more likely to occur and the person has no one to consult if needed. Working alone in this fashion can make the bad situation worse. Weekend work is not much better as support to the individual is not available. On top of that if the extra hours need to be charged the cost goes up. If additional mistakes are made necessitating rework the cost is going to go up as well as putting the schedule further behind. The rework could affect others too. So extra hours is not a good way to get back on schedule. What other alternatives are available?

Add more people to the task - again this usually makes the situation worse. Why is that? One reason is that the new people have to learn what is needed and also an addition level of communication occurs. Experience has shown that the more levels of communication there are between people there is more chance that things will go wrong. Thus, more people mean more communication and greater chance of things being misunderstood with consequential delays while it is sorted out. This also causes the cost to go up. It is a dangerous practice to add more people to a project/task in the expectation that things will get back on track. Usually the reverse occurs.

Provide more detailed experience – this could be in the form of direct assistance to the person on the task that looks like being behind schedule or removal of the person from the job and allocation to a more experienced person. The cost may go up but the job could get finished in time. For this decision to be effective action has to be taken quite early on for the task in question. The more experienced person is likely to get the task completed to the desired/required quality too. This strategy is most likely to work in the programming function. The reason the person is running behind schedule could be that the program is more difficult than the person has experience for. An experienced person can get things done very quickly. The difference between and excellent programmer and an ordinary one can be as much as 5 times. This option is considered by the Project Manager as part of the remedial process.

Reduce the size of the Task. Surprisingly, perhaps, this is a good option to analyse. Often some aspects of the task can be left to later. The problem is deferred for the time being. The heat is off. The task may be able to be simplified in some way, reducing the time needed. Perhaps the time can be made up elsewhere. Perhaps a later task has more time allocated to it than is actually required. The project gets back on schedule. The Project Manager weighs up these alternatives and makes the decision.

Of course, prior to any option being taken the Project Manager has to find out what is happening and attempt to locate the cause of the scheduling problem. This is carried out personally, and not left to an intermediary. The Project Manager's involvement is essential at these times.

The Project Manager decides what to do when it seems likely that no matter what action is taken a task will be finished later than planned. In any plan there is task dependency. As one task gets delayed this can snowball through to other tasks in the development of the computer system. This snowballing effect has to be stopped. The task that is likely to cause the problem is closely examined. Those parts that are needed first so that other tasks can proceed as planned are identified and reassessed. Some reordering of tasks may need to be required. The plan is changed. The Project Manager is on guard and vigilant and is prepared to change plans to get the overall job implemented as planned.

There is always a way.

20.3          Project Manager has no Direct Control

The Project Manager has little control over the amount of time it takes the Sponsor, User management or Enterprise management to make a decision. These decisions occur at key checkpoints, such as the completion of the function specification and requirement specifications. However, if the Project Manager makes it clear to management when these decisions need to be agreed to and the affect on the implementation timetable if delayed decision making is speeded and timetables are usually met. However, the Project Manager needs to be prepared to change the timing of plans and resource needs quickly and to let involved parties know in the event of such a delay.

20.4          Management of Content and Cohesiveness

At all times the Project Manager has sufficient knowledge of the content of the system to avoid mutually conflicting requirements to be incorporated into the system. Additional requirements often occur when a person has an idea for an "improvement". In isolation looks good but in context of the whole system does not work. The Project Manager is on guard for these kinds of common situations. Resolution of such matters can on occasions be quite time consuming and the time is not usually included in the estimates.

20.5          Allocation of Duties

The Project Manager, ideally, is responsible for who does what on the system. However, is not always possible to get the right skill at the right time and support is given where needed. That is, on occasion the Project Manager does a job personally that ideally would be done by someone allocated to the project.

20.6          Methods

The process of making sure all understand the methods to be adopted for the development of the system is the Project Manager's responsibility. From time to time the Project Manager will need to work with team members to create new methods and these are then taught to other members on the project.

20.7          Communication

20.7.1       Project Information

The Project Manager, amongst other things, has the responsibility to coordinate and inform. All involved in the project need to kept up to date with any changes of content, difficulties encountered (and overcome) and development progress. The methods to achieve this communication include meetings, verbal, presentations and written information.

One of the most difficult aspects for a Project Manager about a new project is getting to grips with its content. The Project Manager need not know detailed technical aspects but certainly the content or WHAT the system is planned to do. There is always detailed documentation but the Project Manager needs to have the whole detail of the project in his/her head as without this it is difficult for the Project Manager to make correct and consistent decisions in a timely manner.

20.7.2       Progress Against Plan

A method of monitoring is required. Are we ahead or behind schedule? As things are progressing is the system likely to be over or under cost estimate? This information is provided on a regular basis to the sponsors, user departments and developers of the project.

Should any special action be deemed necessary the Project Manager has the responsibility to take this action and make sure that the variation takes place. All this information is communicated to those on the project in a timely fashion.

20.7.3       Clear Assignments

Each person on the project is told what is expected from him or her and when their assigned task is scheduled to be completed. Communication to them can be in written form or verbal as long as the assignee is clear on expectations. Of course, the progress of each and every assignment will be monitored on a consistent and regular basis and reviewed with all members of the development group.

20.7.4       Verbal and Written

Both means of communication are used. Verbal first followed up by written confirmation is an effective approach. The Project Manager needs to avoid being dictatorial and include/encourage the opinions of others.

20.7.5       Singly and in Groups

Both methods are used as appropriate. Singly is used where some level of confidentiality is needed, else in groups so that all know expectations of themselves and others.

20.7.6       Brainstorming

Should some new ideas be required a brainstorming approach is often very effective. The problem or matter for review is stated and attendees are invited to put up thoughts. These thoughts are not judged or considered until that section of the process is completed. It is important that ideas can be put forward in an unfettered way. A seemingly “stupid” thought from one can trigger off another to have the brilliant thought. The ideas are placed up for all to see as the ideas are presented. The brainstorm leader will need to provoke ideas by the input of various possible trains of thought.

At the end of the brainstorm each point is considered.

The person who put up the thought is not put down in any way. This is vital in a brainstorming session.

Decisions are made at the end of the session.

20.7.7       Writing Style

All documentation is prepared prior to an activity/task being undertaken. This documentation is written in the present tense. The reason for this is that the document becomes the reference manual for the system. This applies to requirement specifications and program specifications. Thus, "is" is used rather than "will be".

The document is not instructional with the verb at the beginning of the sentence. For example, "Calculate the total expenditure ...." is written as "The total expenditure is calculated as .....".

Jargon is avoided unless commonly used by the whole enterprise. Computer jargon is avoided wherever possible, and if used, an explanation is given.

The same word is not used to describe two different things. If a new report is being produced similar to one that went before, it is given a fresh name.

20.7.8       Meetings - Process and Style

The following points are relevant should a meeting be held.

Each attendee has a reason for being at the meeting and this needs to be clear to them. There are two main reasons for attendance at a meeting, either to make a contribution or to obtain information emanating from the meeting that is needed by that individual.

The meeting is led and controlled so that time spent by those attending is effective. The meetings start on time, whether all present or not.

Items covered in the meeting have decisions made as the meeting progresses.

Sometimes meeting appear to reach a stalemate where two or more people take a stand and will not shift. An adjournment for 5 minutes usually is sufficient time for on or both of the parties to be able to shift ground without losing any face.

Minutes may be useful. They do provide a good for follow up or for audit purposes. All decisions should be documented and distributed as well as action points.

All members of the meeting are encouraged to participate and nobody is allowed to dominate, including the chairman.

Attendees are stopped from wandering off the point or undue repetition or being defensive.

Emotional statements are curbed. Random emotional utterances (REU) are identified and exposed. Statements made are required to be backed up by fact.

The exception event is not be taken as the rule for decision purposes.

Thoughts from all are encouraged with the chairman deciding and explaining the course of action. Consensus is immaterial. Voting is not required. The chairman makes the decision on the facts presented to the meeting.

The meeting decision is binding to all attendees. If an alternative decision is found to be desirable a fresh meeting is convened.

Not all decisions are made by meetings.

The Project Manager sets up a weekly pattern of meetings so that attendees know what to expect and are prepared. The Project Manager does not shirk from searching questions even if some embarrassment might result.

20.7.9       System Rules, Constraints and Behaviour

These are debated and documented and be obeyed by all. This specially applies to screen processing and general atmosphere of openness of discussion. Power play has no place in the development of a system.

20.7.10     Project Team Rewards

Sufficient reward is recognition of work done and achievement generally. A statement, privately or in public of well done is usually sufficient reward.

Bonuses or other monetary reward are not usually necessary.

An end of project get-together is often worthwhile. The people may not work together again.

20.7.11     Communication to Management

Best if this kind of communication is in writing and not too detailed. Key factors should be included only. Communication kept at a high level and detail is provided to management if requested.