项目变更流程Change Control Procedure.docx

项目变更流程Change Control Procedure.docx

《项目变更流程Change Control Procedure.docx》由会员分享，可在线阅读，更多相关《项目变更流程Change Control Procedure.docx（9页珍藏版）》请在冰豆网上搜索。

项目变更流程ChangeControlProcedure

1.DocumentOverview

1.1PurposeandScope

ThisdocumentestablishestheproceduresformanagingchangesonCaradigmServicesImplementationprojects.Itdefinesaprocessforrequestingchangestoprojectschedules,cost,resources,anddocumentation.Italsodescribesthenecessarycontrolsrequiredtodocument,approveandtrackthesechanges.

TheScopeofthisprocedureisanychangethataffectsdesignartifactsor“batch”（DesignInputs,Outputs,Verification,Validation,orTransferArtifacts）whichmustfollowthechangecontrolprocess.

ThisdocumentwaswrittenforusebymembersofCaradigmServicesimplementationteams.

1.2Parentdocument

∙CaradigmQualityManual

∙CaradigmImplementationMethodologyOverview

1.3RelatedReferences

∙DocumentControlProcedure

∙DesignControlProcedure

∙RiskManagementWorkInstruction

∙RiskManagementLogTemplate

∙ChangeRequestTemplate

∙ChangeControlRegister

1.4Terminology

ThefollowingtermsoccurinCaradigmMethodologydocuments.

TERM

DEFINITION

Batch

ForCaradigmServices,a“batch”isthedeliverableasdesignedandconfigured.

ChangeControl

AChangeControlProcedureisrequiredforallchangesthatcanpotentiallyimpactdesign,includinganydesignplanning,input,output,Verification,Validation,orartifact.Designplanningencompassesresources,capabilities,costorschedule.FormaldeliverablesaretobeunderChangeControloncebaselinedorapproved.

ChangeRequest（CR）

Achangerequestisusedtohandlepotentialchangestocapabilities,processes,anddesigndocuments（inputs,outputs,Verification,Validation,andartifacts）.

ChangeOrder（CO）

Theterm“ChangeOrder”issynonymous&interchangeablewithChangeRequest（seeabove）.

DeviceHistoryRecord

（DHR）

TheQualityManagementSystem’sDeviceHistoryRecordstoresanarchiveofchangesthatoccurduringtheServicesimplementationproject.

GovernanceBoard

TheCaradigmGovernanceBoardprovidesrepresentationforBestPractices,Engineering,Clinical,PortfolioManagement,Compliance,andMethodology.

Schedule

AMicrosoftProjectfile（.MPP）whichcontainstasksrequiredtocompletetheprojectfromstarttofinish.

Scope

Scopeisdefinedinformalprojectdeliverablesthroughouttheprojectlifecycle.Examplesinclude:

VisionandScope;RequirementsSpecificationsDocument;ProjectPlan;andProjectCharter.

2.ChangeControlProcess

2.1.1Introduction

AneffectiveChangeControlprocedureiscriticaltosuccessfulprojectcompletion.Itwillhelpkeeptheprojectwithinitsscope,schedule,andbudget.

ForCaradigm,aneffectiveChangeControlprocedurewill:

∙Facilitatecommunicationaboutrequestedchangesamongsttheprojectandbusinessstakeholders

∙Provideacommonprocessandescalationpathforresolvingrequestedchanges

∙Reducetheuncertaintyaroundtheexistence,state,andoutcomeofachangethathasbeenrequested

2.1.2Scope

ThisdocumentestablishestheprocedureforchangecontrolinCaradigmImplementations.Itdetailshowtorequestchangestoprojectschedules,cost,resources,andartifacts.Italsodescribesthecontrolsrequiredtodocument,approveandtrackanychanges.TheScopeofthisprocedureisanychangethataffectsdesignartifactsor“batch”（DesignInputs,Outputs,Verification,Validation,andTransferArtifacts）whichareunderchangecontrol.

2.2RolesandResponsibilities

ThePMOmanagestheChangeControlprocedureandensuresthatChangeRequestsareproperlyreviewedthroughouttheprojectlifecycle.Majorrolesaredescribedbelow.

ROLES

RESPONSIBILITIES

Requestor

∙Identifiesanareaofchangetobeaddressedbytheproject

∙Documentsissuedrivingneedforchange

∙Makesanassessmentonmagnitudeofchange

ProjectManager（EM）

∙CollectionpointforeveryprojectteamChangeRequest（CR）

∙ReviewsCRforcompleteness

∙Identifiedimpactedprojectdocumentation（plan,budget,etc.）

∙DeterminesmagnitudeofChangeRequesttoproject

∙PresentsCRtoprojectteamforreviewandimpactconsideration

∙EscalatesCRisbeyondprojectteamscopeofapproval

∙CommunicatesChangeRequestoutcometoprojectteam

∙Revaluatesimpactedschedule/resourcesanddeliverablesuponapprovalofascopechange

∙Responsibleforexecutingtherequestedchange,asappropriate

∙UpdatesdocumentationafterReview/approved/rejected

ProgramManagementOffice（PMO）

∙OwnstheChangeControlprocedure

∙FacilitatestheprocedureforescalationstotheGovernanceBoardandCaradigmLeadership

∙CommunicatesthescopechangedecisionstoStakeholders

ProjectCoreTeam

（PC）

∙Reviewandapproveorrejectalllow-impactChangeRequests

∙MediumorHighimpactCRswillbeescalatedtotheGovernanceBoardforreview

GovernanceBoard

