2-1 CH 2 Systems View Methodology. 2-2 Objectives You will understand the topics when you can.

2-1

CH 2

Systems View Methodology

2-2

Objectives

You will understand the topics when you can

2-3

Objectives

Define the systems approach and its impact on project management

Define a PMLC (project management life cycle) and understand how to apply it

Define several SDLC (systems development life cycle) models and know when to use each different type

Define the relationship between the PMLC and the SDLC and understand how the two work together

2-4

Systems Approach to Project Management

In the early stages of most information technology (IT) education programs, students are taught to examine any proposed issue or opportunity by breaking it down into smaller and smaller parts in order to completely understand the total process and then offer a proposed solution

2-5

Systems Approach to Project Management

The systems approach is a process that allows projects to be viewed in the context of the entire environment, including both inside and outside the organization.

It is the opposite of an analytical process, which takes the whole and breaks it into its component parts. Project managers, to be successful, must learn to use a systems approach.

The systems approach consists of three interrelated components: systems theory, systems components and syatems management

2-6

Systems Approach to Project Management

A project doesn't occur in a vacuum; it exists within a system. There are two broad categories of systems: open and closed.

A closed system is considered to be completely selfcontained; to understand it, you merely look on the inside, without regard to the external environment.

2-7

Systems Approach to Project Management

An open system is not self-defining; to understand it, you must also understand its environment.

2-8

Projects Cannot Be Run In Isolation!

Projects must operate in a broad organizational environment

Project managers need to take a holistic or systems view of a project and understand how it is situated within the larger organization

2-9

For Example: The sales and marketing department has

approached the IT department about adding a “shopping cart” feature to the Web site. It would allow customers to place orders online, adding and removing items until they are ready to process their order (check out). The IT department is very excited because it would be a very cool technology to work with and put on the site

But, someone, ideally senior management and the project manager, needs to take a step back and ask…

2-10

Questions Needing Answers

Before we implement that feature, we need to examine how this will affect and be affected by other projects already underway?

What are our competitors doing? When should this be done in relation to other

projects waiting to start? What legacy systems must we interact with?

2-11

“Systems Thinking”

Allows projects to be viewed in the context of the entire environment including both inside and outside of the organization

Opposite of analytical thinking Analytical thinking, things are broken into

progressively smaller parts and more highly specialized disciplines

2-12

“Systems Thinking”

The Systems Approach is a process which allows projects to be viewed in the context of the entire environment including both inside and outside of the organization. It is a process that can bring order and discipline to a large, chaotic, unorganized situation

2-13

“Systems Thinking” Individuals look at the “whole organism” rather

than just the parts Harold Kerzner wrote: “the ability to analyze the

total project, rather than the individual parts is the first prerequisite for successful project management”

The ability to examine a problem or issue by first understanding the environment it exists within, before reducing the problem or issue into smaller components and finally managing the resolution of the problem or issue

2-14

Definition of ‘System’

An organized or complex whole; an assemblage of things or parts interacting in a coordinated way

CharacteristicsThe whole is greater than the sum of its parts

(body)They are dynamic and exhibit some kind of

behaviorScope is in the eye of the beholder (or

stakeholder)

2-15

Systems View

Forces review of the interrelationship of the various subsystems

Is a dynamic process that integrates all activities into a meaningful total system

Systematically assembles and matches the part of the system into a unified whole

Seeks an optimal solution or strategy in solving a problem

2-16

Systems Terminology Elements – smallest part of a system being

studied (activity) Subsystems – a system is made up of subsystems,

smaller systems that are part of a larger system such as the human heart is a subsystem of the human body or the accounts receivable subsystem is a part of the financial software system of the organization

Attributes – quantitative and qualitative characteristics of systems (Project; Cost and Progress )

2-17

Systems Terminology

Environment – anything that lies beyond the decision maker’s control yet influences the behavior or outcome of the system

Boundary – what separates the system from the environment.

Most of what a Project Manager does exists on the boundary!

2-18

Systems Boundary and Environment

2-19

Systems Terminology

Objectives – human-made systems are designed to do something

Constraints - every system has limitations forced on them from internal forces or external forces and sometimes the limits are self controlled (Scope, Time, Cost)

Requirement – a partial need to satisfy the objective

2-20

Systems Terminology Integration – for a system to reach its

objectives, all the subsystems and elements must work together effectively

