This action might not be possible to undo. Are you sure you want to continue?
Monitoring and Control of a Project
16.1 PROJECT CONTEXT: 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.
16.2 CONTROLLING CHANGES
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 , 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  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.
documentation that describes an automated system are functional specifications and internal design specifications.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. strategies and goals project objectives. Doing so and enforcing that any changes to the automated system also be recorded in the functional and internal design specifications.2. .As the automated system matures. provides control over the automated system. then the automated system must be maintained. priorities of objectives. After an automated system has been completed and goes into ³maintenance mode´. priorities of objectives. including descriptions of user interfaces*. 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. As indicated in chapters 13 and 15. strategies. 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. a user group might take over the change control board in reviewing changes. 16. y Once an automated system has been implemented.
3 Maintenance of an Automated System . 16. workflow or automated system is implemented and how it is documented²this is either an error in the implementation or in the documentation. 16.2. 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.Technical items from which an automated system can be built²program code and databases²are also controlled. A change is a modification in the way an agreement. called the release process or version control is described in detail in section 16. Other documents than those listed above are less often controlled during the project. 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.4. workflow or automated system is implemented when the implementation matches the documentation of it²for a change. An error is an inconsistency between how an agreement.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. both the agreement.2. risks and contingency plans because they are likely to change and be updated quite often. then the overall design will have to be re-visited to determine the change¶s effect on other phases of the project. This process. returning to a previous version.2. including project plans. but should only be changed with careful consideration and consultations.
changes must be introduced in a very disciplined fashion. .1 illustrates the process of maintenance in an automated system. Figure 16. Changes to existing functionality in an automated system is called maintenance.Once a function has been completed in an automated system.
A change document describing the change is written.) .A change is proposed by the business group. (A change could result from a change in a business policy. management or users.
return to the previous release). Because the release process generally involves keeping each successive version of the automated systems. interface descriptions) are updated within release control. unexpected problems sometimes occur just after a release. through control of different versions of the software.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. it is determined whether there is an error in the changed system or in the functional specifications. data dictionaries. 16. Control of software changes is called software configuration management. should be heavily tested before the release. updating the functional specification(s) describing the functions from an external view. but work under two . The development group makes changes to the internal design specifications and the interface plan. the changed code. The release process is also a controlled process. Changes to automated systems are implemented in the healthcare organization.e. The errors are corrected. Variants of a program are two programs that function the same or nearly the same but differ slightly in some way. Although new and changed code. the release process is also referred to as version control. If the release fails. Software configuration management is the discipline of managing the evolution of large and complex software systems. When no discrepancies are found.. The function or functions to be changed are analyzed by the business group and the changes are incorporated into the function(s). etc. Technical documents (program code. with old versions kept to back out the changes if necessary. etc. QA tests the development version of the automated system and compares the way it works as compared to the functional specifications. and cooperation .The change is reviewed and approved by the change control board or a user group for the automated system.. variants of programs. and makes changes to a development version of the automated system or interfaces with other development systems. The automated system is then retested against the functional specifications.4 The Release Process A fully functioning automated system or set of automated systems that is delivered to the customer is called a release .. Such a release is created from program code and databases which together can be used to build or rebuild the automated system. If there are any discrepancies between the automated system and functional specifications. The development group uses the functional specification to identify the internal changes to the system. Subsequent releases could fix program errors or introduce changes in the automated systems. databases. user manuals describing the function are updated and any changes to business policies are recorded. databases. should be backed out with return to a previous version of the system (i. for example. changes back to a previous version. two variants work exactly the same.
Of these identified important risks. phase project managers and overall project manager should y y y y y identify risks. these can be separated into those that the project managers consider to be important and those not considered to be important. 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.2 from reference  lists types of risks. The phase project manager reports to the overall project manager of any risks. Figure 16. Of the identified risks. A phase project manager monitors his phase. some will be actual problems and contingency plans in the schedule would be initiated.different operating systems. Cooperation is allowing multiple developers to work on a program at the same time.2. identified and not identified.2. costs being overrun and schedules significantly slipped. specifically. then resolution will be escalated to the change control board. Jointly. 16.1 Monitoring the Project The project manager monitors the overall project. Also. the important risks can be built into the schedule as discussed in section 14. Lack of resolution there could escalate to upper management. when the constraints of the project may be violated.3 MONITORING THE PROJECT AND RESULTING CHANGES 16.3. these risks will be reported. potential project problems. . of these. When there are disagreements between the phase project manager and overall project manager. When there is a significant chance that the goals of the project will not be met. this risk should be reported to upper management.
there are three paths that result in problems: 1. Those risks that are identified as unimportant and later change into a high risk 3. Risks in 2. Unidentified risks (3. although probably not built into the schedule. should be recorded and remembered and periodically revisited by project managers to determine if they are now turning into problems. These later may not becomes problems. have a higher likelihood of being overlooked. The other category of problems. or may indeed become problems. should never become a problem because the project managers would build them into the schedules.Of the identified risks. Those you do not identify and later become problems.2. Risks in 1.. as shown in figure 16.) require constant monitoring by project managers to identify and resolve. unidentified problems. . Those risks that are identified as important and you do nothing about them 2. Thus. some will be considered not important. some will become problems and others will not. Of these. as expected.
approaching transaction limits.5 16. Once workflows have been implemented. There are also likely to be many generic project risks.5 6 6 5.g. As in the project reengineering process. performance monitoring should be a part of all automated systems that are likely to grow in size. long before they become a problem.2 Monitoring Changes to Workflows Reengineering workflows is not a ³one shot´ deal but should involve ongoing process management and improvement. 16. as compiled from studies in three different countries. lack or processing power. Reengineering is imbedded both within human processes implemented in the organization and within user interfaces..5 7 7 7 6. they should be monitored for actual improvement in business operations and for compliance with business policies. resulting in risks involving these areas.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. identifying potential future bottlenecks in the system.In this book. ranked from most important down to least important. Figure 16. Both should be considered for further (even radical) change once the project is complete. including lack of disk space.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. so corrective action can be taken. Hong Kong and Finland. The results were very much the same in each country.3 from reference  identifies the top ten project risks.3. we discuss complex projects where a lot is likely to be unknown. figure 16. This process is very complex because automated systems will grow in size due to systems being installed incrementally (e. and thus it is likely at points in the project that the project will be ahead of technology and ahead of standards. as reengineering is a social process in addition to a business and technical process. they may be installed at a pilot location first) and due to . the USA. the employee should be heavily involved.3. To take care of this.
bottlenecks identified so far. . 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.future increases in number of customers over time. and contingency plans for resolving anticipated future performance problems. The Performance and Adaptability Plan document would be used by business planners who would project increases in numbers of customers. and capacity planners who would identify requirements for changes to hardware and system software. performance monitors who identify bottlenecks in systems. In this book. 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.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.