Methodology for Information Systems Project Management

1
Methodology for Information Systems Project
Management

• Chapter 4 James R. Burns

2
Some PM humor

• A badly planned project will take three times
  longer than expected a well planned project
  only twice as long as expected.
• The more you plan the luckier you get.
• At the heart of every large project are many
  small projects trying to get out.
• The nice thing about not planning is that failure
  comes as a complete surprise rather than being
  preceded by a period of worry and depression.
•  

3

• The Real Software Development Process
• Out of jest and with tongue firmly in cheek,
  someone suggested the following software
  development process
• 1. Order the T-shirts for the development team
• 2. Announce availability of the product (This
  helps to motivate the team.)
• 3. Write the code (Lets get with it!)
• 4. Write the manual
• 5. Hire the project manager
• 6. Spec the software (Writing the specs after
  the code helps to ensure that the software meets
  the specifications.)
• 7. Ship
• 8. Test (The customers are a big help with this
  step.)
• 9. Identify bugs as potential enhancements
• 10. Announce the upgrade program

4
Summary of Todays lecture

• What do we mean by methodology?
• What are some typical IT Project Types?
• The Generic Lifecycle model

5
Introduction The Methodology Choice Becomes the
Process

• Indigenous to every project are its processes
  the methodologies by which the project is brought
  to fruition
• METHODOLOGY becomes the PROCESS
• When implementation and execution of the
  methodology begins
• In this chapter we discuss the major phases of
  each project type
• We do not give you the entire WBS--just the top
  level

6
What are some IT Project Types??

• Enterprise Resource Planning
• Enterprise Architecture Determination
• Re-engineering projects
• Rapid application development projects
• Product selection

• Component configuration projects
• Conversion projects
• Maintenance projects
• Component integration projects
• Internet Development projects
• Client/server changeover projects

7
A Generic Project Management Process

• Conceptualization and Definition
• Planning and Budgeting
• Execution
• Termination and Closure
• Monitoring and Control

8
STAGE 1 Conceptualizing-and-Defining
STAGE 2 Planning-and-Budgeting
STAGE 3 Executing
STAGE 5 Terminating-and-Closing
STAGE 4 Monitoring-and-Controlling
9
These are stages of the meta project

• Three of these stages must be funded from sunk
  costs.
• In some cases seed money can be obtained to
  enable thorough completion of stages one and two
• Its only at stage three that projects formally
  ramp up and begin spending money from an
  authorized source

10
Alternative names for Stages

• Inception
• Lifecycle Objective Milestone
• Elaboration
• Lifecycle Architecture Milestone
• Construction
• Initial Operational Capability Milestone
• Transition
• Product Release Milestone

11
Definition (Concept)

• Obtain user requirements
• Worth doing?
• Ensure fit
• Assess consistency
• Identify dependencies
• Assess risk
• Determine owners/stakeholders

• Test alignment with strategies
• Test resource availability
• Define scope
• Make go/no go decision
• Obtain funding
• Review alternatives

12
Planning Budgeting (Development)

• Project team is determined
• Resources are negotiated
• Team is formed, stormed, normed and ready to
  perform
• Formal Project plans are determined
• Formal Budgets are prepared

13
Execution (Implementation)

• Where the project ramps up
• And begins to fulfill its phases
• Likened to execution in a sports activity
• Produces the project product
• Change management becomes especially important
  here

14
Closure and Termination (Close-out)

• Document lessons learned
• History database
• Postmortem meeting
• Signature signoffs
• Get paid

15
Software Development Process Models--Boehm

• WERE TALKING ABOUT THE EXECUTION CONTROL STAGE
  HERE
• Code-and-fix model
• Waterfall model
• Evolutionary model
• Transform model
• Spiral model

16
Code-and-fix model

• Write some code
• Then think about requirements, design, test and
  maintenance later
• After a number of fixes, code was poorly
  structured
• Used well before structured programming was
  invented

17
Waterfall model

