Policy and Procedure Rollout

+
PROGRAM GOVERNANCE ROAD MAP
This resource document describes the Program Governance Road map for product development,
deployment, and sustainment of products and services in compliance with CMS guidance, ITIL IT
management, CMMI best practices, and other guidance to assure high quality software is deployed for
sustained operational success in mission critical domains.
1
PROGRAM
GOVERNANCE
ROADMAP
1
Performance–Based Project Management®, Copyright © Glen B.
Alleman, 2012, 2013, 2014, 2015

+
Table of Contents
n Program Management Governance Overview
n Project Management Processes
n Change Control
n Release Management
n Configuration Management
n Software Development Lifecycle
n Product Assurance
n Quality Assurance / Independent Verification and Validation
n Risk Management
n Root Cause Analysis
n Governance Deployment Plan
2
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012, 2013, 2014, 2015

+
PROCESS ARCHITECTURE OF PROGRAM GOVERNANCE
Change Management is the umbrella over all we do. Starting with the eliciting and change of
requirements, changes to processes, software code base, testing processes, security, data, on
infrastructure, risk and its impact, and the root cause analysis needed to determine impacts of any
change
PROGRAM
GOVERNANCE
ROADMAP
3
3
PROCESS ARCHITECTURE
Performance–Based Project Management®, Copyright ©
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Four Core Business Processes†
1. Strategic oversight and planning — board and executive
management level activities to increase effectiveness of core
business functions and their outcomes.
2. Business level planning and budgeting — management translation
of strategies into business plans and allocation of capital,
programs, projects, and operational effectiveness initiatives.
3. Operational effectiveness execution — value creating
implementation of plans and strategies, measures in units
traceable to strategic initiatives.
4. Monitoring and control — project and program performance
measures, corrective actions and forecasting
4
† Insights on governance, risk and compliance May 2014

+ Management of Change is the basis
Operations and Development Models
n Change Requests – add, change, delete – are the life blood of a
firms product and service offerings
n Defect corrections to existing baselines
n External changes
n Customer requested changes
n Product improvement and performance changes
n Management of any change is required to maintain:
n Service level agreements
n Integrity of the code base
n Integrity of data bases
n Operational integrity of the IT infrastructure
5
Management Of Change Is The Overarching Principle For All We Do

6
Change Management
Governs the functions of …
Project
Management
Release
Management
Configuration
Management
Software
Development
Quality
Assurance
Independent
V&V
Risk
Management
Root
Cause
Analysis
Security
and
Product
Assurance
Governance Oversees
the functions of …

+ Management of Change Governs
the Functions of …
7
Process Area Management of Change
Project Management Changes to Cost and Schedule baseline
Release Management
Changes to code base as it is promoted through the
release life cycle
Configuration
Management
Changes to hardware, network, and software
configurations
Software Development
Changes to requirements and developed code as it
moves to production
Security and Product
Assurance
Changes that assure security and integrity
Quality Assurance Changes that improve quality
Risk Management Changes that reduce risk
Management of Change is at the heart of a Service Delivery Model.“Decision
Rights” for all changes to the Baseline of all systems across all functional
organizations is defined through
Management of Change.

8
8

+
PROGRAM GOVERNANCE OVERVIEW
Governance is the process of developing, communicating, implementing, and monitoring, the policies,
procedures, organization structures, and practices associated with projects are properly applied to
increase the probability of success, across all functional activities.
PROGRAM
GOVERNANCE
ROADMAP
9
9
PROGRAM GOVERNANCE
Glen B. Alleman, 2012, 2013, 2014, 2015

+ Value Proposition for
Program Governance
10
PROGRAM GOVERNANCE

+
Program Governance
11
Decision
Making
Structures
Collaboration
Enablers
Operating
Processes
Roles,
Responsibilities,
and Decision
Rights
Essential
processes for
development,
release, project
management, risk,
and, performance
reporting
Capture and connect disparate issues, decision
makers, and issue resolution processes
PROGRAM GOVERNANCE

+
Program Governance in One Page
n Connect project performance measures with business performance
measures through policies, practices, procedures, processes, and tools.
n Measure and manage the spend for the value produced from project
work, including software development, infrastructure, customer support,
testing, quality assurance, validation and other support functions.
n Assure accountability of organizations and individuals in their
participation in our product development and sustainment processes
through performance reporting and variance analysis against planned
performance of cost, schedule, and technical outcomes.
n Increase the maturity of product development, release, and sustainment
processes to transform the organization to increase the effectiveness of
all work activities.
12
Program Governance – specify the decision rights and accountability
framework to elicit desired behaviors in the development and sustainment of
our products and services.
PROGRAM GOVERNANCE

+ Framework for Program
Governance
n Align the processes of software development, testing, quality
assurance, release management, and IT operations with the
business needs.
n Provide predictable, consistent processes that meet customer
expectations.
n Enable efficient and effective delivery of products and services.
n Enable measureable, improvable processes that can be tuned for
accurate delivery and overall effectiveness of the product or
service offerings.
13
ITIL V3 is the basis for delivering these outcomes.
CMMI Dev and CMS guidance are the framework of the processes,
procedure and work practices that deliver outcomes.
PROGRAM GOVERNANCE

+
Business Governance …
14
Governance is the set of decisions that
defines expectations, grants power, and
verifies performance.
It consists either of a separate process or of a
specific part of a management or leadership
process.
PROGRAM GOVERNANCE

+ Information Technology
Governance†
15
Firms with superior software development
governance have 25% higher profits than firms with
poor governance given the same strategic
objectives.
These top performers have custom designed
product development governance for their
strategies.
Just as corporate governance aims to ensure quality
decisions about all corporate assets, software
development governance links decisions with
company objectives and monitors performance and
accountability.
† IT Governance: How Top Performers Manage IT Decision Rights for Superior
Results, Weill and Ross, Harvard Business Press.
PROGRAM GOVERNANCE

+
Program Governance is …
16
Program Governance is the framework that ensures project’s
are conceived and executed in accordance with best project
management practices within a wider framework of an
organizational governance processes.
Effective program governance ensures projects deliver their
expected value.
An appropriate governance framework ensures all
expenditures are appropriate for the risks being managed.
Program governance approach is not about
micromanagement, it is about setting terms of reference an
operating framework, defining boundaries, and ensure
planning and execution are carried out in a way which
assures all projects deliver the planned benefits.
PROGRAM GOVERNANCE

+
Software Project Governance is …
17
The art of using processes across the project to assure a
finished quality project gets delivered on-time and on-
budget.
Program Management Governance is …
A structured, temporary set of processes, escalations,
communication, and organizational structures that steer and
guide the program during its lifecycle while reaching the
agreed end state.
A working set of processes and management structures that
allow key decisions to be made during the lifecycle of the
program to ensure that the benefits and outcomes of the
program are achievable.
PROGRAM GOVERNANCE

+
Program Governance …
n Provides the management framework through which project
decisions can be made.
n Is a critical element within Corporate Governance that establishes
accountability and responsibility of Business As Usual activities are
established through organizational governance arrangements.
n Starting with the organization chart, Program Governance establishes
who in the organization is responsible for any particular operational
activity the organization conducts.
n Program Governance provides the decision making framework
needed for logical, robust and repeatable management of SIS’s
capital investments in SIS’s capital assets.
n Establishes a structured approach for conducting Business As
Usual activities of the business processes, change management,
release management, and project management activities.
18
PROGRAM GOVERNANCE

+
n Establish the basis for program
governance, approval, and
measurement with roles,
accountabilities, policies, standards,
and associated processes.
n Evaluate project proposals to select
those that are the best investment of
funds and scarce resources and are
within the business’s capability and
capacity to deliver.
n Enable resourcing of projects,
harness and manage of business
support and the provision of the
governance resources.
n Define the desired business
outcomes, benefits, and value.
n Control the scope, contingency funds,
overall project value, and other
project performance attributes.
n Monitor the project’s progress,
stakeholder’s commitment, results
achieved and the leading indicators
of failure.
n Measure outputs, outcomes, benefits
and value — against both the plan
and measurable expectations.
n Remove obstacles, manage the
critical success factors, and
remediate project or benefit-
realization shortfalls.
n Develop a project delivery capability
— continually building and
enhancing its ability to deliver more
complex and challenging projects in
less time and for less cost while
generating the maximum value.
Activities of Program Governance
19
PROGRAM GOVERNANCE

