Components of Project Report

Project Report may be presented in accordance with the following outline:

i) Introduction: What prompted you to choose the topic? How is the topic important
in distance education ?
ii) Objectives: Specific and lucid statement of what you wish to achieve through the
project.
iii) Methodology: This may contain:
a) Design: A statement on what your overall plan of action is.
b) Sampling: How you would go about selecting the specific object, events or
respondents you want to study.
c) Tools/Techniques: What instruments, devices, material or techniques you choose
for collecting your data.
d) Processing and Analysing Data: What techniques you may use to process the
data which you collect and analyse them to answer your questions.
iv) Analyses and Findings: A lucid presentation (numerical or graphical wherever
necessary) of the analysed data and the interpretations you make thereof.
v) Conclusions: The insights you have gained through this exercise, and how these
may help in understanding the concept and promoting the practice of distance education
on the whole.
vi) Bibliography and Appendices.

bibliography

list of the books referred to in a scholarly work

Appendices

(n.) Something appended or added; an appendage, adjunct, or concomitant.

 (n.) Any literary matter added to a book, but not necessarily essential to its
completeness, and thus distinguished from supplement, which is intended to supply
deficiencies and correct inaccuracies.
 (n.) The vermiform appendix.

vii) Approved Project Proposal.

In the "traditional approach", we can distinguish 5 components of a project (4 stages

plus control) in the development of a project:

1
Typical development phases of a project

• Project initiation stage;

• Project planning or design stage;
• Project execution or production stage;
• Project monitoring and controlling systems;
• Project completion stage.

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."

Project Initiation Stage

This is when the individual project is initiated. The project is scoped; the project
objectives and benefits are established; the end users identified, the project SWOT is
identified; risk analysis is performed; project sponsor are identified; project funding is
obtained; and a project plan is approved.

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 :

A2.1 Set initial project objectives and scope.

A2.2 Refine project scope.

A2.3 Define project's benefits.

A2.4 Identify sources of business knowledge.

A2.5 Prepare preliminary project timeline.

A2.6 Determine preliminary project costs.

A2.7 Establish business user participation.

A2.8 Identify source of project funding/resources.

3
A2.9 Decide whether to continue with project.

A2.10 Prepare project plan.

A2.11 Create formal project plan document.

A2.12 Set analysis stage standards.

A2.13 Liaison with UCD control function groups.

Stage Output : Approval to launch a project of defined mission and scope.

D2.1 Information System Preliminary Requirements:

D2.2 Project Scope Document.

D2.3 Preliminary Project Plan:

D2.4 Next Stage Project Plans

D2.5 Needs Analysis Report.

D2.6 Decision As To Whether To Proceed With Project As Defined.

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

MONITORING THE PROJECT AND RESULTING

CHANGES
16.3.1 Monitoring the Project

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.

Jointly, phase project managers and overall project manager should

• identify risks, potential project problems, as early as possible

• identify when goals may not be met

4
 • 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.

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

3. Those you do not identify and later become problems.

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.

Figure 16.3—Generic Software Project Risks

Project Risk Importance

Lack of top management commitment to the project 9

Failure to gain user commitment 8
Misunderstanding the requirements 8
Lack of adequate user involvement 7.5
Failure to manage end user expectations 7
Changing scope/objectives 7
Lack of required knowledge/skills in the project personnel 7
Lack of frozen requirements 6.5
Introduction of new technology 6
Insufficient/inappropriate staffing 6
Conflict between user departments 5.5

16.3.2 Monitoring Changes to Workflows

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.

Reengineering is imbedded both within human processes implemented in the

organization and within user interfaces. Both should be considered for further (even
radical) change once the project is complete. As in the project reengineering process, the
employee should be heavily involved, as reengineering is a social process in addition to a
business and technical process.

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.