Systems

Integration &
Architecture
IT 312
 Reference Material:

Effective Methods for Software

and Systems Integration

Boyd L. Summers
Author

Software and Quality Assurance Consultant in BL Summers Consulting.LLC

Technical Lead Engineer & Software Engineering and Quality
Effective Methods in Systems Software Design &
Product Evaluation
Integration & Architecture Pillars of Success
Implementation
Chapters 5-6
Chapter 11

Software Software and

Introduction to Integration System Delivery
Software
Software and
Systems Methods
Requirements Chapter 7 Chapter 10
Chapter 4
Chapter 1

Software and
Software
Systems
Program and Project Subcontractor
Systems Design Integration
Planning Chapter 9
Chapter 3 Chapter 8
Chapter 2
Program and Project
Planning
Chapter 2
 Chapter 2 Program and Project Planning

2.0 PROGRAM Intended Learning Outcomes:

AND PROJECT 1. To recognize the importance of program and
PLANNING project planning.
2. To identify effective methods for software and
system integration dealing with program and
project planning
 Chapter 2 Program and Project Planning

Program and project planning is important as it describes

the necessary planning for software and system efforts
during software design/development life cycles.
Program and The definitions of systems design, software requirements and
Project design, configuration control, systems and software
integration, subcontractor involvement, deliveries, and product
Planning quality evaluations are critical to effective planning efforts.
The initiation of planning starts at the proposal phase with
the customer. The result of defined software design/
development plans, processes, procedures, subcontractor
support, and effective software tools provides estimations for
cost and schedules to be available for teams that are
impacted from the start of the proposal phase to delivery of
the work products to the customer.
 Chapter 2 Program and Project Planning

PROGRAM PROJECT PLANNING

Program and
Project DEVELOPMENT
PLANNED SENIOR
Planning SCHEDULES MANAGER PLAN

TEAMWORK TEAM CODE OF CONDUCT

PROGRAM AND PROJECT PLANNING

 Chapter 2 Program and Project Planning

Before a program can require a plan, program

objectives are defined and technical & management
disciplines are identified.
This information defines a reasonable estimate or
cause for:

PROGRAM
Risk management Defined and
Cost evaluations
assessments documented tasks

Manageable
Progress reports
schedules

The basic difference between plan, project and program: PLAN details a course of action; a PROJECT is short-term and designed to deliver a specified output within time, cost and quality parameters; and a PROGRAM is
a group of related projects that are run as a group toward producing a common benefit.
 Chapter 2 Program and Project Planning

The people who work in a software

design/development life cycle are expected to meet
and achieve program objectives and understand
the high expectations required of them.

PROGRAM These activities begin at the systems design level of

engineering and flows down to other software
disciplines.

Program objectives identify goals for the program

with consideration of how these goals are to be
accomplished.
 Chapter 2 Program and Project Planning

Effective programs that perform to defined

objectives and within the scope are successful
due to implementing:

PROGRAM
• Required data
• Tasks or functions
• How the work product performs
• Quantitative mechanisms
 Chapter 2 Program and Project Planning

When program objectives and the scope are

considered, program managers can select the
PROGRAM best approach that would eliminate
“roadblocks” imposed by scheduled delivery
deadlines, budget concerns, and people
issues.
 Chapter 2 Program and Project Planning

Framework Established
Software processes provide the framework
and effective planning when it is time for
deliveries to software and systems
integration facilities and the customer.
PROGRAM

A process framework, encompassing five activities— communication, planning,

modeling, construction, and deployment—is presented in the next slide,.
 PLANNING AND ENGINEERING TASK
Software Risk
Engineering Communication Planning Managem Deployment
PROGRAM Tasks ent

AND PROJECT Systems design AUG 25

PLANNING Requirements AUG 30

Design SEP 5
The planning and engineering Configuration OCT 5
control
task presented here explains
the disciplines and methods Integration OCT 31
pertaining to communication,
Delivery NOV 30
planning, risk management,
and deployment. Subcontractor
Quality product DEC 5
evaluations DEC 15

Process Framework
 Chapter 2 Program and Project Planning

Framework Established
Software processes provide the framework and
effective planning when it is time for deliveries to
software and systems integration facilities and the
customer.
PROGRAM Activities related to the framework are required for all
programs. For effective planning, there are multiple
tasks, scheduled milestones, and quality aspects
necessary to ensure the framework is established not
only for managers but also for the people who work.
The quality assurance team, which is independent at
times, and configuration management personnel
monitor the framework processes
 Chapter 2 Program and Project Planning

The main reason that software projects are