• Definition
• If DEFINITION takes 2 months, then the project is
  roughly ___ long
• Analysis
• Design
• Construction
• Test
• Operation
• Maintenance

18
The Waterfall Staircase
Definition of Requirements
Analysis
Design
Construction
System Integration Testing
Acceptance Testing
Implementation
Operation
19
Waterfall model

• Required in all government software contracting
• Document-driven
• Good for developing something new and complex--a
  new AI inference engine, a new compiler, a new
  database engine
• PROBLEMS Expensive and time consuming because
  of its dependence on fully elaborated documents,
  curtails testing until near the end

20
The Standard Waterfall Model

• Better than old CODE AND FIX approach
• A manufacturing model for software
• CASE tools were developed to support it TIs
  IEFsold in 1994 to Sterling Software
• Basis for most software acquisition standards in
  government

21
The Standard Waterfall Model, Contd

• Too expensive for small projects
• Still used for project estimation (cost and
  duration) of large projects
• Doesnt get used in practice very often
• Doesnt seem to work satisfactorily

22
Evolutionary Process Model

• Better than WATERFALL for interactive end-user
  software development
• Ideally matched to fourth-generation language
  applications
• Also works well when users say I cant tell you
  what I want, but Ill know it when I see it.
• Gives users a rapid initial operational prototype
  that they can play with and react to, even
  improve upon

23
The Evolutionary Process Model

• NOT MUCH MORE THAN OLD CODE AND FIX APPROACH
• Assumes users operational system will be
  flexible enough to accommodate unplanned
  evolution paths.
• The above assumption is bad, because frequently,
  several independently evolved applications must
  now be integrated
• Temporary work-arounds for software deficiencies
  increasingly solidify into unchangeable
  constraints on evolution

24
Transform model

• Endeavors to address the difficulties associated
  with the code-and-fix, waterfall, and
  evolutionary models.
• Assumes the existence of a software module that
  can parse, interpret and compile written
  specifications automatically into machine code
• There is no 3GL code (COBOL, Fortran) or 4GL code
  (visual languages)
• The specifications are transformed directly to
  machine code

25
The Transform Model

• Steps are
• Formal specification of the desired product
• Automatic transformation of the specification
  into code
• An iterative loop is necessary to improve the
  performance
• Exercise of the resulting product, and
• An outer iterative loop to adjust the
  specification based on the resulting operational
  experience

26
The Transform Model, Contd

• Avoids the difficulty of having to modify code
  that has become poorly structured through
  repeated re-optimization, since the modifications
  are made to the specification
• Avoids the extra time and expense involved in
  intermediate design, code and test activities

27
A Pervasive Problem

• How to enable users to create their own apps
• After all, there just arent enough developers
  around
• Ten years ago, the Air Force said it needed 1 out
  of every 5 HS graduates just to maintain its
  codes
• SOLUTION Let users write their own
  specifications and then transform those same
  specifications directly to code

28
Did it work?

• No! Specifications must be carefully written in
  a compiler-compatible format--the specifications
  become the program. Users have to learn a
  specification language--same as learning a 3GL.
• Like the evolutionary model, it did not
  accommodate unplanned evolutionary paths well.
• Wont work for Large-Scale Development

29
The Spiral Model (Boehm, 1988)

• Overcomes most of these shortcomings and
  addresses these questions
• What shall we do next?
• How long shall we continue doing it?
• Radial dimension represents the cumulative cost
  incurred in accomplishing the steps to date
• Angular dimension represents the progress made in
  completing each cycle of the spiral.

30
Spiral model

• Can accommodate most previous development
  methodologies as special cases
• Is a risk-driven methodology, not a
  document-driven one
• Endeavors to depict both the passage of time and
  the accumulation of expenditure

31
Spiral model, Continued

• Radial dimension represents the cumulative cost
  incurred in accomplishing the steps to date
• Angular dimension represents the progress made in
  completing each cycle of the spiral.
• The methodology is dynamic and dependent upon the
  relative risks remaining