+ Essential Elements of Program
Governance and their Artifacts
Elements of Program Governance means there is … Shown by the Physical Artifact of …
A compelling business case, stating the objectives of the project and
specifying the in-scope and out-of-scope elements.
Risk Adjusted Business Case
A mechanism to assess the compliance of the completed project to its
original objectives identifying all stakeholders with an interest in the project.
Deliverables Plan connected to
business case
A defined method of communication to each stakeholder. Communications Plan
A set of business-level requirements as agreed by all stakeholders. Master deliverables
An agreed specification for the project deliverables and their measures of
effectiveness and measures of performance.
Capabilities, features, functions, and
testable requirements
A clear assignment of project roles and responsibilities. Responsibility Assignment Matrix
A current, published project plan that spans all project stages from project
initiation through development to the transition to operations.
Integrated Master Plan
Integrated Master Schedule
A system of accurate upward promoting status and progress-reporting
including connections between cost, schedule, and technical performance.
Measures of physical percent
complete and delivered business
value
A central information repository for all project planning and reporting data. Enterprise PM System
A process for the management and resolution of issues that arise during the
project.
Issue tracking system
A process for the recording and communication of risks identified during
project planning and execution.
Risk management system
20

+
n Policies and
Procedures of
product
development
n Risk Management
n Project monitoring
and control
n Risk Management
reporting
n Project performance
communications
n Deliverables
management
n Performance
reporting
n Resource reporting
n Risk elicitation,
management, and
reporting
Program Governance Quality Assurance
Roles and Responsibilities in
Governing IT Projects
21
Project Management
n Ensure quality of
product capable of
providing needed
value
n Define processes for
QA and IV&V across
product
development
lifecycle
PROGRAM GOVERNANCE

+
n Analyze, Design,
Code, Unit Test
products
n Manage individual
software
development
resources within
boarder corporate
pool
n Operate production
systems
n Security
n Database and
Applications
performance
management
Software Development Business Analysis
Roles and Responsibilities in
Governing IT Projects
22
IT Infrastructure
n Client management
n Requirements
elicitation
PROGRAM GOVERNANCE

+ Governance is Implemented
Through Decision Rights
23
Decision Decision Right Belongs to …
Change Control Infrastructure
Customer Requirements Business analysis
Software Architecture Software development
Security Infrastructure
System Performance Infrastructure
Resource Planning and Assignment Program governance
Project performance reporting Program governance
IT Infrastructure Infrastructure
PROGRAM GOVERNANCE

+ Root Cause(s) of Business and
Project Performance Shortfalls
24
Current Condition Desired Condition
Conflicting business
priorities
Prioritize of work across the portfolio of projects, services,
and offerings based on capacity for work, business
commitments, and business value.
Over allocation of
resources
Determine the capacity for work and plans for work from the
skills and deliverables assessment of past performance .
No formal ROI based
decision making
Cost, risk, capacity, and delivered value used to make
management decisions.
Late delivery with
mismatched work cycles
Master plans of outcomes with planned work from identified
backlog in sustainable rhythm.
Unproductive work from
break fix break processes
High quality software submitted for release and production on
a sustainable business rhythm.
No optimization visibility
to work processes
Business and Technical decisions based on capacity for work,
productivity, and quality metrics.
Lack of tactical focus Sustainable business rhythm with cost and schedule margin.
Reactive issue resolution
A planning horizon that assures that few surprises are
encountered for unanticipated work load.
Daily impediments
Infrastructure that enables work to be performed with
auditable automated tools as much as possible.

+ Project Success Starts with
Answers to 5 Questions
25
PROGRAM GOVERNANCE

+ Increasing the Probability of
Project Success with Governance
26
Policies and Procedures of Program Governance
Organizational
Structure
defines the
roles,
responsibilities
and
accountabilities
People,
Processes, and
Tools
implement
program
governance
Actionable
Information
in units of
measure
meaningful to
the decision
makers
Increased Visibility to Program Performance
PROGRAM GOVERNANCE

+
Goal of Program Governance
n Define and implement the
structures, processes,
procedures, and policies
needed to execute program
management and
administration.
n Provide active direction,
periodic review of interim
results, and identification
and execution of
adjustments to ensure
achievement of the planned
outcomes which contribute
to the success of the overall
business strategy.
27
n Our Break Fix Break cycle is a non–
recoverable sunk cost, once fixed
returns money to the bottom line.
n The dilution of work force efficiency
from poor quality and break-fix is
measurably high, once reduced,
returns money to the bottom line.
PROGRAM GOVERNANCE

+ Five Beneficial Outcomes of
Program Governance
n Strategic Alignment of a project within the portfolio of projects
with business strategy to support organizational objectives.
n Risk Management by executing appropriate measures to manage
and mitigate risks and reduce potential impacts on projects and
programs to an acceptable level.
n Resource Management by utilizing available resources and
skills efficiently and effectively.
n Performance Visibility through measurement, monitoring and
reporting using project governance metrics to ensure
organizational objectives are achieved.
n Value Delivery by optimizing project portfolio contents in support
of organizational objectives.
28
PROGRAM GOVERNANCE

+ 3 Governance Questions and their
Answers
29
Program Governance
3. How do we know we are being successful at what we’re supposed to be doing?
2. How are we going to do what we said we would do?
1. What do we want to do?
§ Connect Business and
Technical Strategy
§ Deliverables Based
Planning
§ Measures of
Effectiveness (MoE)
§ Install Capacity Based
Planning
§ Assessment of increasing
maturity
§ Measures of
Performance (MoP)
§ Connect delivery of
business value with all
work efforts
§ Definitions of physical
progress of plan
§ Measure Progress as
Physical Percent
Complete
Project Governance is the Primary Role of the Program Management Office
PROGRAM GOVERNANCE

+ Program Governance Means We
Are Using…
n Policies that describe …
n Why we’re doing the things we’re doing
n The you shall language defines the boundaries of behavior and work performance
n A compliance based framework to guide our work activities
n Procedures that describe …
n How we do things that support the Policies,
n Using Step–Action plans for work activities from requirement gathering to production release
n Processes that describe …
n The work activities – manual or automated – needed to implement the How in support of the
Why
n Tools that implement the processes that support the procedures and policies using
n Team Foundation Server – source code control, branch and merge of changes, capture
requirement that generate work assigned to backlog, features taken from Backlog and
assigned to sprints, resources assigned to sprints, defined deliverables used to assessment
progress to plan and forecast estimate to complete, test manager, release manager,
configuration manger functions built and and executed as work flow.
n Test Tracker Professional – capture customer facing tickets.
n Microsoft Project – top level plan for delivery of capabilities, resource loaded from resource
pool to show capacity for work, dependencies (predecessor and successor) between
development, infrastructure, testing, releases, configuration and product road map.
30
PROGRAM GOVERNANCE

+ Applying These 4 Activities,
IT Program Governance …
n Assures projects and the resulting products and services are
managed well and in accordance the requirements of Governance
across the Enterprise.
n Assures management of the collection of projects for our clients is
optimizing the return from corporate resource and maintaining
alignment with strategic objectives.
n Assures management of projects to
n Achieve of strategic initiatives through benefits realization
n Provide accountably through project sponsorship and organizational
accountability
n Enable performance management and controls
n Make effective use of corporate resources with portfolio management
n Apply enterprise risk management is aligned with compliance
requirements
31
PROGRAM GOVERNANCE

+
Program Governance Road Map
32
Time Period Activities
Execute
Now
§ Establish control over the reactionary and functionally
isolated processes
§ Establish a business rhythm to reduce emergency and
expedited updates to the code base
Increase
Maturity
§ Establish a baseline for all processes, data, and code
§ Establish the tools needed to control the baseline
Business
Transformation
§ Using tools, processes, and training, increase effectiveness
of IT staff to meet current and expanding customer needs
Execute
Now
90 Days
Increase
Maturity
120 Days
Business
Transformation
270 Days
PROGRAM GOVERNANCE

+ Critical Success Factors
of Program Governance
n Project Management
n Source Code Control
n Change Management
n Automated Build Processes
n Automated Configuration Management
n Automated Testing and Release Management
n Resource Planning and Management
33
PROGRAM GOVERNANCE

+ Framework of Software
Development and Deployment
34
PROGRAM GOVERNANCE

