SW Project Management Nature of IT Projects

1
SW Project ManagementNature of IT Projects

• INFO 420
• Glenn Booker

2
Intro

• IT projects are organizational investments
• Need to expect commitment of considerable time,
  money, and people
• Some aspects of traditional project management
  need to be tweaked for IT projects take from
  software engineering and system analysis
  design

3
Intro

• Focus reducing costs, reducing cycle time
• Connect organizations strategy to its
  deployment, help improve competitiveness
• PM and IS evolve in parallel timelines
• Three generations of PM strategy
• The EDP era, micro era, and network era

4
EDP era - 1960s to early 1980s

• Central mainframe or minicomputer
• Automate separate tasks, e.g. inventory mgmt,
  accounting, production scheduling
• Data processing manager
• Similar to early steam power use same process,
  with more power behind it

5
Micro era - 1980s to mid-90s

• Introduction of the PC, and soon client-server
  computing
• Network is contained within the organization
• Lost central control over MIS IT is everywhere,
  changing often
• Security, data integrity, support issues
• Fast, cross-area IT projects

6
Network era - mid-1990s to now

• Due to awareness of the Internet
• More strategic partners, alliances, vendors
• Network focus is outside the organization
• Need scalable network architecture
• Digital convergence of data, AV, graphics
• Creates new products and services
• Needs new organization and strategy

7
Globalization

• The omnipresence of computers and the Internet is
  bringing about a globalization previously
  unimaginable
• Work with anyone, any place, any time
• Increases both risks and rewards
• IT has some budget in both good times and bad,
  the question is how to use it best

8
The key decision

• So it boils down to Which IT projects are
  worth supporting?
• Which will provide the most benefit and value to
  the organization?

9
IT project management

• So far, were not doing well at managing IT
  projects
• In 1968 the software development crisis was
  identified
• In 1994, CHAOS study said 16 of IT projects were
  successful, 31 cancelled before completion, and
  53 completed badly

10
IT project management

• More recent studies have shown improvement trend
• In 2006, 35 successful, 19 failed, and 46 weak
• Factors for successful projects, as identified in
  both 2001 and 2006, included
• User involvement, clear business objectives, and
  formal methodology

11
Why do we fail?

• Partly a definition problem how far from the
  plan is a failure? 5? 10? 20?
• Traits of failed or weak projects include
• Incomplete requirements, changing requirements
  and specs, lack of exec support, technology
  illiteracy/incompetence, lack of resources, and
  unrealistic expectations

12
Why do we fail?

• Communication is a key as well
• The 1 reason for project failure, and a factor
  in many other causes
• Resource issues also include staffing, training,
  tools, and facility issues

13
How help success?

• Four approaches are themes throughout
• A value-driven approach
• A socio-technical approach
• A project-management approach
• A knowledge-management approach

14
A value-driven approach

• Make IT projects prove they provide value to the
  organization
• The value the project delivers must more than
  offset its time, money, and opportunity costs

15
A socio-technical approach

• Tools, techniques, and methodologies are not
  enough
• Need to consider the impact of the project on its
  users, and other affected organizations
• Does anyone want the new system?
• Will they use it?

16
A project-management approach

• Need to follow some methodology during the IT
  project
• Dont just wing it!
• What are the processes and infrastructure?
• What tools and controls are used?
• Plan appropriate resources, manage expectations
  (communicate!), consider outsourcing efficiency
  effectiveness goals

17
A knowledge-management approach

• Have a systematic process for capturing and
  sharing knowledge from past projects
• Record lessons learned and best practices
• How can we do it better next time?

18
Project management context

• Our approach for project management is based on
  the Project Management Institute (PMI)s Guide to
  the Project Management Body of Knowledge (PMBOK,
  2004)
• A project is a temporary effort to accomplish a
  product, service, or result

19
Project attributes

• Time frame
• Purpose or goal PM should meet or exceed
  stakeholders needs and expectations
• Ownership (mainly by sponsor)
• Resources the triple constraints of scope,
  schedule, and budget

20
Project attributes

• Roles project manager, subject matter experts
  (SME), technical experts, etc.
• Risks and assumptions
• Risks can be internal or external
• Interdependent tasks in the project
• Organizational change may result
• Operating in a larger environment

21
Project life cycle

• The project life cycle (PLC) defines the life of
  a project in phases
• Any project should have one or more deliverables
  as its output(s)
• Phases help control the project
• Provide gates to decide whether to proceed
• Fast tracking can be done start next phase early

22
PLC Phases

• Define project goal
• Plan project
• Execute project plan
• Close project
• Evaluate project

23
Define project goal

• Have at least one!!!
• How will this project provide value to its
  organization?
• And make sure stakeholders agree
• Define not only the deliverables, but also the
  way project success will be measured

24
Plan project

• Effort (staffing levels) starts low, then rises
  until mid-project, then drops off
• Risks are often highest initially
• Stakeholder input is highest initially
• Cost of correcting scope errors gets higher as
  the project progresses

25
Plan project

• Define the projects plan
• What will happen?
• Why?
• How?
• Who?
• How long will it take?
• How much will it cost?

• What are the risks, and how will we manage them?
• How did we estimate the duration and budget?
• How are decisions reached?
• Were we successful?

26
Plan project

• Plan must define, for each project phase
• Deliverables
• Tasks
• Resources
• Time
• This defines the baseline project plan

27
Execute project plan

• Now actually conduct the project!
• Manage project budget, scope, and duration based
  on stakeholder needs
• Track progress against the baseline plan
• Keep an eye on the overall goal
• At the end, deliver the deliverables

28
Close project

• End the project clearly
• Make sure all obligations have been met
• Document the processes used, final actual budget
  and schedule data
• Give final report, presentation, etc.
• Have sponsor sign off the project