32
Each Loop of the Spiral model

• Identifies the objectives of the product being
  elaborated
• Identifies the alternatives to implementation
• Determines the constraints imposed on the
  alternatives
• Evaluates the alternatives relative to the
  objectives and the constraints
• Dynamically chooses methodological detail needed
  to alleviate perceived sources of risk

33
How is risk mitigated?

• If there is risk associated with the
  specification of the product, then reference
  checking, administering user questionnaires,
  analytic modeling, or combinations of these
  should be used to mitigate the risk

• If there is risk associated with the ultimate
  design of the product, then prototyping,
  simulation, or benchmarking should be utilized to
  mitigate this risk.

34
How is risk mitigated?

• If user-interface risks strongly dominate product
  considerations, or there are internal interface
  control risks, then the next step may be to use
  evolutionary development

35
Figure 2-3. Spiral Model of Software Dev.
36
Advantages of Spiral Model

• Applies to maintenance as well as to development
• Incorporates prototyping as a risk-reduction
  option at any stage
• Accommodates reworks or go-backs to earlier
  stages
• Focuses early attention on reuse of existing
  software

37
More Advantages of the Spiral Model

• Accommodates preparation for life-cycle
  evolution, growth
• Provides a mechanism for incorporating software
  quality objectives
• Focuses on eliminating errors and unattractive
  alternatives early
• More adaptable to projects other than development
  than the waterfall model, which applies only to
  development

38
More Advantages of the Spiral Model

• Provides a viable framework for integrating
  hardware-software system development
• Accommodates CASE and other transform tools

39
Disadvantages of the Spiral Model

• Doesnt work with fixed-price contracts well
• Use by outside contractors and system integrators
  is difficult, therefore
• Competitive front-end contracts and
  level-of-effort and award-fee contracts work
  better
• Relies on project professionals with
  risk-assessment expertise
• If there arent any, it doesnt work well

40
The Dimensions
Waterfall
High Ceremony
Low Ceremony
Iterative
41
Process Map
Waterfall
Few risks, late integration and testing
Low Ceremony
High Ceremony
Little Doc, light process discipline
Heavy Doc, heavy process discipline, CCB
Iterative
Risk Driven, Continuous integration and testing
42
Agile Software Development

• Software is developed in increments using an
  iterative approach
• Backbone first
• User interfaces next
• Important functionality next
• Less important functionality last
• Learning takes place all along the way
• Important components may be improved before less
  important components are even started
• Provides the user with an early experience with
  the software.
• Endeavors to deliver business value early.

43
More Agile Software Development

• An iteration lasts one to four weeks
• Each iteration passes through a full software
  development cycle including planning,
  requirements analysis, design, coding, testing,
  and documentation.
• The goal is to have an available release (without
  bugs) at the end of each iteration.
• At the end of each iteration, the team
  re-evaluates project priorities.
• Agile methods emphasize face-to-face
  communication over written documentation.

44
Principles Behind the Agile Manifesto

• Customer satisfaction by rapid, continuous
  delivery of useful software.
• Working software is delivered frequently (weeks
  rather than months).
• Working software is the principal measure of
  progress.
• Even late changes in requirements are welcomed.
• Close, daily cooperation between business people
  and developers is strongly encouraged.
• Face-to-face conversation is the best form of
  communication.

45
More Principles behind Agile Development

• Projects are built around motivated individuals,
  who should be trusted.
• Continuous attention to technical excellence and
  good design is required.
• Simplicity is a hallmark.
• Self organizing teams are always used.
• Regular adaptation to changing circumstances is
  accommodated.

46
Iterative, Agile Processes

• Rational Unified Process (RUP)
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Crystal
• Scrum

47
The Home Ground

• For agile software development, the home ground
  is a culture that thrives on chaos, low
  criticality, a small number of senior developers
  are used, and requirements change very often,
  applications are small.
• For plan-driven methods (such as the Waterfall
  Model), the home ground is high criticality,
  junior developers, requirements don't change too
  often, a large number of developers, and a
  culture that demands order.