+
PROJECT MANAGEMENT PROCESSES
End–to–End business management processes from elicitating requirements to deployment of products
to production in a seamless business rhythm.
35
35
PROGRAM
GOVERNANCE
ROADMAP
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Provide processes and tool for planning, scheduling, resource management, visibility and corrective action
to cost, technical, and schedule performance in units of measure meaningful to the decision makers
36
Governance Road Map
Project Management
Execute Now Increase Maturity Transform Business
§ Identify projects, resources,
capacity and allocations to
build 1st level of Master
Schedule for all IT projects
§ Capture current work
activities in RAM and
monetize the work
§ Use Intake process to show
release train paradigm of all
work going through IT.
§ Review and understand
existing SDLC, product
assurance and configuration
management processes and
determine how best to
incorporate into more
complete project schedules
§ Determine Capacity for work
and Demand for work using
project Intake process
§ With this information
produce a weekly capacity
planning and throughput
performance forecast for all
planned work authorized
form the Intake process.
§ Provide regular documented
internal status updates on
in–flight efforts with existing
information.
§ Forecast demand and
capability for work and
construct road map and
show margin for surge
§ With this information
produce and Enterprise
level performance forecast.
90 Days 120 Days 270 Days

+ Purpose & Goals of Project
Management
n The Project Management team exists to assist the organization in
achieving the timely delivery of quality products by driving the
successful completion of projects leading to the successful
deployment of releases.
n The Project Management team accomplishes this by assisting in
driving consistency in the requesting of work, assisting in the
governance and prioritization of that work, and by utilizing a
standard, practical set of project management processes that will be
continually measured, validated and improved.
n The Project Management team works hand–in–hand with Product
Management,Technology Management, Product Assurance
Management, and Infrastructure Management to ensure all work is
progressing in the most effective and efficient way possible to meet
client needs and expectations.
37

+ Guiding Principles of Successful
Program Governance
n The Project Management team is driven by 5 basic guidelines that
will help ensure success in our organizational goals:
1. Keep it simple, be realistic, and work on the basics
2. Focus on Value, if it does not add benefit, don’t do it
3. Plan, set expectations and facilitate communications
4. Support, understand needs, goals and expectations of the organization
and clients
5. Communicate, transparently, concisely, accurately and often – explain
what we are doing and why
38

+ Our Approach to Program
Governance
n The PMO is not here to diminish or tear down anything that has
been done to date
n Our goal is to build on the success already achieved and create a
framework within which the firm can repeat that same success elsewhere.
n Additionally, we will introduce processes that will improve the visibility
into the projects as well as the planning of the projects so that the team
can be as efficient and effective as possible and see a reduction in the
number of fires that we have to fight.
n Think of us as mechanics here to lube, oil and tune up the machine and
help keep it running at its absolute optimum level of performance.
n This is an investment made in the future of the organization
n While the clients will not be directly billed for these efforts, they gain
both short and long term benefit from the increased efficiency and
effectiveness of all work efforts.
39

+
Client and Product Management
Software
Development
Life Cycle
Product
Assurance and
Independent
Verification
and Validation
Operational
and Support
Infrastructure
Project Management
Tangible Customer Benefit
End State for Project Management:
Balance Resources & Client Needs
40
Resources Client
Needs

+
5 Steps To Project Success
41
Identify
Needed
Capabilities
Identify
Requirements
Establish
Project
Baseline
Execute
Project
Baseline
§Define Needed
Capabilities
§Define Deliverables
§Analyze Needs, Cost,
and Risk Impactt
tradeoff
§Define Balanced and
Feasible Alternatives
§Fact Finding for each
Deliverable
§Gather And Classify
facts
§Evaluate And
Rationalize facts
§Prioritize Requirements
§Integrate And Validate
§Decompose Scope to
each deliverable
§Assign Accountability
§Arrange Work
§Develop Budget and
Schedule
§Identify Measures of
Success
§Perform Work
§Accumulate
Performance Measures
§Analyze Performance
§Take Corrective Action
Perform Continuous Risk Management (CRM)
Define the Measurable
Capabilities of each
Project Deliverable
Assure All Requirements
Provided In Support of
Capabilities
Define Measures of
Performance and
Effectiveness
Assure Cost, Schedule,
and Technical
Performance Compliance

+ Restating the Obvious Project
Management Functions
42
Function Role, Responsibility, and Outcome Evidence
Integration Management
Scope Management
Time Management
Cost Management
Resource Management
Communications
Management
Risk Management

+CONNECTING PROJECT
MANAGEMENT WITH
OTHER PROCESS AREAS
Project Management is the enabler of other functional area’s
success.
Project Management captures – Where Are We Going? How Do We
Get There? Determines if We Have Enough Time, Resources, And
Money To Get There? Identifies What Impediments Will We
Encounter Along The Way? Provides measures to Know If We Are
Making Progress?
43

+
n Drive the intake and governance
process.
n Establish the processes around request
intake, documentation, approval and
prioritization.
n Establish a solid intake and governance
process forms a solid foundation which
enables the other elements of delivery
to remain stable.
n Create, facilitate and maintain easy to
use processes and tools for the intake,
prioritization, and approval of requests.
n Create the proper work queues (or
backlogs) to provide each department
/ client with a clear vision of priorities.
n Implement a model with the following
characteristics:
n All requests funnel through a single,
consistent process
n At a minimum, each client will have
their own work queue
n A work queue will exist for internal /
architecture work – i.e. work that
doesn’t fall with one specific client
n All work queues will be prioritized
in a similar manner using similar
criteria
Activities PMO Contribution
Project Management and
Product Management
44

+
n The Software Development Lifecycle
establishes the process for delivering
business and technical capabilities to
satisfy client needs.
n Provide for elicitation of capabilities
and requirements, design, coding
standards, architectural standards and
software testing standards.
n Assure the SDLC is the basis is an
efficient platform to manage the cost of
maintenance, upgrades and defect
removal at levels that assure
performance, customer satisfaction,
and business success.
n Create, facilitate and maintain
processes and tools for the tracking
resource capacity and allocation.
n Ensure the SDLC process adherence
through proper project and task
performance reporting.
n Provide escalation paths for issues
encountered in software development
and between other groups impacting
project performance.
n Provide status reporting of all work in
units of measure meaningful to the
decision makers.
n Facilitate in the prioritization of
solutions to issues, risks, and other
impediments with actionable
information of the impact of of those
decisions.
Software Development
45

+
n Drive the process of qualifying all items
to satisfy client needs using a
consistent quality assurance process
n Establish processes for proper test
planning, testing, user acceptance
testing, performance testing and pre–
production testing
n Establish a solid quality assurance
process creates an efficient
environment within which the cost of
ongoing maintenance, and the volume
of production level defects, can be
reduced
n Create, facilitate and maintain easy to
use processes and tools for the tracking
of resource capacity and allocation.
n Ensure identified quality assurance
process is being adhered to via proper
project and task identification and
tracking
n Provide escalation path for issues and
roadblocks product assurance staff
encounter that may need decisions
from other groups such as the client or
product management
n Provide consistent reporting
mechanism for the current status and
health of all in–flight work to enable
leadership to have information needed
for decision making at their fingertips
n Assist in resolution of prioritization
“disputes” by providing clear
information regarding the impact of
changing directions
Product Assurance and IV&V
46

+
n Infrastructure should drive the process
of change management and production
deployment using a consistent
configuration management process
n Assure processes for proper change
management, security, system
performance and production
deployment.
n Establish a configuration management
process for modifications to hardware
and software released to production
environments that minimizing
downtime experienced by the users.
n Create, facilitate and maintain
processes and tools for the tracking
resource capacity and allocation
n Ensure the configuration management
process is adhered to through proper
project management, task identification
and work performance tracking.
n Provide an escalation path for issues
and roadblocks infrastructure staff
encounter that may need decisions
from other groups such as the client or
product management
n Provide a consistent reporting
mechanism for the current status and
health of all in–flight work to enable
leadership to have information needed
for decision making at their fingertips
n Assist in the resolution of prioritization
“disputes” by providing clear
information regarding the impact of
changing directions
Infrastructure
47

+
n Deploy Continuous Risk Management
(CRM) processes for all projects
n Management all projects using CRM
n Assure connections of risk management
tools and processes with Integrated
Master Schedule, progress
performance reporting and resource
planning.
n Provide risk reporting through
centralized project reporting
processes.
Risk Management
48

+THE MECHANICS OF
SOFTWARE DEVELOPMENT
PROJECT SUCCESS
People, process, and policies are necessary but far from sufficient
for project success.
Information is needed to identify gaps, develop closure activities,
applies these, and measure improvements.
These activities start with visibility to project performance.
49

+ Task Schedules show
Cross-Functional Dependencies
n Dependencies between functional areas needed to assure resource
allocation, predecessor and success completion, and critical path to
completion date
n Document of Record is the MSFT Project Schedule for all work
50

+ Work Management Through
Release Planning and Sprints
n Tasks defined in
sprints for a
release in Team
Foundation Server
n Task Backlog
allocated to
Sprints and staff to
execute the Sprint
51

