PMP Final Report

UNIVERSITY OF TECHNOLOGY, SYDNEY

31272 – Project Management and the

Professional Assignment 2: TASS Management Report

Tutor: David Ty

5/31/2012

Student Name (Number): David Ascic (10852958) & Ashan De Silva (10838542)

UTS Autumn Semester 2012 31272 Project Management and the Professional TASS Management Report

2

Executive Summary

The following report provides a comprehensive documentation on the TASS (Tutorial Allocation of

Student System) specifications supplied for the commencement of a software project. Through a

careful analysis of the specifications provided, task decomposition was carried out whereby system

requirements were broken down into simpler and more rational tasks. These tasks were then

planned based on a hierarchal rationale, where order and structure accounted for greater simplicity

and quality assurance.

Furthermore, it was also discovered that it is vital all tasks are completed within the time assigned

due to completion requirements imposed on the project. An estimated time frame of 53 working

days has been identified. It was also demonstrated that planning and system programming phases

were most focused upon due to the nature of each group of tasks, as these activities were more

complex and important in nature for underlying success of the project.

Additionally, a risk analysis specifically denoted the identification of the risks involved with TASS and

an approximation and evaluation of those risks. There is a primary importance to this analysis,

highlighting all the potential areas of the project where risks and issues can be mitigated through

contingency plans and new activities, and, more importantly, it provides an insight into the projects

long-term prosperity, whether that may involve potential barriers in the future. It was found in the

TASS system, due to the nature of the project, that is, a tutorial allocation system, there were many

risks which could potentially de-rail the overall implementation and integration of the system, thus

new risk-averse activities were established to mitigate such risk in the best possible manner.

As shown throughout the report, it is recommended that project plans be the focus of attention by

project managers first and foremost before conducting a project. Unfortunately, there are no

straight forward methods or practices for planning; rather, it is purely dependent on the type of

context for which the project is situated around. In this instance, the TASS system could be

decomposed in a structured manner due to the systematic nature (e.g. sub-systems) of the entire

project. Each project requires contextual realisation, where given the situation, one must adapt

promptly and apply understanding in an appropriate manner.


3

Contents Additional Assumptions ...................................................................................................................... 4

Decomposition and Planning Rationale .............................................................................................. 5

Time Estimation and Complexity Rationale ........................................................................................ 7

Risk Analysis ........................................................................................................................................ 9

Conclusion and Recommendations .................................................................................................. 12

A1: Activities and Deliverables .......................................................................................................... 13

A2: Duration, Classification, Complexity, Size, Confidence Estimation ............................................ 17


4

Additional Assumptions 1. A normal working day for a team member is 8 hours, between Monday and Friday. This is a

realistic assumption, as is necessary in order to accurately contextualize time estimation and

complexity.

2. The weekends are not taken into consideration throughout any of the project phases. This

assumption is required once again to promote a realistic view of the project, as employees do

not usually work on weekends, thus the subsequent delay needs to be taken into account

through estimation.

3. System programmers are able to understand and be able to convert specifications to

programming language, that is, no additional training is required. This enables the project team

to focus purely on the task at hand, rather than out of scope aspects.

4. Basic GUI is assumed for basic functionality purposes upon demonstration and presentation.

5. Testing will need to be undertaken throughout the whole project, and at times may take longer

than expected according to the complexity and overall estimate of the task.

6. It was also assumed that the university would provide all necessary hardware, thus eliminating

the need for research into hardware vendors.

7. Lux and Osborne Consultants have also assumed to have an ‘unlimited’ budget to complete the

TASS System in order to expedite the process.


5

Decomposition and Planning Rationale As per specifications, the TASS system deconstructed into tasks of appropriate size. Therefore, it was

suitable to use an activity oriented work break-down structure (WBS) in order to classify and

organise tasks (as demonstrated in the PERT diagram), with clear and practical milestones,

subsequently being presented to university management. In addition, though many of these tasks

established may be assigned to an individual alone, the reality of the case suggests otherwise within

the scope of complexity in specific tasks, thus it was taken in consideration through our rationale

that multiple individuals would be required to perform particular tasks. This would therefore have

manipulated the way in which tasks were broken down and planned, for instance, tasks classified as