48
Project Management SCRUM

• SCRUM is a type of agile software development,
  along with extreme programming (1996) , Crystal
  Clear, Adaptive Software Development, Feature
  Driven Development, and Dynamic Systems
  Development Method (DSDM) (1995).

49
More SCRUM

• Scrum is an agile development methodology,
  implying low ceremony (little documentation,
  face-to-face meetings).
• Scrum is a process skeleton that includes a set
  of practices and predefined roles.
• There are two types of roles used in connection
  with Scrum, those who are committed are called
  pigs and those
• who are involved who are called chickens.
  Stakeholders are considered chickens whereas the
• project team and Scrum master (project manager)
  are called pigs.

50
Still More SCRUM

• Scrum consists of a series of sprints. Each
  sprint is a period of 15 to 30 days, during which
  the team creates a usable module of software.
• Scrum is considered easy to learn and doesnt
  require a lot of training to start using it.
• Sprint periods of 30 days are similar to the
  monthly time-boxes used in RAD.

51
SCRUM Meetings

• Each day during the sprint, a project status
  meeting occurs. This is called a SCRUM Meeting.
• The procedure for a SCRUM Meeting is the
  following
• 1) the meeting starts precisely on time with
  team-decided punishments for tardiness
• 2) all are welcome, but only pigs may speak
• 3) the meeting is time-boxed at fifteen minutes
  regardless of the teams size
• 4) all attendees should stand
• 5) the meeting should happen at the same location
  and same time every day

52
SCRUM.In Summary

• In summary, scrum is an agile process to manage
  and control development work.
• Scrum is a team-based approach to iteratively,
  incrementally develop systems and products when
  requirements are rapidly changing.
• Scrum is a process that controls the chaos of
  conflicting interests and needs.
• Scrum is a way to improve communications and
  maximize co-operation.
• Scrum is a way to detect and cause the removal of
  anything that gets in the way of developing and
  delivering products.
• Scrum is a way to maximize productivity.
• Scrum is scalable from single projects to entire
  organizations. Scrum has controlled and organized
  development and implementation for multiple
  interrelated products and projects with over a
  thousand developers and implementers.

53
PM Humor
You can con a sucker into committing to an
impossible deadline, but you cannot con him into
meeting it. A two-year IT project will take three
years, a three-year IT project will never
finish. The sooner you get behind schedule, the
more time you have to make it up. Overtime is a
figment of the naïve project managers
imagination. A project gets a year late one day
at a time. The sooner you begin coding the later
you will finish. Some projects finish on time in
spite of project management best practices. The
bitterness of poor quality lasts long after the
sweetness of making a date is forgotten.
54
Rational Unified Process (RUP)

• An iterative, use-case driven approach to
  software development
• The RUP is a well-defined and well-structured
  software engineering process
• The RUP is also a process product (vended by
  Rational Software) that provides you with a
  customizable process framework for software
  engineering
• The RUP provides you with re-usable plug-ins and
  re-usable best practices (developed by IBM) that
  can evolve into ever better practices
• A huge library comes with RUP

55
Essential Principles of the RUP

• Attack major risks early
• Ensure that you deliver value to your customer
• Stay focused on executable software
• This is how progress is measured
• Documents, designs, and plans are good but they
  are a poor indication of true progress
• Accommodate change early in the project
• Baseline an executable architecture early on
• Build your system with components
• Better than objects that use lots of inheritance
• Facilitates reusability
• Facilitates maintenance
• Work together as one team
• Make quality a way of life, not an afterthought

56
RUP

• Early iterations will emphasize Requirements and
  Design
• Later iterations will emphasize implementation
  and testing
• Completed usable software modules are what gets
  measured
• Architectural requirements, design,
  implementation is done firstlike rapid
  prototyping
• Accommodates changing requirements
• Integration is not one major undertaking at the
  end
• Risks are found in the early integrations
• Reuse is facilitated
• Defects can be found over several iterations
• Team members and users learn along the way

