Software Project Plan

2.0
Team Name:
A New Hope

Team Members:
Andrew Voszatka
Josh Major
John Battaglia
Kenny Urena

1.0 Introduction
1.1 Project Scope
Description of Software
Console Based Bidding/Selling program
Inputs

Login/Password of sellers/bidders
Item information including: Title, starting bid, description, and ending date
Item to be searched
Feedback comments (additional functionality)
Feedback score (additional functionality)

Outputs
Total amount in sales
number of items
total items unsold
total amount of money spent by a bidder
number of items purchased by bidder
items bidder bids on that are in progress with totals-number in-progress, number winning,
$ amount of winning items
Processing Functionality
Input of login/password by user and/or seller

Authentication/Validity is checked

Once authenticated sellers can post items that they want to sell

Search item results will be in lists

Items will be put in alphabetical order so it's easier for bidder to find what they are
looking for

Bidders can bid on available items based on money available and how much they are
willing to spend on an item

At the end of the time period given, the person who would spend the most will win the
item

A collection of operations will take place after each auction. Such as declaring the
winner, updating items sold, dollars spent, and search list

1.2 Major Software Functions

Functionality:
Seller:

Be able to post an item to sell

Set Items details upon bidding: title, description, starting price, ending date

Be able to view history: total dollar amount sold, total unsold, items with no bids

View dollar amount of winning items

Bidder:

Place bid on in-progress items

Win bids, if highest bidder on end date

View bid history and details: total dollars spent and number of items, and dollar amount
of winning items

View items they bid on that are in progress with totals: number in-progress and number
winning

Aministration:

Alphabetical list of items

Searching mechanism for items (based on keywords for words in the title or
description)

Display Accurate Item price

Charge winning bidder accurate price and add amount to sellers totals

1.3 Performance/Behavior Issues

There are no special requirements for performance or behavior to note.

1.4 Management and Technical Constraints

Time Constraints:

Deadline of Software Project Management Plan: March 4, 2013

Deadline of Software Requirements Specification: March 25, 2013

Drop dead delivery date of completed program: April 15, 2013

Our team members are all full-time college students, and thus have limited time to work
on the project.

Knowledge Constraints:

The following table shows what programming languages each team member has
knowledge of. "Highly Skilled" means the team member is very familiar with the
language, "Known" means the team member has some familiarity with the language,
"Pending" means the team member is currently learning the language, and "None" means
the team member has no significant knowledge of how to use the language.
Team Member

Knowledge

Andrew

John

Kenny

Josh

C++

Highly Skilled

Highly Skilled

Highly Skilled

Highly Skilled

Assembly (68K)

Known

Known

None

Known

PHP

None

Known

None

Known

VB.NET

None

Known

None

Known

None

Known

None

Known

HTML/CSS

None

Known

None

Known

Drupal

None

Known

None

None

Linux/Unix shell None

scripting

Known

None

Known

Java

None

None

Known

None

SQL

Pending

None

Pending

None

C#

None

None

Pending

None

Any languages not listed are unknown to any of the team members. Thus, the project
must be conducted entirely using the above languages, unless we wish to invest a large
amount of extra time learning new languages.

If team wishs to use database languages in the project, we will have to wait until Kenny
and Andrew get far enough in their Database class this semester to have learned it.

None of the team members are aware of how to create a single application using multiple
programming languages.

Financial Constraints:

Our customer is unwilling to pay any money.

Our team members are all of limited means financially, and as we are already paying
thousands of dollars for the class alone, we are unlikely to be able to afford spending any
money on the project.

Given the above factors, our budget for this project, not including transportation
expenses, is limited to $0.

Technical Constraints:

Team's program must be capable of running on the professor's computer through an easy
step-by-step process.

The program must be able to run quickly enough so that it's user-friendly.

There is no upper bound given for how much activity the auction system will be
handling, so the program must be capable of running properly even for extremely large
numbers of users and transactions.

