项目变更流程Change Control ProcedureWord文档下载推荐.docx
- 文档编号:16240350
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:9
- 大小:359.95KB
项目变更流程Change Control ProcedureWord文档下载推荐.docx
《项目变更流程Change Control ProcedureWord文档下载推荐.docx》由会员分享,可在线阅读,更多相关《项目变更流程Change Control ProcedureWord文档下载推荐.docx(9页珍藏版)》请在冰豆网上搜索。
∙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*
NameofpersoninitiatingtheCR
DateRequested*
Date
InitialCRsubmissiondate
RequestorEmail*
Requestor’semailaddress
RequestedImplementationDate*
DateCRexpectedtobecompleted
ChangeTitle*
NameassignedtoChangeRequest
ChangeDescription*
Multi-Line
Detailedfunctionaland/ortechnicalinformationaboutthechange,includingbusinessjustification.Useanattachment,ifnecessary,toprovideadequatedetailorsupportingdocumentation.E.g.,statementofnewrequirement.
Priority*
LevelofimportancethattheCRshouldbegiven.Choicesareasfollows:
•High:
Impacttobusinessvalue,customersatisfaction,orresultsinhighbusinessrisk(resources,budget,capabilities,andschedule)
•Medium:
Impacttosystemeffectiveness(resources,budget,capabilities,andschedule)
•Low:
Changecanbeplanned,scheduled,andprioritized(capabilitiesandschedule)
ImpactonProject
Selection
TobecompletedbyEvaluator,identifyimpactoftheCR.
Optionsare:
Capability,Cost,Resources,Schedule
ApprovalThreshold
Single-Li
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目变更流程Change Control Procedure 项目 变更 流程 Change