Technologie & Riskprofile  


 Anforderungs definition 

 Techn. Unterstützung 

New Page 1







Wir sind ein neu gegründetes  Unternehmen für IT-Dienstleistungen und –Beratung in der Stadtverwaltung, Energieversorgungswirtschaft und Telekommunikation.

wir setzen neueste SAP ERP BI SOA BOBJ Technologien ein – für die optimale Unterstützung unserer Kunden.

Wir entwickeln Lösungen nach Maß – aus der Theorie für die Praxis.

Wir bieten den vollen IT-Service inkl. Anforderungsdefinition für alle betrieblichen Prozesse.


Page 2 of 55
IBB METRONET Breitband FiberOptik beratung&Trainingsprojekt.doc
                                                         Prof.Dr.Mehmet Erdas 23.11.2005
Project Definition Document
<Enter Project Name Here>
Issue <Enter Revision Number>   Dated <Enter Date>
Client Company
<Enter Client Company's Name>
Client Sponsor
<Enter Client Sponsor's Name>
Project Manager
<Enter Project Manager's Name>
Project Number
<Enter Project Number>
Cross Reference
<Enter associated documents here - below are ones currently referenced - delete this note>
Statement of Work
Microsoft Project Plan (schedule)
Project Contact List
Project Meetings Attendance List
Project Information Distribution List
Risk Register
INVESTMENT PROTECTION: NPV, IRR, Pay-back periods, Obsoleteness
Tendering Process and Methodology: How to choose best of the best!
-Guidelines for engagements and deliverables value-chain (legal, administrative, technical, financial, social-environmental decision rules, regulations, factors.)
-Templates, tools, forms, samples, checklists, procedures and standards
-A training tool for how to do contracting, consulting in specific technologies and projects
-A technical resource for bidding tendering contracting people
     -A consistent transparent open clear message internally, to clients and  
       Industry and Trade
·        Proposal check-list first phase:
Doc. location
1.     Feature list (All requirements evaluated and prioritised with regard to customer) Feature Description (short)
2.     Business case (benefit, volume data, price/cost. The basic economic feasibility has been verified)
3.     Tendering Staff planning (Availability of resources and skills within the requested time frame verified, make-or-buy options considered)
PLM/ R&D/ Service/ factory
4.     Tendering Process Checklist completed
5.     Roadmap updated/ more detailed information provided
6.     O&M inter-working clarified
7.     Manufacturing/ Pre-integration centre ramp-up started
PLM/ Service
8.     Pricing Proposal
9.     Version strategy (upgrade, swap ...)
10.           Operator business case
11.           Milestone-plan/ Project-schedule
12.           Customer Feedback assessment
PLM/ Mgr.
·        Proposal Check-list second Phase:
document location
1.     Updated feature list as part of the package (from the customers viewpoint)
2.     Description of features and feature interaction in the package
3.     Version concept (up-grade/  ....)
4.     Description of user interface,Ergonomy
5.     Product industrial design
6.     Testing and field trial concept (incl. volumes)
PLM/ Service/ R&D/ System Test
7.     Pilot project concept
PLM/ Sales/ Service/ R&D/ System Test
8.     Description of system environment/corresponding products
PLM/ Service/ R&D
9.     Conformity with the Roadmap(s) and or regional/local supplements
10.           Marketing concept, including country/customer group and channel strategies
11.           Set-up of Service concept started
12.           Logistics concept (Procurement; Manufacturing concept incl. manufacturing test concepts)
13.           Support tools; procurement tools concept (e.g. configurator, )
14.           Documentation concept (work-split, schedule, content, structure, inclusive/ exclusive)
who? (not PLM!)
15.           Regulatory agency requirements
16.           Training concept
Service/ Training centre
17.           Environment protection, technical safety (EU-Environmental Regulations); recycling concept
18.           Data/ information security concept
19.           Phase-out concept for predecessor products and corresponding products
PLM/ Service
20.           up-dated Resource plan
PLM/ R&D/ Service
21.           Business case (see Tendering Process guidelines)
22.           Risk analysis, patent and license situation clarified
23.           Product Quality Agreement (PQA) plan
24.           Contractual conditions for out-sourced /OEM products
PLM/ Log
25.           Project Schedule dates/ Milestones up-dated
PLM/ R&D/ Service
·        Third Phase check-list:
·        task
document location
1.     Pilot project report available
2.     O&M subjects released
3.     Release for parts procurement
4.     Development release notification
5.     Internal conformity notification (CE)
6.     Systems Fault-Match set up done
Service/ R&D
7.     Tendering Process Checklist updated
8.     Spare log
Log/ Service
9.     Restriction list
Service/ R&D/ Log/ PLM
10.           Maintenance procedures defined/ described
11.           Upgrade/ review (inclusive product return) procedures
R&D/ Service/ Log
12.           Configuration data available
13.           Assembly instructions
14.           Logistics and order fulfillment ready for use
15.           Buy-Make notification
16.           Service information available
17.           Acceptance test cases (ATMN)
R&D/ Service
18.           Enabling offer and execution (Tools and order processing procedures are deployed and in place)
19.           Business case (WPP) has been updated
20.           Basic data available
21.           Re-Sales, Re-Production enabling
22.           Customer and internal documentation according to doc. concept available
PLM/ Service/ R&D/ Log
23.           Product training (for sales, service and customer) available according to training concept
Service/ Training center / PLM
24.           Planned Product support (technical documentation) is in place.
0.1 Issue Control
0.2 History
0.3 References Info.Sources
0.3.1 User Features
0.3.2 Design Features
0.3.3 Operational Features
0.3.4 Affected Systems and Product Group(s)
0.3.5 Additional relevant Documentation
0.4 Glossary and Abbreviations
0.5 Keyword/Descriptor
0.6 List of Figures and Tables
·     2 SYSTEM STRUCTURE        
·     3 REALIZATION(Production Process, QA QC TQM)
3.1 Feature Description        
3.1.1 Short Description        
3.1.2 Functional Description Functionality Different realizations of the same functionality Authorization Access Accounting Configuration Management Performance Management Maintenance and Safeguarding Modular Design, Program Controlled Operation and Maintenance Services Subsystems Performance Management      KPI BSC Benchmarking values… and Safeguarding         18 Recommendations Restrictions Man Machine Interface (Operator) Man Machine Interface (User) Error Symptoms, Diagnostics Manual
3.1.3 Additional Impacts Inter-working with other Features Prerequisites    
3.1.4 Sub-features       
3.1.5 Checklist for Inter-working between Features Existing Functions for expendability, adaptability, interface interoperability, universality... Configuration Management Object Model Generics Protocols Overall end-to-end Systems Performance Management Security Management Access Authentication Accountability Control Access Control Object Model New Functions for ... Configuration Management Object Model Generic Admin Feature Control Object Model Realization Client Provider Alternative solutions Overall Maintenance and Safeguarding Shut-down, Emergency, Recovery Alarms and Notifications Alternative solutions Security Management Restrictions
3.2 Interface Descriptions
4.1 Test Data     
4.2 Test Data Remarks        
·     5 APPENDIX
5.1.3 Final Closing Remarks (Minimum Requirements Definition)    
         Example: All elements of the software (not just source code)The code
       The updates
       The data and databases
       The online user instruction
       The interfaces
       The user manuals
       The training materials
       The development and maintenance documentation
       The test planning
       The test scripts
       Anything else which is not clearly hardware
         All stakeholder valued aspects of system performance, including quality and savings
       And very many more
