31272 – Project Management and the Professional

Assignment 2

Semester 1, 2008

CELIA HO 10546404        

Executive Summary

This report provides three parts in the project management for the TASS implementation. They are Decomposition Planning, Estimating and Risk Reporting. They were all carried out based on the analysis of the requirements and specification of the desired system and continue through to full system test and documentation tasks as indicated in the specification. Assumptions given have been taken into consideration during each stage and new ones were also generated to help the project management more reasonable and efficient.

The work breakdown structure was used to decomposition the specification into five components and each component was further divided into sub-tasks and in turn detailed tasks one after another. Then PERT diagram was drawn to illustrate how the dependency network of all the detailed tasks, meanwhile the Milestones were also identified and indicated in the diagram.

Estimating is then carried out based on the pervious part. Time duration for each specific task and each phase were both estimated and the critical path on the PERT diagram was then calculated. The estimation of complexity, size and confidence for the estimation were given to each detailed task as well. A Functional Point Analysis performed online was used to compare the estimating results and the industry norms. Java has been chosen to analyze the hours per function point for each phase.

Risk reporting is the last part in the range of the TASS project management. The risks and hazards, which could interrupt the implementation of all the tasks, were categorized into four main factors and the likelihood, impact and exposure of each hazard was estimated based on the experiences and materials available. All the risks were mitigated by strategies which were indicated on the PERT diagram as well.

The rationale used to implement the three parts mentioned above and how they were utilized in the TASS project have been provided at the beginning of each part.

There are 75 detailed tasks in total have been generated to implement the project within the scope required. The whole project can be completed on time under the assumption that the each detailed task on the critical path can be finished within the time slack and meet the basic requirements. The slacks for some tasks can be used to deal with emergencies encountered in the real implementation process and make the schedule flexible to a certain extent.

The Build or Development phase was estimated out of the normal range by the Functional Point Analysis. There are the several factors contributing to under-estimating the time duration for this phase. There are complexity and size of the system, the lack of experience of and non-sufficient materials available and lack of foreseeing redundant work in the real work place. More detailed discussion on this issue is under the Estimating part.

Documenting what have been achieved, problems encountered and correspondent resolution on time could help make the next task implemented more realistic and effective. Constant checking and re-estimating all elements from time to time seem to be important in order to reduce errors and adjusting the following events according to the real situation. These could guarantee effective resource allocation to be implemented in the next stage and provide good references for monitoring and control the progress of the whole project.


Addition to the assumptions provided in the specification, we decided to add more assumptions to create a more precise system.

We assumed that the traditional System Development Life Cycle (SDLC) methodology as we were not provided with a specific methodology for this development. We have chosen SDLC as it is one of the oldest and structured methodology. SDLC is divided into different phrases such as analysis, design, development, implementation, testing and evaluation. The advantages of these phrases are that it allows us to break our tasks for this development into suitable categories, where it would be easily understood by stakeholders.

A benefit of sorting the tasks by these phrases is that when the function point analysis was performed, we could easily use their category format as it was also sorted according to SDLC.

Another assumption that we made for this development was that we assumed that the development process would performed as planned, tasks would be performed on time and output would be available for the next stage. Although this assumption, to a certain degree, is unrealistic, however, we must note that any minor error within the development stage could affect the whole project, therefore it would be difficult to predict how much time to allocate to these unexpected events. However, we have not excluded major risks which are more likely to occur; this would be covered in the risk section of this report and mitigation of the risks would be identified.

Part 1: Decomposition and Planning

Before a project commences it is vitally important to explore the different elements of the project; understanding the requirements of the proposed system and users that would be using the system. This planning step would significantly help in ensuring that the completed system would run closely to the requirements.

Planning is “an ongoing process of refinement” (Hughes & Cotterell, 2002), this includes elements such as defining the tasks to be acted upon, setting targets, resources to be used, cost of development and timeframe of the proposed project.

However, before a plan can be created and documented, decomposition of the tasks are required, this is where the entire project is broken down into small manageable components, where activities could be monitored, helping to ensure that the tasks can be delivered close to the planned timeframe. Due to the fact that the Tutorial Allocation of Students System consisted of many different components, it would have been impossible to build the system as one large task.

In order to break up the tasks within TASS, the project was divided according to stages of the traditional System Develop Life Cycle (SDLC), such as Analyse, Design, Development and Testing (Refer to Appendix A).

Breaking down the tasks has allowed developers to see which tasks could be carried out at the same time, allowing better allocation of resources, reducing time of development as well as cost.

Before TASS could be decomposed, discussion of all possible tasks was required; this provided us an outline of the tasks and aided us in deciding how to categorize the tasks under the appropriate stages.

Join now!

1.1 Activity-based Approach

An activity-based approach was taken to decompose the tasks; this is where we generated a list of activities to create a Work Breakdown Structure (Refer to Appendix C). The benefits of this is that it allowed us to break the stages into high level activities then further decomposed into lower level activities until the activities are decomposed into a manageable size. An example would be the design stage of TASS; this stage could be further broken down into different areas such as user interface design, report design and SQL design.

Breaking tasks into ...

This is a preview of the whole essay