+ Executive Summary of Projects
and Portfolios of Work
n Executive summary of planned work, progress of that work to date,
and deliverable milestones.
n This summary chart is derived directly from MSFT Project schedule
52

+ Relationships between Views of Projects
in the Portfolio Tailored to User Need
53
Master
Schedule is
Document of
Record
SW
Development
Team’s work
planning in TFS
Management
Summary of
planned work
progress Estimate
to Complete and
Estimate at
Completion

1. Where Are We Going?
2. How Do We Get There?
3. Do We Have Enough
Time, Resources, And
Money To Get There?
4. What Impediments Will
We Encounter Along
The Way?
5. How Do We Know We
Are Making Progress?
IMMUTABLE
Of Project Management
Project Success
54

+
PROJECT MANAGEMENT
MATURITY ASSESSMENT
The CMMI paradigm applied to Project Management reveals
strengths we can build on and weaknesses were we can make
improvements to increase our maturity.
55

+
Project Management
Maturity Descriptions
n No project or program management
processes or practices are consistently
available, no organizational expectations for
PM processes
n The organization is using individual heroics
to accomplish project management
processes
n No baseline established, no change
management process
n Lack of senior management strategy for
project management
n The efforts of project management are
functionally isolated. No integrated
approach, each person and organization
attempts to performance project
management activities
n No project management data consistently
collected or analyzed
n Informal project management processes
defined.
n Basic industry framework has been
recognized.
n Some processes created.
n Available PM processes applied
inconsistently within and across projects.
n Change control not yet applied consistently.
n Senior management has communicated a
strategy of the goals and direction for project
management.
n Functional isolation still prevalent
n Project management data needs identified,
but with informal methods for obtain data
ML 1 – Isolated ML 2 – Initial
56

+
Project Management
Maturity Definitions
n Project management processes are defined,
documented, implemented and executed
n Baselines are established for projects
including development, operational support,
and production.
n Change management processes in place and
operational
n Senior Management engaged as part of the
project management process.
n Compliance with project management
process oversight in place and adherence
confirmed.
n Cross–functional interfaces, roles, and
responsibilities have been defined.
n Customer interface at project and scope
management level defined and managed.
n Project Management data needs identified
with methods for generation and
communications.
n Project Management process in place to
integrate management of individual projects,
operational support, and production.
n Project Management practices integrated
with business management processes.
n Change control consistently applied with
control processes, stakeholder entities and
levels of authority defined.
n Senior Management engaged with enterprise
decision making processes.
n Process integration achieved through: (1)
Cross functional processes; (2) stakeholder
processes; (3) rollup of projects to enterprise
reporting.
n Project Management data analyzed and
decisions made using that data.
n Aggregated metric and data management
systems in place.
n Data use to proactively support future
planning and analysis.
ML 3 – Consistent ML 4 – Integrated
57

+
Project Management
Maturity Definitions
n Established process reviewed and
challenged to ensure improvement
considered and implemented.
n Focused effort on automating, streamlining,
increasing efficient.
n Lessons learned captured and addressed in
an an on–going process.
n Change Management incorporated in Project
Management processes.
n Senior Management engaged in ensuring
continuous improvement activities receive
priority and resources, and business
practices continue to evolve with optimized
processes.
n Organizations work collaboratively to
develop and implement improvements.
n Project Management data used to optimize
and sustain project performance.
ML 5 – Continuous
58
n Isolated
n Hope
n Faith
n Initial
n Project Team
n Team Effort
n When Required
n Consistent
n Organizational
Effort
n Project
Management
Systems
n Integrated
n Common Resource
Management
n Coordinate Work
Efforts
n Continuous
n Best In Class
Common ML Terms
n Individual Effort
n Informal
n Appropriate
n Informal
n Routine Review
n Management
Review
n Trained
n Best Practice Tools
n Cross–functional
n Rigorous

+
CHANGE MANAGEMENT
The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be
made with minimum disruption to IT services. †
PROGRAM
GOVERNANCE
ROADMAP
59
† ITIL V3.1 Glossary
59
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Provide processes and tools to ensure all changes to the firms assets result in outcomes to continue to meet service level
agreements are managed through all stages of the application development lifecycle—from change request approvals to
checkouts for development through testing and final deployment into production.
60
Governance Road Map
Change Management
Execute Now Increase Maturity Transformation
§ CMS Change Control Policy
deployed through CCB
§ Establish Measures Of
Effectiveness for Program
Governance
§ Requirements traceability
matrix syndicated across all
projects
§ Establish Measures of
Performance for Program
Governance
§ Maintenance and upgrade
schedules integrated with
project work in Integrated
Master Schedule
CHANGE MANAGEMENT

+
Change Management
n Ensures that changes are made with minimum disruption to the services IT has
committed to its users through SLA’s and OLA’s.
n Supports the efficient and prompt handling of all changes.
n Provides accurate and timely information about all changes to all stakeholders
impacted by a change to the production systems.
n Ensures all changes are consistent with business and technical plans and
strategies.
n Ensures that a consistent approach to changes, testing, quality assurance and
production release management is used.
n Reduces the ratio of changes that need to be backed out of the system due to
introduced defects and inadequate preparation for the change.
n Ensures the required level of technical and management accountability is
maintained for every change.
n Monitors the number, reason, type, and associated risk of the changes.
61
CHANGE MANAGEMENT

+
Change Management Process Flow
62
Generate
Change
Request
Evaluate
Change
Request
§ Complete Change
Request form
§ Submit CR Form to
Change Manager
§ Change Manager enters
the Change Request to the
Change Log
§ Change Request status is
updated throughput the
processes as needed
§ Approve to move forward
with incorporating the
suggested change into the
production system
§ If approved make the
necessary adjustments to
carry out the requested
change
§ Communicate the change
status to submitter and
other stakeholders
Implement
Change
Request
Authorize
Change
Request
CHANGE MANAGEMENT

+
RELEASE MANAGEMENT
Release management combines quality assurance compliance activities with management of software artifacts in a
central repository (source control), then releases those software artifacts to a client production environment for
application deployment.
The process responsible for planning, scheduling and controlling the build, test and deployment of releases, and the
delivering new functionality required by the business while protecting the integrity of existing services. †
PROGRAM
GOVERNANCE
ROADMAP
63
† ITIL V3.1 Glossary
63
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Continuous delivery of value to our customers requires a seamless, uninterrupted flow of
value delivered automatically with the minimum defects and disruptions to production.
64
Governance Road Map
Release Management
§ Entry criteria for each gate
in the release management
process
§ Single point of integration
for all changes - CCB
§ Automation of all change
requests from Change Sets
§ Specific check list activities
performed at each stage of
the release process
§ Track of all changes using
Branch and Merge in the
Change Set
§ Verification of all changes,
fixes, and updates with
check lists
§ Validation of integrity of
applications with regression
tests established in QA
§ Promotion of changed
baseline through each
release stage documented
RELEASE MANAGEMENT

+ Success of Release Management
Depends on a Gatekeeper
65
Zuul is the Gatekeeper in Ghost Busters
RELEASE MANAGEMENT

+
Release Management Flow
66
Intake Development Production
Pre
Production
(UAT)
Staging
(QA)
Build Release
Make changes to
baseline
Receive
request for
change to
baseline
Packaging of
selected changes
to baseline
Internal testing
of release
candidate
External testing
of release
candidate
New baseline
from release
candidate
Protect
Baseline
Protect
Production
§ Verification and
Validation (IV&V) of
the release
candidate
§ Performance and
security validation
§ Receive request for
change
§ Analyze the RFC
§ Prioritize the RFC
§ Assign change resource
§ Determine package for
release candidate to
Staging
§ Verification and
Validation of the
release
§ CCB Sign offs from
§ Security
§ Code review
§ Customer acceptance
testing
§ Change baseline per
approved RFC
§ Peer review of changes
§ Perform Unit Testing
§ Functional testing of
release candidate
§ Performance and
Security review
§ CCB Sign Offs from
§ Performance
§ Security
§ Development
§ Quality Assurance
§ Customer Management
§ Change Management
CCB CCB
RELEASE MANAGEMENT

+
n The Request for Change (RFC)
form completed:
n Statement of Change
n TTPro Ticket #
n Approved change
description
n Submitted for review
n Approval to make changes to
code
n Unit test scenarios
n Security impact assessment
n Performance impact
assessment
n Modules to be changed
checked out
n Development Test Plans
defined
n Unit Test data
n Unit Test scripts
n Changes ready for
incorporation to code base in
DEV Environment
n Changes verified with
Development Testing
Request for Change Into Development
Primary Conditions for
Release Management Success
67
RELEASE MANAGEMENT