Marketing management
 Market intelligence
   Distribution channels
     Technical support marketing
        Integrated marketing comms
            Marketing operations
Just-in Time Logistics
Just-in Time Procurement
Just-in Time Fulfillment
Just-in Time Service Solutions
Just-in Time Contracts & negotiations
Just-in Time Business development
Just-in Time Service Operations
§ Dedication to every client’s user`s success
§ Innovation that matters – for IBB and for Istanbul, Turkey, World
§ Trust and personal responsibility in all relationships
§ Cultural Awareness
§ Equal Opportunity
§ Work/Life Balance
§ Connecting through communities and collaboration
§ Assess skills & competencies / Update development plan
§ Participate in learning activities
§ Checkpoint/ Feedback
§ Performance evaluation
§ Compensation &
§ future opportunities
§ Foundational Competencies
§ Trustability, dependability, reliability
§ Honesty
§ ….

Acceptance Sign-Off
If this PDD is used for internal purposes only and will not be shared with the client, remove this page. This may be the case if using a separate Cost Management PDD versus the ‘single source’ PDD, which includes all plans. In all cases, delete this paragraph.
[Document Title]
Client:        [Client]
IBB Sec.Geneal : [Enter region name]
Project Code:      [Enter project code]
Engagement Kickoff Date:   [Enter project start date]
Final Presentation Date:       [Enter date PDD was presented/reviewed]
We have reviewed and agreed to the information described in this Project Definition Document and referenced attachments.
____________________________________   ___________________
[Client Representative, Title] Date
[Client Company]

Distribution List
Revision History
Initial Draft

Paragraph &     Description          Page
Title Page i
Acceptance Signoff      ii
Distribution List iii
Revision History iii
Table of Contents        iv
1.0    Purpose     1
2.0    Project Overview & Background 2
2.1    Project Overview         2
2.2    Business Needs Addressed by the Project         2
2.3    Related Business Needs Not Addressed by This Project     2
3.0    Project Organization and Responsibilities       3
3.1    Key Team Members    3
3.2    Committees         3
3.3    Contact List        3
3.4    Roles & Responsibilities        4
3.5    Client Participation     4
4.0    Program or Project Interrelationships    5
4.1    <Program Name>        5
4.2    <Project Name> 5
4.3    <Project Name> 5
5.0    Project Scope of Work 6
5.1    Project Objectives        6
5.2    Statement of Work      6
5.3    Project Deliverables     6
5.4    Work Breakdown Structure 6
5.5    Client Mandates, Processes & Preferences       6
5.6    Project Constraints      7
5.7    Project Priorities (cost vs. time vs. quality)       7
5.8    Assumptions and Dependencies     8
6.0    Schedule & Milestones 11
6.1    Milestones 11
6.2    Estimated Schedule      11
7.0    Technical Requirements        12
8.0    Acceptance Plan 14
8.1    Purpose     14
8.2    Deliverable or Milestone Acceptance Plans      14
8.3    <Enter Deliverable or Milestone Name> 14
8.4    <Enter Deliverable or Milestone Name> 15
8.5    <Enter Deliverable or Milestone Name> 15
9.0    Quality Plan       16
9.1    Purpose     16
9.2    Quality Control 16
9.3    Documentation   17
9.4    Reports      18
9.5    Service Level Agreements     18
9.6    Client Satisfaction Survey    18
10.0 Communications Plan 19
10.1 Purpose     19
10.2 Scheduled Meetings     19
10.3 Information Distribution      20
10.4 Project Close-out Process      20
11.0 Risk Management Plan        21
11.1 Purpose     21
11.2 Risk Management Process    21
11.3 Risk Register       22
11.4 Risk Prevention & Response Actions      22
11.5 Risk Contingency Plans        23
12.0 Change Management & Control Plan    23
12.1 Purpose     23
12.2 Change Management Process        23
12.3 Change Documentation        24
13.0 Escalation Plan   26
13.1 Purpose     26
13.2 Escalation Philosophy 26
13.3 Escalation Levels         27
13.4 Escalation Procedures 27
13.5 Escalation Path & Responsibilities 27
13.6 Definition of Critical Item Categories     27
13.7 Escalation Methodology       29
14.0 Jeopardy Plan    31
14.1 Purpose     31
14.2 Definition of Project Jeopardy Categories       31
14.3 Jeopardy Escalation Path & Responsibilities   32
14.4 Jeopardy Process Flow         32

Figure        Description          Page
Figure 1:    Change Request / Order Form (Front)   24
Figure 2:    Change Request / Order Form (Back)    25
Table         Description          Page
Table 1:     Requirements Management Process        12

The purpose of the Project Definition Document is to provide a documented repository for all project plans, either in a single document or in a set of documents. This is a living document intended to be updated throughout the project as plans are refined, changed or updated.
If any of the statements below are true - use the individual Project Definition Documents  for your project. This is the 'single source' file which includes all the project plans (risk, communications, change management, etc.). There are also separate PDDocs for each plan that can be used individually.
·The project requires certain plan be shared with a limited number of people Some plans are changed more frequently than others
·Only a limited number of plans will be shared with the client
Any text in colour is for development guidance purposes only and should be deleted upon distribution. For more information visit the process (function) page for each plan to aid in development.

[This section describes the background that led up to the engagement and gives a brief overview of the project. Provide a description of the intended purpose of the solution that the project addresses. This includes an outline of the main users of the solution and the benefits that are anticipated by the client from its implementation.
[This section describes the clients business requirements that are driving the engagement. This section describes what the client needs to accomplish, from a business standpoint. The client may be merging with another company, creating a new distributed order entry capability, or adding offices and people at a rate that is unsustainable with the current infrastructure. Business requirements could include budget and time constraints. Business requirements should not be confused with functional requirements or system requirements. There may be multiple business objectives or requirements.]
[Describe other needs or problems that may be related to this project but are not directly addressed by this project.   These business needs/problems and their potential solutions may be addressed in the "Recommendations" section of the Project Description Doc.]

The following table identifies the project sponsor, managers, team leaders, and other core team members. See the Project Contact List file for a more detailed list of other team members and stakeholders.

Mahir Ver
<Client Name
CTO, Project Sponsor
IBB Gen.Sek.
Program Manager
Project Manager
Account Manager
Team Leader, Security

Describe any committees (e.g., change control board, steering committee, red team, etc.) that are established for the project or already in place that service the project. Describe the responsibility for each group and identify the members either here or in the Project Contact List matrix section.


See the related Project Contact List file for a list of all project team members and stakeholders and their contact information, including phone numbers and email addresses.

The following summarizes the overall roles & responsibilities for the project. See the project Work Breakdown Structure or schedule for more specific resource responsibilities/assignments.

<Client Name>
IBB Gen.Sek.
<3rd Party>

It is important to clearly define all planned client participation. This includes any client involvement in the design or requirements definition and planning process and client review periods for items such as design reviews or test results reviews, etc. These must be clearly defined with time limits measured from the date of request or delivery so that there will be no question as to the client's responsibility for timely participation.
Also see the Logistics and Administration section for client dependencies in the area of facilities, security and information access and support needs.

[Describe in this section how this project relates to an overall program or other projects (if applicable)]
Program Manager: <enter name>
[Describe relationship]
Project Manager: <enter name>
[Describe relationship]
Project Manager: <enter name>
[Describe relationship]

[For Fixed price contracts, if a detailed statement of work includes all the elements below simply reference that document here as a substitution for the following sub-sections. Time & Materials contract]
[Describe in detail what the project is to accomplish in terms of its objectives. The scope of work is the solution to those objectives so avoid getting into detail about the project's scope.]
[Include a copy of the statement of work or reference it as an external document]
[List all deliverables and be sure to specifically identify what documentation will be provided to the client with each deliverable]
[Include the Work Breakdown Structure here in outline fashion. It is sufficient to list it without schedule information since the schedule is referenced in another area.]
[Include for Time & Material contract-based projects only]
[This section describes what is absolutely required by the client and what is preferred (but not absolutely required). This allows tradeoffs to be made, when necessary, on the basis of what is most important to the client. Client mandates and preferences may apply to the project scope and constraints. For example, ten of the twenty routers must be upgraded by the first of the month, but the client prefers that all twenty be upgraded. This is an example of a mandate and a preference relating to scope and a constraint (time).]

5.5.1Mandatory Requirements
[What MUST the client have for the project to be a success and for IBB Gen.Sek. to perform under the contractual terms?]
5.5.2Nice to Have Requirements
[What would the client like to have but is not absolutely necessary for performance of the contract.]
This section documents any constraints on the project and their origination date. The origination date will assist in managing constraints that are derived from project changes or additional planning activities.
[Examples of constraints could be:]
·Overall End-to-End Network performance
·Functionality (certain functions must be available when the project is completed). This is closely related to project objectives.
·The network may be available for changes only during certain small windows of time. This could place constraints on the project.

Origination Date

[Each member of the team should understand the client's priorities in terms of the order of importance for the triple constraints (time, cost and quality). This section attempts to document how the client would prefer that decisions be made when they involve tradeoffs among these constraints. Some projects may be driven entirely by cost, others by time, and others by quality. Each of these can be broken down into much more detail and the client's priorities documented as they relate to each. This can provide vital information in managing the project.]

This section describes any project-related assumptions and client dependencies. Assumptions are factors that, for planning purposes, will be considered to be true, real, or certain.
5.8.1Client Dependencies
If applicable, reference the Contract or Contract Statement of Work. Otherwise, describe those items here. Any other dependencies defined during the project should be documented and agreed to with the client.
Some examples of assumptions are:
·Client support and cooperation will be forthcoming
·Work will be done during normal business hours (M-F, 8-5)
·The Client will complete all activities for which the Client is responsible according to the project work plan and schedule.
·The Client will provide access to Client's information as reasonably required by Lucent NPS to perform its obligations under the contract.
·Lucent NPS is assuming that the Client will provide fast turnaround time on critical decisions, essential information and approvals which are required to continue with work in progress, or which is critical to meeting a deliverable due date. IBB Sec.Gen. expects that a decision will be elevated to the appropriate level within the Client's organization to make a decision in a timely manner.
·The Client will provide, on time, any personnel resources as mutually agreed upon and as incorporated into the project work plan.
·Any other assumptions that could significantly affect project performance
5.8.2Logistics and Administration
This section describes in detail the support that the client has agreed to supply. The table below lists all necessary support items required for IBB to begin and execute project-related work.
[Delete items not needed]

Client Contact
Planned Supply Date
Actual Supply Date
Conference room or meeting room space
Office or cubicle space
Lab space
Staging and/or configuration space
Security & Access
Keys and access cards to facilities
System and network accounts and passwords
Network access
Host access
Accounts on client e-mail system
Test equipment
Software and hardware
Fax machines
A/V equipment
Administrative support
Client team members
Client project manager
Other client personnel made available
Network manager/administrator access
Client-supplied client contact list (including roles, responsibilities, and authority)
Vendor and subcontractor contact list
Network documentation, designs, etc.

Status key:
·Done = Item has been addressed and is completed.
·Open = Item has not been addressed or is not completed
·N/A = Item has not been addressed and is not related to this project.
·P = Item has been addressed and some issue resolution is needed to complete the item or annotate it as "N/A."

The following defines the milestones identified as part of this project

Milestone Name
Target Date

See the Microsoft Project file for the detailed schedule

The technical requirement's definition should be the complete statement of requirements available at the time of contract signature and a description of the planned approach to gathering and defining requirements once contract delivery begins.
In either case, the requirement's information should be included here or referenced as a separate document.
The table below may be used if requirement's definition is part of the contracted services.

Table 1:     Requirements Management Process
Develop specific approach to plan and manage all aspects of a project.
Allocate Resources
Identify Client Resources
Determine Agreeable Techniques and Standards
Determine Evaluation Parameters
Build Client Plan
Collect information from which the client's requirements will be determined.
Determine Requirement Sources
Determine Method to Obtain Information
Store Obtained Information
Survey of Facilities
Access to Data Storage
Analyze the implications of the client's requirements.
Define and detail requirements.
Define and link to existing documents.
Perform Root Cause Analysis
Verify Completeness of Information.
Comparison to Prior Assumption Sets
Validate mutual understanding of the client requirements and implications of client impact.
Determine Validation Participants
Determine Levels of Detail
Confirm Validated Techniques
Complete Requirements management
Lab Testing


The acceptance criteria for each contract deliverable must be defined in sufficient detail to remove ambiguity.
The Customer Acceptance Plan addresses each deliverable or milestone with the following:
·Contracted deliverables (if pertaining to a milestone)
·Evidence of delivery or installation
·Evidence of passage of quality standards such as SLAs and other performance or testing measures
·Customer acceptance criteria
·Customer acceptance process & format
·Mapping to invoice and payment plan
Use either the term deliverable or milestone depending on your project and edit the header of each section below (and the one above) to reflect this. If any of the sections under the deliverable header is the same for all simply raise it to a higher header level and note the similarity.
8.3.1Delivery Method & Quality Demonstration
Describe how the customer will know that the deliverable has been delivered, installed, created, etc. This may range from a visual inspection to user acceptance testing.
Also describe how IBB will demonstrate that the deliverable has passed quality standards such as SLAs and other performance or testing measures. This may involve the presentation of a report, other documentation, visual inspection, etc.

8.3.2Acceptance Criteria
Describe criteria for acceptance. This does not necessitate describing the specific quality standards that must be met - this may say "meets agreed-upon quality standards" and references those in the Quality Plan or these sections may be combined.
8.3.3Acceptance Process & Format
Review the contract T & C's and the Statement of Work to identify the general requirements for acceptance criteria, responsibilities and/or procedures which have been specified (this may not be applicable in all cases. Define and document the reporting/tracking and client sign-off procedures to be used during acceptance
This may be the same for each deliverable/milestone. Group or individualize this section accordingly.
8.3.4Invoicing & Payment
Describe the related invoicing & payment process for the deliverable or milestone.
[Paste in above sub-sections for each deliverable or milestone]
[Paste in above sub-sections for each deliverable or milestone]

The Quality Plan identifies the quality requirements for this project and the criteria for meeting these requirements as well as the activities defined for meeting quality requirements and the organization(s) responsible.
This section lists the major quality control activities related to each deliverable as well as the responsible organization.
[These activities (and associated efforts) must be included in the project's charts and schedules. There is no need to identify dates or timeframes here as those are included in the schedule]

Quality Control Activity(ies)
Responsible Organization


This section identifies the documentation that describes the development, testing, and implementation of the quality activities as well as identifying the review or audit that will confirm the acceptability of each document.
[Typical technical documents requiring review and audit are:]
·Requirements Specification
·Systems Design Specification
·Functional Specifications
·Design Specifications
·User Documentation
·Test Plans
·Development Plan
·Standards and Procedures Manual
·Conversion Plan
·Installation Plan
·Training Plan

Documentation Title
Document Purpose
File Name
Document Reviewer(s)


This section identifies the reports that will be used to provide status regarding and communicate quality activities.
Typical quality documents to be collected and maintained include, but are not limited to:
·Audit and review reports
·Problem reports
·Metrics data
·Test results
·Corrective action plans and status
[This section will describe the Service Level Agreements that must be adhered to as part of the contract]
The Client Satisfaction Survey is administered upon the project's completion. This survey provides valuable feedback from the client to IBB regarding project performance. As the survey is requested from more than 1 party, the following information assists with the survey's administration:
Survey administered by:       <Enter IBB Project Manager's name or Quality group representative>

Survey to be Completed By
Email Address
Telephone Number


This section describes the process for project communications and information distribution to the client.
[Client satisfaction surveys have indicated that good communications is one of the MOST important factors in their satisfaction!]
The following table lists the regularly scheduled project meetings. See the Project Meetings Attendance List for a list of all meeting attendees.
[It is IBB policy to provide regular status reports to, and status meetings with, the client. The frequency and format for the meetings is documented below.]

Day & Time
Location or Bridge Number
Agenda Distributed By
Minutes Distributed By
Project Kickoff Meeting
Weekly Internal Status Meeting
Weekly Client Status Meeting
Milestone Readiness Review
Milestone Review
Final Client Project Review
(Enter or edit as necessary)


The following table lists the project reports and information that will be developed and distributed as part of this project. See the Project Information Distribution List for a list of all regular recipients of these documents.

Document or Data
Distribution Frequency
Distributed By
Status Report
Action Item Register
Status Meeting Minutes
(Enter or edit as necessary)

This section documents what will occur after the last work is done. This should describe the closeout meeting that will follow a phase or the final project.

This plan will outline the processes and procedures that will be used to identify, evaluate, prioritize and manage the risks inherent in the project.
The Risk Management Process is divided into two areas, risk management planning and risk management tracking and control. Risk management planning consists of the following steps:
1.      Identify risks
2.      Assess risks
3.      Select risk to manage
4.      Define risk avoidance, mitigation, and contingency approaches
5.      Document the Risk Management Plan
6.      Implement risk management approaches
7.      Provide risk status
8.      Review and improve risk management plan (steps 1 to 5), to include the following:
§Review periodically all risk avoidance, mitigation and contingency actions
§Evaluate the effectiveness for current risk avoidance and/or mitigation activities

The Risk Register will be used to document identified risks, their likelihood and impact.
Provide a list of risks below (better for smaller projects) OR reference the Risk Register (Excel version) as an external document.
Fixed Price projects that require risk Cost Impact calculations should use the external Risk Register (Excel version) to perform calculations and maintain cost impact data. All risk lists are linked by their "ID #"
If using the external Risk Register delete the table below & add the text "The Risk Register may be found in a separate file"

ID #
Risk Issue
Risk Exposure
(P) * (I)
“Project Stopper”

All risks selected to be managed have avoidance, mitigation and contingency actions defined for implementation. These actions will be periodically reviewed for currency and effectiveness. Note that some actions may be defined for more than 1 risk when some risks are similar in nature and exposure.
If using the external Risk Register delete the table below & add the text "The Risk Register may be found in a separate file"

ID #
Risk Issue
Avoidance or Mitigation Plan
Assigned Party


Contingency plans for risks which cannot be avoided or mitigated are defined below.
If using the external Risk Register delete the table below & add the text "The Risk Register may be found in a separate file"

ID #
Risk Issue
Contingency Plan
Assigned Party

The purpose of the Change Management Plan is to define the processes and forms that will be used in controlling changes that are made to the project. Changes may be initiated by a Lucent or client stakeholder and will need to be evaluated, reviewed and formally agreed-to before including in the project plan.
The change management process is defined to facilitate the recognition, processing, and closure of project changes. The overall process is as follows:
1.      Initiation - Change need expressed
2.      Evaluation - Determination as to whether the initiated change is in scope or out of scope and it's impact from a technical, scope, cost, schedule, quality and risk perspective. The change is logged and evaluated by members of the IBB Project Management program and project team.
3.      Negotiation - The customer and IBB negotiate the terms and conditions of the change.
4.      Documentation - The negotiated changes are documented formally in a new or revised contract.
5.      Inform Stakeholders & Implementation - The change is formally communicated to all stakeholder organizations, such as the project team, supporting functional organizations, subcontractors, customer, etc.

A Change Request / Order Form will be used to initiate, process and track all proposed project changes. A sample form is shown below.
Any initiated, rejected or agreed-to change will be logged in the Change Log. This is used to track changes in a summary form throughout the project.
Figure 1:    Change Request / Order Form (Front)

Figure 2:    Change Request / Order Form (Back)

The Escalation Plan describes the process and people involved in escalating project issues and jeopardies. The Project Escalation Plan is used to surface all critical items that potentially have an impact on the project. Those items that move through the various (two, for example) stages of the Escalation Plan would then move into the Jeopardy Plan. It should be noted that some issues are of such a nature that they may be immediately escalated to a Project Jeopardy status. The Jeopardy Plan is used solely by the Project Manager and stakeholders, to communicate the elevation of a critical item to the Project Jeopardy category. Once this occurs, the Jeopardy Plan is used to resolve the jeopardy.
[Note that this plan is used and should be agreed to with both the client and IBB]
The escalation philosophy that should be understood, actualized, and reviewed thoroughly is summarized in the following points:
1.      Escalation is a reality of Project implementation. In today's environment with resource constraints and heavy workloads, escalation becomes inevitable.
2.      Escalation is a normal business alternative, which should not become a personal or emotional event. It would be naive to believe that the emotional aspects of escalation can be eliminated, but they must be minimized.
3.      The Project Manager should monitor the progress of the escalated issue.
4.      The Escalation Plan should be reviewed and explained at the Project Kickoff meeting with the entire team.
5.      The Project Manager's procedure is to notify the involved parties of the timetable, i.e., the length of time given to resolve the problem. The steps in the timetable are simplified below:
(a)     Identify the involved person and/or organizational entity
(b)     Define the interval allowed to the entity to escalate within their organization to resolve the problem.
(c)     Follow-up on the problem resolution.

There are two levels of escalation, Critical Item-Level 1 (CI-1) and Critical Item-Level 2 (CI-2), that are rated upon the severity of the problem and potential effects to the Program/Projects. CI-1 and CI-2 are resolved using the Escalation Plan. If a CI cannot be resolved in the required time-frame, it may be escalated to a Jeopardy status and be handled within the Jeopardy Plan.
The Escalation Plan is an extremely important project control tool. The Plan is designed to communicate and resolve problems (roadblocks) as quickly as possible, which will avert a jeopardy status. Typically, there are various critical items, below are those most impacting to a Project/Program; there are also two levels of concern; Critical Item-Level 1 (CI-1) and Critical Item-Level 2 (CI-2). CIs can escalate from one level to another anytime within the Plan that it is deemed appropriate.
The following defines the specific person or persons on the escalation path. This includes escalation for Critical Items and Jeopardies.

Item Type
Issued By
Distribution List
Critical Item-Level 1 (CI-1)
Project Manager
Critical Item-Level 2 (CI-2)
Project Manager
Jeopardy Alert
Project Manager
Jeopardy Declaration
Project Manager or Program Manager
Jeopardy Clearance
Project Manager or Program Manager

The following paragraphs describe the Critical Item categories for the Project Management Escalation Plan.

13.6.1Critical Item-Level 1
A Critical Item-Level 1 is issued when something is placing a deliverable, contract milestone, cutover date, etc. in immediate danger and it has a profound affect on the overall project. Immediate action is required to bring the critical path activity(s) back on schedule and to avoid a project delay and/or escalation to Project Jeopardy. The critical path must be reworked and replanned to meet the scheduled cutover. Several examples are:
·A Project Manager fails to provide the necessary and agreed upon resources to complete a critical path task on schedule. The project is nearing jeopardy.
·Failure to deliver a critical piece of equipment on schedule. The equipment delivery and installation are on the critical path. The project is nearing jeopardy.
·A major software technical problem surfaces during installation and testing. The estimated problem resolution date puts the project in danger of jeopardy.
13.6.2Critical Item-Level 2
A Critical Item-Level 2 is issued when something may endanger a deliverable, contract milestone, cutover date, etc. Immediate action must be taken to ensure that the problem does not impact critical path activities. Two examples are:
·An essential task not on the critical path is missed and the slack time to complete the task is nearly depleted. If steps are not taken to relieve the situation, before the slack is consumed, the situation may endanger the cutover date.
·A Project team member anticipates that a non-critical path activity may not start on schedule. If the task does not start on schedule, it will become critical and cause a project delay.
A Critical Item-Level 2 could also be issued when a commitment is required but not received or a commitment is missed. The cut-over date is not in immediate danger. Two examples are:
·A Project team member needs a resource commitment from another team member but is unable to obtain that commitment. The resource commitment is needed but there is no immediate impact on the Project.
·Someone with a role in the Project misses a commitment to start a non-critical path activity on schedule but the Project is not in jeopardy.

An Escalation Memo Form may be issued by any Project team member. Typically, it is either the person responsible for, or about to receive, input from another team or organization. The following is an explanation of each step in the Escalation flow.
1.      Project team member identifies a problem or situation that may effect their own or another's ability to complete an activity on time. The situation should be investigated to determine the impact to the Project, root cause, entities involved, action required to relieve the problem, drop dead dates for resolution, and the ramifications if not relieved.
2.      The Project team member who is initiating the escalation determines if the CI is internal, customer, or a supplier organization. If CI is internal, proceed with step 7.
3.      If escalation is to the customer or supplier organization, the originator escalates to the Program/Project Manager.
4.      The Program/Project Manager escalates the CI to the client Single Point of Contact (SPOC).
5.      The customer or supplier SPOC escalates the CI within their organization. Proceed to step 11.
6.      The originator completes the Escalation Memorandum Form and forwards it to the Program/Project Manager via electronic mail or fax. This step is to notify the Program/Project Management organization that a CI situation exists and escalation is in progress by the functional entity.
7.      The originator determines if escalation is within their organization or to another internal organization. If escalation is within their organization, proceed with step 9. If escalation is to another organization, proceed with step 8.
8.      Should the escalation involve another entity, the originating organization has responsibility to escalate within that entity or entities, to the District Level if necessary. The level of CI should be determined by the severity of the problem and level of authority required to resolve the problem. Should the CI not be resolved at this step, the escalation will go directly to District Level as notification. The CI could escalate to a higher level anytime deemed appropriate during this Plan. If so, proceed to step 10.

9.      The Program/Project team member escalate the CI to the appropriate level within their own organization. The level of CI should be determined by the severity of the problem and the level of authority required to resolve the CI. Should the CI not be resolved at this, the escalation will go directly to district Level as notification. The CI could escalate to a higher level anytime deemed appropriate during this Plan.
10.    During the execution of the Escalation Plan, the Program/Project team member provides Program/Project Manager with written status in the form of a memo attached to the original Escalation Memorandum.
11.    A Resolution Plan will be developed and implemented within 48 hours, or an appropriate of time depending on the severity, Project impact, etc. If resolved, the Program/Project Manager will be notified to close the Escalation Memorandum.
12.    When the Resolution Plan has been implemented, the Program/Project team member provides Program/Project Manager with written status in the form of a memo attached to the original Escalation Memorandum.
13.    The Program/Project team member (originator) determines whether or not the CI is resolved. If the CI is resolved, proceed with step 18. If the CI is not resolved, proceed with step 14.
14.    The Program core team members and/or Project Manager forwards the Escalation Memorandum with a request for escalation to a Program Jeopardy to the Program Manager via e-mail or fax.
15.    The Program Manager verifies that the functional entities followed the escalation plan and all appropriate management levels have been involved.
16.    The Program Manager issues the formal Jeopardy Notice using the defined Jeopardy Plan (refer to the Project Management Jeopardy Plan document [1]).
17.    The Program/Project Manager closes out the formal Escalation Memorandum when CI (or Project Jeopardy) is resolved.
18.    Once the critical item is resolved, the Program/Project Manager notifies the Program/Project team with an explanation of the resolution.

Project jeopardy is a very serious condition that implies that the success of the project may be impacted if the jeopardy is not resolved quickly. The issue usually has a profound impact on the team's ability to meet major contract deliverables. Once a jeopardy is issued, all those involved, including Executive management and stakeholders, should do everything in their power to aid in the development of a resolution plan immediately.
The Jeopardy Plan is an extremely important Project control tool. The Plan is designed to communicate and resolve Jeopardy issues as quickly as possible while minimizing the impact on the Project. The Jeopardy Plan defines the following:
·Jeopardy Definition - What constitutes a jeopardy, how an escalation becomes a jeopardy
·Jeopardy Declaration - How to declare an jeopardy, which stakeholders are notified of jeopardies
·Jeopardy Clearance - How to clear a jeopardy, when is the jeopardy cleared.
The following paragraphs provided the definitions for the different categories of Project Management Jeopardy.
14.2.1Project Jeopardy-Alert
The Project Jeopardy-Alert stage is the initial stage for a Critical Item that has been escalated to Project Jeopardy. The Project Manager works directly with the appropriate level of management within the project or program (if a Program, Program Manager, otherwise the Engagement Manager). Everyone involved understands that if the Jeopardy is not resolved during the Alert stage, the next step is to formally issue the Jeopardy through the path defined in the Escalation Plan.

14.2.2Project Jeopardy-Declared
The Project Jeopardy-Declared stage is the highest stage a Jeopardy can reach. The Jeopardy has been formally issued and distributed to all executive management and associated stakeholders. The Jeopardy could not be resolved in the Alert stage and thus, all involved need to develop a Resolution Plan on how to move forward. This is a critical level because these jeopardies have a major impact on the Project Manager's ability to successfully deliver the Project.
14.2.3Project Jeopardy-Clearance
The Project Jeopardy-Clearance stage is the final stage of a Jeopardy. The Project Manager formally declares the Project Jeopardy closed and all appropriate documentation is updated to reflect this.
See Escalation Path & Responsibilities section for a list of responsible parties in the event of a jeopardy.
The Jeopardy Plan begins when the Escalation Plan has unsuccessfully attempted to resolve a Critical Item. This item has developed into an issue that threatens the success of the Project and thus, has been declared a Jeopardy candidate. Perform the following procedures to engage the Project Management Jeopardy Plan to resolve a Critical Item:
1.      The Project Manager assesses the Critical Item and decides if it is necessary to declare a Project Jeopardy. The first stage is to issue a Jeopardy Alert
2.      The Project Manager issues a Jeopardy Alert. This is done using the Jeopardy Notification Report via e-mail. The Jeopardy-Alert may only be sent to select Stakeholders or it may be sent to the entire distribution list. This is the decision of the Project Manager.
3.      The Project Manager works directly with Program and/or Engagement Management and Stakeholders to attempt to resolve the issue.
4.      If the Jeopardy Alert is resolved, proceed to step 6, otherwise go to step 5.
5.      The Project Manager must now formally issue a Project Jeopardy-Declared. This is done by updating the original Jeopardy Notification Report (refer to Appendix A) and redistribute via email. This should be sent to the ALL Executive Management and Stakeholders defined in the Escalation path.

6.      If the Jeopardy Alert is resolved, then the Item is closed out both from the Jeopardy Plan and also from the Escalation Plan. The Jeopardy logs should be updated and Lessons Learned documented.
7.      The Jeopardy Notification Report with Jeopardy-Declared is received by Executive Management and Project Stakeholders.
8.      Appropriate Project Team management is also notified.
9.      Acknowledgment of the receipt of the Jeopardy by all recipients is sent to the Project Manager
10.    The Project Manager schedules a Jeopardy Review with all Stakeholders within 48 hours.
11.    The Jeopardy Review is held either in person or via conference call. In addition, a Jeopardy Resolution Plan is developed and status reviews are scheduled.
12.    The Resolution Plan is communicated to all appropriate Team members, Stakeholders, and any other groups included in the Resolution Plan.
13.    Actions are initiated. The time frame from the Jeopardy Issuance to the initiation of appropriate actions should not exceed 48 hours. All actions need to be monitored and tracked by the Project Team. These actions need to be documented as part of the Jeopardy Notification Report.
It is very important to note that replanning and rework of the Project Schedule is implied for anything that affects time or cost. Replanning is a constant throughout the life of a Project.
14.    Progress Reports should be distributed to all appropriate Stakeholders on a weekly or as needed basis.
15.    A Jeopardy Status Review Meeting is held to determine if progress is being made on the Jeopardy Resolution Plan.
16.    If Jeopardy-Clearance is issued by the Project Manager, proceed to step 18. Otherwise, proceed to step 17.
17.    The Jeopardy Resolution Plan should be reviewed, and if necessary, modified to address progress that has been made. The next Jeopardy Review should be scheduled.
18.    If the Jeopardy is resolved, then the Item is closed out both from the Jeopardy Plan and also from the Escalation Plan. The Jeopardy Notification Report is updated to reflect Jeopardy-Clearance. The Jeopardy logs should be updated and lessons learned documented.






Copyright © 2008 Mehmetrdassapbidanismani.com Tüm Hakları Saklıdır..



Web Tasarım ve Kodlama: ATLASDİZAYN.NET