designing could have been broken down into many tasks and delegated to particular individuals,

instead it was seen as requiring a multiple individual effort, thus it was kept as one large task.

Moreover, the decomposition and planning of the entire system and its tasks reflected that of the

stages in which a system is normally produced, that is, beginning with a planning phase, followed by

development, acceptance testing and implementation phases, decomposed through deconstructing

the functionalities of the system. As such, the planning stage for example encompassed tasks

relating mostly to the administrative preparation tasks, such as the distributing and analysing the

system specifications, delegation of tasks to staff, initial communication with clients, negotiating

contracts and so on.

The development phase involves tasks relating to the system creation, mostly incorporating

designing of system frameworks and code creation. Finally the testing and implementation stages

involved the system being tested rigorously, subsequently being handed over to the client insuring

all functionalities are up to standard. In particular, focusing on phases allowed easier deconstruction

of tasks, but at the same time, allowed specific task groupings to be performed simultaneously. This

can be seen in the development phase section, where all subsystems and there corresponding tasks

were executed and created simultaneously.

Through this process, the TASS system decomposition and planning was performed in a hierarchical

or structured manner, allowing the system to be systematically assembled and tested. As such, this

made it substantially easier to decompose the system into smaller tasks which could then be

delegated to individuals without unduly complicating the model. This method was also chosen as it is

structured; it follows a foreseeable path and would create a sense of completion and measurability

when milestones are met. However, this does not entail that tasks decomposed and planned under a

hierarchical method cannot be performed simultaneously, rather, each task is organised in a


6

structured manner, only allowing tasks to be performed simultaneously if they are not dependent on

the other, as well as restricting task execution to only if the ‘root’ task is completed.

This may appear as being restrictive on human resources and, overall, an inefficient way to deliver

the project in the earliest time period possible with minimal costs, but this is a small deterrent when

looking at the larger scope of the project and its ambition of guaranteed success upon

implementation. For example, an unstructured decomposition and plan would be the testing of the

system without test plans or the completion of pivotal coding. The structured approach chosen

however, would involve the production of the test cases after all relevant coding has been written

and the entire system is completed, followed by the execution of these test cases in an orderly

fashion. This clearly demonstrated a more logical approach to decomposing and planning each task,

guaranteeing minimal delays in the long-run by minimising potential problems in the future, whilst

promoting consistency and quality assurance throughout all phases.

In conjunction with this, milestones were set throughout the projects life. These were events in the

project plan that, upon completion, can be reviewed. 21 milestones were identified and chosen; this

was due to the fact that those in a reviewing position would want to see large scale functional and

tangible deliverables throughout the project, and not minor completions, as this will not

demonstrate the systems true function capabilities, potentially losing the interest of high-level

stakeholders. For instance, a milestone is set directly after the completion and integration of all sub-

systems, which conveys a noticeable deliverable. Additionally, adequate testing procedures

throughout the project and implementation procedures implies that a number of smaller milestones

(e.g. documentation creation) would be performed regardless; thus the need for large amounts of

milestones can been deemed as redundant time wastage by potential stakeholders reviewing the

project. By focusing on key constructs and rather than a proliferation of technical details, the

decomposition of the tasks provides a useful vehicle for communicating the architecture to non-

technical audiences, such as management, marketing, and potential users.


7

Time Estimation and Complexity Rationale The time estimation process involved having estimations calculated for each tasks. When estimating

the time it would take to complete each task, we would have to take into consideration a number of

factors of why we had estimate that amount of time to a particular task. These important factors

consist of:

Classification of the task.

Degree of complexity (range: simple, medium, complex).

Size of the task (small, medium, large).

From past experience and knowledge, giving an unrealistic estimate could cause the project to not

meet deadlines, which in this case give’s the client an expectation that cannot be met. The general

rationale focuses on the following factors:

Allocating realistic time estimates, we could give the client an estimated time the project will be

completed.

Proper time management for each task and meeting client expectations, we would need to

consider the degree of complexity and size of the task as a primary factor

Tasks that require a combined group to action or lengthy process to complete, we have

considered more time allocated. Simply because of the resources that are required for that

particular tasks compared to individual working on one task

Our main objective is to deliver the completed TASS system on time and meet the system

specification requirements. As time factors into delivering the TASS system on time, we have