∙Escalationpoint（Fromprojectcoreteam）forallmedium-impactChangeRequests

∙ApproachedforguidanceifthemediumimpactCRhasbeenrejectedandrequestorescalates

CaradigmLeadership

∙EscalationpointaboveGovernanceBoardforhigh/materialimpactCRs

∙ApproachedforguidanceifthehighimpactCRhasbeenrejectedandrequestorescalates

2.3ProjectCoreTeam

2.3.1CoreTeamMembers

ThefollowingrolesparticipateintheProjectCoreTeamchangereviews:

∙ProjectManager

∙ImplementationArchitect

∙CustomerServiceManager

∙ImplementationEngineers（ApplicationsConsultant,DatabaseSystemsAnalyst,IntegrationAnalyst）

2.3.2CoreTeamMeetings

TheProjectManager（EM）determinesthefrequencyofCoreTeammeetings.ThisisestablishedanddocumentedintheCommunicationsPlanintheProjectCharter.Duringthesemeetings,theEMwillintroducethesubmittedChangeRequestsforreviewanddiscussionbytheProjectCoreTeam.TheteamwillevaluatethepotentialimpactstotheprojectbeingproposedbytheChangeRequest.

2.4IdentifyingPotentialChangeRequests

Intheplanningstagesofaproject,theprojectscope,requirements,andassumptionsmustbeclearlydefinedanddocumented.Next,theprojectworkschedulemustbecreated,reviewed,approved,andbaselinedonthedefinedscope.Iftheneedarisestoincreasethescopeofworkand/orupdatetheworkschedule,aChangeRequestmustbesubmitted.

ChangeRequestsmayarisefrom:

∙Existingissues

∙Requirementchanges（fromprojectteamorprojectstakeholders）

∙Requestforadditionalfunctionality/capabilitiesafterinitialapproval

2.5IdentifyingaNeedforDesignChange

IdentificationoftheneedforaChangeRequestinvolvesthefollowing:

1.If,aftertheprojecthasbeenbaselined,aneedforchangehasbeenidentifiedthroughissuemanagement,scopechangesoradditions,aChangeRequestformiscompleted.

2.Dependingonurgency,atthediscretionoftheProjectManagerandImplementationArchitect,togetherwithkeymembersoftheprojectteam,canrequesttheGovernanceBoardconvenetoreviewtheChangeRequest.Alternatively,theteamcanwaituntilthenextPhasereview,ifthechangeisdeemedlowriskandlowimpact.

3.TheGovernanceBoard,withCustomerinput,shallapproveordisapprovetheChangeRequest.

4.IftheChangeRequestisapproved,theappropriateartifactsareupdatedandtheunittestedcodeisupdatedaccordingtotheconfigurationmanagementprocedureinsuchawaythatenablestraceabilityofrequirementsandtraceabilitytochanges.

5.RisksassociatedwithapprovingordisapprovingtheChangeRequestwillbeidentified,andthenenteredintotheriskregisterwithamitigationplan.

6.TheresultingChangeRequestandallrelateddocumentsarestoredintheDHRandtheChangeRequestisplacedunderDocumentControl.

2.6IdentifyingaNeedforChangeOtherThanDesignChange

Somechangesarerelativelysmall（e.g.,tonotchangetheintentofthedesignorthecapabilitytocarryoutthedesign）.ThesechangescanbehandledthroughtheChangeControlProcedurebutwillnotinfluenceanychangeinanyofthedesignartifactssuchasDesignInputs,Outputs,Verification,Validation,orTransfer.

2.7ChangeRequestForm

WhenenteringanewChangeRequest（CR）,pleasenotesomefieldsshouldonlybefilledoutbycertainprojectteammembers（Requestor,ProjectManager,etc.）.Thesefieldsmayalsobeenteredorrevisedduringeachstageinthereviewprocess.AllprojectteammembersshouldhaveaccesstotheChangeRequestFormtoreviewidentifiedrequestsindetail.

Requestersmustcompleteallfieldnamesmarkedwithastar（*）belowonanewCR.

FIELDNAME

FIELDTYPE

DESCRIPTION

ENTEREDBY

CRNumber

Single-Line

ChangeRequest（CR）trackingnumberperproject

EM

RequestorName*

Single-Line

NameofpersoninitiatingtheCR

Requestor

DateRequested*

Date

InitialCRsubmissiondate

Requestor

RequestorEmail*

Single-Line

Requestor’semailaddress

Requestor

RequestedImplementationDate*

Date

DateCRexpectedtobecompleted

Requestor

ChangeTitle*

Single-Line

NameassignedtoChangeRequest

Requestor

ChangeDescription*

Multi-Line

Detailedfunctionaland/ortechnicalinformationaboutthechange,includingbusinessjustification.Useanattachment,ifnecessary,toprovideadequatedetailorsupportingdocumentation.E.g.,statementofnewrequirement.

Requestor

Priority*

LevelofimportancethattheCRshouldbegiven.Choicesareasfollows:

•High:

Impacttobusinessvalue,customersatisfaction,orresultsinhighbusinessrisk（resources,budget,capabilities,andschedule）

•Medium:

Impacttosystemeffectiveness（resources,budget,capabilities,andschedule）

•Low:

Changecanbeplanned,scheduled,andprioritized（capabilitiesandschedule）

Requestor

ImpactonProject

Selection

TobecompletedbyEvaluator,identifyimpactoftheCR.

Optionsare:

Capability,Cost,Resources,Schedule

Requestor

ApprovalThreshold

Single-Li