Methodology for Information Systems Project Management Chapter 4

Methodology for Information Systems Project Management Chapter 4: James R. Burns

Some PM humor n n 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. n At the heart of every large project are many small projects trying to get out. n 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. n

The Real Software Development Process n n n 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 (Let’s 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

Summary of Today’s lecture n n n What do we mean by methodology? What are some ‘typical’ IT Project Types? The Generic Lifecycle model

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

What are some IT Project Types? ? n n n Enterprise Resource Planning Enterprise Architecture Determination Re-engineering projects Rapid application development projects Product selection n n n Component configuration projects Conversion projects Maintenance projects Component integration projects Internet Development projects Client/server changeover projects

A Generic Project Management Process n n n Conceptualization and Definition -- Initiating Planning and Budgeting -- Planning Execution -- Executing Termination and Closure -- Closing Monitoring and Control -- Monitoring and Controlling

STAGE 1: Initiating STAGE 2: Planning STAGE 3: Executing STAGE 5: Closing STAGE 4: Monitoring-and-Controlling

These are stages of the meta project n Three of these stages must be funded from sunk costs. u n 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

Alternative names for Stages n Inception u n Elaboration u n Lifecycle Architecture Milestone Construction u n Lifecycle Objective Milestone Initial Operational Capability Milestone Transition u Product Release Milestone

Initiating n n n n Obtain user requirements Worth doing? Ensure fit Assess consistency Identify dependencies Assess risk Determine owners/stakeholders n n n Test alignment with strategies Test resource availability Define scope Make go/no go decision Obtain funding Review alternatives

Planning n n n 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

Executing (Implementation) n n n 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

Closing n n n Document lessons learned History database Postmortem meeting Signature signoffs Get paid

Software Development Process Models--Boehm n n n WE’RE TALKING ABOUT THE EXECUTING STAGE HERE Code-and-fix model Waterfall model Evolutionary model Transform model Spiral model

Code-and-fix model n n 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

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

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

Waterfall model n n 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

The Standard Waterfall Model n n Better than the old “CODE AND FIX” approach A manufacturing model for software CASE tools were developed to support it: TI’s IEF—sold in 1994 to Sterling Software Basis for most software acquisition standards in government

The Standard Waterfall Model, Cont’d n n Too expensive for small projects Still used for project estimation (cost and duration) of large projects Doesn’t get used in practice very often Doesn’t seem to work satisfactorily

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

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

Transform model n n 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 3 GL code (COBOL, Fortran) or 4 GL code (visual languages) The specifications are transformed directly to machine code

The Transform Model n Steps are: u u u 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

The Transform Model, Cont’d n n 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

A Pervasive Problem n n How to enable users to create their own apps After all, there just aren’t 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

Did it work? n n n 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 3 GL. Like the evolutionary model, it did not accommodate unplanned evolutionary paths well. Won’t work for Large-Scale Development

The Spiral Model (Boehm, 1988) n Overcomes most of these shortcomings and addresses these questions n 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. n n n

Spiral model n n n 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

Spiral model, Continued n n n 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

Each Loop of the Spiral model n n n 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

How is risk mitigated? n If there is risk associated n 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.

How is risk mitigated? n 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

Figure 2 -3. Spiral Model of Software Dev.

Advantages of Spiral Model n n 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

More Advantages of the Spiral Model n n 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

More Advantages of the Spiral Model n n Provides a viable framework for integrating hardware-software system development Accommodates CASE tools

Disadvantages of the Spiral Model n n n Doesn’t 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 riskassessment expertise If there aren’t any, it doesn’t work well

The Dimensions Waterfall High Ceremony Low Ceremony Iterative

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

Agile Software Development n Software is developed in increments using an iterative approach u u n Learning takes place all along the way u n n Backbone first User interfaces next Important functionality next Less important functionality last 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.

More Agile Software Development An iteration lasts one to four weeks n 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. n At the end of each iteration, the team reevaluates project priorities. n Agile methods emphasize face-to-face communication over written documentation. n

n n n 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

More Principles behind Agile Development n n n 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.

Iterative, Agile Processes n n Rational Unified Process (RUP) Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Crystal n Scrum

The Home Ground for Agile Software n A culture that thrives on chaos, product is of low criticality, a small number of senior developers are used, and requirements change very often, applications are small.

The Home Ground for Waterfall n For plan-driven methods (such as the Waterfall Model), the home ground is high criticality, requirements are wellknown and don't change too often, a large number of developers, and a culture that demands discipline and order.

Project Management & SCRUM n 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).

More SCRUM n n n Scrum is an agile development methodology, implying low ceremony (little documentation, faceto-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. ’

Still More SCRUM n n n 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 doesn’t require a lot of training to start using it. Sprint periods of 30 days are similar to the monthly time-boxes used in RAD.

SCRUM Meetings n n n n 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 teamdecided punishments for tardiness 2) all are welcome, but only “pigs” may speak 3) the meeting is time-boxed at fifteen minutes regardless of the team’s size 4) all attendees should stand 5) the meeting should happen at the same location and same time every day

Traditional PM versus Agile Methods n Traditional PM Approach u u n Concentrates on thorough, upfront planning of the entire project. Requires a high degree of predictability to be effective. Agile Project Management (Agile PM) u u Relies on incremental, iterative development cycles to complete less-predictable projects. Is ideal for exploratory projects in which requirements need to be discovered and new 17– 53