specified each task and the duration of that task to the best of our knowledge.

The planning of the project is complex and is essentially the preliminary execution of the project.

The TASS specification and requirements are to be thoroughly analysed to ensure that the project

team understands the project and how the project will be organized. This stage of the project is

critical as it requires on how the project will proceed and what tasks are involved in this project.

The database system is an integral part of the system and is required to be accurately designed and

operated. This phase in the project provides a rational amount of time as it is the foundation of the

whole system. By allowing adequate time for this phase, we can ensure that quality work to make

the system operational will allow us to easily integrate the following sub-system without much

change to the design.

The Lecturer, Subject, Student and Student-Subject sub-systems are developed after each one has

been completed. These four sub-systems take’s the most time as it is the development of the TASS

project. Estimation of these sub-systems is given at a reasonable amount of time due to the fact that

the written codes are being re-used. The specifications of the TASS system requirements are to have

these sub-systems integrated with the entire system.


8

Although this phase may take the most time, codes written for these four sub-systems are re-used.

Programmers will not be required to duplicate the code as by re-using the code, the sub-systems are

built on consistency of the code throughout the sub-systems which can save time and effort.

The entire system phase is to ensure that after each sub-system has been integrated, following

errors may appear. Reasonable amount of time has been allocated to this section as it compiles to

design error messages for the entire system if they arise.

The final implementation stage has a reasonable amount of time allocated as it involves building and

implementing the TASS system in a production environment. Also documentation can be written

simultaneously by various members of the project to create an on-line TASS manual and technical

documentation. The disaster recovery plan is also given a specific amount of time to make sure there

is an off-site to handle the data backup of the TASS system in event of a disaster.

Risk Analysis Risk No.

Risk Identification Likelihood Impact Risk Mitigation

1 Client changes project requirements.

Medium High Ensure that requirements are defined in the scope. Any changes required during the project, the contract will state that it is their responsible for time and budget loss.

2 Deadline disagreements that are mentioned in the contract.

Low High Obtain contractual legal advice of the project documentation.

3 Unidentified system errors on the system during a production environment.

Medium Medium Review the actual implementation/production system on the test environment.

4 Hardware incapabilities. Medium Medium Hardware specifications and research will be examined during and after the coding stages.

5 User passwords are weak and can be decrypted by a small amount of random guesses

Medium High Password are required to meet the criteria when creating/changing. After 3 attempts, the user's account will be suspended.

6 User's responsibilities on giving out information.

Medium High Ensure that User reads and understand the policy on giving someone their username and password to log into the system

7 Student gain's access to Lecturer system.

Low High Login and password are required to access the system at all times. User's should "lock" their computer when away from the system.

8 Project cancelled before completion.

Low High Contract agreement that states in the event of the project being cancelled, client must comply with payments up to the current project.

9 University management wants to push the project to an earlier timeframe.

Low Medium System has been planned out to give an estimate of the completed time and date. A planned system of the project should address the management of it's timeframe and advise the risks involved if trying to complete it at an earlier date.

10 User's gain access to sensitive information & unauthorised access.

Medium Medium User's access should be identified according to their position and updated as required.


10

11 Pressure on the developers to ensure it meets deadlines and is error free.

Medium Medium Make sure tests are done thoroughly during the test phase.

12 Attack on the network to gather data traffic or login details.

Low High Ensure that data that is being sent is secure and user's must take precautions when entering their details.

13 Lecturers of other Subjects incorrectly alter other Subject Information

Medium High System monitoring requires to log new, modified, deleted changes within the system. This allows the audit log to identify who made the changes and too whom.

14 Student gains control of the entire system.

Low Low Have areas with emergency shutdown of the TASS system.

15 User's unable to work in certain areas due to installation of the TASS system.

Medium High Have areas with emergency shutdown of the security system.

16 User's unable to work in certain areas due to installation of the TASS system.

High Medium Schedule planned installations by each area/section.

17 Legal constraints that may stop the project that requires access to students’ personal information.

Low High Make sure that the legal requirements for the TASS's project has been met and documented. Constraints can be dealt with during the beginning of planning of the project.

18 Legal constraints that may stop the project that requires access to student’s personal information.

