User acceptance testing

In order to create Responsibility Assignment Matrix (RAM) and RACI chart, I made these assumptions:

1. Project manager is involved in all processes of testing. He is responsible and is performing in writing a test plan, unit testing and user acceptance testing. He is also performing in integration testing and system testing.

2. Patrick, a network specialist is performing in writing a test plan, integration testing and is responsible for and is performing in system testing.

3. Nancy, a business analyst, is performing only in writing a test plan.

4. Bonnie, a programmer/analyst is performing in writing a test plan. Furthermore, Bonnie is responsible for and performing in all three phases of module integration testing.

5. User representatives are performing in all the testing processes, but not in writing a test plan. 6. Outside consultants are involved in unit, module integration, and system testing.

WBS Testing Activities

5.1 5.2 5.3.1 5.3.2 5.3.3 5.4 5.5

OBS Units Project manager R P R P P P P P R P

Network specialist P P P P R P

Business analyst P

Programmer/analyst P P R P R P R P

User representatives P P P P P P

Outside consultants P P P P P

45 Below is a RACI chart (Responsibility, Accountability, Consultation, and Informed roles for project stakeholders)

Tony Prince

programmer / analyst & project manager

Patrick - network specialist Nancy - business analyst Bonnie - programmer / analyst User representatives Outside consultants

Writing a test plan R C C C I I

Unit testing R I I A A A

Registration module integration

testing I A I R A C

Tracking module integration

testing I A I R A C

Incentives module integration

testing I A I R A C

System testing C R I I C C

46 MEMO

To: Anthony J Dionisio, Jr, COO MYH From: Tony Prince, project manager Subject: Resource histogram

Date: Tuesday, November 13, 2007

In response to the requests from user representatives and outside consulting group, I created a resource histogram to show how many of their employees will be needed for testing and when.

Outside consulting group has Senior and Junior testers, while user representatives have workers and managers that will be involved in testing processes.

Below is the table with the requirements and a resource histogram.

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Senior testers 1 1 1 1 1 1 Junior testers 0 0 2 2 2 2 Workers 2 0 0 4 4 4 Managers 0 0 0 0 2 2

0

1

2

3

4

5

6

7

8

9

10

Week 1

Week 2

Week 3

Week 4

Week 5

Week 6

Number o

f People

47 MEMO

To: Anthony J Dionisio, Jr, COO MYH From: Tony Prince, project manager

Subject: Issue log: Working effectively with users during testing Date: Thursday, November 15, 2007

I have people with different personalities working in the testing team. Some members in my project team are very introverted and strong thinking types, while several members in the users’ group are very extroverted and strong feeling type. This means that these two groups will possibly have trouble in communicating and expressing thoughts, needs, and ideas. Since not all of my team members are introverts, nor all members in the users’ group are extroverts, I will not assign them to the same jobs.

Introverted individuals in my group will be assigned jobs that can be performed by an individual. On the other hand, tasks needed to be accomplished by a group of team members will be assigned to extroverts from users’ group. That way, all of them will stay inside their comfort zones able to provide their best performance without wasting time and energy on conflicts with each other.

Furthermore, in cases where I need to put some of both groups together, I would allow enough time for the teams to get through the basic team-building stages of forming, storming, norming, performing, and adjourning. That will give them time to get to know each other and understand the way everyone functions.

In addition, teams will not be larger than 4 people, because it is much easier to manage groups of moderate amount of people.

And at the end, in case the problem still occurs, I will avoid putting blame on people for the problem, but instead I will do all that I can to fix it and encourage them to work together.

48

49 MEMO

To: Anthony J Dionisio, Jr, COO MYH From: Tony Prince, project manager Subject: Communication plan

Date: Friday, November 16, 2007

Communication is a major component of successful project delivery. Without effective communication, vital information may not be exchanged between the project team and other stakeholders. Lack of communication among project team members and stakeholders may prohibit or delay the execution or completion of scheduled tasks. Success is enabled through the effective development and execution of a Communication Management Plan. The Communication Management Plan identifies project stakeholders and the information that is to be exchanged between the project team and stakeholders. In addition, the Communication Management Plan documents the methods and activities needed to ensure timely and appropriate collection, generation, dissemination, storage, and ultimate disposition of project information among the project team and stakeholders.

Below you can find Stakeholders communication analysis, presented in a table.

Stakeholders Document Name Document Format Contact Person Due Date

Internal Management Monthly Status Report Hard Copy Bonnie, Nancy and Patrick

First of month Internal Management Weekly Status Report Hard Copy Testing Consultants Mondays at 9am Internal Management Daily Status Report E-mail Bonnie, Nancy,

Patrick and User workers and managers

Daily at 8pm

User Management Monthly Status Report Hard Copy Tony Prince First of month Internal business staff Monthly Status Report E-mail Tony Prince First of month

Comments: All emails need an acknowledgement reply or a receipt. All hard copy documents should have the title clearly printed in the header to state the type and content of the document.

50 MEMO

To: Anthony J Dionisio, Jr, COO MYH From: Tony Prince, project manager Subject: Issue log

Date: Monday, November 19, 2007

An issue log should be maintained so it records details of the issue, its owner and progress up to final resolution. The owner of the issue is normally the individual in the project team or project board most able to progress the issue to resolution. In our case the owner of the issue log is me, the project manager.

Issues must be appropriately managed and controlled. Below you can see an issue log in connection with the testing phase of the Recreation and Wellness Intranet project.

Issue # Issue Description Impact on Project Date Reported Reported By Assigned To Priority

(M/H/L) Due Date Status Comments

1 User is hard to