6.0 PROJECT MANAGEMENT AND CONTROLS
6.1 RISK AND ISSUE MANAGEMENT 6.1 RISK AND ISSUE MANAGEMENT
PMBOK©:
project’s objectives.”
Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”
Both Risks and Issues can significant impact a project’s success, and both should be handled in similar ways.
• Project Management IS Risk Mitigation. Is about how we create and manage a temporary organization to deliver the unique product, service or result!
• By providing structure to the temporary organization and the solution
development/deployment process we reduce the risk of counterproductive Chaos.
• By communicating with stakeholders we keep them in the loop, and often involve them in risk mitigation or lessening its impact
• By acknowledging that there is risk, we can structure ways of avoiding or effectively dealing with specific risk.
6.1.1 R
6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY
Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked. Include the use of tools such as project management software, forms, and templates. A separate risk management plan may also be developed if needed for the project and included as an Appendix to this document. If that is the case, a high level summary of this plan needs to be included here with the specific reference.
6.1.2 P
6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION
• Organizational
• Priorities Change
• Unrealistic Deadline
• Funding
• Lack of internal stakeholder support
• Delayed Approval/Decisions
• Lack of Technical or business direction
• Project Manager Experience or inexperience
• No organization history
• No established project templates or processes
• No organizational understanding of RISK
Resource Risks
• Lack of Resources
• Staff Availability
• Staff Inexperience
• Holiday and Vacation
• Personal or Family Illness
• Retirement or resignations
• Overbooking
• Personalities
• Ineffective training
• Contractor or Consultant
• Team Morale
• Ineffective Communication
External Risks
• Vendor/Supplier
– Quality
– Lack of incentive or penalty
• Misunderstood requirements
• Statement of Work incomplete
• Too Many External vendors or suppliers
• Weather Issues
• Key Staff issues or sickness
• Dependencies on other projects
• Purchasing or hiring
Planning Risks
• Lack of Planning
• Lack of Anticipation
• Poor Estimation
• Lack of stakeholder involvement
• Lack of end customer involvement
• Poor Project Definition
• Unrealistic expectations
• Number of implementation sites
• Training process
• Government or Regulatory Changes
• Poor Communications
• Poorly Run or attended meetings
• No record keeping
Technical Risks
• Incomplete Requirements
• Scope Creep
• No or Poor Change Management Process
• Complex or Overly Complex Designs
• Technology Readiness
• Technical Dependencies
• No Test Environment
• Cutting Edge Components
• Inadequate Documentation
• Vendor Technical Support
• Code or Patch directly to Production Environment
• No Pilot
6.1.4 R
6.1.4 RISKISK R REPORTINGEPORTINGANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY
The DoIT Risk and Issue Log Template uses a calculation based on the following values:
• Probability Levels: Certain, Expected, Likely, Possible, Unlikely
• Impact Levels: Very High, High, Medium, Low, Very Low
The following table suggests the values at which the risks should be tracked, reported and escalated:
Minimum risk - Acceptable
Some risks - Monitor at PM/Team Level
High risks - Active monitoring with ongoing Contingency/Mitigation activity Show stoppers - Active participation with steering committee to mitigate
This is an example of the calculation that indicates a serious risk that needs to be escalated to the Steering Committee.
Number Risk Probability Impact Rating
1 Example Certain High 0.7125
6.1.5 P
6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH
In the DoIT Risk and Issue Template the risk log provides a risk log that not only calculates the risk level, but also provides space for inputting the contingency and mitigation plan summary highlights.
Number Risk Probability Impact Rating Contingency Plan
Mitigation Plan
1 Example Certain High 0.7125
6.1.6 ISSUE MANAGEMENT 6.1.6 ISSUE MANAGEMENT
For either type of issue, projects should consider using the DoIT Risk and Issue Log template as is presented below:
Issue Log:
Issue
No. Issue Person
Responsible Date Opened - Month/Day/year
1 Project Manager 03/15/07 Open
Issue (From Issue Log) Example
Consequence(s)
If not resolved this issue could delay the project by 30 days, resulting in a fine for non-compliance
Resolution
Hiring a contractor could resolve this delay at a cost less than the fine for non-compliance
6.1.6.1 Internal Issue Escalation and Resolution Process
This internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.
6.1.6.2 External Issue Escalation and Resolution Process
The external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality.
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V 6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V
Independent Verification and Validation (IV&V) means the process of evaluating a system to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the development
organization. Describe the process that will be employed to meet IV&V requirements.
See Project Charter for Certification Workbook for some details.
6.3 SCOPE MANAGEMENT PLAN 6.3 SCOPE MANAGEMENT PLAN
Describe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.
6.3.1 CHANGE
6.3.1 CHANGE CONTROL CONTROL
6.3.1.1 Change Control Process
Change Control establishes how change will be managed, including capturing, tracking,
communicating, and resolving change. Due to much ambiguity regarding change, it is vital that we document and discuss the change process with the executive sponsor.
6.3.1.2 Change Control Board (CCB)
Insert a graphic or textual description identifying the Change Control Board (or function) for this project. The CCB may be an individual or group of individuals authorized to approve changes to the project plan.
A project might want to formalize Change Management through a form such as shown below:
P P ROJECT ROJECT C C HANGE HANGE R R EQUEST EQUEST
PROJECT:
PROJECT:
AGENCY: DATE:
PROJECT
MANAGER:
PROJECT #:
AGENCYAND PROJECT INFORMATION:
REQUESTED BY: DATE:
AUTHORIZED BY: DATE:
DESCRIPTION:
ACTION PLAN:
MARK ONE:
THIS CHANGE: Is Is NOT Within Scope.
THIS CHANGEIS: Accepted Denied On Hold Delayed
6.4 PROJECT BUDGET MANAGEMENT 6.4 PROJECT BUDGET MANAGEMENT
Costs estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).
6.4.1 B
6.4.1 BUDGETUDGET T TRACKINGRACKING
6.5 COMMUNICATION PLAN 6.5 COMMUNICATION PLAN
Communication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan;
however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.
6.5.1 C
6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX
6.5.2 S
6.5.2 STATUSTATUS M MEETINGSEETINGS
6.5.3 P
6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) 6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)
The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.
Project Area Category Measure
Example used by another state:
Common Project Issue Area Category Measure
Schedule and Progress Milestone Performance • Milestone Dates Work Unit Progress • Component Status •
Requirement Status • Test Case Status • Critical Paths Tested • Problem Report Status • Reviews Completed • Change Request Status
Incremental Capability • Build Content – Component • Build Content – Function Resources and Cost Personnel
• Effort • Staff Experience • Staff Turnover
Financial Performance
• Earned Value • Cost
Availability • Resource Availability Dates • Resource Utilization
Growth and Stability Product Size and Stability
• Lines of Code • Components • Database Size
• Change Request Workload
Product Quality Defects • Problem Reports • Defect
Density
Complexity • Cyclomatic Complexity
Rework
• Rework Size • Rework Effort Development Performance Process Maturity • Capability Maturity Model Level
Productivity • Product Size/Effort Ratio • Functional Size/Effort Ratio
6.6.1 B
6.6.1 BASELINESASELINES
6.6.2 M
6.6.2 METRICSETRICS L LIBRARYIBRARY
6.7 QUALITY OBJECTIVES AND CONTROL 6.7 QUALITY OBJECTIVES AND CONTROL
Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.
6.7.1 Q
6.7.1 QUALITYUALITY S STANDARDSTANDARDS
Describe the agency, industry or regulatory project performance standards that will be followed and assessed by the project. These quality standards will be used to assess whether the quality objectives were achieved.
Identify each of the project quality standards that are directly related to the project and not to the performance of the actual product and/or service. For each quality standard, identify the tracking tool or measure such as number of project reviews or Project Status.
From another state’s planning process
No. Quality Standard Tracking Tool or Measure
1 Project phase is completed by the established finish date. • Project Schedule
• Project Status
2 Project is completed within budget. • Project Charter
• Project Status 3 Quarterly project reviews show contractors deliver requirements
specified in the contract by due dates or pay penalties.
• Vendor Contract
• Final Customer Acceptance
No. Quality Standard Tracking Tool or Measure 4 Project issues are resolved and documented within 10 calendar days of
identification or extensions are justified.
• Issues Tracking
5 Project will be completed based on the original project scope and approved scope changes.
Review Type Quality Standard Tools Reviewer Reports
Requirements Plans Milestones Testing
6.7.3 A
6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION
The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.
Examples:
Areas of feedback When How Often
Agency awareness
Quality of communications Manages project tasks Productive Meetings .
An example used by some State of New Mexico agencies:
SSTANDARDSSSTANDARDS ApplicableNot DisagreeStrongly
Disagree Somewhat Agree
Agree Strongly Agree
The level of business or agency
knowledge of [project’s name] meets your expectations.
[Project’s name] performs in a professional and cooperative manner.
The level of communications by
[project’s name], both written and oral, meet your expectations.
[Project’s name] project team works well with you and your staff.
[Project’s name] project management team is accessible when you need them.
[Project’s name] provides adequate information and training resulting in effective knowledge transfer.
[Project’s name] completes project tasks within the agreed upon schedule.
The level of technical or business expertise of [project’s name] meets your expectations.
You are receiving full value from the [project’s name] project management team.
The overall service provided by [project’s name] is fully meeting your expectations.
6.7.4 P
6.7.4 PRODUCTRODUCT D DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCESSROCESS
How the client takes procession of the product. Delivery of media; manuals; contracts; licenses;
services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product.
Deliverable Final Approval Process Customer Acceptance Criteria
6.8 CONFIGURATION MANAGEMENT 6.8 CONFIGURATION MANAGEMENT
Configuration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.
6.8.1 V
6.8.1 VERSIONERSION C CONTROLONTROL
Documents should be tracked for version control, on the title page, and using a revision history table such as used for this PMP. Document file names should have project name agency revision number reflected. Best practice involves change management for documents, and a numbering scheme such as 1.0, 2.0, 3.0 to reflect a project’s phases and toll gates or approval processes per phase.
6.8.2 P
6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))
“Provide to the Department all project management and product deliverables. Deliverables shall include but not limited to the project plan, project schedule, initial and periodic risk assessments, quality
strategies and plan, periodic project reports, requirements and design documents for entire project. The lead agency must make available all deliverables in a repository with open access for the Department to review” PROJECT OVERSIGHT PROCESS Memorandum.
6.9 PROCUREMENT MANAGEMENT PLAN 6.9 PROCUREMENT MANAGEMENT PLAN
Projects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements;
solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included.
State of New Mexico RFP, IT Contract and other procurement processes should be followed by all state agencies’’ IT Projects.
Project Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments.
Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.
7.1 A
7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE
Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailor Project Close procedures to compliment the project’s objectives
7.2 C
7.2 CONTRACTONTRACT C CLOSELOSE
Contract close is similar to administrative close in that it involves product and process verification for contract close.
Projects that have been certified need to complete the required DoIT project closure certification processes.
ATTACHMENTS ATTACHMENTS
Attachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples
• Acronyms, abbreviations and definitions
• Technical glossary of IT terms
• Project Work breakdown schedule
• Project timeline
ATTACHMENT A ACRONYMS, ABBREVIATIONS AND DEFINITIONS ATTACHMENT A ACRONYMS, ABBREVIATIONS AND DEFINITIONS
PMI Project Management Institute.
PMBOK Project Management Body of Knowledge PMO Program Management Office
PMP Project Management Plan WBS Work Breakdown Structure
DEFINITIONS DEFINITIONS
Acceptance Criteria
The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]
Acceptance Testing
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]
Assumptions
Planning factors that, for planning purposes, will be considered true, real, or certain.
Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.
Baseline
A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]
Commitment
A pact that is freely assumed, visible, and expected to be kept by all parties.
Configuration Management (CM)
A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]
Configuration Management Library System
The tools and procedures to access the contents of the software baseline library.
Constraints
Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.
Contingency Planning
The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.
Crashing
Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.
The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.
Dependencies, Discretionary
Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential logic. This may also
encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
Dependencies, Mandatory
Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.
Dependency Item
A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.
Deliverable
Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.
Duration
The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.
Duration Compression
Shortening the project schedule without reducing the project scope. Often increases the project cost.
End User
The individual or group who will use the system for its intended operational use when it is deployed in its environment.
Effort
The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.
Fast Tracking
Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.
Float
The amount of time that an activity may be delayed from its early start without delaying the
The amount of time that an activity may be delayed from its early start without delaying the