+
n The Request for Change (RFC)
has been verified to:
n Correct identified defects
n Changes to functionality
n Changes to improve
performance
n Have predictable impact on
resource capacity
n Be compliant with SLA and
other contractual
requirements
n Successful development should
result in no undesirable impact
on
n Performance
n Security
n Database integrity
n Pass Quality Assurance and
Exit criteria
n The process to maintain a
desired level of quality in a
service or product, by
means of attention to every
stage of the process of
delivery or production.
n Pass Verification and
Validation Exit Criteria
n The process of confirming
the software system meets
specifications and fulfills its
intended purpose.
Out of Development Into Release Management
Primary Conditions for
Release Management Success
68
RELEASE MANAGEMENT

+ Release Management …
Is Process Centric
n Start with policies and processes
n These guide the development of procedures and identify the needed tools to
implement those procedures
n Support the entire release management process with a step-by-step
action plan
n From identification of the change request to final deployment to production
n Provide support for the agreed levels of traceability
n Be able to answer
n How Did This Piece of Software Get Here?
n What was the justification for making this change to the production system?
n Use tools to federate and automate across the release management
process rather than defining a process which fits the tools.
n All activities across the firm touch the product baseline release in some way
n No action can be taken outside the release management process
69
RELEASE MANAGEMENT

+
Principles of Release Management
n There is a Release Management Policy
n An written agreement with the business and all relevant parties on how releases to
production will be conducted
n Release need to be well planned in advance
n A release road map shows what features and functions will appear in what release
n Emergency releases are managed in line with an emergency release procedure
n No change to the baseline can be made without authorization to do so
n Risk and back out or remediating a failed release assessed and managed
n Stability of the baseline must be assured
n Success and failures of releases measured and corrective actions taken to
improve success rate
n No improvement to the Release Management process can be made without knowing
where process gaps are, what corrective actions are needed to close the gaps, and hoe
to make process improvements.
70
RELEASE MANAGEMENT

+ Calendar Events for Successful
Release Management
n Requirements freeze - «define this date»
n Code freeze - «define this date»
n Estimated “Go Live” - «define this date»
n Re-estimate “Go Live”
n Entrance and Exit cutoff dates for
n QA
n Performance
n UAT – assumes we’re ready to go
n Production
71
RELEASE MANAGEMENT

+ Top Level Release Management
Process Flow Activities
n Development
n Code and Unit Testing of 100% assigned TTPro Tickets
n Staging
n QA Test of deployed Release Package (Code and DB Changes that have
been Unit Tested)
n Pre-Production
n Verification and Validation of deployed Release Package
n Production
n Verification and Validation of deployed Release Package
72
RELEASE MANAGEMENT

+ Automation is the Key to Successful
Continuous Delivery of Value
n Everything is under change control
n Monitoring of progress through check lists
n Continuous integration of code in each environment
n Version control with Branch and Merge
n Code review with peers
n Configuration management of outcomes prior to Pre-Production
n Performance dashboards for activities
73
RELEASE MANAGEMENT

+ Addressing recurring problems
with Release Management
n Development doesn’t have enough time
to analyze, design, and Unit Test
n Integration testing doesn’t have enough
time to cover all impacts of the change
n QA doesn’t enough time to assure not
undesirable outcomes have occurred
n Full regression testing not available in a
change controlled baseline
n Branch and Merge of locked down code
baseline not in place
n Architectural coupling too high and
cohesion too low for rapid change
processes †
74
† Low coupling is a sign of a well-structured computer system and a good design, and when combined with high cohesion,
supports the goals of high readability and maintainability.
Readiness
Impact
Scope
Complexity
Guides promotion of code
RELEASE MANAGEMENT

+
n Degree of coordination and
communication in place
n Length of lead time to prepare
n Degree and quality of testing
conducted
n Back Out plan if the change
has unfavorable impact on
production
n Past implementation success
rate for similar changes
n Criticality of service, system,
device impacted if change
fails
n Number of users disrupted if
change fails
n Legal, Regulatory, or Public
sensitivity of the change
n Criticality of business or
processing dependencies
impacted
n Degree of contingency
Readiness (R)
1 Very Ready ➔ 5 Not Ready
Impact (I)
1 Minimal ➔ 5 Major
Review and Approval of Change
Requests are Driven by R.I.S.C.
75
RELEASE MANAGEMENT

+
n Number of systems impacted by
the requested change
n Number of software modules
impacted by the requested
change
n Criticality of the systems
impacted by the requested
change
n Duration of the change
n Type of change
n Release
n Conversion
n Upgrade
n Recovery / Restoration
n New System
n Number of steps in change
n Number of support teams to
implement the change
n Change requires GO / NO GO
decision points
n Degree of repeatability and
experience with change
n Degree of post-
implementation validation or
testing
n Ability to Back-Out or restore
the service
n Size of the implementation
window
Scope (S)
1 Small Scope ➔ 5 Major Scope
Complexity (C)
1 Simple ➔ 5 Complex
Review and Approval of Change
Requests Driven by R.I.S.C.
76
RELEASE MANAGEMENT

+ Presume all changes result in
Failure
n The focus of Release Management is to …
n Protect the Baseline
n Changes to the baseline must assure not undesirable outcomes
n Protect of Production system
n Changes to production must assure not negative impacts to current
performance, security, functionality, any of the …ilities,and SLAs
n The R.I.S.C. assessment of the change request presumes the change
will result in failure
n The assessment of the possibility of failure on the production system is
the first priority.
n With this assessment complete, the other aspects of release qualifications
can be applied.
77
RELEASE MANAGEMENT

+
R.I.S.C. Process Steps
n Evaluate overall impact of the change and assume they will fail.
n Collaborate with other subject matter experts knowledgeable about
the are being changed or that will be impacted by the change if it
fails.
n Collaborate with business representatives or leaders that will be
impacted by the change if it fails.
n Evaluate the circumstances around the change window, other
changes occurring, other events occurring, or mitigating
circumstance that may bot be directly related to the change but
could have a negative impact and cause the change to fails.
78
RELEASE MANAGEMENT

79
RELEASE MANAGEMENT

+
n Readiness
n Conditions needed for
approval to start the work
n Impact
n Process, customer, quality,
testing, security, operations
impacts of the change
n Scope
n The number of items being
changes
n The number of differences
in the baseline after the
change
n Complexity
n The level of knowledge
needed to make the change
n The effort required to make
the change
n The work activities to be
performed
Entry to Stage Activities in Stage
Gated Flow
Request for Change to “Go Live”
80
RELEASE MANAGEMENT

+
n Assess RFC for end-to-end
process (Intake management)
n Scope
n Resources
n Capacity for work
n Risk assessment
n Business impacts
n SLA
n RFC
n TTPro tickets for
n Operational changes
n Defect fixes
n New work from customer
n Test plan for changed code
n Requirements
n Analysis
n Development
n Unit Testing
Entry to Dev from RFC Activities in Development
Authorized To Enter Development
from Request for Change to “Go Live”
81
RELEASE MANAGEMENT

+
n All Requests for Change (RFC)
documented and recorded
n Evidence of Dev exit criteria
n Impact assessment
n Design impacts
n Assessment complete of package
and individual contents as
compliant
n Architecture impacts
n UT completion to plan
n Build and run books started
n Code walk through complete
n Implementation, deployment plan
for release
n Requirements for change
complete
n Confirm sufficient capacity available
for testing in Staging are committed
n All votes of the CCB are recorded
and concurrence not consensus
n Confirm system testing and QA
success to release meets meets
requirements
n Requirements for change trace
back to documentation
n Confirmed sufficient resources for
success in Preproduction
n People
n External conflicts
n CCB approval criteria to move to
Preproduction complete
n Release package or collection
of packages are promoted with
approval
n Completion of the Build and Run
book
Entry to Staging from Dev Activities in Staging
CCB Approval to Enter
Staging from Development
82
RELEASE MANAGEMENT

+
n CBB approve and accept any
outstanding defects not
corrected
n Plan to correct
n Production Release
Implementation plan is
complete
n Back out plans
n Communication plan
n Test scenarios and strategy
complete
n Confirm release against
requirements
n Validate
n Customer verification of
capabilities and scope
n Signed off release plan
Entry to Pre-Production Activities in Pre-Production
Move from
Staging to Pre-Production
83
RELEASE MANAGEMENT

