Monitoring and Control of a Project

This chapter deals with unplanned events that can occur at any point during the project. Subjects covered are
y y y

controlling changes monitoring the project: anticipating, identifying and controlling risks monitoring changes to the organization.

In order to provide stability to the project, project agreements must be recorded, and any changes to agreements must be evaluated for their effects upon other agreements. These agreements should thus be recorded in controlled documentation [1], and when an agreement is changed, then all other agreements that are based upon that agreement must be reevaluated. In order to control controlled documents in the project, it is proposed that there be a change control board [1] to review changes. The change control board would include the overall project manager, phase project managers, representatives of workers, users, the data processing group and business policy management, and perhaps a change control administration manager to update schedules and provide unbiased advice on business, technical and administrative decisions. Problems of interest to upper management, such as budget issues, would be escalated up to them for resolution. As the project progresses, the responsibilities of the phase managers might be consolidated and the change control board might grow smaller, eventually just handling maintenance changes rather than monitoring the project. When a phase is completed, resulting automated systems should go into maintenance mode. Changes to an automated system agreed upon by the change control board would be sent to a business group for design and to a maintenance group for implementation in the automated system. The maintenance group is often part or all of the group that did the development of the automated system. Once a phase is implemented, a help desk should take telephone calls from users of an automated system. The help desk would give advice on the use of the system and report on errors and suggested enhancements to the maintenance group who would go through the change board for review.

.As the automated system matures. strategies and goals project objectives. including descriptions of user interfaces*. priorities of objectives. provides control over the automated system. These documents should also be controlled. documents that extend beyond the project and should be maintained and kept up-todate are those with an asterisk next to them. strategies. then the automated system must be maintained.1 Controlled Documents Controlled documents may include the following: y y y y y y y y y y y y y y organizational objectives. y Once an automated system has been implemented. priorities of objectives. 16. After an automated system has been completed and goes into ³maintenance mode´. goals and constraints business requirements workflow requirements system requirements organizational business policies* interface plans* functional specifications* internal design documents (programming specifications)* vendor customization specifications* programs and program code* databases and data dictionary* test plans* performance and scalability requirements (a ³Performance and Adaptability Plan´)* user documentation. documentation that describes an automated system are functional specifications and internal design specifications.2. Doing so and enforcing that any changes to the automated system also be recorded in the functional and internal design specifications. As indicated in chapters 13 and 15. a user group might take over the change control board in reviewing changes.

This process. then the overall design will have to be re-visited to determine the change¶s effect on other phases of the project.Technical items from which an automated system can be built²program code and databases²are also controlled. 16. workflow or automated system and the documentation should be changed. Program code and databases for previous versions of the automated system are also kept in case a severe problem occurs that requires a changed automated system to be backed out. risks and contingency plans because they are likely to change and be updated quite often. both the agreement.4. Other documents than those listed above are less often controlled during the project. but should only be changed with careful consideration and consultations. including project plans.2 Change Control Board Questions the change board might ask are the following: y y Is the change necessary? When? What groups are impacted by the change? How will dependencies and schedules be impacted? Is there are more effective and preferred change to the one that is proposed? Can changes be consolidated? How and when can the change be best made with the least negative impact? Will the change also change the overall project? After approved: What is the priority of the changes with respect to other approved changes? y y y y If the change would change the overall project or change other phases in the project.3 Maintenance of an Automated System .2. called the release process or version control is described in detail in section 16. returning to a previous version. An error is an inconsistency between how an agreement.2. 16. workflow or automated system is implemented and how it is documented²this is either an error in the implementation or in the documentation. workflow or automated system is implemented when the implementation matches the documentation of it²for a change. Controlled documents can be used y y to control changes that may seriously harm a project to distinguish an error in the project from a change in the project.2. A change is a modification in the way an agreement.

1 illustrates the process of maintenance in an automated system.Once a function has been completed in an automated system. . changes must be introduced in a very disciplined fashion. Figure 16. Changes to existing functionality in an automated system is called maintenance.

A change is proposed by the business group. management or users. (A change could result from a change in a business policy.) . A change document describing the change is written.