29
Evaluate project

• The value of IT projects may be hard to measure
  most dont directly earn
• Document the lessons learned carefully
• What went well? Dont forget that part!
• Define best practices, when possible
• Evaluate the team as well as the project

30
System Development Life Cycle

• In contrast, the actual development of a system
  has its own life cycle, which takes place inside
  the project
• The SDLC defines the phases needed to create a
  system, then maintain it
• There are many versions of SDLC to choose from

31
Generic SDLC Phases

• Planning
• Analysis
• Design
• Implementation
• Maintenance support

32
Planning

• Defines the problem to be solved, or opportunity
  to be taken, and outlines the goal and scope of
  the system
• The plan for developing the system is defined
• Should include budget, schedule, technology,
  development processes, methods, and tools

33
Analysis

• Documents the existing system or processes (the
  as is model)
• Leads to requirements analysis
• Might use JAD, surveys, brainstorming,
  interviews, etc. to determine requirements
• Define how the new system will work (the to be
  model)

34
Design

• Define the high level design of the system
  (architecture) based on the requirements
• Refine the design to produce the low level
  design
• Designs include software, hardware, network,
  databases, user interface concept, etc.

35
Implementation

• Construct, test, and install the system
• Easy to say, huh?
• Also develop the documentation, training
  materials, and supporting information

36
Maintenance support

• Maintenance of a system is often a separate
  ongoing project
• After installation, the system is in production
  mode for most of its life
• Still need to make improvements (enhancements),
  and fix bugs (maintenance)
• May manage a call center or help desk

37
Retirement

• Eventually, a production system becomes obsolete,
  leading to a new project to replace it
• As part of that project, phasing out the old
  system will be done, until its completely offline

38
SDLC Examples

• Implementing the SDLC can follow several types of
  approaches
• The oldest is the structured approach, better
  known as the waterfall life cycle
• Its simple and sequential do each phase
  completely before moving to the next one
• Requirements, design, code, test, deploy

39
Waterfall SDLC

• Some versions of the waterfall model
  (DOD-STD-2167a, MIL-STD-498) defined very
  precisely how the results of each phase were
  documented
• Waterfall depends on very clearly defined
  requirements and well known methodology and tools
  rarely the case

40
Waterfall SDLC

• Still useful for maintenance or small projects
• Also good for inexperienced development teams
• Can be good for shrink wrapped software
  development

41
Iterative system development

• Need for faster development, and accommodation of
  changing requirements led to a variety of
  iterative SDLC models

• Iterative approaches include
• RAD
• Prototyping
• Spiral
• Agile
• RUP

42
RAD

• Rapid Application Development (RAD) compresses
  the life cycle using special software development
  tools (CASE tools)
• Each iteration produces more and more of the
  final product in usable form, until its completed

43
Prototyping

• Generally, prototyping is used to refine or
  discover system requirements
• Prototyping depends on close work between the
  developer and the customer to create a partially
  functional system
• Then full system development takes place

44
Spiral

• The spiral model (Boehm, 1988) is used to
  address big risks facing a project
• Each spiral miniproject is a short life cycle
  devoted to resolving one key risk area
• After all the major risks have been resolved,
  then another life cycle is used for full system
  development

45
Agile

• Agile software development is defined loosely as
  
• An iterative and incremental (evolutionary)
  approach to software development which is
  performed in a highly collaborative manner by
  self-organizing teams within an effective
  governance framework with "just enough" ceremony
  that produces high quality software in a cost
  effective and timely manner which meets the
  changing needs of its stakeholders.

From http//www.agilemodeling.com/essays/agileSoft
wareDevelopment.htm
46
Agile

• Agile methods include various methodologies, such
  as
• SCRUM
• DSDM (Dynamic Systems Development Method)
• ASD (Adaptive Software Development)
• XP (eXtreme Programming)

47
Extreme Project Management

• Extreme Project Management (XPM) is a project
  management approach to go with eXtreme
  Programming (XP)
• It is designed for projects with very high rates
  of requirements and environment change
• Change is inevitable, so planning is iterative
• Has been adapted for architectural projects

48
RUP

• The Rational Unified Process (RUP), now owned by
  IBM, is an object oriented, iterative life cycle
  methodology
• RUP promotes iterative development and organizes
  the development of software and systems into four
  phases, each consisting of one or more executable
  iterations of the software at that stage of
  development.

From http//www-01.ibm.com/software/awdtools/rup/
49
PLC vs. SDLC???

• So how does the project life cycle relate to the
  software development life cycle?
• The SDLC is conducted entirely within the PLC
  phase of Execute project plan
• The structure and details of the project plan
  depend on your choice of SDLC

50
PMBOK

• The Guide to the Project Management Body of
  Knowledge captures the major topics within
  project management
• First defined in 1987
• Current version is ISBN 1933890517 (2008)
• It has nine knowledge areas

51
PMBOK knowledge areas

• Project integration management
• Coordinating changes to the project plans
  development and execution
• Project scope management
• Ensuring complete definition and completion of
  the project scope

52
PMBOK knowledge areas

• Project time management
• Developing, monitoring, and managing the project
  schedule
• Project cost management
• Develop and complete project per its budget
• Project human resource management
• Create, develop and manage the project team

53
PMBOK knowledge areas

• Project quality management
• Create a quality environment to help project meet
  stakeholder needs and expectations
• Project communications management
• Ensure project communicates with stakeholders

54
PMBOK knowledge areas

• Project risk management
• Identify and respond to risks facing the project
• Project procurement management
• Manage procurement of products and services from
  outside the organization

55
Summary

• Weve introduced the major topics in IT project
  management
• History of IT project management
• Reasons for project failure and success
• Our approach for encouraging success
• Define a project
• Project and system development life cycles
• PM body of knowledge