+
n All tickets closed
n Regression testing complete
n Cyber security
n Performance assessment
n All test results available for
review
n Back out plan ready to execute
n Confirmed to work
n Criteria for Back Out
documented
n Performance monitoring in
place
n Staff ready to assess and
take corrective actions
n Corrective actions ready to
be applied for specific
detected difficulties
Entry to Production Activities in Production
CCB Approval to Move from Pre-
Production to Production
84
RELEASE MANAGEMENT

+ Core Requirements for
Release Management
n Dependencies for the change are explicit and easily recorded.
n Developers document dependencies as part of the release process, even if
dependencies across organizational boundaries.
n Description is directly usable by release management tool traceable to
baseline contents.
n Release process involves minimal effort on the part of the developer.
n When a new version of a system is released, the developer should only have
to specify what has changed, rather than treating the new version as a
completely separate entity
n Scope of a release is controllable.
n A developer is able to specify to whom, and under what conditions, the
release changes is visible.
n A history of revisions is kept.
n This allows developers to track their systems, and to contact users with
announcements of new releases, patches, related products, and the like.
85
RELEASE MANAGEMENT

+
n Number of Requests for Change
n Percent emergency releases
(submission rate)
n Number of changes made by
release team
n Number of successful
installations of new version
n Number of builds or
deployments aborted
n Percentage of release
performed on schedule
n Number of failed or backed out
releases
n Number of unauthorized
changes deployed to
production
n Resource cost per release
n Service time lost due to
release activity
n Number of defects per state,
team, release unit, release
n Percentage of gates missed
per team
n Average time in process state
Release Management Metrics
86
RELEASE MANAGEMENT

+
Key Elements of RM Success
87
Action Outcome
Release Plan
ü Strategy for segmenting delivery
ü Phased functional rollout
Release Content
ü Identify specific release
ü Describe specific content of the release
ü Map individual requirements to specific release
Release Schedule
ü Provide high level schedule for planned delivery
ü Define significant milestones for transitioning release to
production
Release Impacts
ü Describe business or system impacts
ü Identify systems and interfaces directly impacted
ü Identify impacts to end-users
Release Notification ü Notify all impacts stakeholder
Release Management
ü Identify activities to mange planning, organizing,
developemnt, testing and implementation of release
Release Numbering ü Identify numbering schema for release
RELEASE MANAGEMENT

88
88
RELEASE MANAGEMENT

+
ITIL Release Management
Processes
Software defects discovered y end-users are inevitable
consequences of vendors lack of testing, fundamental design
issues, and poor preparation for release management.
“Orchestrating End-User Perspectives in the Software Release
Process: An Integrated Release Management Framework,”
Advances in Human-Computer Interaction, 2014.
89
RELEASE MANAGEMENT

+ ITIL Based Release Management
Processes Needed for Success
n Release Policy – corporate guidance for managing product release
n Release Planning – business rhythm for managing releases, ensures all
defects, features, and changes adhere to release policies
n Design and Development of Solution – repair of defects, addition of
features, and upgrades to infrastructure
n Build and Configure Release
n Assure Fit for Purpose
n Release Acceptance
n Roll Out Planning
n Communication, Preparation, and Training
90
RELEASE MANAGEMENT

+
Release Policy
n The formal agreement of the release management approach and
includes
n Infrastructure used for the release
n Acceptable schedule of releases
n Definition of major versus minor releases
n Deliverables for each release
n Roll-out and Back-out plans
n Documentation of the releases
n Roles and responsibilities
n Expected frequencies
n Ensure each release has a unique number
n Naming conventions
n Types of releases
n All detected defects resolved with patches or new releases
91
RELEASE MANAGEMENT

+
Release Policy
n Naming conventions
n Types of releases
n Expected frequency
n Test environments
n Back out planning
n Gate review criteria
n Grouping and prioritizing releases
n Entry and exit criteria for each promotion state
92
RELEASE MANAGEMENT

+
Release Planning
n Designation of resources
n Agreement of policies and procedures used during the release
n Decisions on deliverables and features
n Pre-defined acceptance criteria
93
RELEASE MANAGEMENT

+
Design and Develop Software
n Designing software based on requirements
n Developing software to those requirements
n Repairing defects that were non-compliance with requirements and
design
n End-use acceptance testing based in Use Cases
94
RELEASE MANAGEMENT

+
Build and Configure Release
n Assembly of modules for traceable changes to baseline stored in the
software library to create the derived new baseline
n Build procedures, tools, checklists used during this assembly also
under change control and configuration management to ensure
repeatable, traceable practices to produce the anticipated
outcomes
95
RELEASE MANAGEMENT

+
Fit for Purpose Testing (QA)
n Functional, operational, performance, and integration testing of the
release/
n Reliability models to forecast outcomes
n Casual predictions of failure modes
n Parameters of Good Enough To Release (GETR) criteria.
n Testing mimics actual use from scenarios
96
RELEASE MANAGEMENT

+
Release Acceptance
n Testing software by end users and obtaining approval for release to
proceed
n Release package deployed to customer environment with
coordinated customer team.
n Release acceptance based on specific conditions defined by
customer.
n Automated User Acceptance Testing based on actual scenarios
developed during requirements elicitation
97
RELEASE MANAGEMENT

+
Roll-Out Planning
n Time table, resources, roles and responsibilities defined during
planning phase
n Pre-defined schedule with cut-off dates for inclusion of additional
features or defect fixes
n Release check list to ensure no steps missed
98
RELEASE MANAGEMENT

+ Communications, Preparations,
and Training
n Formal notifications to all stakeholders
n Roll-out meetings
n Training sessions
n Clearly defined procedures for all communications with Point of
Contact (POC)
99
RELEASE MANAGEMENT

100
100
RELEASE MANAGEMENT

+
CHANGE MANAGEMENT
Software Change Management establishes and maintains the integrity of the products of the software
project throughout the project's software life cycle. Software Configuration Management involves
identifying configuration items for the software project, controlling these configuration items and
changes to them, and recording and reporting status and change activity for these configuration items
PROGRAM
GOVERNANCE
ROADMAP
101
101
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Establish and maintain the integrity of work products using configuration identification,
configuration control, configuration status accounting, and configuration audits.
102
Governance Road Map
Change Management
§ Source code migration plan
to Team Foundation Server
with established
configuration of software
components used to build
the system
Effectiveness for
Configuration Management
§ Infrastructure control plan
based on server and
network diagram and impact
analysis
Performance for
§ Hardware configuration
plans placed in Integrated
Master Schedule
CHANGE MANAGEMENT

+ Change Management (CM)
Operational Policy
n CM scaled to meet the needs of the firm and Stakeholders
n Rigor scaled to maintain the integrity of the product baseline
n Adequacy and sufficiency defined in at enterprise level
n Process protects the firms assets from unauthorized or uncoordinated
changes in accordance with business Policy
n Change Control Board (CCB) is a Promotion Approval process
n Evaluate scope, applicability, and effect of proposed change
n Asses impacts on cost, schedule, and compliance
n Approve or reject change based on risk, contractual compliance,
business objectives, and budget
n Change Communication is the mechanism for all changes
n Apply defined Communications Plan
n Maintain POC list
n Engage stakeholder in Change Request impact assessment
n Report change status across the organization and stakeholders
103
CHANGE MANAGEMENT

+
Release Verification
Quality Assurance,Test, and Release Implementation
Assessment and Approval
Identification
Configuration, Change, Release, and
Quality Assurance Management
104
Change
Request
Review and
Assign
Assess Impact
of Change
Approval
Change
Plan Change
Schedule
Change
Test, Quality
Assurance or
Change
Release
Changes to
Production
Status
Accounting
Audit Impact
of Changes
System

+ Change Management Key Top
Level Processes
105
Action Outcome
Generate Request ü Complete Change Request form
Log Status
ü Enter request in Change Request Log
ü Update CR status throughout Change process
Evaluate CR
ü Review Change Request and estimate effort to process
ü Develop proposed change
Authorize CR ü Grant approval to move forward with Change
Implement
Change
ü Make necessary changes to requested change
ü Communicate CR status to all stakeholders
CHANGE MANAGEMENT

+ Key Elements of Change
Management Success
106
Action Outcome
Planning ü Identify, resolve, and document Change Plan
Process ü Define Change process to level needed for control
People ü Identify and define roles and responsibilities
Culture ü Plan approach to mitigate cultural issues
Product ü Determine what products under Change Control
Automation ü Determine automation needs
Management ü Resolve managerial decisions regarding make buy
CM Plan
ü Document needs, planning, processes, procedure,
policies, schedules, responsibilities to integrate
Change Management
CM System
ü Tools chosen to assist in automating Change
Management
CM Adoption ü Implement strategy to adopt Change Management
CHANGE MANAGEMENT