Open and Closed SystemsClosed – self contained, focus on internal workings

(machine). Ignore the environment’s influenceOpen – just the opposite, they interact with the

environment and adapt. (humans, organizations)

2-21

Project Management Impact Organizations are Open Systems

They must interact with the environment to surviveManagers must:

• Appreciate the need to assess forces in the environment• Understand the forces that significantly affect their

organization• Integrate these forces into the organization’s goals,

objectives, and operationsRole of the Project Manager

• Every project is influenced by outside forces, these alone should not be allowed to dictate the conduct of the project

• Must manage the behavioral and social aspects of the project

2-22

Systems Approach Emerged in the 1950s to describe a more

analytical approach to management and problem solving

Three parts include:Systems philosophy: View things as systems,

interacting components working within an environment to fulfill some purpose

Systems analysis: problem-solving approachSystems management: Address business,

technological, and organizational issues before making changes to systems

2-23

The Project Management “Systems” Approach:

1. First take on a systems philosophy, understand the environment

2. Then conduct your systems analysis and finally

3. Perform systems management (responsible for the management of the

whole system—objectives, environment (both internal and external), constraints, resources (both human and other), and the culture and social environment of the organization. This is what project management is all about)

2-24

Good Project Managers Must

Appreciate the need to assess forces in the environment

Understand the forces that significantly affect their organization

Integrate these forces into the organization’s goals, objectives, and operations

2-25

Good Project Managers Must Getting answers to the following questions as soon as

possible will help your project get off to a great start: • Who is the project sponsor? • What other ongoing or pending projects might

have an impact on this project? • What outside influences could have an impact on

my project? • What early constraints, if any, have been placed on

the project from scope, time, and cost perspectives?

2-26

PROJECT MANAGEMENT LIFE CYCLE(PMLC)

Project managers and their project teams divide projects into phases to facilitate better control and communication. When you put these phases together into a prescribed order, you have the project's life cycle.

2-27

PMLC A project management life cycle is a prescribed

order of phases (smaller segments of the entire project) in which each contains a specific deliverable which collectively deliver a resultWhat work will (should) be done in each phase.A definition of each phase’s deliverables and when.The change control process for each deliverableWhat resources are involved in each deliverableCriteria that needs to be met complete each phase

2-28

PMLC Every organization should create a standard

project life cycle in order to promote communication within the team and stakeholders and across all teams in the organization

A deliverable is a product or service produced or provided as part of a project

Project life-cycles and phases vary by project and/or industry depending on the Methodology

2-29

PMLC

Figure below shows a generic project life cycle that has six phases: initiate, plan, execute, control, close iteration, and close projec

2-30

PMLC

2-31

PMLC Notice in Figure above that there are two close phases. The

close iteration phase addresses the process steps that happen at the end of each iteration, such as:

• Did we get everything done in this iteration that we planned to?

• If not, what is remaining, and when will this get done? • What lessons have we learned in this iteration? • When have we scheduled the next iteration? The close project phase occurs after the team decides to

complete the project

2-32

A Project Lifecycle Should Include: What specific work (activities) should be done in

each phase A definition of each phase’s deliverables

(outcomes) The integrated change control process being used What resources are involved with each

deliverable Criteria that needs to be met to complete each

phase

2-33

SDLC

The systems development life eycle (SDLC) is a systems approach to problem solving that organizes these processes into phases and tasks for the purpose of building an information system product, starting with the initial planning processes and carrying through to implementation and support.

2-34

SDLC

Many SDLC methodologies have been developed over the years to guide the development effort. One of the first and most common is the waterfall model, which was inherited from the engineering community.

2-35

Product Life Cycles Building a Product also requires a life cycle The Systems Development Life Cycle (SDLC) is an

approach to building information technology systems consisting of a standard set of phases each producing a prescribed set of deliverables

Review SDLC Models/MethodologiesWaterfall (predictive)Spiral (somewhat predictive)Iterative/Incremental (adaptive)Agile (Scrum, RUP, Extreme Programming)

2-36

Waterfall Model

The waterfall model is considered the traditional approach to systems development. It describes a development approach that is linear and sequential, has distinct objectives for each phase, and in which the output of one phase is the input for the next.

There is generally not a yes/no or true/false answer, but there may be a good/bad distinction.

2-37

Waterfall Model