Medium High Make sure that the legal requirements for the TASS project has been met and documented. Constraints can be dealt with during the beginning of planning of the project.

19 Conflict with current user processes.

Low Medium Have regular meetings with Lecturers and University Management during each phase.


11

20 Data loss due to natural disaster.

Low High Disaster recovery plan created.

21 Data loss due to natural disaster.

Low High Disaster recovery plan created.

Conclusion and Recommendations Fundamentally, this management report has outlined and deconstructed the entire proposed TASS

system. Evidently, there are many key issues and aspects relating to the nature of the project itself,

and the art of project management, which was expressed throughout the development of the project

plan.

Firstly, decomposition and planning of the project into manageable tasks promoted simplicity and

ease of execution, thus hierarchical or structured rationales insight a more efficient structuring of the

entire project, ensuring accountability and accuracy of delivery. Furthermore, phases of the

development life cycle were used in order to make it more apparent as to what tasks were required

at what specific time period, as each phase is used to decompose the system into the relevant tasks

that relate to that particular phase. This brought the question of whether the surplus use of human

resource allocation was a necessary burden through structural analysis of the project. It was

determined that indeed, accuracy and quality of delivery will always outweigh emphasis on early

delivery and human resource restrictions.

Furthermore, the time estimation and complexity was found to be quite a liable aspect of the project,

carrying with it a great risk if estimations were significantly inaccurate in comparison to the actual

true outcome. It was therefore necessary to assess and analyse the context in which these activities

were being conducted, applying time estimation techniques accordingly to find the best possible

estimate which mutually satisfied both complexity and contextual duration.

Risk analysis was also found to be of paramount necessity throughout project management. This

included the identification of risks, the impact and likelihood and risk mitigation strategies which

either attempts to reduce the probability of a risk occurring or aims to reduce the impact of a risk,

should it occur. The prioritisation and ranking of the risks allows the project team to further

understand the importance of preventing higher priority ranked risks over other risks, mitigating

them accordingly with contingency plans in the form of new activities and tasks.

Ultimately, the success of the project depends upon a well-constructed project plan which assesses

all aspects of the project, including the system specifications and user requirements. It is important

to note though that the fundamental basis of planning is that of a continually iterative task; a plan is

out of date the moment it is finished. Therefore, continual adaptation to contextual circumstances

must be adopted to guarantee any project success in the future.

Appendix

A1: Activities and Deliverables

TASK NUMBER

TASK DELIVERABLES

1 Read TASS specification document Understanding the project requirements and complete overview of TASS System Specification

2 Decomposition of the specification document Produce a network dependency diagram

3 Document artefacts gathered from decomposition Develop schema for sub systems, including Lecturer Table, Student Table, Subjects Table, Student-Subject Table

4 Create contact for TASS system Comprehensive Contract created outlining overall TASS system requirements

5 Sign off on TASS system contact Both University Management and Lux & Osborne, IT Consultants sign off and agree to the created contract

6 Identify risks associated with TASS system Create Risk Management Report

7 Create website GUI for TASS users TASS user log-in webpage created

8 Create student log-in interface Student Log in screen created, ready for data entry

9 Create lecturer log-in interface Lecturer Log in screen created, ready for data entry

10 Develop user help system User Help system created, for ease of use by simple mouse operations and minimal keystrokes on the keyboard

11 Design the relational database tables Completed Schema for all relational tables for the system, including an Entity Relationship Diagram depicting Lecturer Information Table, Student Information Table, Subject Information Table and Tutorial Information Table

12 Create lecturer information table Overview of program coding required for the Lecturer Information Table

13 Create student information table Overview of program coding required for the Student Information Table

14 Create subject information table Overview of program coding required for the Subject Information Table

15 Create student-subject information table Overview of program coding required for the Tutorial Information Table

16 Implement lecturer table function: add a lecturer Ensure Add Lecturer feature operates


14

17 Implement lecturer table function: enquire on a lecturer Ensure Enquire on a Lecturer feature operates

18 Implement lecturer table function: change lecturer Ensure Change a Lecturer feature operates

19 Implement lecturer table function: delete lecturer Ensure Delete a Lecturer feature operates

20 Test lecturer table functionality User Test of lecturer table for approval of interface, functionality and ease of use

