Components Of Project Report 1h5f6h

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 istration. 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 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 s 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 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. tly, 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 ed 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 commitment

8

Misunderstanding the requirements

8

Lack of adequate involvement

7.5

Failure to manage end expectations Changing scope/objectives Lack of required knowledge/skills in the project personnel Lack of frozen requirements

7 7 7 6.5

Introduction of new technology

6

Insufficient/inappropriate staffing

6

Conflict between 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 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.

8