The waterfall approach is typically used because it provides management the most visibility, is easier to manage, and it is best understood within the industry. It lends itself to large, complex applications due to its reliance on documentation and end-oF-phase deliverables

2-38

Waterfall Model

2-39

Waterfall Model Strengths

Is well understood by most practitioners Easier to manage than the new agile methods When working on large complex applications When teams are distributed geographically When using a less experienced IT resources

Weaknesses Does not accommodate a change to requirements very well All Requirements must be known and defined in the beginning Does not allow a repeat of a phase (iterate) Limited adaptability to different project types Encourages communications gap between users and IT

2-40

Evolutionary Prototyping Focuses on gathering correct and consistent

requirements and is the approach of building a system incrementally through a series of gradual refinements or prototypes

Requirements are discovered throughout the process and the system is repeatedly refined based on those discoveries

Allows developers to learn from each prototype and apply those lessons to future versions

The prototyping approach is an excellent choice for research and development projects, quickly building mockups of system components for user review allows for timely feedback that can be incorporated in the next design or prototype

2-41

Evolutionary Prototype Strengths

Visibility – customers see steady progressUseful when requirements are changing rapidly or

no one fully understands the requirements Weaknesses

It is impossible to know at the beginning of the project how long it will take

There is no way to know the number of iterations/phases that will be required

Difficult to build an accurate cost estimate

2-42

Spiral Model

The spiral life cycle model (see Figure 2-5) is based on the classic waterfall model with the addition of risk analysis and iterations.

2-43

Spiral Model

The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses.

It's actually a series of short waterfall cycles, each producing an early prototype that represents a part of the entire project.

2-44

Spiral Model

Similar to the classic waterfall model with the addition of risk analysis and iterations

emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses

It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project

2-45

Spiral Model

2-46

Spiral Model Strengths

Good for large complex projectsAccommodates change wellCan react to risks very quickly Software produced early in the life of the project Increased user visibility

WeaknessesCan be a costly model to useRisk analysis requires highly specific expertiseProject’s success highly dependent on risk analysisDoesn’t work well for small projects

2-47

Iterative and Incremental Model The iterative and incremental model is an intuitive

approach to the waterfall model and is similar to the spiral model. Multiple development cycles commonly referred to as (timeboxes) take place in this model (see Figure 2-6). Cycles are divided into smaller, more easily managed iterations.

Each iteration passes through the standard lIfe cycle phases.

A working version of software is produced during the first Iteration, so you have working

2-48

Iterative and Incremental Model

Each iteration passes through the standard lIfe cycle phases.

A working version of software is produced during the first Iteration, so you have working software early on during the project life cycle. Subsequent iterations build on the initial software produced during the first iteration.

2-49

Iterative and Incremental Model Repeating a process phase until ultimately

meeting the project requirements (iterating the phases) and developing and delivering a system in stages (increments)

The system grows by adding new and enhanced functionality with each build cycle

Each cycle tackles a relatively small set of requirements and proceeds until the entire scope of the project is completed

Similar to the spiral model

2-50

Iterative and Incremental Model

2-51

Iterative and Incremental Model Strengths

Generates working software quickly and earlyFlexibilityEase of testing Ease of risk management

WeaknessesNot easy to manageMust be able to estimate well to plan iterationsHard to determine cost and time estimates early

in the process

2-52

Fig page 42

2-53

Scrum Model

The Scrum approach, developed by Ken Schwaber and Jeff Sutherland, was developed for managing the systems development process.

Scrum is based on the concept that software development is not a defined process but an empirical process with complex input-to-output transformations that mayor may not be repeated under different circumstances

2-54

Scrum Model Based on the concept that software development is

not a defined process, but an empirical process with complex input to output transformations that may or may not be repeated under differing circumstances

The name Scrum is essentially derived from the game of rugby. In rugby, a play where two opposing teams attempt to move against each other in large, brute-force groups is called a scrum. Each group must be quick to counter the other’s thrust and adjust and exploit any perceived weakness, without the luxury of long term planning

2-55

Scrum Model The main idea of Scrum is that systems

development involves several environmental and technical variables that are likely to change during the process (for example, requirements, time frame, resources, technology)

This makes the development process unpredictable and complex, requiring flexibility of the systems development process in order to respond to these changes

2-56

Scrum Model

2-57

Scrum Model Strengths The project is more manageable Progress is made, even when requirements are