57
RUPthe initiating (inception) Stagestage 1

• Understand the requirements
• Build and test the business caseusing a rapid
  prototype
• Get stakeholder buy-in to move ahead

58
RUPthe planning stagestage 2

• Understand major technical risks
• Create a base-lined architecture
• Understand what the time and cost parameters are

59
Construction stagestage 3

• Build the first formal operational version of the
  productvery little functionality
• Test the product with users/customers
• With each iteration, release versions of the
  product that possess ever-increasing
  functionality, incorporating what you have
  learned in previous releases
• Each stage consists of one or more iterations

60
RUP Transition Stage, Stage 4

• Ensure that the software meets the needs of its
  users
• At this point in the lifecycle, user feedback
  focuses mainly on fine-tuning the product,
  configuration, installation, and usability issues

61
Roles, Activities and Artifacts

• Rolea hat that a project professional may wear
  during an iteration
• Activitiesthings like use-case analysis,
  use-case design
• Artifactinformation item (doc, model, prototype,
  component, etc.)
• Within his role, a project professional completes
  activities to build artifacts
• THE END

62
Another IT Project Type System
Acquisition/Conversion/Cut-over

• Decide on requirements
• Grade commercial apps that fit
• Decide on one of them
• Install
• Conversion
• Cut-over

63
Another IT Project Type Conversion

• Slam-dunk
• Parallel
• Pilot

64
Another IT Project Type System Integration and
Test

• Component selection
• Component integration and testing

65
Another IT Project Type Process
ReengineeringMichael Hammer

• 1) determine measures of performance
• 2) install measures of performance
• 3) delineate entire existing process in all its
  gory detail
• 4) perform process value analysis and
  activity-based costing
• 5) benchmark processes by comparison with other
  processes

66
More Process Reengineering

• 6) design re-invented process
• 7) simulate re-invented process
• 8) prepare report with recommendations
• 9) upgrade the software applications that support
  the re-engineered process
• 10) install re-invented process
• 11) measure improvements

67
Another IT Project Type Enterprise Integration

• the ability to read-from and write to all of the
  apps and data sources across the enterprise
• Application integration
• Use a common SOFTWARE BUS to glue them together
• Data warehousing

68
More Enterprise Integration

• Workgroup/Workflow Apps
• Messaging systems
• Data federation
• performs integration while leaving the source
  data in place

69
Another IT Project Type System Maintenance

• Can use Spiral model here
• Software doesnt need to be greased, like
  something mechanical does, so what do we mean by
  maintenance of software?

70
Selection Methodology For Software, Processes
and Projects

• Could use MAUT, as we previously suggested
• Could use ROI
• Could use IRR

71
This is it no more time.no more slides in this
section. This year.
72
JAD, Joint Application Development

• Involves the use of GROUPWARE to jointly develop
  software
• Developers can be geographically dispersed
• Analogous to concurrent engineering
• McConnell considers it a best practice

73
Another IT Project Type Rapid Application
Development

• The Dupont time-bucket approach

74
RAD, Rapid Application Development

• Show the user/client a piece
• Get feedback and revise
• Show user/client another piece
• Get feedback and revise
• POWERBUILDER, VISUAL BASIC fit this kind of
  development
• Utilizes a prototyping tool, usually

75
RAD and eCommerce Internet Development

• Projects last any where from 3 weeks to 6 months
  max
• Most are around 5 weeks in duration
• Not much analysis is done
• VB, XML, ASP and Visual InterDev are the
  technology choices
• About four or five team members
• Front-end developer, back-end developer, DB
  specialist, PM and or PL

76
RAD Basics

• Uses time-boxing
• Is focused on getting at least some functionality
  delivered by a specific due date
• Often, this approach skips the analysis phase and
  goes immediately to design
• Fits the paradigm of a software factory

77
RAD Disadvantages

• Does not scale up
• Would not use this on any large project,
  especially one with lots of indigenous risk

