sw project management nature of it projects

INFO 420 Chapter 1 1

SW Project ManagementNature of IT Projects

INFO 420Dr. Jennifer Booker

Chapter 1 2INFO 420

Intro

IT projects are organizational investmentsNeed to expect commitment of considerable

time, money, and peopleSome aspects of traditional project

management need to be tweaked for IT projects; take from software engineering and system analysis & design

Chapter 1 3INFO 420

Intro

Focus: reducing costs, reducing cycle timeConnect 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 4INFO 420

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 5INFO 420

Micro era - 1980’s to mid-90’s

Introduction of the PC, and soon client-server computingNetwork is contained within the organization

Lost central control over MIS – IT is everywhere, changing oftenSecurity, data integrity, support issuesFast, cross-area IT projects

Chapter 1 6INFO 420

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 servicesNeeds new organization and strategy

Chapter 1 7INFO 420

Globalization

The omnipresence of computers and the Internet is bringing about a globalization previously unimaginableWork 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 8INFO 420

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 9INFO 420

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 10INFO 420

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


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


Why do we fail?

Communication is a key as wellThe #1 reason for project failure, and a factor

in many other causes Resource issues also include staffing,

training, tools, and facility issues


How help success?

Four approaches are themes throughoutA value-driven approachA socio-technical approachA project-management approachA knowledge-management 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


A socio-technical approach

Tools, techniques, and methodologies are not enoughNeed to consider the impact of the project on

its users, and other affected organizationsDoes anyone want the new system?Will they use it?


A project-management approach

Need to follow some methodology during the IT projectDon’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


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?


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


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


Project attributes

Roles – project manager, subject matter experts (SME), technical experts, etc.

Risks and assumptionsRisks can be internal or external

Interdependent tasks in the project Organizational change may result Operating in a larger environment

Extreme Project Management

Extreme Project Management (XPM) tries to stay adaptable and flexible enough to handle high speed, high change, high uncertainty, high stress projectsRequirements changes are inevitablePlanning is iterative and self-correcting Innovation in processes or tools are expected



PMBOK

The Guide to the Project Management Body of Knowledge captures the major topics within project managementFirst defined in 1987Current version is ISBN 1935589679 (2013)

It has nine “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



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



Project quality managementCreate a quality environment to help project

meet stakeholder needs and expectations Project communications management

Ensure project communicates with stakeholders



Project risk management Identify and respond to risks facing the project

Project procurement managementManage procurement of products and

services from outside the organization


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 itThere are many versions of SDLC to choose

from


Generic SDLC Phases

Planning Analysis Design Implementation Maintenance & support


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 definedShould include budget, schedule, technology,

development processes, methods, and tools


Analysis

Documents the existing system or processes (the ‘as is’ model)

Leads to requirements analysisMight use Joint Application Development

(JAD), surveys, brainstorming, interviews, etc. to determine requirements

Define how the new system will work (the ‘to be’ model)


Design

Define the high level design of the system (architecture) based on the requirements

Refine the design to produce the low level designDesigns include software, hardware, network,

databases, user interface concept, etc.


Implementation

Construct, test, and install the systemEasy to say, huh?

Also develop the documentation, training materials, and supporting information


Maintenance & support

Maintenance of a system is often a separate ongoing project

After installation, the system is in production mode for most of its lifeStill need to make improvements

(enhancements), and fix bugs (maintenance)May manage a call center or help desk


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


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


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 documentedWaterfall depends on very clearly defined

requirements and well known methodology and tools – rarely the case for new development, but may be true for maintenance


Waterfall SDLC

Still useful for maintenance or small projects

Also good for inexperienced development teams

Can be good for shrink wrapped software development


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


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


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


Spiral

The spiral model (Boehm, 1988) is used to address big risks facing a projectEach 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


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


Agile

Agile methods include various methodologies, such as SCRUMDSDM (Dynamic Systems Development

Method)ASD (Adaptive Software Development)XP (eXtreme Programming)


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/


Summary

We’ve introduced the major topics in IT project managementHistory of IT project managementReasons for project failure and successOur approach for encouraging successDefine a projectPM body of knowledgeSystem development life cycles