21 Implement subject table function: add subject Ensure Add a Subject feature operates

22 Implement subject table function: change subject Ensure Change a Subject feature operates

23 Implement subject table function: delete subject Ensure Delete a Subject feature operates

24 Implement subject table function: enquire on a subject Ensure Enquire about a Subject feature operates

25 Implement subject table function: modify subject data Ensure Modify Subject Data feature operates

26 Implement subject table function: modify subject status Ensure Modify Subject Status feature operates

27 Test subject table functionality User Test of subject table for approval of interface, functionality and ease of use

28 Implement student table function: add student Ensure Add Student feature operates

29 Implement student table function: change student Ensure Change Student feature operates

30 Implement student table function: enquire on a student Ensure Enquire on a Student feature operates

31 Implement student table function: delete student Ensure Delete a Student feature operates

32 Test student table functionality User Test of students table for approval of interface, functionality and ease of use

33 Implement student-subject table functionality: enquire tutorial lists

Ensure enquire tutorial lists from student-subjects functions

34 Implement student-subject table functionality: add student

Ensure add student from student-subjects functions

35 Implement student-subject table functionality: change a student

Ensure change a student tutorial lists from student-subjects functions

36 Implement student-subject table functionality: add subject for student

Ensure add subject for a student from student-subjects functions

37 Implement student-subject table functionality: delete subject for student

Ensure delete a subject for student from student-subjects functions

38 Implement student-subject table functionality: delete student from a subject

Ensure delete a student from student-subjects functions

39 Implement student-subject table functionality: delete all students in a subject

Ensure delete all students from student-subjects functions

40 Test student-subject table functionality User Test of students-subject table for approval of interface, functionality and ease of use


15

41 Implement function: lecturer log-in Complete interactivity and log-in function for the user interface: Lecturer

42 Implement function: student log-in Complete interactivity and log-in function for the user interface: Student

43 Implement function: user log-in error reporting Complete list of all possible error reports for end users

44 Test user log-in functionality Identify any faults and rectify immediately

45 Implement function: print full student list Complete print processes for full student listing

46 Implement function: print full lecturer file Complete print processes for full lecturer file

47 Implement function: print full subject file Complete print processes for full subject file

48 Implement function: print student details Complete print processes for student details

49 Implement function: print student tutorial details Complete print processes for tutorial details

50 Implement function: print student enrolment details Complete print processes for student enrolment details

51 Implement function: print summarised subject list Complete print processes for summarised subject lists

52 Integrate reporting functions Complete interactivity requirements for all reporting functions required by users

53 Test integrated reporting functions Identify any faults and rectify immediately

54 Implement function: encode lecturer passwords Ensure software utilises a quality encoding system for encoding user passwords

55 Implement function: blocking a user after a number of incorrect attempts

Create a contingency plan prohibiting users with incorrect passwords

56 Implement function: terminating the system after 10 incorrect attempts in a processing run

Create a system which ends the current session after 10 incorrect password attempts, locking both the IP address and username of the user.

57 Implement BATCH JOB function: one word commands Finalise Coding of one word commands

58 Implement BATCH JOB function: reporting systems Finalise Coding of reporting systems

59 Implement BATCH JOB function: backup data tables Finalise Coding of backup data tables

60 Implement BATCH JOB function: restore data tables from backups

Finalise Coding of restoration of data tables from backups

61 Implement BATCH JOB function: automated system start Finalise Coding of an automated system start

62 Implement BATCH JOB function: copy all programs and libraries from development directory

Finalise Coding for copying all programs and libraries from development directory

63 Implement BATCH JOB function: compile all programs in the system

Finalise Coding for compilation of all programs within the TASS system

64 Implement BATCH JOB function: copy all executable versions of the program from production directory to operating directory

Finalise Coding for all executable versions of the TASS program.


16

65 Test BATCH JOB functionality Complete thorough testing of BATCH JOBS, identifying faults and rectifying these immediately.

70 Test security functionality Complete thorough testing of the Security system, identifying fualts and rectifying these immediately

71 Conduct system audit System compliance document stating the specified requirements

72 Conduct systems' test Complete testing of identifying faults and rectifying these immediately.

73 Create disaster recovery plan Implement action to switch the System to disaster recovery mode until the System is rectified.