78
Visual Basic and PowerBuilder

• Facilitates both RAD and SAD
• Must REUSE the base objects that come with the
  tool
• to get the full benefit
• Must create a culture and an environment that
  encourages use of the base objects
• Sometimes, both the waterfall and the spiral
  models are too slow

79
How do we get applications out the door in a
timely manner?

• Reuse as much as possible--data and presentation
  components
• Intuitive Object-Oriented approach is the answer
• Use Duponts approach
• Calendar-driven development
• Trade time for functionality
• Use time boxes (three months, usually)
• can drop low-priority functionality

80
One of our Goals Flexibility

• We want a methodology that is so flexible that
  the requirements can change all during the
  development process, yet we can still meet the
  needs of the end users at the time of cut-over
  (i.e., deliver the product on time and within
  budget)

81
User Prototypes

• First couple of iterations are really
  prototypes--fifth iteration is the final product
• Limit cosmetic iterations to just two
• MDI frames should not be coupled, should possess
  very low cohesion

82
Teams

• Are in competition with each other
• Use a JAD session to plan the project
• Provide training as needed
• Use a pilot project

83
Change Management

• If end-users want to add something, they must
  then be willing to give something up
• There can be instances in which the time-box must
  be aborted
• But the end-users will have to eat the cost

84
The Goal

• Get the application living quickly
• Learn from it
• Then enhance it
• Time is more important than functionality
• Use two three-month time-boxes
• When the final version of the product is
  delivered the end of the second three-months,
  users will have a much greater understanding of
  their requirements

85
Creating object repositories

• Must use the old software factory model
• Deposit well-documented objects, COMPONENTS in
  the repository
• Encourage developers to reuse the objects by
  incentive/reward mechanisms
• Must avoid re-inventing objects within all the
  functions of an organization

86
Standards should be devised

• Version control--allowing for all versions of the
  module to be tracked

87
Screens/Pages

• Each member of the team delivers from 1 to three
  screens (pages) daily
• A significant release should be forthcoming each
  week
• Each developers assigned tasks should be broken
  down into chunks of functionality that must be
  delivered by certain due dates

88
Selection Methodology For Software, Processes
and Projects

• Define the application to be computerized
• Develop a list of COTS packages that is available
  to support the app
• Gather information about the COTS packages
• Narrow the list of possible choices down to less
  than a half dozen
• Obtain hands-on demonstrations of the few
  remaining packages

89
Selection Methodology, Contd

• Of those that remain, perform a final detailed
  evaluation
• Make a decision
• Purchase the selected COTS package
• Learn to use the package
• Implement the package

90
Project Standards
91
Operational Issues -- Brooks

• Another Software guru like Boehm

92
Software Development -- Brooks

• What is the problem with hiring additional people
  on a project that is behind schedule?
• Under what circumstances are men and man-hours
  interchangeable?
• How much time should be set aside for testing and
  integration, according to Brooks?
• What are some good ways to organize work packages
  to avoid some of the problems Brooks is talking
  about?

93
Questions

• All programmers are ____.
• When schedule slippage occurs, the natural thing
  is to ____.
• What are the three stages of creative activity?
• These are analogous to ____?
• Brooks says that the programmer builds from ____.
• pure thought stuff concepts and flexible
  representations. However, today this is not true.

94
Questions, Contd

• Cost varies as the number of persons and the
  number of months
• However, progress does not.
• Can we use the man-month as a unit for sizing a
  job?
• No. It is too dangerous
• People and months are inter-changeable only when
  a task can be partitioned among many workers with
  _____.
• No communication between them
• The added burden of communication is made up of
  _____.
• two parts training and intercommunication.
• Long projects can expect a turnover of ___ a
  year.
• 20

95
Questions, Contd

• How much of the total time does Brooks devote to
  Definition, Analysis and Design?
• 1/3
• How much time to coding?
• 1/6 to Coding
• How much time to testing?
• 1/4 to component test and early system test
• 1/4 to total system test