+
107
IEEE–STD–828–2012
Configuration Management (and the associated Change
Management) is 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.
SWEBOK, IEEE STD 12207, IEEE STD 15288
Software Configuration Management (SCM) is the discipline of
identifying the configuration of software at distinct points in
time for the purpose of systematically controlling changes to
the configuration and of maintaining the integrity and
traceability of the configuration throughout the system
lifecycle.
CHANGE MANAGEMENT

108
108

+
SOFTWARE DEVELOPMENT LIFE CYCLE
The SDLC is the process for planning, creating, testing, and deploying software solutions to meet the
client needs whose timeliness, efficiency, and effectiveness is measured in units meaningful to the
decision makers.
PROGRAM
GOVERNANCE
ROADMAP
109
109
SDLC
Glen B. Alleman, 2012, 2013, 2014, 2015

+
The framework for all work activities performed at each stage of the software development project to assure
the resulting products meet customer requirements at the needed quality levels.
110
Governance Road Map
Software Development Life Cycle
§ Unit testing coverage policy
established and in place for
all changes to baseline from
Change Management Policy
§ Code changes traceable to
Change Request
§ Start reverse engineering
software topology
§ CMMI PIIP assessment to
identify obvious gaps and
closure plans in the SDLC
SDLC

+First Let’s Establish a
Framework for SDLC
Improvement
CMMI is a framework known to deliver business benefits to it’s
adopters Using CMMI provides a framework for the development
of a SDLC, that is consistent with the foundation of CMS processes
and the process improvement effort of our major client.
111
SDLC

+
CMMI Has …
n Purpose
n Method
n Mode/Means
112
BUT CMMI has NO Processes, NO Procedures, NO Work
Instructions.
CMMI has Process Areas to assess our practices for
writing software.
CMMI Process Areas are descriptions that improve
existing work practices, but do not Define what those work
practices must be for any given activity or organization.
SDLC

+
CMMI Purpose
n The Purpose of CMMI is to improve processes that facilitate
organizations' abilities to deliver product on time (schedule), within
budget (cost) and that does what it's supposed to do (quality and
functionality).
n The authors of the CMMI found a set of practices that, when
performed, has a consistently positive effect on Schedule, Cost and
Quality and Functionality.
n They found that these values can be further improved and
optimized by being able to pinpoint controllable variables and
apply quantitative analysis on those variables to tweak what affects
them.
113
SDLC

+
CMMI Method
n The Method CMMI is graduated institutionalization.
n The graduated approach towards institutionalizing processes starts
with simply performing process improvement practices without
much in the way of managing and organization.
n The next step moves up into planning and providing resources,
training, and controlling the output and checking the results of the
processes.
n After that, further institutionalization includes creating consistent
practices across projects, collecting feedback about the processes
then finally graduating towards statistical controls, predictive
analysis and removing causes of inconsistencies.
114
SDLC

+
Mode and Means
n An unspoken theme throughout CMMI is that of Communication.
n All CMMI practices work by facilitating communication.
n However, communication isn't just project participants talking to one
another.
n Communication also includes communication for the benefit of
those from which we need action to be taken as well as for the
benefit of those that follow that action.
115
SDLC

+
Just another reminder
116
CMMI is meant to help organizations improve their
performance of and capability to consistently and
predictably deliver the products, services, and sourced
goods their customers want, when they want them and at a
price they're willing to pay.
The CMMI Processes are NOT an engineering
development standard or a software development life
cycle.
From a purely inwardly-facing perspective, CMMI helps
companies improve operational performance by lowering
the cost of production, delivery, and sourcing.
SDLC

+ Motivation for a processed based
SDLC
117
Without insight into and control over their internal
business processes, we cannot know how well we're
doing before it's too late to do anything about it.
And we wait until the end of a project or work package to
see how close or far we were to our expectations, without
some idea of what our processes are and how they work,
how else could can we ever make whatever changes or
improvements we need to make in order to do better next
time?
CMMI provides the model to pursue these insights and
activities for improvement. It's a place to start, not a final
destination.
SDLC

+
CMMI is Just a Model
118
Like any other model, CMMI reflects one version of reality,
and like most models, it's rather idealistic and unrealistic.
When understood as just a model, people implementing
CMMI have a much higher chance of implementing
something of lasting value.
As a model, what CMMI lacks is context.
Specifically, the context of the organization in which it will
be implemented for process improvement.
Together with the organization's context, CMMI can be
applied to create a process improvement solution
appropriate to the context of each unique organization.

+
A Parallel Approach
ISO 12207 is the basis of CMS processes. Using 12207 in
conjunction with CMMI DEV, the firm can Test the SDLC to assure it
has the needed elements to actually deliver the needed
improvements
119

+
A Software Lifecycle Framework†
120
† Called out in CMS CM Policy April 2012, ISO/IEC 12207:2008(E), IEEE STD 12207-2008

+ Core Elements of a Software
Development Life Cycle in 12207
121
Knowledge Area
Requirements
Gathering
The elicitation, analysis, specification, and validation of software
requirements – those properties that must be exhibited to solve a real-
world problem
Design of Solution
The process and result of software architectural design – describing the
system’s top level structure and organization and identifying its
components – and software detailed design – describing each component
sufficiently to all for its construction
Development of
Solution
The detailed creation of working, meaningful software through a
combination of coding, validation, unit testing, integration, and debugging
Testing Developed
Software
The dynamic verification of the behavior of a program on finite set of test
cases, suitably selected from the usually infinite execution domain, against
the expected behaviors
Quality Assurance
Software quality considerations – the degree to which a set of inherent
characteristics fulfills requirements – that transcend the individual life
cycle processes of the software

+ Core Elements of a Software
Development Life Cycle in 12207
122
Knowledge Area
Maintenance of
Code Baseline
The totality of activities – both pre-delivery and post-delivery – to provide
cost effective support to the software system throughout its life cycle.
Configuration
Management
The discipline of identifying and controlling the configuration of the
system and its software components to maintain integrity and traceability.
Engineering
Management
The application of management activities – including measurement – to
ensure that the development and maintenance of software is systematic,
disciplined and quantified.
Engineering
Processes
The definition, implementation, measurement, management, change, and
improvement of software development processes.
Engineering Tools
and Methods
Software development tools and environments and methods to develop
software.

+
Why is Software Development not the
Same as Project Management?
CMMI–DEV
1.3 Separates
“Engineering”
from the
management
of Engineering
for a reason …
“Doing, is not
the same as
management
of the Doing”
Process Management ML 2 ML 3 ML 4 ML 5
Organizational Process Focus OPF ✔
Organization Process Definition OPD ✔
Organization Training OT ✔
Organization Process Performance OPP ✔
Organizational Innovation and Deployment OID ✔
Project Management ML 2 ML 3 ML 4 ML 5
Project Planning PP ✔
Project Monitoring and Control PMC ✔
Supplier Agreement Management SAM ✔
Integrated Project Management IPM ✔
Risk Management RSKM ✔
Quantitative Project Management QPM ✔
Engineering ML 2 ML 3 ML 4 ML 5
Requirements Management RM ✔
Requirements Development RD ✔
Technical Solution TS ✔
Product Integration PI ✔
Verification VER ✔
Validation VAL ✔
Support ML 2 ML 3 ML 4 ML 5
Configuration Management CM ✔
Process and Product Quality Assurance PPQA ✔
Measurement and Analysis MA ✔
Decision Analysis and Resolution DAR ✔
Causal Analysis and Resolution CAR ✔
123

+ Process Management
Maturity Assessment
124
CMMI Process Area ML
Organizational Process
Focus
2
Organization Process
Definition
3
Organization Training 3
Organization Process
Performance
3
Organizational
Innovation and
Deployment
3

+ Project Management
Maturity Assessment
125
Project Planning 2
Project Monitoring and
Control
2
Supplier Agreement
Management
2
Integrated Project
Management
3
Risk Management 4

+ Engineering
Maturity Assessment
126
Requirements
Management
2
Requirements
Development
3
Technical Solution 3
Product Integration 3
Verification 3

+ Support
Maturity Assessment
127
Configuration
Management
2
Process and Product
Quality Assurance
2
Measurement and
Analysis
2
Decision Analysis and
Resolution
3
Causal Analysis and
Resolution
5