Some Agile definitions n n Stories, story points—these are features, portions of functionality Elevation—an iteration that does not result in added functionality, does not usually get released to the customer Scrum meeting—held daily, usually at the beginning of the day—for 15 min Sprint—an iteration--usually 1 to 4 weeks in duration, resulting in the delivery of something of value to the customer—a small, short ‘project’

Project Uncertainty FIGURE 17. 1 17– 55

Traditional Project Management versus Agile Project Management Traditional Agile Design up front Continuous design Fixed scope Flexible scope, specifically Deliverables Features/requirements Freeze design as early as possible Freeze design as late as possible Low uncertainty High uncertainty Avoid change Embrace change Low customer interaction High customer interaction Conventional project teams Self-organized project teams TABLE 17. 1 17– 56

Agile Project Management n Agile PM u Is related to the rolling wave planning and scheduling project methodology. F Uses iterations (“time boxes”) to develop a workable product that satisfies the customer and other key stakeholders. F Stakeholders and customers review progress and re-evaluate priorities to ensure alignment with customer needs and company goals. F Adjustments are made and a different iterative cycle begins that subsumes the work of the previous iterations and adds new capabilities to the evolving product. 17– 57

Iterative, Incremental Product Development FIGURE 17. 2 17– 58

n Agile Project Management (cont’d) Advantages of Agile PM: u Useful in developing critical breakthrough technology or defining essential features u Continuous integration, verification, and validation of the evolving product. u Frequent demonstration of progress to increase the likelihood that the end product will satisfy customer needs. u Early detection of defects and problems. u Superior to traditional plan-driven development when it comes to creating new products, evidence shows 17– 59

Popular Agile PM Methods Scrum Crystal Clear Extreme Programming RUP (Rational Unified Process) Agile Modeling Rapid Product Development (PRD) Agile PM Methods Dynamic Systems Development Method (DSDM) Lean Development 17– 60

Agile PM Principles Focus on customer value Iterative and incremental delivery Experimentation and adaptation Self-organization Continuous improvement 17– 61

Agile PM in Action: Scrum n Scrum Methodology u Is a holistic approach for use by a crossfunctional team collaborating to develop a new product. u Each iteration is called a SPRINT u Defines product features as deliverables and prioritizes them by their perceived highest value to the customer. u Re-evaluates priorities after each iteration 17– 62

Scrum Development Process FIGURE 17. 3 17– 63

Key Roles and Responsibilities in the Scrum Process n Product Owner u n Development Team u n Acts on behalf of customers to represent their interests. Is a team of five-to-nine people with crossfunctional skill sets--is responsible for delivering the product. Scrum Master (aka Project Manager) u Facilitates scrum process and resolves impediments at the team and organization level 17– 64

SCRUM…. In Summary n n n n 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.

Another IT Project Type: System Acquisition/Conversion/Cut-over n n n Decide on requirements Grade commercial apps that fit Decide on one of them Install Conversion Cut-over

Another IT Project Type: Conversion n Slam-dunk Parallel Pilot

Another IT Project Type: System Integration and Test n n Component selection Component integration and testing

Another IT Project Type: Process Reengineering—Michael Hammer n n n 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

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

Another IT Project Type: Enterprise Integration n n the ability to read-from and write to all of the apps and data sources across the enterprise Application integration u n Use a common SOFTWARE BUS to “glue” them together Data warehousing

More Enterprise Integration n Workgroup/Workflow Apps Messaging systems Data federation u performs integration while leaving the source data in place

Another IT Project Type: System Maintenance n n Can use Spiral model here Software doesn’t need to be greased, like something mechanical does, so what do we mean by maintenance of software?

Selection Methodology: For Software, Processes and Projects n n n Could use MAUT, as we previously suggested Could use ROI Could use IRR

This is it: no more time…. no more slides in this section…. This year….

JAD, Joint Application Development n n Involves the use of GROUPWARE to jointly develop software Developers can be geographically dispersed Analogous to concurrent engineering Mc. Connell considers it a best practice

Another IT Project Type: Rapid Application Development n The Dupont time-bucket approach

RAD, Rapid Application Development n n n 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

RAD and e. Commerce Internet Development n n n 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 Inter. Dev are the technology choices About four or five team members u Front-end developer, back-end developer, DB specialist, PM and or PL

RAD Basics n n 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

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

Visual Basic and Power. Builder n n Facilitates both RAD and SAD Must REUSE the base objects that come with the tool u n n 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

How do we get applications out the door in a timely manner? n n n Reuse as much as possible--data and presentation components Intuitive Object-Oriented approach is the answer Use Dupont’s approach u u Calendar-driven development Trade time for functionality Use time boxes (three months, usually) can drop low-priority functionality

One of our Goals: Flexibility n 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)

User Prototypes n n n 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

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

Change Management n n If end-user’s want to add something, they must then be willing to give something up There can be instances in which the timebox must be aborted u But the end-users will have to eat the cost

The Goal n n n 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

Creating object repositories n n 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

Standards should be devised n Version control--allowing for all versions of the module to be tracked

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

Selection Methodology: For Software, Processes and Projects n n n 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

Selection Methodology, Cont’d n n n 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

Project Standards

Operational Issues -- Brooks n Another Software guru like Boehm

Software Development -- Brooks n n 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?

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

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

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