not stable Everything is visible to everyone Team communication improves The team shares successes along the way and at

the end Customers see on-time delivery of increments Customers obtain frequent feedback on how the

product actually works

2-58

Scrum Model Weaknesses

Doesn’t work well with large teamsRequires experienced developersNot good for mission or life critical systems.Requires hands-on management, but not

micromanagementRequires constant monitoring both

quantitatively and qualitatively

2-59

Rational Unified Process (RUP)

RUP provides a disciplined approach to assigning tasks and responsibilities within a development organization.

Its goal is to ensure the production of high-quality software that meets the needs of end users, within a predictable schedule and budget.

2-60

Rational Unified Process (RUP)

RUP is an iterative process that identifies four phases of a software development project: inception,

elaboration, construction, and transition .

2-61

Rational Unified Process (RUP) Developed as a process complement to the Unified

Modeling Language (UML) Adaptable process framework which can be used for

both heavy and light projects Based on iterative development paradigm with Four

Phases • (Inception, Elaboration, Construction and Transition)• Each phase contains one or more iterations

2-62

RUP

2-63

RUP Strengths

Risks are mitigated earlier Change is more manageable Higher level of reuse The project team can learn along the way Better overall quality Enhances team productivity, by providing every team

member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities.

Weaknesses Not easy to tailor to smaller projects Has a large volume of process guidelines and is detail heavy

2-64

eXtreme Programming (XP Model)

Extreme Programming (XP) is arguably the best known of the agile methodologies.

XP's basic approach involves short development cycles, frequent updates, dividing business and technical priorities, and assigning user stories.

2-65

XP Model

XP has four key values- communication, feedback, simplicity, and courage-plus a dozen practices

2-66

XP Model

These practices are followed during XP projects-planning, small releases, metaphor, simple design, refactoring, testing, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards.

2-67

eXtreme Programming (XP Model)

Basic approach includes short development cycles, frequent updates, dividing business and technical priorities, and assigning user stories

Four key values: communication, feedback, simplicity, and courage

Designed to allow small development teams to deliver quickly, change quickly, and change often

2-68

XP Strengths

The project is more manageable Progress is made, even when requirements are not stable Everything is visible to everyone Team communication improves The team shares successes along the way and at the end Customers see on-time delivery of increments Customers obtain frequent feedback on how the product

actually works Weaknesses

Doesn’t work well with large teams/projects Requires very experienced team members

2-69

Integration Project to Product Life Cycles

The project life cycle applies to all projects, regardless of the products being produced

Product life cycle models vary considerably based on the nature of the product

Most large IT products are developed as a series of projects (Program)

Project management is conducted during all of the product life cycle phases

2-70

Integration Project to Product Life Cycles

2-71

Integration Project to Product

Life Cycles – Multiple

Phases/Projects

2-72

Chapter Review

Project managers must understand and utilize the systems approach-view projects in the context of the entire environment, both inside and outside the organization-to get projects designedand planned optimally.

2-73

Chapter Review

The systems approach consists of three interrelated components: a. Systems theory involves a philosophy of or a way

of looking at the world-a language or set of principles and interventions for thinking and solving problems.The following related terms are defined in this chapter: subsystem, element, attribute, boundary, environment, objectives, constraints, and integration.

2-74

Chapter Review

b. Systems analysis is a problem-solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose.

2-75

Chapter Review

c. Systems management is responsible for the management of the whole system: objectives, the environment (both internal and external), constraints, resources (both human and other), and the culture and social environment of the organization

2-76

Chapter Review

The PMLC is a prescribed order of phases smaller segments of the entire project. Each contains a specific deliverable, and they collectively deliver a result

2-77

Chapter Review

A PMLC includes the following information: a. What specific work should be done in each

phase b. A definition of each phase's deliverables,

plus the change control process for each c. What resources are needed and involved d. Criteria that need to be met to complete

each phase

2-78

Chapter Review

An SDLC is a systems approach to problem solving that organizes a standard set of processes or activities into phases and tasks for the purpose of building an information systems product.

2-79

Chapter Review

Many variations of the SDLC have been used to develop information systems, and each has strengths and weaknesses. This chapter covers the following methodologies:

2-80

Chapter Review

Waterfall-This traditional approach describes a development approach that is linear and sequential, has distinct objectives for each phase, and for which the output of one phase is the input for the next