+ One Approach to SDLC is an Agile
Paradigm
128
User Story
Clarity
Tasks Identified
Build Setup
Changes
Product Owner
Approval
Product
Backlog
Updated
Environment
Ready
Design
Complete
Unit Test Cases
Written
Documentation
Pre-release
Builds
Code Complete
Unit Tests
Executed
Refactoring
Code Check-In
Code Merging
and Tagging
Automated
Code Review
Peer Review
Code Coverage
Burn down
Chart Ready
Release Build
Functional
Testing
Regression
Testing
Performance
Testing
Acceptance
Testing
Closure of
Release Process

129
129

+
Software Testing in the SDLC
is a Critical Success Factor
The goal of development testing is to Break the software for the
purpose of revealing defects.
Black Box testing is done without knowledge of the design of the
software
White Box testing is done with design knowledge that generate
and select test cases
130

+ Test Techniques Applicable to the
Code Baseline
n Experience Based
n Ad hoc test cased based on testers intuition and experience
n Specification Based
n Specifications for the test target are analyzed to produce test cases
n Code Based
n Examination of code using control flow and data flow
n Fault Based
n Test cases generate to reveal specific faults by error guessing and mutation
testing
n Usage Based
n Evaluate reliability objectives based on usage profiles
n Application Based
n Specialized techniques applicable to systems constructed, integrated, or
operated in a particular fashion
131

+
PRODUCT ASSURANCE
Product Assurance provides the level of confidence that software is free from vulnerabilities, defects,
functional failures, missing requirements gaps, either intentionally by design or accidentally inserted
at anytime during its lifecycle, and that the software functions in the intended manner as described in
the business and technical requirements documentation.
PROGRAM
GOVERNANCE
ROADMAP
132
132
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Provide the level of confidence that software is free from vulnerabilities, either intentionally designed into the
software or accidentally inserted at anytime during its life cycle, and that the software functions in the intended
manner, including: Information Assurance and Application Security
133
Governance Road Map
Product Assurance
§ Establish minimally
acceptable documentation to
start product assurance
processes
Effectiveness for Product
Assurance
§ Develop release processes
around NIST Cyber
Framework V 1.0
Performance for Product
Assurance

+
Product Assurance
n Governance – centers on the processes and activities related to how the firm
manages overall software development activities.This includes concerns that
cross–cut groups involved in development as well as business processes that
are established at the organization level.
n Construction – concerns the processes and activities related to how the firm
defines goals and creates software within development projects.This includes
product management, requirements gathering, high–level architecture
specification, detailed design, and implementation.
n Verification – is focused on the processes and activities related to how the firm
checks and tests artifacts produced throughout software development.This
includes quality assurance work such as testing, but it can also include other
review and evaluation activities.
n Deployment – entails the processes and activities related to how the firm
manages release of software that has been created.This involves shipping
products to end users, deploying products to internal or external hosts, and
normal operations of software in the runtime environment.
134

+ Product Assurance is an Integrated activity
with Software Development
n Software assurance defined as …
n … the level of confidence that software is free from vulnerabilities,
either intentionally designed into the software or accidentally inserted
at anytime during its life cycle, and that the software functions in the
intended manner, including …
n Information Assurance and Application Security
n The firms software is part of a larger system – delivering value to
our clients – where most of what the system does is software, but
other components are critical as well as …
n Reliability
n Maintainability
n Availability
n Service Level Agreements
n Fault tolerance
n Disaster Recovery
135

+
Product Assurance Framework
n Identify – Develop the organizational understanding to manage
cyber security risk to systems, assets, data, and capabilities.
n Protect – Develop and implement the appropriate safeguards to
ensure delivery of critical infrastructure services.
n Detect – Develop and implement the appropriate activities to
identify the occurrence of a cyber security event.
n Respond – Develop and implement the appropriate activities to
take action regarding a detected cyber security event.
n Recover – Develop and implement the appropriate activities to
maintain plans for resilience and to restore any capabilities or
services that were impaired due to a cyber security event.
136
Framework for Improving Critical Infrastructure Cyber security, Version 1.0, National Institute of Standards and Technology February 12, 2014

137
137

+
QUALITY ASSURANCE,
VERIFICATION AND VALIDATION
Verification and Validation (V&V) is the process of checking that a software system meets
specifications and that it fulfills its intended purpose.
Quality Assurance is the processes needed to maintain a desired level of quality in a service or
product, especially by means of attention to every stage of the process of delivery or production.
PROGRAM
GOVERNANCE
ROADMAP
138
138
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Develop, document, and oversee the application of procedures to control the product design and development process that ensure that all
requirements are being met (QA). Demonstrate that a product or product component fulfills its intended use when placed in its intended
environment (VAL), and ensure that selected work products meet their specified requirements (VER)
139
Governance Road Map
Quality Assurance and V&V
§ Define the level of quality
needed in a release
§ Define the entry and exit
criteria for assuring the
release is ready for
production

+
Quality Assurance
n The purpose of the quality assurance process is to provide
assurance that work products and processes comply with their
specified requirements and adhere to their established plan. (TR
15504-2)
n Objectives:
n Identify, plan and schedule QA activities
n Identify quality standards, methods and tools
n Identify resources and responsibilities
n Establish and guarantee independence of those..
n Perform the QA activities
n Apply organizational quality management systems
140

+
Quality Assurance Model
The purpose of the
quality assurance
process is to
provide assurance
that work products
and processes
comply with their
specified
requirements and
adhere to their
established plan.
141
Application
Quality
Dependability
Availability
Reliability
Security
Functionality
Capabilities
Feature Set
Accuracy
Performance
Efficiency
Configurability
Interoperability
Maintainability
Testability
Supportability
Configurability
Interoperability
Maintainability
Usability
Documentation Quality
Ease of Learning
Output Understandability

+
TECHNICAL AND PROGRAMMATIC RISK MANAGEMENT
Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as
the effect of uncertainty on objectives) followed by coordinated and economical application of
resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to
maximize the realization of opportunities.
PROGRAM
GOVERNANCE
ROADMAP
142
142
Glen B. Alleman, 2012, 2013, 2014, 2015

+
Identify potential problems before they occur so that risk handling activities can be planned and invoked as needed
across the life of the product or project to mitigate adverse impacts on achieving objectives.
143
Governance Road Map
Risk Management
§ Establish risk register for
enterprise level risks
§ Connect risks with
Integrated Master Schedule
and adjust cost and schedule
forecasts based on risk
§ Establish risk registers for
HEAPlus
§ Integrate risk handling plans
with planned and budgeted
work in the IMS
§ Establish risk register for
OneEAp

+
Continuous Risk Management
144
http://www.sei.cmu.edu/risk/index.html

+
Control
§Review
§Integrate across teams
Plan
§Approve plans
§Recommend plans
Track
Identify
Analyze
§Review
§Prioritize
§Evaluate
§Classify
Top N Risks Assigned
Responsibility
Required Indicators
Status / Forecast
Status / Trends
Risks
Project Manager
1
2
3
4
5
Connecting the Continuous Risk
Management Processes
145
Technical Leads
Team Members

Technical Risk Management
Tracking and Controlling
Performance Deviations
Deliberating and
recommending a decision
alternative
Risk analysis of decision
alternatives, performing
trade studies and ranking
Proposing and/or identifying
decision alternatives
Formulation of objectives
Hierarchy and Technical
Performance Measures
Stakeholder
expectations,
requirements
definition and
management
Design solutions,
technical planning
Design solution,
technical planning,
and decision
analysis
Technical planning
and decision
analysis
Decision analysis,
lessons learned,
knowledge
management
Identify
Analyze
Plan
Track
Control
Decide and
implement
decision
alternatives
Communicate
146

147
147

+
Root Cause Analysis
Root Cause Analysis is a method of problem solving that identifies the sources of failure or problems.
A root cause is the source of a problem and its resulting symptom, that once removed, corrects or
prevents an undesirable outcome from recurring.
Failure
Is Trying to Tell
Us Something
It is not the Root Cause We Seek, It Is an Effective Solution
148
Performance–Based Project Management®, Copyright © Glen B.
Alleman, 2012, 2013, 2014, 2015

+ Our Path to Better Root Cause
Analysis
n Principles of Root Cause Analysis
n Understanding the weaknesses in our current method
n Introduction the Apollo Method
n Steps to applying Apollo
n Transition from the current method to Apollo
149

+
Beyond Conventional
Wisdom of Problem Solving
The common approach to problem solving is to categorize causes
or identify causal factors and look for root causes within the
categories.
Categorization schemes do not reveal the cause and effect
relationships needed to find effective solutions.
It is effective solution we are after
150

Policy and Procedure Rollout

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Policy and Procedure Rollout

Similar to Policy and Procedure Rollout (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Policy and Procedure Rollout