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:
