sw project management nature of it projects n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SW Project Management Nature of IT Projects PowerPoint Presentation
Download Presentation
SW Project Management Nature of IT Projects

Loading in 2 Seconds...

play fullscreen
1 / 45

SW Project Management Nature of IT Projects - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

SW Project Management Nature of IT Projects. INFO 420 Glenn Booker. Intro. IT projects are organizational investments Need to expect commitment of considerable time, money, and people

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SW Project Management Nature of IT Projects' - malory


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sw project management nature of it projects

SW Project ManagementNature of IT Projects

INFO 420

Glenn Booker

Chapter 1

intro
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

Chapter 1

intro1
Intro
  • Focus: reducing costs, reducing cycle time
    • Connect organization’s 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

Chapter 1

edp era 1960 s to early 1980 s
EDP era - 1960’s to early 1980’s
  • 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

Chapter 1

micro era 1980 s to mid 90 s
Micro era - 1980’s to mid-90’s
  • 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

Chapter 1

network era mid 1990s to now
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

Chapter 1

globalization
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

Chapter 1

the key decision
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?

Chapter 1

it project management
IT project management
  • So far, we’re 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

Chapter 1

it project management1
IT project management
  • More recent studies have shown some improvement
    • In 2008, 32% were successful, 24% failed, and 44% were weak
  • Factors for successful projects included (2010 CHAOS Manifesto)
    • User involvement, executive support, clear business objectives, and emotional maturity

Chapter 1

why do we fail
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, lack of user involvement, changing requirements and specs, lack of exec support, lack of resources, and unrealistic expectations

Chapter 1

why do we fail1
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

Chapter 1

how help success
How help success?
  • Four approaches are themes throughout
    • A value-driven approach
    • A socio-technical approach
    • A project-management approach
    • A knowledge-management approach

Chapter 1

a value driven approach
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

Chapter 1

a socio technical approach
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?

Chapter 1

a project management approach
A project-management approach
  • Need to follow some methodology during the IT project
    • Don’t 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

Chapter 1

a knowledge management approach
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?

Chapter 1

project management context
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, 2008)
  • A project is a temporary effort to accomplish a product, service, or result

Chapter 1

project attributes
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

Chapter 1

project attributes1
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

Chapter 1

extreme project management
Extreme Project Management
  • Extreme Project Management (XPM) tries to stay adaptable and flexible enough to handle high speed, high change, high uncertainty, high stress projects
    • Requirements changes are inevitable
    • Planning is iterative and self-correcting
    • Innovation in processes or tools are expected

Chapter 1

pmbok
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 1935589679 (2013)
  • It has nine “knowledge areas”

Chapter 1

pmbok knowledge areas
PMBOK knowledge areas
  • Project integration management
    • Coordinating changes to the project plan’s development and execution
  • Project scope management
    • Ensuring complete definition and completion of the project scope

Chapter 1

pmbok knowledge areas1
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

Chapter 1

pmbok knowledge areas2
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

Chapter 1

pmbok knowledge areas3
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

Chapter 1

system development life cycle
System Development Life Cycle
  • The development of a system has its own life cycle, which takes place inside the project
  • The System Development Life Cycle (SDLC) defines the phases needed to create a system, then maintain it
    • There are many versions of SDLC to choose from

Chapter 1

generic sdlc phases
Generic SDLC Phases
  • Planning
  • Analysis
  • Design
  • Implementation
  • Maintenance & support

Chapter 1

planning
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

Chapter 1

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

Chapter 1

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

Chapter 1

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

Chapter 1

maintenance support
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

Chapter 1

retirement
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 it’s completely offline

Chapter 1

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

Chapter 1

waterfall sdlc
Waterfall SDLC
  • Some versions of the waterfall model (DOD-STD-2167a (1988), MIL-STD-498 (1994)) 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 for new development, but may be true for maintenance

Chapter 1

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

Chapter 1

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

Iterative system development

Chapter 1

slide39
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 it’s completed

Chapter 1

prototyping
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

Chapter 1

spiral
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

Chapter 1

agile
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/agileSoftwareDevelopment.htm

Chapter 1

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

Chapter 1

slide44
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/

Chapter 1

summary
Summary
  • We’ve 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
    • PM body of knowledge
    • System development life cycles

Chapter 1