The program is designed to be used by ordinary people, so its interface must be easily
usable even by someone with no programming background.

2.0 Project Estimates

2.1 Historical data used for estimates
Estimates for the Software Project Plan were formed by considering our team members writing
speed in the past and estimating the sections length. Estimates for the production of the correct
functionality are based on the complexity of task, past experiences, and employing rigorous
testing once a task is completed. The design section has a minimum of .5 hours for the main
project to ensure sufficient time is dedicated to it.
2.2 Estimations Techniques Applied and Results
Only one estimation was made based on past historical data and educated guesses.
2.3 Estimates
ESTIMATES FOR SOFTWARE PLAN
Section

Group Member
Responsible

1.1
1.2
1.4
2.1
2.3
3.1
3.2
3.3
4.1
4.2

Josh
John
Andrew
Kenny
Kenny
Andrew
Andrew
John
Josh
John

Estimated Time Needed

(Hours)
1
1
1
1
3
3
1
1
1
1

4.3
4.4
5.1
5.2
6.1
6.2
Time Spent in Meetings Estimate:

Andrew
Andrew
Kenny
Kenny
Josh
John

3
1
2
1
2
1
10

Time Spent Revising Final Project:

Presentation 1 Preparations:

6
1

Software Plan Total Estimated Time:

40

ESTIMATES FOR PROGRAM

Task/Base Functionality:
(Hours)
Training in programming languages (in totals)

Estimated Time Needed

36

User Log In/Log out System

Design
Implementation
Testing

1
3
1

Seller:
Post Item to sell with title/description/ Starting Price/End date
Design
Implementation
Testing

1
15
5

View Sellers Items Status (In-progress/Sold)

Design
Implementation
Testing

0.5
3
1

