Professional Documents
Culture Documents
bibliography
Appendices
1
Typical development phases of a project
Not all the projects will visit every stage as projects can be terminated before they reach
completion. Some projects do not follow a structured planning and/or monitoring stages.
Some projects will go through steps 2, 3 and 4 multiple times.
Many industries use variations on these project stages. For example, when working on a
brick and mortar design and construction, projects will typically progress through stages
like Pre-Planning, Conceptual Design, Schematic Design, Design Development,
Construction Drawings (or Contract Documents), and Construction Administration. In
software development, this approach is often known as the waterfall model[16], i.e., one
series of tasks after another in linear sequence. In software development many
organizations have adapted the Rational Unified Process (RUP) to fit this methodology,
although RUP does not require or explicitly recommend this practice. Waterfall
development works well for small, well defined projects, but often fails in larger projects
of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the
planning made on the initial phase of the project suffers from a high degree of
uncertainty. This becomes especially true as software development is often the realization
of a new or novel product. In projects where requirements have not been finalized and
can change, requirements management is used to develop an accurate and complete
definition of the behavior of software that can serve as the basis for software
development[17]. While the terms may differ from industry to industry, the actual stages
typically follow common steps to problem solving — "defining the problem, weighing
options, choosing a path, implementation and evaluation."
2
Stage Diagram: Hide Figure
Stage Scope : A business area (major subset of the University (enterprise) defined via
business activities, business events, and/or entity types) or a pre-scoped BPR, Feasibility
Study or IT development project.
Stage Input : A request to analyze an area of the business, to launch either a business
process re-engineering project, a feasibility study or assessment or an information
technology development project.
Stage Tasks :
3
A2.9 Decide whether to continue with project.
Project Completion
The project is considered as completed when the product meets all of the stated
requirements and is accepted by the customer.
The stage of the project completion involves last-minute refinements, reviewing
procedures, and packaging of the product
The project manager monitors the overall project. A phase project manager monitors his
phase. The phase project manager reports to the overall project manager of any risks.
4
• identify when constraints may be violated
• provide and receive project status for the phases and total project.
When there is a significant chance that the goals of the project will not be met, this risk
should be reported to upper management. Also, when the constraints of the project may
be violated, specifically, costs being overrun and schedules significantly slipped, these
risks will be reported.
When there are disagreements between the phase project manager and overall project
manager, then resolution will be escalated to the change control board. Lack of resolution
there could escalate to upper management.
Figure 16.2 from reference [3] lists types of risks, identified and not identified. Of the
identified risks, these can be separated into those that the project managers consider to be
important and those not considered to be important; of these, the important risks can be
built into the schedule as discussed in section 14.2.2. Of these identified important risks,
some will be actual problems and contingency plans in the schedule would be initiated.
5
Of the identified risks, some will be considered not important. These later may not
becomes problems, as expected, or may indeed become problems.
The other category of problems, unidentified problems, have a higher likelihood of being
overlooked. Of these, some will become problems and others will not.
Thus, as shown in figure 16.2, there are three paths that result in problems:
1. Those risks that are identified as important and you do nothing about
them
2. Those risks that are identified as unimportant and later change into a
high risk
6
Risks in 1. should never become a problem because the project managers would build
them into the schedules. Risks in 2., 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. Unidentified risks (3.) require constant monitoring
by project managers to identify and resolve.
In this book, 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, resulting in risks involving these areas. There are also likely to be many
generic project risks; figure 16.3 from reference [4] identifies the top ten project risks,
ranked from most important down to least important, as compiled from studies in three
different countries, the USA, Hong Kong and Finland. The results were very much the
same in each country.
Reengineering workflows is not a “one shot” deal but should involve ongoing process
management and improvement. Once workflows have been implemented, they should be
monitored for actual improvement in business operations and for compliance with
business policies.
7
16.3.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,
performance monitoring should be a part of all automated systems that are likely to grow
in size, identifying potential future bottlenecks in the system, including lack of disk
space, lack or processing power, approaching transaction limits, long before they become
a problem, so corrective action can be taken.
This process is very complex because automated systems will grow in size due to systems
being installed incrementally (e.g., they may be installed at a pilot location first) and due
to future increases in number of customers over time. 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, 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, bottlenecks identified so far, 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, performance monitors who identify bottlenecks in systems, and capacity
planners who would identify requirements for changes to hardware and system software.