74 Develop data recovery procedures Implement a Data Backup Procedure which can comprehensively recover the data input into the system.

75 Final systems inspection System running to specifications. Review entire system. Only ongoing support required

76 Create technical documentation Complete all end TASS system documentations.

77 Create user manual Provide a printed-out user management to the prison management, and also access to the online version

78 Presentation to university management Host a presentation to the University Management, detailing the specifications of the TASS system.

79 Sign off on completed TASS system Sign off on each TASS system elements in the contact

80 Integrate relational tables Each of the relational tables are connected according to constraints, this information is outlined in a Project work document

81 Database functionality test The database is tested using provided data and a functionality report is produced

82 Compile documentation All necessary documentation is compiled and published


17

A2: Duration, Classification, Complexity, Size, Confidence Estimation

TASK NUMBER

DURATION CLASSIFICATION COMPLEXITY SIZE CONFIDENCE OF ESTIMATE

1 1 Planning Simple Small Good

2 1 Planning Medium Small Good

3 1 Planning Medium Small Good

4 2 Documentation Complex Medium Good

5 1 Documentation Simple Small Good

6 1 Planning Medium Medium Good

7 2 GUI Design Medium Small Good

8 1 GUI Design Simple Small Good

9 1 GUI Design Simple Small Good

10 1 GUI Design Simple Medium Good

11 3 SQL Programming Complex Medium Good

12 2 SQL Programming Medium Medium Good








20 5 Testing Medium Medium Good



18


























19








53 1 Testing Medium Large Good

54 1 SQL Programming Complex Large Good



57 1 SQL Programming Complex Small Good








65 3 Testing Medium Large Good

70 3 Testing Complex Large Good




20

73 2 Documentation Medium Medium Good



76 3 Documentation Complex Large Good


78 2 Documentation Medium Small Good

79 1 Documentation Simple Small Good



82 3 Documentation Medium Large Good

Requirements Traceability Table

Student #: 10852958, 10838542

Requirement No.: Actual Requirement: Location of Requirement in

Assignment:

Location of where it is

Addressed in the

Submission:

1 Title Page Page 5, Deliverable 2, 1

st

Paragraph. Page 1

2 Table of Contents Page 5, Deliverable 2, 1

st

Paragraph. Page 2

3 Executive Summary Page 5, Deliverable 2, 1

st

Paragraph. Page 3

4 Assumptions Page 5, Deliverable 2, Point

1. Page 4

5 Decomposition and Planning

Rationale

Page 2, Part 1, Paragraph 2

and Page 5, Deliverable 2,

Point 2.

Pages 4 - 5

6 Decomposition and Planning

Activity Table Page 2, Part 1, Paragraph 6.

Pages 13 - 16

Appendix - A1.

7 Milestones Page 2, Part 1, Paragraph 1. Page 7

8 Estimation of Task Duration Page 2, Part 2, Paragraph 1. Pages 17 - 20

Appendix – A2.

9 Classification of the Tasks Page 3, Part 2, Paragraph 2 Pages 17 - 20

Appendix – A2.

10 Complexity of the Tasks Page 3, Part 2, Paragraph 2 Pages 17 - 20

Appendix – A2.

11 Size of the Tasks Page 3, Part 2, Paragraph 2 Pages 17 - 20

Appendix – A2.

12 Confidence in Duration Estimate

of the Tasks Page 3, Part 2, Paragraph 2

Pages 17 - 20

Appendix – A2.

13 Time Estimation and Complexity

Rationale Page 3, Part 2, Paragraph 3 Page 6


22

14 Sensitivity of the Critical Path Page 2, Part 2, Paragraph 1. Page 12

15 Risk Reporting Page 3, Part 3. Page 9 - 11

16 Risk Identification Page 3, Part 3, Dot Point 1. Page 9 - 11

17 Risk Estimation Page 3, Part 3, Dot Point 2. Page 9 - 11

18 Risk Evaluation Page 3, Part 3, Dot Point 3. Page 9 - 11

19 Conclusion Page 5, Deliverable 2, Dot

point 6 Page 12

20 Requirements Traceability Table Page 5, Deliverable 2, Dot

Point 7 Page 21

Documents

PMP Final Report