planned and controlled is to eliminate any
confusion that could occur.
The teams that are expected to provide work
PROJECT products struggle if projects are not planned,
and control is not even an option.
Studies showed that when schedule, cost, and
quality objectives are not a top priority, the
project is not successful.
 Chapter 2 Program and Project Planning

Although project success rates are improving,

the failure rate can be high when an objective
such as quality attributes is not
implemented.
PROJECT To avoid failure, the project manager and a
team of systems and software engineers who
build work products must develop an
approach for project planning, oversee
activities, and ensure configuration control is in
place.
Configuration Control is the activity of managing the product (or project's deliverables) and related documents, throughout the lifecycle of the product. An effective Configuration
Control system ensures that: The latest approved version of the product and its components are used at all times.
 Chapter 2 Program and Project Planning

Software projects get in trouble when uncertainty

and confusion come into play. There are times
when systems and software designers do not
communicate, so defined requirements are not
discussed in relation to the developed work
PROJECT product. To eliminate this lack of communication,
guidelines must be established, such as:
• Structure daily meetings
• Share ideas
• Inform project managers of problems occurring
• Listen and try to resolve complaints
 Chapter 2 Program and Project Planning

Projects can have a “daily standup”

meeting. One a day can get to the
critical points or problems and resolve
them that day.
PROJECT

A daily stand-up meeting is an opportunity for the project team to discuss a project's progress at a high level. These meetings allow project members to share critical information, openly
discuss issues, and hold themselves and each other accountable. Daily stand up meetings should be no longer than 15 minutes in order to stay effective
 Chapter 2 Program and Project Planning

If there are concerns, discuss issues with a

project manager, then you do not waste other
PROJECT team members’ time. In the past and
currently, these meetings have an impact on
hours of work that could be accomplished.
 Chapter 2 Program and Project Planning

“Project managers need to have the confidence that

their people can take care of the daily routines, so the
project managers do not need to attend meetings for
PROJECT hours and hours. Time is lost; then, people are ready to
go home for the day knowing they have time sitting
around listening to people who have no impacts on
what they are trying to accomplish that day. Stop this
right now. Let us go to work.” Boyd L. Summer
 Chapter 2 Program and Project Planning

Communication planning principals define goals and

objectives during the course of program and project
planning. The planning aspects require a set of
managers to understand not only their position but
also the technical practices that support systems and
software engineering and to define the course that
PLANNING lies ahead.
There are many planning ideas and decisions by
managers that are not accepted by team members
due to the complexity of change.
What should you do?
Under planning, the program and project should
consider eliminating chaos.
 Chapter 2 Program and Project Planning

The pressure on teams can be enormous, and useful

guidance can be provided, such as:
• Providing a scope for the team to know what is
ahead
• Involving systems and software teams to help with
PLANNING delivery schedules
• Planning to adjust and accommodate change
• Identifying risks that could have an impact on
program and project planning
• Defining and understanding quality
• Tracking the progress daily and adjusting if needed
 Chapter 2 Program and Project Planning

At the senior management level, program

and project managers are required to provide
effective planning and focus so teams can be
effective during software design/
SENIOR development activities.
MANAGEMENT Failure in planning is not an option and does
jeopardize the success in achieving sound
practices in program and project execution.
Communication early in the process is the
key to eliminate risks and the ability to
embark on operational deployments.
 Chapter 2 Program and Project Planning

The required job of a senior manager is to

provide the common framework for
program and project planning to address
engineering tasks.
SENIOR
MANAGEMENT Many software managers begin their careers
as software designers or developers. These
types of managers serve:
• The company program and projects
• Their employees
• Themselves
 Chapter 2 Program and Project Planning

When a software manager’s team or

organization delivers software to a customer in a
timely fashion, this is called execution.
There are questions that involve execution, such
SENIOR as:
MANAGEMENT • Do you have customer requirements?
• Do you have an approved budget?
• Do you have an approved plan and schedule?
• Are your program and project capable of dealing with change?
• Do you keep everyone focused?
• Do customers encounter quality issues with delivered work products?
• Do you measure work status on a regular basis?
• Do you find ways to improve?
 Chapter 2 Program and Project Planning

Communication is important.
A good software manager must learn to
communicate in different ways, for example,
SENIOR providing formal presentations for upper-level
MANAGEMENT management.
Face-to-face communication to explain
agreements with other program and project
managers provides a road map and the plans
for meeting goals.
 Chapter 2 Program and Project Planning

Communication is important.
E-mails work at times, but having a discussion
SENIOR will open up your team members to explain
MANAGEMENT good and bad news.
Also, communication is a positive way for
team members to understand your
expectations.
 Chapter 2 Program and Project Planning

Program and project schedules that are not

understood from the start will have an impact
on resistance.
SENIOR To implement and use unreasonable
MANAGEMENT schedules will imply that organizations and
team members are not working hard.
Software managers must be aggressive and
demand the best from designers and
developers, but do not abuse them. Manage
your teams wisely.
 Chapter 2 Program and Project Planning

The program and project planning method is

well defined in the project planning process.
The process area states the following:
PROGRAM The term “project plan” is used throughout this
AND PROJECT process area to refer to the overall plan for
PLANNING controlling the project.
The project plan can be a standalone document or be
distributed across multiple documents. In either case,
a coherent picture of who does what should be
included. Likewise, monitoring and control can be
centralized or distributed, as long as at the project
level a coherent picture of project status can be
maintained.
 Chapter 2 Program and Project Planning

The scale of numerous software design/

development efforts is huge and can lead to
confusion and coordination with affected teams.
PROGRAM Internal organizations in programs and projects
AND PROJECT develop schedules and define processes and tasks.
PLANNING At the senior management level, managers assign
responsibility, authority, and accountability to
program and project managers or team leaders to
define the software design/development (i.e.,
systems and software design, configuration
management, quality engineering, etc.) to provide
required support.
 Chapter 2 Program and Project Planning

Planning activities include:

• Software lessons learned from previous programs
and projects
• Cost and schedule estimates and staffing plans
PROGRAM
AND PROJECT • Software and system requirement definitions
PLANNING • Defined safety and security requirements
• Selection of appropriate software subcontractors
• Engineering documentation and historical data
impacts
• Program and project objectives
• Contract understanding of required or necessary
requirements
 Chapter 2 Program and Project Planning

The planned schedule defines tasks and processes

to be conducted for implementation of those tasks
and processes. The schedules that are planned affect
PLANNED team capabilities for risk assessment, configuration
SCHEDULES control, and quality.
There are three critical factors in many software
design/ development programs and projects. The
scope, schedule, and budget combined affect the
quality of work products.
 Chapter 2 Program and Project Planning

The critical items pertaining to a documented

DEVELOPMENT development plan consist of planned schedules and
PLAN provide engineering information and direction for
the production of software. It is important to know
that the planning process is consistent with system-
level planning.
 Chapter 2 Program and Project Planning

All major software design/development activities require

consistency in accordance with the steps outlined in the use
of development planning, including the following:
• Definition of entry and exit criteria for the software design/
DEVELOPMENT development
PLAN • Review and assessment of the work product and task
requirements
• Definition or updates of the process for each software activity
• Development or update of the estimating process
• Development of initial cost and schedule estimation and risks
• Preparation of detailed implementation plans
 Chapter 2 Program and Project Planning

An important element in all software programs and

projects is teamwork, the coordination and
communication within teams applied to meet work
expectations.
The effective methods for systems and software
planning coordination provide value for a program
TEAMWORK and projects to far exceed high expectations.
The software design/development energy and
consistency appeal to achieve high-performance
goals and aspirations. By having trust among teams,
a cohesiveness is maintained in the work
environment, and planning schedules becomes
much easier to coordinate and implement within the
team.
 Chapter 2 Program and Project Planning

A plan developed is correct or successful when the

team delivers a high quality work product on time to
meet the schedule and works within the budget.
TEAMWORK
Remember that senior managers must encourage
the program and project managers to work together
with their teams to become effective, respond to
customer expectations, and ensure quality.
 Chapter 2 Program and Project Planning

As teams inside programs and projects

become autonomous, they run the risk of
pulling in different directions. One team that
establishes goals to improve its own
TEAMWORK processes could subvert the efforts of other
teams.
When there is a face-to-face meeting as one
group, teams are able to agree on proposed
planning and project schedules and quality
goals or expectations.
 Chapter 2 Program and Project Planning

In meeting as one group, the team will accomplish

the following:
• Meet and achieve team objectives
• Resolve conflicts and issues
TEAMWORK
• Satisfy customer requirements

When struggles with everyday challenges and

problems are ignored, a team may use the required
team action cycle shown in the next slide.
 Chapter 2 Program and Project Planning

TEAMWORK

Team action cycle

! Managers do not control change but manage change.

 Chapter 2 Program and Project Planning

It is okay for a team to fail but to be right at least

80% of the time.
TEAM CODE OF
CONDUCT Teams that have the privilege and are able to
provide clear communication and their own
opinions seem to be successful.

When one person speaks, listen and treat that

person with respect.
 Chapter 2 Program and Project Planning

Once you help each other, you will:

TEAM CODE OF
CONDUCT • Show trust in every individual
• Be honest with your team
• Have ideas that show value
• Stop whining or crying
 Chapter 2 Program and Project Planning

When teams are expected to attend meetings,

be prepared and ensure that action items
received are understood in connection with
expected goals to be completed. Work
TEAM CODE OF
together and do not be lazy.
CONDUCT
Many software designers get themselves in a
mode of wanting to be left alone when coding.
They get in a zone, so be polite, and do not
interrupt, and show respect for other software
designers.
 Chapter 2 Program and Project Planning

The team process includes meetings; promise

to honor meeting start and end times. Finally,
bring your sense of humor, be friendly and
TEAM CODE OF flexible, and always keep a positive attitude.
CONDUCT
As a software designer, I know the frustrations
that could have an impact on jobs and careers
in software design/development. Change from
an individual to become a team player as
shown in the next slide.
 Chapter 2 Program and Project Planning

TEAM CODE OF
CONDUCT

Team development life cycle.

 Chapter 2 Program and Project Planning

Teams should not assume that being knowledgeable

would offend others or expect other team members
to understand what offends you.
The team needs to recognize the relationship
CONCLUSION between the intent and impacts and stay away from
misunderstandings and the scenario of assigning
blame.
Effective teams need to learn to manage their own
reactivity and to be curious about what caused the
blame. Practice letting members of a team know
how something has an impact on you and rely on
others’ experience and expertise.
 Chapter 2 Program and Project Planning

CONCLUSION
There is no “I” in team.
 Chapter 2 Program and Project Planning

Read the case study (Westinghouse Electric’s

Cornerstone  project) and answer the
following questions:
1. Identify and discuss the risks in  Westinghouse
Electric’s Cornerstone  project. 
ASSESSMENT
2. Why was change management so  important for
this project and this  company? 
3. What management, organization and
 technology issues had to be addressed by  the
Westinghouse project team?
 Chapter 2 Program and Project Planning

Westinghouse Electric Company provides  fuel,

services, technology, plant design, and  equipment to
WESTINGHOUSE utility and industrial customers  in the worldwide
ELECTRIC TAKES ON commercial nuclear electric  power industry. A
THE RISKS OF A “BIG private company created in  1999 after its
BANG” PROJECT predecessor was sold and spun  off, Westinghouse
Case Study has 14,500 employees in  17 countries and is
headquartered in  Cranberry Township, Pennsylvania.
Shortly  after Westinghouse’s creation, the company
 implemented a full suite of SAP software  across the
enterprise.
 Chapter 2 Program and Project Planning

For the past 15 years, the nuclear energy industry

was in a holding pattern, with steady business
WESTINGHOUSE throughout but minimal growth. Westinghouse
ELECTRIC TAKES ON supplied nuclear equipment and services to plants
THE RISKS OF A “BIG all around the world, and the business was
BANG” PROJECT successful. The initial SAP installation served
Case Study Westinghouse just fine for nearly an entire decade.
From 2010 onward, the nuclear energy industry
started to expand. Westinghouse began to
experience growth in sales, and its legacy SAP
installation was not equipped to handle the
increased volume of business.
 Chapter 2 Program and Project Planning

Westinghouse needed to update its older system

to support new processes, configurations, and
WESTINGHOUSE functionalities that related to the larger amount of
ELECTRIC TAKES ON business it was conducting. The company estimated
THE RISKS OF A “BIG that it would increase in size fourfold over the next
BANG” PROJECT few years. Westinghouse opted to launch a
Case Study sweeping new program to update its IT. The
program, called Synergy internally, consisted of 40
different projects, and updating the SAP system
was one of the largest.
 Chapter 2 Program and Project Planning

Rather than simply upgrade its existing systems,

Westinghouse opted to “re implement” those
WESTINGHOUSE systems with much more current SAP technology.
ELECTRIC TAKES ON Westinghouse did this because its 10-year-old SAP
THE RISKS OF A “BIG ERP implementation was too outdated. It was
BANG” PROJECT easier for the company to simply replace the old
Case Study SAP ERP systems with a completely new
configuration. The division of the Synergy project
dedicated to the SAP re implementation was known
as Cornerstone, aptly named because the new
system would be the foundation for the company’s
future growth.
 Chapter 2 Program and Project Planning

Westinghouse wanted to start with a cleancore

SAP environment with a completely new
WESTINGHOUSE reconfiguration. The company’s goals were to
ELECTRIC TAKES ON convert all existing data that the company wanted
THE RISKS OF A “BIG to save, as well as add new functionalities that
BANG” PROJECT would help the company manage its imminent
Case Study growth. Westinghouse hoped to add a new general
ledger, a new enterprise reporting environment
based on SAP NetWeaver Business Warehouse (BW)
and SAP BusinessObjects solutions, and new
implementations of SAP Customer Relationship
Management (CRM).
 Chapter 2 Program and Project Planning

In order to ensure that the re implementation

WESTINGHOUSE went smoothly, Westinghouse took many
ELECTRIC TAKES ON precautions to manage the risks involved in such a
THE RISKS OF A “BIG significant change. First, the company ensured that
BANG” PROJECT every element of the Cornerstone project was
Case Study motivated by a particular business driver or goal.
 Chapter 2 Program and Project Planning

For example, the SAP CRM implementation was

WESTINGHOUSE intended to address the company’s goal of aligning
ELECTRIC TAKES ON three distinct operational regions to present a single
THE RISKS OF A “BIG face in every customer location, and the SAP ERP
BANG” PROJECT Human Capital Management and SAP NetWeaver
Case Study Portal implementation were intended to support
the company’s plan to increase global hiring. By
associating goals with each element of the project,
Westinghouse was able to more precisely control
the implementation of the new system.
 Chapter 2 Program and Project Planning

Once the elements of the new SAP system came

into place, Westinghouse had to decide how to
WESTINGHOUSE actually roll out the new system. It could have used
ELECTRIC TAKES ON a gradual, phased approach, adding new systems
THE RISKS OF A “BIG over a three-year period, but the company instead
BANG” PROJECT decided on what it called a “big-bang approach.”
Case Study Management decided that the company was
growing too fast for a slow approach—it needed the
new systems as soon as possible, and hoped to
recoup the return on investment sooner rather than
later. However, while the phased approach was
more expensive, it was also much less risky.
 Chapter 2 Program and Project Planning

To manage the increased risk of the big-bang

approach, the company brought in a change
WESTINGHOUSE management consultant. The consultant, John
ELECTRIC TAKES ON Flynn, helped Westinghouse with both the Synergy
THE RISKS OF A “BIG and Cornerstone projects, but focused on the
BANG” PROJECT Cornerstone project. Flynn performed a risk
Case Study assessment study to identify business areas that
were most likely to undergo significant change. He
found that the Westinghouse supply chain was one
of the areas most likely to endure significant
change, since the company’s growth would add
many new elements to the chain.
 Chapter 2 Program and Project Planning

Therefore, the change management team spent

extra time with Westinghouse’s supply chain staff
WESTINGHOUSE members to help them understand the new project
ELECTRIC TAKES ON and its impact on their day-to-day routines. The
THE RISKS OF A “BIG project team recruited power users from the supply
BANG” PROJECT chain organization and discussed specific project
Case Study details with business unit leaders. These meetings
also helped gain support from supply chain
executives who could better understand the link
between the information systems project and their
business goals, and then articulate this connection
to other users.
 Chapter 2 Program and Project Planning

Next, after mapping the risk associated with each

element of the SAP re implementation,
WESTINGHOUSE Westinghouse had to finally switch, or cut over, to
ELECTRIC TAKES ON the new system. To handle that event, Flynn worked
THE RISKS OF A “BIG with business leaders to recruit coordinators for
BANG” PROJECT every site in the organization. Each site coordinator
Case Study had a list of responsibilities and a checklist to
complete prior to the system going live to ensure
each site was ready when the switch was flipped.
Westinghouse dedicated extra staff to answer
employee questions in the problem areas
designated by Flynn.
 Chapter 2 Program and Project Planning

The company created an automatic call

distribution system and e mail system that routed
WESTINGHOUSE users across all time zones to the employees most
ELECTRIC TAKES ON able to answer their questions. For example,
THE RISKS OF A “BIG Westinghouse expected that there would be many
BANG” PROJECT questions about passwords, access issues, time
Case Study entry, and purchase requisition management after
the new system went live, so the company provided
extra staff to answer those and other frequently
asked questions.
 Chapter 2 Program and Project Planning

This “temporary help desk” handled over 2,000

inquiries during the first three weeks of the
WESTINGHOUSE implementation. The project team also set up a blog
ELECTRIC TAKES ON where users could share tips and solutions. The
THE RISKS OF A “BIG cutover to the new SAP system went smoothly, and
BANG” PROJECT the company plans to use many of the techniques
Case Study that it learned from the implementation in the
future. It plans to use the blog as its primary
communication method for support solutions and
other Synergy projects, and future additions to the
SAP suite will be much easier than the sweeping
big-bang change.