Control of software changes is called software configuration management. should be heavily tested before the release. Variants of a program are two programs that function the same or nearly the same but differ slightly in some way. etc. The function or functions to be changed are analyzed by the business group and the changes are incorporated into the function(s). The development group uses the functional specification to identify the internal changes to the system. Technical documents (program code. Subsequent releases could fix program errors or introduce changes in the automated systems. user manuals describing the function are updated and any changes to business policies are recorded. Because the release process generally involves keeping each successive version of the automated systems.4 The Release Process A fully functioning automated system or set of automated systems that is delivered to the customer is called a release [1]. updating the functional specification(s) describing the functions from an external view. The automated system is then retested against the functional specifications. databases. When no discrepancies are found. If the release fails. Software configuration management is the discipline of managing the evolution of large and complex software systems. two variants work exactly the same. and cooperation [2]. and makes changes to a development version of the automated system or interfaces with other development systems..The change is reviewed and approved by the change control board or a user group for the automated system. it is determined whether there is an error in the changed system or in the functional specifications. with old versions kept to back out the changes if necessary. The release process is also a controlled process. the release process is also referred to as version control. QA tests the development version of the automated system and compares the way it works as compared to the functional specifications. Changes to automated systems are implemented in the healthcare organization. but work under two . Such a release is created from program code and databases which together can be used to build or rebuild the automated system. etc.. databases.e. The development group makes changes to the internal design specifications and the interface plan. interface descriptions) are updated within release control. return to the previous release). 16. through control of different versions of the software. data dictionaries.. Although new and changed code. variants of programs. unexpected problems sometimes occur just after a release. If there are any discrepancies between the automated system and functional specifications. the changed code. for example.2. The change is discussed with the technical development group who will implement the change and the quality assurance (QA) group who will test the change. changes back to a previous version. The errors are corrected. should be backed out with return to a previous version of the system (i.

2. then resolution will be escalated to the change control board. When there are disagreements between the phase project manager and overall project manager.3 MONITORING THE PROJECT AND RESULTING CHANGES 16. when the constraints of the project may be violated. Also. Of these identified important risks. When there is a significant chance that the goals of the project will not be met. as early as possible identify when goals may not be met identify when constraints may be violated ensure that contingency plans occur before unrecoverable problems occur provide and receive project status for the phases and total project. the important risks can be built into the schedule as discussed in section 14. these can be separated into those that the project managers consider to be important and those not considered to be important. A phase project manager monitors his phase. Jointly. identified and not identified. some will be actual problems and contingency plans in the schedule would be initiated. Figure 16. Cooperation is allowing multiple developers to work on a program at the same time. specifically. potential project problems. phase project managers and overall project manager should y y y y y identify risks. these risks will be reported. The phase project manager reports to the overall project manager of any risks. of these.1 Monitoring the Project The project manager monitors the overall project. .different operating systems. costs being overrun and schedules significantly slipped.3. this risk should be reported to upper management. 16. Of the identified risks.2 from reference [3] lists types of risks. Lack of resolution there could escalate to upper management.2.

some will become problems and others will not. have a higher likelihood of being overlooked.. some will be considered not important. unidentified problems. Those risks that are identified as important and you do nothing about them 2. Those you do not identify and later become problems.2. should never become a problem because the project managers would build them into the schedules. Risks in 2. Those risks that are identified as unimportant and later change into a high risk 3. or may indeed become problems.Of the identified risks. Unidentified risks (3. should be recorded and remembered and periodically revisited by project managers to determine if they are now turning into problems. as expected. although probably not built into the schedule.) require constant monitoring by project managers to identify and resolve. These later may not becomes problems. Risks in 1. as shown in figure 16. Thus. . The other category of problems. there are three paths that result in problems: 1. Of these.

long before they become a problem. The results were very much the same in each country.3²Generic Software Project Risks Project Risk Lack of top management commitment to the project Failure to gain user commitment Misunderstanding the requirements Lack of adequate user involvement Failure to manage end user expectations Changing scope/objectives Lack of required knowledge/skills in the project personnel Lack of frozen requirements Introduction of new technology Insufficient/inappropriate staffing Conflict between user departments Importance 9 8 8 7.5 16.g. This process is very complex because automated systems will grow in size due to systems being installed incrementally (e. Hong Kong and Finland. they should be monitored for actual improvement in business operations and for compliance with business policies. Once workflows have been implemented.3. the USA.5 7 7 7 6. approaching transaction limits. lack or processing power. figure 16. as reengineering is a social process in addition to a business and technical process.In this book. There are also likely to be many generic project risks.2 Monitoring System Performance A potential problem when automated systems are involved is the potential of the systems not being able to handle increased volumes of data in the future.. To take care of this. identifying potential future bottlenecks in the system. including lack of disk space. performance monitoring should be a part of all automated systems that are likely to grow in size. as compiled from studies in three different countries. 16. they may be installed at a pilot location first) and due to . Figure 16.3. Reengineering is imbedded both within human processes implemented in the organization and within user interfaces.3 from reference [4] identifies the top ten project risks. we discuss complex projects where a lot is likely to be unknown. and thus it is likely at points in the project that the project will be ahead of technology and ahead of standards.5 6 6 5. ranked from most important down to least important. so corrective action can be taken.2 Monitoring Changes to Workflows Reengineering workflows is not a ³one shot´ deal but should involve ongoing process management and improvement. Both should be considered for further (even radical) change once the project is complete. resulting in risks involving these areas. As in the project reengineering process. the employee should be heavily involved.

performance monitors who identify bottlenecks in systems. it is proposed that information required for this planning be kept in a Performance and Adaptability Plan document that identifies future projections of increases in number of customers handled by automated systems. It is also complex because new technology may become available that handles greater capacity but that will incur additional costs to the organization to implement. . In this book. and capacity planners who would identify requirements for changes to hardware and system software. bottlenecks identified so far. The Performance and Adaptability Plan document would be used by business planners who would project increases in numbers of customers.future increases in number of customers over time. and contingency plans for resolving anticipated future performance problems.

Sign up to vote on this title
UsefulNot useful