2-81

Chapter Review

Evolutionary prototyping-This model focuses on gathering correct and consistent requirements and involves building a system incrementally through a series of gradual refinements or prototypes

2-82

Chapter Review

Spiral-This model involves a series of short waterfall cycles, each producing an early prototype that represents a part of the entire product.

2-83

Chapter Review

Iterative and incremental-In this model, multiple development cycles, called iterations, take place. Each iteration passes through the standard life cycle phases, similarly to the waterfall approach. A small working version of software is produced during the first iteration, so the team has working software early in the process. Subsequent iterations build on the initial software produced during the first iteration.

2-84

Chapter Review

Scrum-This model is based on the concept that software development is not a defined process but an empirical process with complex input/output transformations that mayor may not be repeated under different circumstances

2-85

Chapter Review

Rational Unified Process-The RUP model is an iterative process that identifies four phases of any software development project: inception, elaboration, construction, and transition. Each phase contains one or more iterations where an executable is produced but that is perhaps an incomplete system

2-86

Chapter Review

Extreme Programming-The XP model includes short development cycles, frequent updates, division of business and technical priorities, and assignment of user stories. XP has four key values:communication, feedback, simplicity,and courage.

2-87

Chapter Review

Product life cycles are integrated with but defined separately from project life cycles because of the differences in deliverables and resources involved.

2-88

Glossary

life cycle :A prescribed order of phases (smaller segments of an entire project) in which the phases contain specific deliverables that collectively deliver a result.

Program: A group of related projects, managed in a coordinated way to obtain benefits and control not available when managing them individually.

2-89

Glossary

stage gate: A decision-making opportunity between phases or iterations in the project life cycle to determine whether the project should proceed as is, proceed with changes, or be terminated.

2-90

Glossary

System: A set of interacting, interrelated, or interdependent

elements that work as part of a whole. systems approach: A process of examining a

problem or an issue by first understanding its environment and then reducing the problem or issue into smaller components and finally managing the resolution of the problem or issue.

2-91

Glossary

systems development life cycle (SOLC): An approach to building IT systems that consists of a standard set of phases, each of which produces a prescribed set of deliverables.

2-92

Research Topics You work for a large pharmaceutical company that has offices

spread out all over the globe. Your boss comes to your office, excited about a new methodology he just read about called Extreme Programming, and he wants you to use it on the new HR application that your group is getting ready to work on. The HR software will track employee information such as job performance, salary, vacation, and so on for all 12,000 employees in all countries, and it will tie into the corporate payroll system. The project team contains members from the United States, the United Kingdom, Singapore, Japan, and India. Write a memo to your boss, explaining why the use of Extreme Programming might not be such a good idea for this project.

2-93

Research Topics Lori is the newly appointed project manager for the

Fultz Metal Works Company, a small $30 million tool-and-die manufacturer. To remain competitive, the company is launching a series of projects to upgrade all of its computer-aided machinery. The project will be costly and risky for Fultz Metal. Unfortunately, no one in the company is familiar with the new hardware and software. The company wants all work done in house because they don't trust outsiders. If you were offering advice to Lori on the selection of a methodology, what would you say and why?

2-94

Research Topics

Based on the following criteria, construct a decision tree to determine the best product development methodology: risk, size both in dollars and effort, company culture, location of team participants, amount of planning and control needed,and rate of environment change.

2-95

Research Topics

Give some examples of projects you have worked on where you feel the wrong methodology was used and where you feel the right methodology was used. Explain the ramifications of these methodology choices.

Which one(s) of the methodologies described in this chapter do you feel would be the most difficultto manage? Explain. Which do you think is the most successful? Why?

2-96

Research Topics

Write a memo to a nontechnical manager, explaining why a team decided to use an iterative and incremental development methodology on its project.

2-97

Research Topics

As a student, you generally take more than one course during a given semester. Each course requires different amounts of your time, at varying schedules. Many students spend more time on the courses within their major than on others because generally they are more interested in the subject. But students need to be able to balance their time and demonstrate a solid overall GPA. How might the systems approach aid students in budgeting their time and efforts?

2-98

Research Topics

Explain the difference between systems thinking and analytical thinking. Also, explain why both are important to a project manager.

For an IT project dealing with upgrading all company computers to the latest version of the Windows operating system, list and explain the forces in the environment that may cause problems.