CH 2

1. CH 2 Systems View Methodology

2. Objectives You will understand the topics when you can

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

4. Systems Approach to Project Management In the early stages of most information technology (IT) education programs, students aretaught to examine any proposed issue or opportunity by breaking it down into smallerand smaller parts in order to completely understand the total process and then offer a proposedsolution

5. Systems Approach to Project Management The systems approach is a process that allows projects to be viewed in the context ofthe entire environment, including both inside and outside the organization. It is the oppositeof 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

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 externalenvironment.

7. Systems Approach to Project Management An open system is not self-defining; to understandit, you must also understand its environment.

8. Projects Cannot Be Run In Isolation! • Projects must operate in a broad organizational environment • Project managers need to take a holistic or systemsview of a project and understand how it is situated within the larger organization

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…

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?

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

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

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

14. Definition of ‘System’ • An organized or complex whole; an assemblage of things or parts interacting in a coordinated way • Characteristics • The whole is greater than the sum of its parts (body) • They are dynamic and exhibit some kind of behavior • Scope is in the eye of the beholder (or stakeholder)

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

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 )

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!

18. Systems Boundary and Environment

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

20. Systems Terminology • Integration – for a system to reach its objectives, all the subsystems and elements must work together effectively • Open and Closed Systems • Closed – self contained, focus on internal workings (machine). Ignore the environment’s influence • Open – just the opposite, they interact with the environment and adapt. (humans, organizations)

21. Project Management Impact • Organizations are Open Systems • They must interact with the environment to survive • 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 • Role 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

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 approach • Systems management: Address business, technological, and organizational issues before making changes to systems

23. The Project Management “Systems” Approach: • First take on a systems philosophy, understand the environment • Then conduct your systems analysis and finally • 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)

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

25. Good Project Managers Must Getting answers to the following questions as soon as possiblewill 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, andcost perspectives?

26. PROJECT MANAGEMENT LIFE CYCLE(PMLC) Project managers and their project teams divide projects into phases to facilitate better controland communication. When you put these phases together into a prescribed order, you havethe project's life cycle.

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 result • What work will (should) be done in each phase. • A definition of each phase’s deliverables and when. • The change control process for each deliverable • What resources are involved in each deliverable • Criteria that needs to be met complete each phase

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

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

30. PMLC

31. PMLC Notice in Figure above that there are two close phases. The close iteration phase addressesthe 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

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

33. SDLC The systems development life eycle (SDLC) is a systems approach to problemsolving that organizes these processes into phases and tasks for the purpose of building aninformation system product, starting with the initial planning processes and carryingthrough to implementation and support.

34. SDLC Many SDLC methodologies have been developed over the years to guide the developmenteffort. One of the first and most common is the waterfall model, which was inheritedfrom the engineering community.

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/Methodologies • Waterfall (predictive) • Spiral (somewhat predictive) • Iterative/Incremental (adaptive) • Agile (Scrum, RUP, Extreme Programming)

36. Waterfall Model The waterfall model is considered the traditional approach to systems development. It describesa development approach that is linear and sequential, has distinct objectives foreach 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, butthere may be a good/bad distinction.

37. Waterfall Model The waterfall approach is typically used because itprovides management the most visibility, is easier to manage, and it is best understoodwithin the industry. It lends itself to large, complex applications due to its reliance on documentationand end-oF-phase deliverables

38. Waterfall Model

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

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

41. Evolutionary Prototype • Strengths • Visibility – customers see steady progress • Useful 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

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

43. Spiral Model The spiral model emphasizes the need to go backand reiterate earlier stages a number of times as the project progresses. It's actually a seriesof short waterfall cycles, each producing an early prototype that represents a part of theentire project.

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

45. Spiral Model

46. Spiral Model • Strengths • Good for large complex projects • Accommodates change well • Can react to risks very quickly • Software produced early in the life of the project • Increased user visibility • Weaknesses • Can be a costly model to use • Risk analysis requires highly specific expertise • Project’s success highly dependent on risk analysis • Doesn’t work well for small projects

47. Iterative and Incremental Model The iterative and incremental model is an intuitive approach to the waterfall model and issimilar 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, moreeasily 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

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 initialsoftware produced during the first iteration.

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

50. Iterative and Incremental Model