View Totals/History (Total sales/# of items/Total unsold/No bids)

Design
Implementation
Testing
Bidder:

1
10
3

View List of Items purchased (View History) with totals:

-Total $ spent (completed), Number of items bought, Status (in progress/done)
-Total number of bids in progress, Bids winning, $ amount of winning items
Design
Implementation
Testing

2
8
5

Search Function:
Design
Implementation
Testing

1
3
2

Category System for Items

Design
Implementation
Testing
Bid Price Display
- place specified starting bid if no other bids shown
- Shows Highest Bid if More than two bids
Design
Implementation
Testing

1
2
1

0.5
2
2

Bid Payment/Result
-price is second high bid + 10%, charged to winning seller
after time is over
-If no bids, bid ends status changes to completed and no transaction
take place
Design
Implementation
Testing
Keywords in title and description For Search

1
4
2

Design
Implementation
Testing

1
3
2

Database Functionality Development and testing for all features:

20

Total Estimate for Program:

144

ADDITIONAL FUNCTIONALITY
Kennys Additional Functionality
Allow user to change password
Design
Implementation
Testing

0 .5
3
1

If a field has data entered and the user tries to quit then display: are you sure you want to
exit? [name] has data entered into it and will not be saved
Design
Implementation
Testing

0 .5
1
2

Leave an X out of 5 star rating after purchase

Design
Implementation
Testing
Kennys Total:

1
4
2

16

Andrews Additional Functionally

Notify a seller when the end date of an item they listed for sale has been reached.
-Tell the seller what item it was, whether it was successfully sold or not, and if so, how
much it
was sold for.

Design
Implementation
Testing

0.5
2
2

Seller can edit the starting price or end date of an in-progress item they listed for sale, if nobody
has thus far bid on it.
Design
Implementation
Testing

1
3
2

Seller can cancel their listing of an in-progress item if nobody has thus far bid on it.
Design
Implementation
Testing

1
3
2

Bidder notification when the end date of an item they bid on has been reached.
- The notification should tell the bidder the item, if their bid was successful or not, and
the final sale price was.
Design
1
Implementation
4
Testing
3

Let bidder know if they have already made a bid.

-Asks user if new bid should be placed.
Design
Implementation
Testing

1
2
1

Display an error message when an incorrect or nonexistent login id or password is entered.

Design
Implementation
Testing

0.5
1
0.5

Andrews Total: 31.5

Johns Additional Functionality
Security Algorithm
Design
Implementation
Testing

1
4
1

Message Boards
Design
Implementation
Testing
Add comments to a user member
Design
Implementation
Testing

1
3
2

0.5
3
2

Change currency format to European or US style

Design
Implementation
Testing

0.5
2
1

Change data format to European or US style

Design
Implementation
Testing
Johns Total: 24.5
Joshs Additional Functionality:
The list of items sold under each category is in alphabetical order

0.5
2
1

Design
Implementation
Testing

1
2
1

Display an error message when a bidder types in an invalid item to bid on

Design
Implementation
Testing

0.5
2
1

Calculate the average of the ratings to see an overall rating for each seller
Design
Implementation
Testing

1
3
2

Replace password input character with xs

Design
Implementation
Testing

0
1
0.5

Joshs Total: 15

Extra Functionality Group Total:

89

TOTAL ESTIMATED HOURS FOR PROJECT:

Task
Software Plan

Hours
40

Base Functionality
Additional Functionality
Project 2 Completion, Revisions, and Preparations
Group Meetings

151
87
212
35

Total

525

2.4 Project Resources

While a complete team would contain all of the following personnel, A New Hope has four team
members. Each team member will be performing multiple jobs.

Required Staff
o

Project Manger-John

Project Team Leader-John

Business Analyst-John

Software Architect-Kenny

Designer-Andrew

Software Developer-Andrew

Software Tester-Josh

Required Software
o

Microsoft Visual Studio 2012 C++

Microsoft Office (or open source equivalent)

Adobe Photoshop (or open source equivalent)

Microsoft Windows OS

Dropbox

Skype

Google Docs

Required Hardware (to run Visual Studio-Development software)

o

1.6 Ghz or faster processor

1 GB of RAM (1.5 GB if running on a virtual machine)

15 GB (NTFS) of available hard disk space

5400 RPM hard drive

DirectX 9-capable video card running at 1024 x 768 or higher display resolution

3.0 Risk Management

3.1 Project Risks

Loss of Team Member: If a team member were to drop the class, or worse, die.

Indisposed Team Member: If a team member were to become incapacitated or otherwise

unavailable for a significant length of time, such as due to injury, illness, or other
problems.

Personal Data Loss: If a team member's computer or other memory storage device
crashed, causing their work done thus far to be lost.

Online Data Loss: Data we have stored online might be lost, perhaps due to unforeseen
technical difficulties on the part of the website.

Online Data Unavailability: Data we have stored online may be made temporarily
unavailable at an important time, perhaps due to scheduled maintenance on the part of the
website.

Irresponsible Team Member: If a team member were to become irresponsible and refuse
to do the work assigned to them.

Procrastinating Team Member: If a team member were to refuse to do work until the
absolute last minute.

Conflicting Responsibilities: If a team member were to become so busy with other

responsibilities, such as homework or exams from other classes, that they are temporarily
unable to invest time on this project.

Poor Estimates: If we underestimate the amount of time a project task will take, and thus
have less time for later tasks.

Language Incompatibility: If we determine that our chosen language, is incapable of

fulfilling the project's needs, and have to change to a different language.

Changed Requirements: Our customer, the professor, may clarify the assignment, or give
us other instructions that require us to revise our project's technical requirements.

Language Learning Difficulty: One or more of our team members may have difficulty
adjusting to the programming language of choice and thus be incompetent in their coding,
or outright be unavailable to code until they've learned it.

Unable to Meet: School closings or unexpected schedule conflicts might interfere with
team meetings.

Coding Errors: Even once the code is apparently complete, there might be countless
errors that take hours to debug, some of which may even require us to revise our
documentation.

Debugging Difficulties: If the person assigned to do so proves incapable of fixing a

coding error within a reasoable amount of time.

Additional Functionality Problems: If implementing one or more team members' pieces

of additional functionality proved too difficult, time-consuming, or impossible.

Code Merging Difficulties: If the completed functionality coded by different group

members proved incompatible, and need to be changed drastically to make them work
with each other.

Personal Conflict: If a personal conflict between two or more team members occurred,
which might prove disruptive to the group and hurt our progress.

Electronic Sabotage: If malware or hackers damaged a team member's ability to

participate in the project, such as by stealing their online accounts, making their
computers nonfunctional or buggy, or something else along those lines.

Compiler Incompatibilities: If using different compilers caused code written by one team
member on their compiler to not work for the other team member on their differing
compiler.

Time Runs Out: If it looks like we will be unable to meet the project deadline.

3.2: Risk Table

Risk Name

Probability

Loss of Team Member Low

Impact

RM3 Pointer

Critical

Mitigation #1,
Monitoring #3,
Monitoring
#6,Management #2

Indisposed Team
Member

Low

High

Mitigation #1,
Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #2

Personal Data Loss

Medium

High

Mitigation #1,
Monitoring #6

Online Data Loss

Low

Medium

Mitigation #3,
Monitoring #6

Online Data
Unavailability

Low

Irresponsible Team
Member

Low

Medium

Mitigation #3,
Monitoring #6

Critical

Mitigation #1,
Monitoring #5,

Monitoring #6,
Management #2
Procrastinating Team
Member

High

Medium

Monitoring #5,
Monitoring #6,
Management #8

Conflicting
Responsibilities

High

High

Mitigation #8,
Monitoring #2,
Monitoring #6,
Management #2

Poor Estimates

High

Medium

Mitigation #2,
Monitoring #1,
Monitoring #6,
Management #1

Language Incapability Low

High

Mitigation #4,
Monitoring #1,
Monitoring #6,
Management #4

Changed
Requirements

Low

Language Learning
Difficulty

Low

High

Monitoring #6,
Management #3

High

Mitigation #2,
Mitigation #4,
Mitigation #9,
Monitoring #1,
Monitoring #6,
Management #1

Unable to Meet

Medium

Medium

Monitoring #4,
Monitoring #5,
Monitoring #6,
Management #5,
Management #6

Coding Errors

High

High

Mitigation #9,

Monitoring #6,
Management #3
Debugging Difficulties High

High

Mitigation #9,
Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #1,
Management #3

Additional
Functionality
Problems

Medium

Code Merging
Difficulties

High

Low

Monitoring #1,
Monitoring #5,
Monitoring #6

Medium

Mitigation #6,
Mitigation #9,
Monitoring #5,
Monitoring #6,
Management #1

Personal Conflict

Low

High

Monitoring #6

Electronic Sabotage

Low

Varies depending on
severity; potentially
critical.

Mitigation #1,
Mitigation #3,
Mitigation #5,
Monitoring #6,
Management #2

Compiler
Incompatibilities

Low

Time Runs Out

Medium

Low

Mitigation #7,
Monitoring #6

Critical

Mitigation #2,
Mitigation #9,
Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #1
Management #2,
Management #7

3.3: Overview of Risk Mitigation, Monitoring, Management

Mitigation
1. Have a backup for all project work so far completed-- stored online.
2. Allocate an extra amount of time for project tasks - assume that project tasks may take
longer than estimated, and plan accordingly.
3. Team members should not delete any project work they have done even after they upload
them, in case the online data is lost somehow.
4. Team members should begin learning the programming language of choice before we
actually have to code the project - preferably over spring break at the latest.
5. All team members should ensure they have some form of anti-virus and firewall installed.
6. Team members should keep each other informed of the methods by which they are
implementing their portions of the code with short e-mail summaries.
7. All team members should use Microsoft Visual Studio as their compiler.
8. Team members should have slightly reduced workloads during weeks when they have
multiple exams, and should be assigned larger workloads to make up for it on other
weeks when other team members have the same problems.
9. Allocate adequate debugging and testing time in project schedule.
Monitoring
1. If a team member thinks they will not be able to meet their deadline on a task, they
should immediately e-mail the group to say so.
2. Team members should tell the group about any exams or projects from other classes that
may prevent them from working on this project.
3. If a team member feels they may have to drop the class, they should warn the group as
early as possible.
4. If a team member can't make an assigned meeting time, they should say so in advance.
5. The team leader should regularly ask team members how their tasks are progressing.

6. The team should briefly discuss all the project risks, and possible new risks, at least once
per meeting.
Management
1. In the event that a team member is unable to complete a task on their own or takes too
long, team leader should assign another team member to assist them. The two team
members should then meet in person to overcome the hurdle.
2. In the event that a team member is unable or unwilling to do a job, the team leader should
assign another team member to perform the task. If the team member is being
irresponsible, the team leader and the rest of the team should threaten the team member
with negative evaluations.
3. If it becomes necessary to make large revisions of earlier documentation to the point that
it distracts from other project tasks - have one person put in charge of revising all the
earlier documentation as necessary, with the other team members just telling that person
what they changed, so that the rest of the team can focus on the current portion of the
project instead of spending all their time revising the documentation over and over again.
The team leader should OK the final revision for each part of the project. The least adept
coder should preferably be assigned this task.
4. In the event that we have to change programming languages, we should decide at a
meeting whether it would be better to reduce the project scope before we go to the trouble
of starting over with another language, and the team should pick a new language that at
least three people in the group already know, as we are unlikely to have time to learn a
new language.
5. In the event that the group is unable to meet in person, we should hold a group meeting
over Skype.
6. In the event that a member can't make it to a meeting, the team leader should send them
an e-mail summarizing the decisions and results of the meeting.
7. In the event that it looks like we literally cannot meet the deadline for the project, we
should reduce the project scope and just try to have some partially functional program to
turn in.
8. If a team member appears to be procrastinating, the team leader should politely but
incessantly remind them to start their task soon.

4.0 Project Schedule

4.1 Project Task Set

Process Model
1. Model: Waterfall Model

Framework Activities and Activities

2. Compiler: Visual Studio 2012
3. Language: C+

Tasks to be accomplished

Set up a login and password for users to access

Password input replaced by x's

Limit username size between 6-15

First character must be a letter

Sellers lists items available for sell in the database

Keep Track of Seller information

Items to sell

Details about item: Title, Description, Starting price, ending date, total dollar amount,
total unsold, items with no bids

Keep track of Buyer/Bidder information

List of items they purchased with:

Total dollars spent

Number of items

Items they bid on that are in progress with totals:

Number in-progress

Number winning

Dollar amount of winning items

Searching mechanism

Alphabetical list of items

Different categories of items

Looking for words in the title or description

The bidding process

During an in-progress auction, the bidder can place a bid on that items that must be
higher than the current price shown which is starting price if no bids, bid price if one bid
or second high bid + 10% if multiple bids (bid price if bid price is less than second high +
10%)

4.2 Functional Decomposition

Base Functionality:

Seller
o

Ability to choose item categories

Title

Description

Starting Price

Ending Date

List of items

Sold

In-progress

Or both

List of totals for items

$ amount of sales

Number of items

Total unsold (completed)

No bids (in-progress)

Bidder
o

Editable item details

List of items

Purchased with totals

Total $ spent(completed)

Number of items purchased

Items they bid on that are in-progress

List of totals

Number of bids in progress

Number of bids winning

$ amount of winning items

Bidding on in-process items from ANY list

Place specified starting bid if no other bids shown

Place bids higher than current price shown

Bid price if one bid or second high bid + 10% if multiple bids (bid price if
bid price IS LESS than second bid + 10%).

Administration
o

Must have login IDs and passwords

Search by

Category

Additional Functionality:

Seller
o

Which item

Successfully sold or not

If sold, how much sold for

Ability to cancel item if no bids have been placed

Bidder
o

Notify seller when end date of an item listed for sale has been reached

Notify bidder when end date of an item they bid on has been reached

Which item

Successful bid or not

If won, how much bought for

If bidder attempts to place a bid on item, interruption in the system occurs if

bidder has already placed bid on that item.

System notifies bidder they have already placed bid

Asks user if they would still like to place the bid

Leave a X out of 5 star rating after purchase

Administration
o

Display error message when an incorrect or nonexistent login ID or password is

entered

Security algorithms to keep user passwords secure

Allow user to change password

typing in current password, then new password twice

Message board for items being sold

Ability for all users to add comments to a seller or buyers profile

Ability to change currency format to European or US style

Ability to change date format to European or US style

If a field has data entered and the user tries to quit then display: are you sure you
want to exit? [name] has data entered into it and will not be saved

List of items sold under each category can be listed alphabetically

Display error message when a bidder types in an invalid bid

Calculate average of the ratings to sees an overall rating for each seller

Replace password input with x's

Set a limit of user name size between 6-15 with only letters and numbers, first
character must be a letter.

4.3 Task Network and Timeline Chart

Task #

Task

Duration

Predecessors

Meeting 1

.5 hours

Decide Additional Functionality

1 hour

Software Project Plan Section 1

3.75 Hours

Meeting 2

Software Project Plan Section 2

1.5 Hours
4 hours

Software Project Plan Section 3

2.5 Hours

Meeting 3

1.5 Hours

3,4

Software Project Plan Section 4

4 Hours

Software Project Plan Section 5

3 Hours

10

Software Project Plan Section 6

3 Hours

11

Meeting 4

1.5 Hours

5,6,7

12

Software Project Plan Section 7

.5 Hours

11

13

Meeting 5

4 Hours

8,9,10,11,12

14

Software Project Plan Revision

6 Hours

13

15

Project 1 Presentation Preparation

1 Hour

11

16

Project 1 Presentation To Class

15 minutes

14,15

17

Learning Programming Languages

36 Hours

18

Other Meetings

20 Hours

16

19

Project Part 2

200 Hours

16

20

Revisions of Project 1

6 Hours

19

21

Implementing Login Functionality

5 Hours

17,19

22

Implementing Seller Functionality

39.5 Hours

17,19

23

Implementing Buyer Functionality

15 Hours

17,19

24

Implementing Searching Mechanism

12 Hours

17,19

25

Implementing Bidding Process

16 Hours

17,19

26

Implementing Additional Functionality

89 Hours

17,19

27

Revisions of Project 1 and 2

12 Hours

21,22,23,24,25,26,27

28

Final Presentation Preparation

1 Hour

20

Final Presentation

15 minutes

28

Section 5: Staff Organization

5.1 Team Structure
The team roles and responsibilities for the team are determined by who is best suited for each
position. John is the most knowledgeable member of the team so he is the Project Team Leader

and Manager. His responsibilities include ensuring deadlines are met, issues are resolved swiftly,
and that everyone understands what their assignments are.
The project will be divided into database and forms for design. Kenny and Andrew are in a
database class and are better suited to design and implement the tables and queries that will be
required. John and Josh have a background working with form based applications (VB.NET) and
would be better suited to designing how the forms will look, integrate query result data, and
function
The entire team will serve as software developers and testers when writing their own code. Their
responsibility is to ensure the code segment has sufficient comments and delivers on its required
functionality without enormous mistakes or bugs.

5.2 Management Reporting and Communication

The team will hold meetings every Thursday morning at 11:00 AM to discuss current project
progress. For more immediate communication all members have access to each others email,
cell phone numbers, and Skype. In addition, all members will briefly discuss their current status
on Mondays and Wednesday before/after the software engineering classes. Dropbox and email
will be used as primary means to share important artifacts. The team will identify level of
progress by using metrics created during a very detailed design phase.

6.0 Tracking and Control Mechanisms

6.1 Software Quality Assurance
Quality is a key aspect of a product. There are seven elements to assure this.

Application of Technical Methods

Formal Technical Reviews

Software Testing

Control of Change

Measurement

Record Keeping

Reporting

Application of Technical Methods

It's good if you know how to code, but if the planning is bad and you don't understand
what the correct problem is, you will end up with the wrong results

The analyst plays an important role in this. He/She should know how to:

Grasp abstract concepts

Organize solutions to smaller problems

Absorb facts from different sources

Understand the user/client environment

Apply hardware and/or software system elements to the environment

Modeling has to take place

o

Focuses on what the system has to do

Helps in understanding function and behavior to make implementation easier

Helps determine completeness, consistency, and accuracy

Basically a mapped representation

Partitioning
o

A project as a whole is usually very complicated and takes many steps

Breaking down the problem to smaller pieces will make the problem easier,
because doing small increments won't be as complex

Formal Technical Reviews

Preparation for the product is essential

Reviews might include error detection, inspection, a walk through, and other assessments

Doing this is a good learning tool for those who are not that familiar with planning and
design

Meetings are important

Usually during meetings, updates are brought up. Members show their assigned
completed tasks

The next steps might be presented, along with possible changes

Another factor is duration of the meeting

If a meeting is too short, important announcements might be missed

If a meeting is too long, time will be wasted that could be used to work

When a meeting's about to close, and if decisions are made about a project, attendants of
that meeting sign off to indicate that they agree to it and are responsible

If participants don't accomplish what needs to be accomplished, they are then held
responsible
Software Testing

A product isn't deliverable if it doesn't do what you want it to do 100% of the time

A few of the ways to test

o

The college way: When you compile a program, put in values that you know
should work to make sure you get the right result

The business way: Break it! Purposely try and come up with solutions that should
fail. Then you can work from there to fix the errors so eventually you can't
purposely break the program

More than just when the software is completed. It should start early in the project

About 30% of the project involves testing

Control of Change

There will certainly be change some time during a project. Things will come up that are
unavoidable.

The goal is to minimize change

Before a change is to be made, make sure it is necessary

If a change is to occur, there will probably be a cost whether it's time, money, or both

Changes should be analyzed, reported, and recorded

Measurement

perfect

They are based on estimates and prior knowledge and experience

Tasks are measured by time spent and completeness

Measurements turn opinions into facts

Data is gathered and processed. Through measured analysis, there's:

o

Characterization:

Evaluation:

Determine the status with respect to the plans

Prediction:

Gain understanding of process

Through understanding and information, attributes can be predicted

Improvement:

Fixing errors, getting through obstacles, and inefficiencies

Meas
urem
ents
are
never

Record Keeping

Each element of a project needs to be recorded

Everything from diagrams, to outlines, to code, changes, and other elements need to be
written down to document what has been done, and what needs to be done.

When members of a group are assigned tasks, they are recorded so they know what they
are responsible for and are held accountable for those tasks

Report

Going along with recording is the concept of reporting

o

A report is generated from the information that is gathered from the meetings

Some of the information that might be in the report includes:

What was reviewed?

Who reviewed it?

What were the findings?

Conclusions?

6.2 Change management and control

Introduction
The Change Management Plan was created for the CIS375: On-Line Auction System (OAS)
team, A New Hope, in order to set expectations on how the approach to changes will be
managed, what defines a change, the purpose and role of the change control board, and the
overall change management process. All stakeholders will be expected to submit or request
changes to the OAS Project in accordance with this Change Management Plan and all requests
and submissions will follow the process detailed herein.

Change Management Approach

The Change Management approach for the OAS will ensure that all proposed changes are
defined, reviewed, and agreed upon so they can be properly implemented and communicated to
all stakeholders. This approach will also ensure that only changes within the scope of this project
are approved and implemented.
The Change Management approach is not to be confused with the Change Management Process
which will be detailed later in this plan. The Change Management approach consists of three
areas:

Ensure changes are within scope and beneficial to the project

Determine how the change will be implemented

Manage the change as it is implemented

The Change Management process has been designed to make sure this approach is followed for
all changes. By using this approach methodology, the OAS project team will prevent
unnecessary change from occurring and focus its resources only on beneficial changes within the
project scope.

Definitions of Change
There are several types of changes which may be requested and considered for the OAS project.
Depending on the extent and type of proposed changes, changes to the project documentation
and the communication of these changes will be required to include any approved changes into
the project plan and ensure all stakeholders are notified. Types of changes include:

Scheduling Changes: changes which will impact the approved project schedule. These
changes may require fast tracking, crashing, or re-baselining the schedule depending on
the significance of the impact.

Scope Changes: changes which are necessary and impact the projects scope which may
be the result of unforeseen requirements which were not initially planned for. These
changes may also impact the schedule. These changes may require revision to project
scope statement, and other project documentation as necessary.

The project manager must ensure that any approved changes are communicated to the project
stakeholders. Additionally, as changes are approved, the project manager must ensure that the
changes are captured in the project documentation where necessary. These document updates
must then be communicated to the project team and stakeholders as well.

Change Control Board

The Change Control Board (CCB) is the approval authority for all proposed change requests
pertaining to the OAS Project. The purpose of the CCB is to review all change requests,
determine their impacts on the project risk, scope, cost, and schedule, and to approve or deny
each change request. The following chart provides a list of the CCB members for the IS Project:

Name

Position

CCB Role

J. Battaglia

Project Sponsor

CCB Chair

A. Voszatka

Project Manager

CCB Member

J. Major

Project Team Member

CCB Member

K. Urena

Project Team Member

CCB Member

As change requests are submitted to the OAS Project Manager by the project team/stakeholders,
the Project Manager will log the requests in the change log and the CCB will convene every
Thursday to review all change requests. For a change request to be approved, all CCB members
must vote in favor. In the event more information is needed for a particular change request, the
request will be deferred and sent back to the requestor for more information or clarification. If a
change is deemed critical, an ad hoc CCB meeting can be called in order to review the change
prior to the next scheduled weekly CCB meeting.

Roles and Responsibilities

The following are the roles and responsibilities for all change management efforts related to the
OAS Project:
Project Sponsor:

Approve all changes to budget/funding allocations

Approve all changes to schedule baseline

Approve any changes in project scope

Chair the CCB

Project Manager:

Receive and log all change requests from project stakeholders

Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB

Seek clarification from change requesters on any open issues or concerns

Make documentation revisions/edits as necessary for all approved changes

Participate on CCB

Project Team/Stakeholders:

Submit all change requests on standard organizational change request forms

Provide all applicable information and detail on change request forms

Be prepared to address questions regarding any submitted change requests

Provide feedback as necessary on impact of proposed changes

Change Control Process

The Change Control Process for the OAS Project will follow the organizational standard change
process for all projects. The project manager has overall responsibility for executing the change
management process for each change request.
1. Identify the need for a change (Stakeholders) Change requester will submit a completed
change request form to the project manager.
2. Log change in the change request register (Project Manager) The project manager will
keep a log of all submitted change requests throughout the projects lifecycle.
3. Evaluate the change (Project Manager, Team, Requester) The project manager will
conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and
scope and seek clarification from team members and the change requester.
4. Submit change request to CCB (Project Manager) The project manager will submit the
change request, as well as the preliminary analysis, to the CCB for review.
5. Obtain Decision on change request (CCB) The CCB will discuss the proposed change
and decide whether or not it will be approved based on all submitted information.
6. Implement change (Project Manager) If a change is approved by the CCB, the project
manager will update and re-baseline project documentation as necessary.

Sponsor Acceptance

Date:

7.0 Appendix
Customer Requirements: