PERFORMANCE BIKE
®
CRM SYSTEM
INFO 638-900 ASSIGNMENT 3
PROJECT CONTROL & MANAGEMENT
GROUP 5
B R A D C L O U S E R B D C 3 7 @ D R E X E L . E D U P R I N C E T I T U S C O D J O E P T C 2 9 @ D R E X E L . E D U C H R I S T E N S Y L V E S T E R C A S 3 6 3 @ D R E X E L . E D U T E R E N C E T U H I N A N S H U T T 3 5 8 @ D R E X E L . E D U N O V E M B E R 1 5 , 2 0 0 9PERFORMANCE BIKE CRM SYSTEM
INFO 638-900 ASSIGNMENT 3TAB L E O F C O N T E N T S
TABLE OF CONTENTS... 2
INTRODUCTION... 5
PROJECT STATUS REPORTING METHOD ... 5
OVERVIEW OF STATUS REPORTING FOR PERFORMANCE BICYCLE CRM SYSTEM... 6
WEEKLY STATUS REPORT DESCRIPTION... 6
ORIGINATOR ... 6
RECEIVER ... 6
FREQUENCY... 7
TIME-SCOPE ... 7
CONTENTS... 7
WEEKLY ISSUES REPORT DESCRIPTION... 7
ORIGINATOR ... 7
RECEIVER ... 8
FREQUENCY... 8
TIME-SCOPE ... 8
CONTENTS... 8
WEEKLY PROJECT OVERVIEW DESCRIPTION ... 8
ORIGINATOR ... 8
RECEIVER ... 9
FREQUENCY... 9
TIME-SCOPE ... 9
MEETING DETAILS ... 9
TYPE I – PROJECT STATUS MEETINGS... 10
PURPOSE ... 10
AGENDA... 10
ATTENDEES ... 10
FREQUENCY... 10
OUTCOMES ... 10
TYPE II - PROJECT STAKEHOLDERS MEETINGS... 10
PURPOSE ... 10
AGENDA... 11
ATTENDEES ... 11
FREQUENCY... 11
OUTCOMES ... 11
TYPE III – EXECUTIVE OVERVIEW MEETINGS ... 11
PURPOSE ... 11
AGENDA... 11
ATTENDEES ... 11
FREQUENCY... 11
OUTCOMES ... 12
TYPE IV – RISK IDENTIFICATION MEETINGS... 12
PURPOSE ... 12
AGENDA... 12
ATTENDEES ... 12
FREQUENCY... 12
OUTCOMES ... 12
TYPE V – TEAM/INDIVIDUAL DEVELOPMENT MEETINGS... 12
AGENDA... 12
ATTENDEES ... 12
FREQUENCY... 13
OUTCOMES ... 13
TYPE VI – LESSONS LEARNED MEETINGS... 13
PURPOSE ... 13
AGENDA... 13
ATTENDEES ... 13
FREQUENCY... 13
OUTCOMES ... 13
CHANGE CONTROL PROCESS ...13
RISK ANALYSIS ...16
APPENDIX ... 20
APPENDIX A – WEEKLY STATUS REPORT EXAMPLE ... 20
APPENDIX B – WEEKLY ISSUES REPORT EXAMPLE ... 21
APPENDIX C – WEEKLY PROJECT OVERVIEW EXAMPLE... 22
APPENDIX D – PROBLEM LOG INSERT FORM... 23
I N T R O D U C T I O N
This paper outlines the project control and management procedures for the Performance Bicycle CRM system. It provides details on the project status reporting methods, meeting details, change control processes, and risk analysis. These processes are intended to be implemented throughout the life of the project.
P R O J E C T S TA T U S R E P O RT I N G M E T H O D
In order to monitor the progress of the development of Performance Bike’s CRM system, periodic status reports must be completed. The goal of these status reports is to update project stakeholders with timely, complete, clear, accurate information and serve as an early warning system so problems can be identified while there is still time to fix them.
While status reports are important, it’s also important that the creation of these reports does not present an undue burden to the point of becoming counterproductive. For this reason, we will focus on the status reports that provide the most value: Weekly Status Reports from the programmers and designers to their activity managers, Weekly Issue Reports from the activity managers to the project manager, and a Weekly Project Overview Reports from the project manager to Performance Bike upper management. These reports are described in detail in their respective sections. Examples of all three reports can be found in the Appendix.
The following diagram shows how these three reports will be used, and how project status will be communicated up the chain of command and finally to Performance Bike management.
OVERVIEW OF STATUS REPORTING FOR PERFORMANCE BICYCLE CRM SYSTEM Performance Bicycle Management Project Manager Training Specialist Development Manager Infrastructure Manager Weekly Issues Report Design Manager Weekly Issues Report Weekly Issues Report Weekly Issues Report Weekly Project Overview
Weekly Status Report
Weekly Status Report Weekly Status Report
ENGINEERS Database Administrator Microsoft System Engineer Network Engineer Web Security Expert DEVELOPERS / TESTERS System Testers Website Programmers C++ Developer Technical Writer DESIGNERS / ANALYSTS GUI Designer POS Business Analyst ERP Business Analyst Social Marketers Web Trends Analyst Social Media Analyst System Analysts
WEEKLY STATUS REPORT DESCRIPTION
The Weekly Status Report is prepared by the project designers, programmers, and engineers for their activity managers. It looks at the past week, and explains the detailed, granular work that has been done that week. A sample of this report can be found in Appendix A.
ORIGINATOR
The Weekly Status Report is prepared by the first-level designers, developers, and engineers as shown in the diagram in the previous section. For example, all the personnel under the design manager (including marketers, designers, and analysts) would contribute their input into a single report, with a different section for each of them.
RECEIVER
After the report is finished, it is submitted to the activity manager. Continuing with the example above, the report would be delivered to the design manager, who would review the different sections prepared by the different members of his/her team.
FREQUENCY
The Weekly Status Report is prepared weekly, and submitted to the activity manager every Monday. This allows the team to include any last-minute work that needed to be wrapped up over the weekend, if necessary.
TIME-SCOPE
The Weekly Status Report is a current period report. It only looks at things that have taken place since the last Weekly Status Report. Therefore, each report will look at the period of time from Monday – Sunday each week. This allows the report to contain very granular data without ballooning into a 100+ page report as the project progresses. The report can, however, discuss follow-ups to previous problems that were performed during that week.
CONTENTS
Activity managers are interested in very granular data. For this reason, the Weekly Status Report is a current period report that covers only the most recently completed week. It shows the status of tasks that were assigned to be completed or worked on during that week. It contains the following two sections:
Complete Activities
This section shows those activities that were completed this week, as scheduled. It also shows tasks that were scheduled to be completed in previous weeks, but were behind schedule and not completed until this week. The report shows the total man-hours the task required, and a brief summary of any issues of which the task manager should be aware.
Incomplete Activities
This section shows those activities that were scheduled to be completed this week, but were not. Explanations of why these activities are behind schedule should be very detailed. This section should make up the majority of the report, since these are the issues that the task manager is most interested in. The report should explain what caused the task to be behind schedule and provide information on what additional resources, if any, the developer needs to complete the task as soon as possible. It should also contain an estimate of when the developer expects the task to be completed.
WEEKLY ISSUES REPORT DESCRIPTION
The Weekly Issues Report isn’t as detailed as the Weekly Status Report. It doesn’t cover everything that was done in the previous week. Instead, it is an exception report. It focuses on the “Incomplete Activities” in the previously mentioned report. It brings the project manager up to date on behind-schedule tasks that could potentially impact the entire project’s timeline and/or budget. A sample of this report can be found in Appendix B.
ORIGINATOR
The Weekly Issues Report is prepared by the task managers. They review the Weekly Status Report provided to them by their respective departments, and take any corrective actions needed to get any past-due tasks back on schedule. If there are any issues that are significantly behind schedule or any critical-path components that are even slightly behind schedule (or have the potential to slip behind schedule), they include these in the Weekly Issues Report. They also include any completed or incomplete tasks that are significantly over budget.
RECEIVER
The Weekly Issues Report is received by the project manager. The project manager’s two biggest concerns are schedule and budget. Therefore, the project manager is interested in the granular data for any tasks that are behind schedule and could potentially impact the entire project’s timeline. He/she is also interested in the granular data for any tasks that are significantly over budget.
FREQUENCY
The Weekly Issues Report is prepared weekly, and submitted to the project manager every Tuesday. This gives the task managers a day to prepare it, since they receive their Weekly Status Reports on Monday from their respective departments.
TIME-SCOPE
The Weekly Issues Report is an exception report. As such, it reports variances from the planned schedule, no matter when they occurred. Therefore, it is a cumulative report. Tasks that are behind schedule are not removed from the report until they are completed. Therefore, the time scope for this report is from the start of the project (or the earliest scheduled completion date of all the behind-schedule tasks) to the current week.
CONTENTS
The project manager is most interested in keeping the project on schedule and within budget. Because of this, he/she needs to be made aware of anything that could potentially threaten either of these two goals. The Weekly Issues Report is an exception report. It lists all the tasks that are behind schedule or over budget, and gives detailed granular data about what caused this to occur, what steps the task manager has already taken to resolve the issue, and what resources are needed to get the task completed as quickly as possible. The report also clearly highlights any behind schedule tasks that are on the project’s critical path. On a separate page, the report contains an EV graph for all tasks currently in progress. This shows at a glance how many of the current tasks are ahead-of or behind schedule.
In addition to behind-schedule tasks, the report also includes any tasks that are significantly over budget. These tasks need to be monitored closely as they have the potential to threaten the budget for the entire project.
WEEKLY PROJECT OVERVIEW DESCRIPTION
The Weekly Project Overview is prepared by the project manager for Performance Bike upper management. It is a summary of the project as completed thus far. It is graphical in nature, and does not contain detailed granular data. Its purpose is to highlight accomplishments and give upper management an idea of where the project is compared to the planned schedule and budget. A sample of this report can be found in Appendix C.
ORIGINATOR
The Weekly Project Overview is prepared by the project manager for Performance Bike upper management. The project manager starts with last week’s Weekly Project Overview and updates it, adding on data for the most recent week.
RECEIVER
The Weekly Project Overview is prepared for Performance Bike upper management. Upper management isn’t concerned with the granular details of the project. They just want to know how to project is progressing, and if it’s still going to be completed on time and within budget. The Weekly Project Overview was designed to communicate this information as clearly and concisely as possible. FREQUENCY
The Weekly Project Overview is prepared weekly, and submitted to Performance Bike upper management every Wednesday. This gives the project manager one day to prepare the report, since he/she receives the Weekly Issues Report (discussed in the previous section) on Tuesday.
TIME-SCOPE
The Weekly Project Overview is cumulative. It represents everything that has been accomplished in the project since the first day, and up to the most recently ended week. All graphs and charts are updated to include the most recent week, and any new accomplishments are added to the report.
CONTENTS
The Weekly Project Overview is a high-level report for Performance Bicycle’s upper management. It spares them all the granular details and provides a very high-level view of the project’s health. Management’s main concern is that the project is progressing as scheduled and within budget. Therefore, these two important indices have been displayed graphically as the first item on the report. (See Appendix C) Also, it shows any project accomplishments from this past week. This can be re-assuring for system owners to see tangible progress being made. The Weekly Project Overview meets the needs of upper management without providing too much information. It’s important to remember that while the project manager is working on this project full time, upper management is performing their regular duties in addition to receiving project status updates. Therefore, we should make the information as clear and concise as possible. The project health graphics and high-level accomplishments provide the information upper management is interested in, without the details. However, management should know that details are available upon request.
M E E T I N G D E TA I L S
Since the scope of this assignment starts once the project has begun, kick-off meetings and meetings regarding analysis, design, business requirements, and technical design prior to the start of the project will not be discussed. Five important meeting types will be outlined: project status meetings, project stakeholders meetings, executive overview meetings, risk identification meetings, team/individual development meetings, and lessons learned meetings. Each meeting has a defined purpose, agenda, list of attendees, frequency, and outcomes.
The CRM Project Sharepoint Site will be used as the project workspace and will house all documentation discussed in project meetings, including the project schedule, budget status, action items in the form of task and deliverable lists with status, defect status and reporting, all technical and user documentation, and weekly project updates in the form of meeting agendas and post-meeting minutes. Sharepoint is an excellent tool for document control because it will keep track of all document revision history and is compatible with all MS Office document types as well as other common document types. The project manager can also build workflows in Sharepoint to manage the distribution of updates to lists and tasks.
All meetings will be held face-to-face when possible. However, there will most likely be a need for virtual meetings, in which case Microsoft Live Meeting or Skype will be used to communicate and share documents and information.
TYPE I – PROJECT STATUS MEETINGS
PURPOSE
The project status meeting will serve as an informational exchange amongst the CRM project team leads and business subject matter experts. Project tasks will be reviewed, new tasks will be defined and assigned, and issues will be brought to the group’s attention. Weekly priorities will be established so that team members have goals to meet by the following week’s meeting. The project timeline will be reviewed so everyone is made aware of any important changes or upcoming deadlines.
AGENDA
Detailed Project Task Review New Task Definition
Discuss Issues and Roadblocks Set Weekly Priorities
Review Timeline ATTENDEES
Project Manager, Technology Lead, Business Lead, CRM Business Analyst, ERP Business Analyst, POS Business Analyst, Reporting Business Analyst, Marketing Lead, Developers, Business SMEs.
FREQUENCY
Weekly, Mondays, 30 min - 1 hr OUTCOMES
Adds, Updates, and Deletes to the Project Issues List Adds, Updates, and Deletes to Individual Tasks List Updates to Project Timeline
List of the Top Priorities for the Week
List of Items to be Reviewed with Stakeholders
TYPE II - PROJECT STAKEHOLDERS MEETINGS
PURPOSE
Initially, this meeting will provide an overview of the project, stakeholders, system benefits and business functionality that will be included in the project. This meeting will introduce the project to departments and establish cooperative working relationships so that the project will succeed. The ongoing purpose of this meeting will be to keep project stakeholder aware of the progress made to date and any key issues affecting the project. Throughout the project, changes that are to come and the need to start preparing for them will be discussed.
AGENDA
Overall Project Status Communications
Stakeholder Participation Key Successes and Challenges
Set and Manage Expectations on Timelines and Budget Future Activities
Questions ATTENDEES
Project Manager, Project Stakeholders from each business function FREQUENCY
Bi-weekly, Tuesdays, 1 hr
This meeting will be held one day after the project status meeting so important outcomes from the status meeting can be discussed amongst stakeholders.
OUTCOMES
Decisions on issues raised by the project team leads List of Items to be Reviewed with the Executive Team
TYPE III – EXECUTIVE OVERVIEW MEETINGS
PURPOSE
This is an opportunity for the project manager and stakeholders to report progress and discuss key project issues with the executive team. The project team can also confirm that the project is still aligned with organizational goals and objectives and ask for guidance when the path to success is unclear.
AGENDA
Overall Project Status Key risks and issues Solicit executive input
Confirm project is aligned with organizational vision ATTENDEES
Project Manager, CIO, CEO, CFO, COO, Key Stakeholders that may reinforce importance of specific issues
FREQUENCY
OUTCOMES
Decisions on issues raised by the project stakeholders List of questions posed to the project team
TYPE IV – RISK IDENTIFICATION MEETINGS
PURPOSE
A failure analysis will be conducted in this meeting to determine any potential risks and their impact on the project scope and/or timeline. Strategies and action plans for reducing the identified risks will be created.
AGENDA
Review Feedback from Status and Stakeholder meetings Project Timeline Review
Failure Analysis Define Risks ATTENDEES
Project Manager, Technology Representative, SMEs, Stakeholders, BAs FREQUENCY
Bi-weekly, Tuesdays, 1 hr
This meeting should take place after the project status meetings and stakeholder meetings for a given week so feedback from those meetings can be incorporated in the failure analysis.
OUTCOMES
Prioritized list of risks Mitigation strategy
TYPE V – TEAM/INDIVIDUAL DEVELOPMENT MEETINGS
PURPOSE
The purpose of team and individual meetings is to provide coaching and mentoring to team members. There may be communication issues between team members that need to be hashed out, or they may be a specific team member whose performance has been either outstanding or sub-par, one case calling for recognition and the other for a discussion of improvement opportunities.
AGENDA
Off-Site Lunch or Small Event Informal Discussion of Issues ATTENDEES
FREQUENCY
Monthly, Fridays, 2 hrs OUTCOMES
Plan to resolve outstanding issues More cohesive team
TYPE VI – LESSONS LEARNED MEETINGS
PURPOSE
This meeting serves as a way to learn from mistakes made throughout the project and benefit from those learnings for the remainder of the project and in future projects. It is also an opportunity to highlight communication methods that worked well, work strategies that were successful, and other key contributors to success.
AGENDA
Discuss strategies that worked well throughout the project Discuss opportunities to improve communication
Discuss opportunities to improve workflow
Discuss effectiveness of meetings and potential changes to structure and frequency Discuss ways to improve overall project management
ATTENDEES
Project Manager, Technology Lead, Business Lead, CRM Business Analyst, ERP Business Analyst, POS Business Analyst, Reporting Business Analyst, Marketing Lead, Developers
FREQUENCY
After completion of each project milestone OUTCOMES
List of best practices
C H A N G E C O N T R O L P R O C E S S
During the course of the project, there are many things that can stall its progress and would have to be addressed. They could come from three main sources: Performance Bike staff and customers who will use the system and members of the software contracted company. The changes could be the following:
Id Change Type Possibilities Possible Requesters
1 Computational Incorrect operand in equation Incorrect use of parentheses Incorrect/inaccurate equation Rounding or truncation error
2 Logic Incorrect operand in logical expression Logic out of sequence
Wrong variable being checked Missing logic or condition test Loop iterated incorrect number of
times
Developers
3 Input Incorrect format
Input read from incorrect location End-of-file missing or encountered
prematurely
Performance Bike employee (user)
Tester Developer 4 Data Handling Data file not available
Data referenced out-of-bounds Data initialization
Variable used as flag or index not set properly
Data not properly defined/dimensioned Subscripting error
Developers
5 Output Data written to different location Incorrect format
Incomplete or missing output Output garbled or misleading
Performance Bike employee (user)
Tester Developer 6 Interface Software/hardware interface
Software/user interface Software/database interface Software/software interface
Performance Bike employee (user)
Tester Developer 7 Operations COTS/GOTS software change
Configuration control
Delay in buying of COTS product
Performance Bike employee (user)
8 Performance Time limit exceeded Storage limit exceeded Code or design inefficient Network efficiency
Performance Bike employee (user)
9 Specifications System/System Interface incorrect/inadequate Requirements specification incorrect/inadequate
User manual/training inadequate
Performance Bike employee (user)
10 Improvement Improve existing function Improve interface
Performance Bike employee (user)
Customer 11 Staff Turnover Loss of personnel Developers
Using a problem report, a Performance Bike staff, tester or developer identifies a desired change, e.g., a delay in needed servers. The problem report is then reviewed by an analyst at the location and then checks with other problem reports to cross out duplication and ensure the reporter understood the system. The analyst then categorizes the problem putting it under one of the twelve possibilities of change shown in the table above. Depending on the change, the analyst fills the change request form with the following fields: (1) Project Name, (2) Change Requested By (3) Date Change Requested (4) Description of Change, (5) Business Justification, (6) Action, (7) Approved by, (8) Date
An analyst could be a developer or program manager. The analyst checks it with a problem log to make sure of uniqueness. The log sheet has the following fields: (1) ID Number, (2) Date logged, (3) Description of the problem, (4) Impact if not resolved, (5) The problem owner, (6) Action to be taken, (7) Status, (8) Outcome
If the problem is software oriented it is submitted to a user board for validation and to a software maintenance engineer for independent evaluation based on three criteria: (1) effort required to complete the change, (2) computer resources required, and (3) impact on the quality of service. The engineer makes the effort estimate based on the taxonomy of change types described later. If this independent analysis is 20 percent greater or less than original user's estimates, the user and engineer meet to resolve the difference. This often helps clarify the requirement. [Stark G. E.]
Next, at the risk identification meeting, the change request form is categorized as either a modification or a fix. A modification is a change which is not part of the current system and a fix seeks to correct a fault. From there, a priority is placed on it as emergency, high-priority, urgent, or routine.
After acceptance, it is placed in line for inclusion in a version release. All stakeholders then negotiate the version content. This planning and approval process will include a review of several metrics: release complexity, software reliability, software maintainability, and computer resource utilization.
The maintenance configuration control board then reviews the release plan and schedules the release.
The software engineering team then completes the design, code, test, installation, and quality assurance of the release, with user and system engineering reviews at milestone dates throughout the release [Stark G. E.]
R I S K A N A L Y S I S
This project is developed using Incremental SDPM, and hence has traditional internal risks such as resource contention, rework, schedule slippages, team changes, etc. Specific to the activities performed, we can identify the following risks:
Risk Name Risk Description
1. Incorrect user profiling The user profile template is incomplete or incorrect. All data that is stored will follow a wrong model.
2. Website model not persuasive
The functionality of the system rests on large part on the user
contributions. If the advertising or marketing is not persuasive enough, then there won’t be any real data to work with.
websites interface system will have to take those changes into account. But if they change mid-development some systems will have to be updated or potentially remodeled.
4. System management not powerful enough
We use COTS for the System Management component. It is possible that some features of the system evolve beyond what COTS can support. 5. Data warehouse inflexible
The data model may change with time. If the data warehouse design or implementation is inflexible, then the database could not be updated to match the data model.
6. Fixed definition of management reports
Management may need any type of statistic to support decision making. If the reports are strongly defined and cannot be changed on the fly, the reporting will be ineffective and cumbersome. Making generic models to fit any report is extremely difficult.
7. Department interfaces may not serve functionality properly
The specialized dept interface is used to capture point of service data about users, but if it interferes with the original service process then it becomes counter-productive.
8. Security issues
Because the system accepts input from the e-Commerce website, the order data is sent to two locations. This complicates the security and
transactional integrity procedures, and there could be loopholes.
9. Training incomplete
Many components like the service dept or the POS components involve existing store employees doing regular tasks in new ways. This change in human practice will have to be monitored, and any supplementary training which may be needed will have to be arranged.
We can prioritize these risks by assessing their likelihood and severity as follows:
Risk Name Risk Likelihood 0 - 9 Risk Severity 1 - 10 Risk Significance 0 - 90 Risk Priority 1 - 9 1. Incorrect user profiling 5 8 40 2 2. Website model not persuasive 6 5 30 5 3. Change in external social websites interface 8 3 24 6 4. System management not powerful enough 6 6 36 3 5. Data warehouse inflexible 5 7 35 4 6. Fixed definition of management reports 4 4 16 7 7. Department interfaces may not serve functionality properly 6 5 30 5 8. Security issues 6 6 36 3 9. Training incomplete 8 7 56 1
Using these identified risks, we can declare the primary risk drivers in this project:
B. Weak Analysis: Of requirements and user profiles. C. Security Issues: A result of insecure design.
D. Ineffective User Motivation: The appeal of public presentation. E. Inflexibility: The system is unable to adapt.
Based on these analyses, we can devise static and dynamic risk contingency plans. The static plan will be used to initially define the risk management policies with respect to specific risks identified. The dynamic plan evaluates how the risk drivers affect different parts of the system.
Risk Priority Risk Name Static Prevention Plan
1 9. Training incomplete
Client representatives will be constantly involved with design process. Mentors within the staff body can be identified and appointed who learn the ins and outs of the system, and can communicate it to their peers. Most importantly, some level of user involvement will be present at all stages, minimizing the suddenness of change.
2 1. Incorrect user profiling
The user profile must be studied and designed with the utmost care. Specialists in the fields of psychology will be brought in for expert judgment.
3 8. Security issues
The current security model will be evaluated to look for weaknesses. Data transmission will be designed to minimize sets of information, so that the most critical data can go through in a single secure message, and routine data can be sent over a standard connection. 3 4. System management not powerful enough
Some components may have to be written manually in the future if they do not fall under the domain of COTS.
4 5. Data warehouse inflexible
The data warehouse must be designed to be open to extension. Design must be well documented to allow maintenance staff to understand it. Data best practices must be followed to ensure standard implementation that is easy to understand and translate.
5 7. Department interfaces may not serve functionality properly
They must be as unobtrusive as possible, needing minimal additional effort on part of the service agent and gathering data implicitly as much as possible.
5 2. Website model not persuasive
The website must follow existing web standards that allow users to navigate easily. The design must expose its functionality completely. It must be supplemented and advertised in other media.
6 3. Change in external social websites interface
The logic of gathering data must be separated from the scaffolding that retrieves the data, so that changes have minimum effect.
7 6. Fixed definition of management reports
The Management reporting tool must be easily extensible, and provide scripting support. There will need to be a post of scripting specialist created who would have the skills needed to manipulate this system.
Dynamic Risk Drivers 1 - 3 Activity A B C D E Total Requirement Analysis 1 3 1 2 3 10 Training Website 1 2 2 3 1 9 External Social Websites Component 1 2 2 1 3 9 System Management Component 2 2 2 1 2 9 Data Warehouse 1 3 2 1 3 10 Management Reporting 3 3 1 1 2 10 Specialized Dept Interfaces 3 2 1 1 1 8 e-Commerce Website 1 1 3 1 2 8 Point of Sale Component 3 2 1 1 1 8 Total 16 20 15 12 18 81/150 From the above table, we can draw the following conclusions:
No particular stage of development is at much higher risk than any other. All stages have stable and consistent risk levels.
The Risk Driver B, Weak Analysis, affects most systems of them all, and hence must be monitored closely. Not only must more effort be put into the prevention of this risk, but it must be actively observed because its results can be disastrous.
A P P E N D I X
APPENDIX A – WEEKLY STATUS REPORT EXAMPLE
Performance Bike CRM Development
Weekly Status Report
ORIGINATOR Design Team
RECEIVER Design Manager
FREQUENCY Weekly
TIME-SCOPE 11/09/2009 – 11/15/2009
Complete Activities
Activity Name – Description Total Man Hours
Incomplete Activities
Task 1
1. Task Name – Description 2. Task Description
3. Why is it behind schedule?
4. What extra resources are needed? 5. When will it be completed?
Task 2
1. Task Name – Description 2. Task Description
3. Why is it behind schedule?
4. What extra resources are needed? 5. When will it be completed?
APPENDIX B – WEEKLY ISSUES REPORT EXAMPLE
Performance Bike CRM Development
Weekly Issues Report
ORIGINATOR Design Manager
RECEIVER Project Manager
FREQUENCY Weekly
TIME-SCOPE 11/09/2009 – 11/15/2009
Critical Path Issues
Issues Description Percent Complete
Days Behind Schedule
Non-Critical Path Issues
Issues Description CompletePercent Days Behind Schedule
Over Budget Issues
Issues Description Original Budget Projected Cost
Issue Details
APPENDIX C – WEEKLY PROJECT OVERVIEW EXAMPLE
Performance Bike CRM Development
Weekly Project Overview
ORIGINATOR Project Manager
RECEIVER Performance Bicycle Management
FREQUENCY Weekly
TIME-SCOPE 11/09/2009 – 11/15/2009
Project Status at a Glance
This Week’s Accomplishments
Accomplishment #1 Description Accomplishment #2 Description Accomplishment #3 Description
Previous Accomplishments
Short Description Week Accomplished
Accomplishment 4 3
Accomplishment 5 2
APPENDIX D – PROBLEM LOG INSERT FORM
Performance Bike CRM Development
Problem Log Insert Form
ID NUMBER DATE LOGGED
THE PROBLEM OWNER STATUS
OUTCOME
1. Description of the Problem
2. Impact if not resolved
APPENDIX E – CHANGE REQUEST FORM
Performance Bike CRM Development
Change Request Form
PROJECT NAME
CHANGE REQUESTED BY DATE CHANGE REQUESTED TIME-SCOPE 1. Description of Change 2. Business Justification 3. Action Approved by Date _______________________________ ________________
