Title: Introduction to project management topics
1Introduction to project management topics
2Persuasive Communicator
Good Controller
Effective Planner
Project Manager
Effective Manager
Good Trainer
Technically Competent
Sensitive to problems of change
Organisationally Powerful
3DEVELOPMENT MODELS
- Waterfall
- Clear deliverables
- Spiral Model
- Risk assessment
- Evolutionary
- Staged Delivery
- RAD
- Fast development enivronment
- Package based
- Using a foundation
4Waterfall Model
Feasibility Study
Define Requirements
System Design
Programming and Testing
Implementation
5V Model
Concept
System
QA Activities
Development Activities
6Incremental
Initial Requirements and Design
Increment 1 Detailed design, programming and
testing
Increment 2 Detailed design, programming and
testing
Increment 3 Detailed design, programming and
testing
7Spiral Model
Evaluate alternatives, identify and resolve risks
Determine objectives, alternatives, constraints
Risk Analysis
Prototype
Review
Reqs/ Design/ Code
Project plan Q.Plan Test plan
Plan for next phase
Develop Verify
8PRINCE -Overview
- A project management methodology
- Other similar ones METHOD/1 SDM
- Public domain / standard
- Separates management from technical
9PRINCE - Organisation
Project Board
Project Assurance Team
Project Manager
Stage Manager(s)
Team
Supplier(s)
10PRINCE - Planning/ Deliverables
Project Deliverables
Managerial
Technical
Quality
11PRINCE - Planning / Tolerances
Target
Cost
Tolerance Box
-
-
Time
12PRINCE - Control
Stages
Phases
Product
Product
Product
Management Control - health of project
Technical Control - health of product
13Rapid Application Development
- Martin - 1992
- Initially synonymous with hacking
- DSDM - mid-1990s
- Iterative approach
- Minimum documentation
- Scientific (objective) philosophy
- Further reading / sources
- Stapleton, J. (1997) Dynamic Systems Development
Method, Addison -Wesley - Beynon-Davies et al (1999) Rapid Application
Development (RAD) an empirical review, European
J. of IS, vol.8, pp211-223.
14DSDM Principles (1)
- Active user involvement
- Team empowered to make decisions
- Frequent delivery of products
- Fitness for purpose is acceptance criterion
- Collaborative co-operative approach
15DSDM (2)
- Iterative incremental development
- All changes are reversible
- Requirements frozen at high level
- Testing integrated throughout life cycle
16Components of RAD
- Joint Application Design (JAD)
- Clean rooms
- Time boxing
- Rapid development tools
- Highly interactive, low complexity projects
- Intensive phased projects
17Time Boxing
U s e r R e v i e w
U s e r R e v i e w
U s e r R e v i e w
Time box 1
Time box 2
Time box 3
18DSDM Life Cycle
Feasibility
Business Study
Agree Schedule
Implement
Functional Prototype Iteration
Implement- ation
Create Functional Prototype
Identify Functional Prototype
Business Review
Train Users
Review Prototype
User approval user guidelines
Review Design Prototype
Design Prototype Iteration
Identify Design Prototype
Create Design Prototype
Agree Schedule
19Project planning topics
20REASONS FOR PLANNING
- Target Verification
- Resource Planning
- Commitment
- Basis for What-if
- Enforces Pre-thinking
- Step in Delegation
- Basis for Control
21ELEMENTS OF A PLAN
- Project Activities
- Tasks / Deliverables
- Dependancies
- Resource Estimates
- - mandays - Mb
- Activity Schedules
- Resource Budgets
- By Task / Person
- Risk Analysis
- Risk - Reductions - Contingency
- Quality Plan
22ACHIEVES THE GOAL
- Meets the projects objectives
- Deliverables based
- NOT 80 of program XYZ done
- SHOULD BE program XYZ signed off by team leader
as complete - All activities catered for
- Major cost overrun
- Checklists /Methodologies
Programmers
CONTRACT
Project Manager
Customer
23REALISTIC TARGETS
- Short Activities
- eg 1 week
- Real Estimates
- NOT time sliced
- Dependencies
- all clearly defined
- Calculated Contingency
- from risk analysis
- per task not the whole
- risk of wrong estimates
- OSINTOTS
- rework
24PURPOSE OF CONTROLLING THE PLAN
PLAN
OBTAIN AGREEMENT
REASSESS
PROCEED
- To monitor progress
- To provide motivation
- Input to formal estimating technique
- Input to staff performance reviews
- Basis of lessons learnt
- Mainly to trigger replanning
25PROCESS OF DECOMPOSITION
Project WBS
Program Design
Program Coding
Program Testing
Prog Prog Prog A B C
Prog Prog Prog A B C
Prog Prog Prog A B C
- Guidelines
- Method of evaluating task completeness
- Tasks clearly defined
- Tasks should be assigned to very few people
- Time duration short enough to monitor
- Task cohesion (same type of work)
- Minimise task coupling (interdependency)
26DEPENDENCIES
- Types
- Finish - Start
-
- Start-Start
- Finish-Finish
- Partial Finish -Start
- Predecessor task has another dependent task on
it. - Successor task is dependent on another task
27SCHEDULING
- Gantt (bar) Chart
- What to be done
- Who will do it
- When it will be done
- Activity Network
- Inter-dependencies
- Estimated Effort
- Resource Matrix
- Skills/resources required
- Under/over utilisation
- Used to smooth team size
- Loss Factors
- Non-productive time
- Absences
- Increases with team size
- 4 days a week productive
28NETWORK ANALYSIS
- Steps
- Establish sequence
- Timetable for each job
- Analysing spare time
- Identifying most critical jobs
- Advantages
- Attention can be given to most critical jobs
- Spare time can be utilised
- Resources can be balanced
- Project Completion dates advanced
- Updating/Revision of plans easier
- Diagrams
- Activity on the arrow
- Activity on the node
29NETWORK CONVENTIONS
- Start and Finish Events
- Single start activity and completion
activity - Left to right Dependencies
- No Dangling Events
- No Looping
- Avoid Redundancy
- Example Node
A B
A B C E (finish) D.........?
A B C
A B C
EST Earliest Start Time LST Latest Start
Time DUR estimated DURation SLK SLacK time
(LST-EST)
Activity
EST
DUR
LST
SLK
30WHY ESTIMATING IS IMPORTANT
- To determine feasibility
- Calculate when and at what cost a system can be
delivered - Deciding on staffing policies and how to carry
out a project - If our estimates are inaccurate then our ability
to control and deliver the system on time and to
budget is affected - Affects all subsequent stages if we get it wrong
31HOW ESTIMATES FIT INTO OVERALL PROCESS
- It is one element of an iterative process which
includes - information gathering
- breaking down the job
- estimating of effort and skills
- scheduling
- monitoring and control
- reporting
Accuracy 100
Information Available
32WHY THERE ARE PROBLEMS
- Inappropriate expectations of accuracy
- Lack of experience and methods
- Different methods used by different people
- Poor record in the past
- Failure to take into account changes in
development environment - Lack of separation of estimating from scheduling
- Skill level assumed is not clear
- Elapse time between original estimate and the
event - No estimate for dealing with problems
33METHODS
MODEL
Known factors
Estimate
- Function Point Analysis
- Cocomo - lines of code based
- Pert - weighted average
- (A4BC)/6
- Ratios
- High Level (phases)
- Low Level (tasks)
- Standard Estimates
- Fixed
- Multiplied by number of items
- Based on complexity / size
- Multiple Estimate
- Compare and contrast
- Evolution of a local model
34FUNCTION POINT ANALYSIS
- Steps in performing FPA
- Defining the system boundary
- Defining the parameters
- external inputs
- external outputs
- internal logical data groups
- external logical data groups
- inquiries
- Identifying unique occurrences of parameters
- Complexity assessment
- low, average, high
- General System Characteristics
- VAF (TDI x 0.01) 0.65
- Final FP score unadjusted score x VAF
35COCOMO
- Basic level
- Effort a x sizeb size KLOC
- Organic (small scale)
- Effort 2.4 x size1.05
- Embedded (large, formal)
- Effort 3.6 x size1.2
- Semi-detached (medium)
- Effort 3.0 x size1.12
- Intermediate
- takes other factors into account
- Extended
- breaks the project down into phases / tasks
36PROJECT CONTROL
- Planning alone does not ensure the success of a
project - The project must be controlled
- monitoring progress
- evaluating performance
- making adjustments
- reacting to changes
PLAN
CONTROL LOOP
FEEDBACK
INFORM
ACTIVITY
37CONTROL PROCESS
Change Requests
Timesheets
INPUT INFORMATION
QUESTIONS
Are we on schedule?
OUTPUTS
New Resource Requirements
Revised Plan
Progress Report
38SLIPPAGE / VARIANCE
- Common Causes
- Calculating Slippage / Variance
- Earned Value
- Use of network chart
- Actions
- Extra Manpower ?
- Active management
- Recovery plans
- Work longer / harder
- Training
- Examine all possible solutions
- Hustle
- Review critical path
- Smooth the way ahead
- Remove / Reduce tasks
- phase system in?
39Quality management topics
40DEFINITION OF QUALITY
- Crosby defines quality as
- Conformance to requirements
- not goodness or elegance
- Quality is implemented through prevention of
defects - not through post-manufacturing inspection
- Performance standard must be zero-defects
- not thats near enough
- The measurement of quality is the price of
non-conformance
41COST OF QUALITY
- Prevention
- Planning
- Standards
- Training
- Improving the process
- Doing
- Cost of Production
- eg production of program design
- Appraisal
- Reviews Testing
- Failure
- Reworked Scrapped Work
- Data Corrections
- Retests
- User Discussions
- Cost of Q. price of non-conformance
42CUSTOMERS
- Identify your customers
- Internal / External
- Senior / Junior
- Involve throughout the project
- Mere Perception
- The individual perceives service in his or her
own way Arch McGill (IBM VP) - Tom Peters adds ....in his or her own unique,
idiosyncratic, human, emotional, end-of-the-day,
irrational, erratic way.
43QUALITY ETHOS
- Quality comes from people
- It happens because YOU want it to happen
- Quality staff Quality work?
- Avoid the were no worse than anyone else
syndrome - Ownership motivation for quality
- Difficult to improve 1 thing 100 It is easier
to improve 100 things by 1 - Book A Passion for Excellence, Peters Austin
44Accumulating Errors
Ideas, wishes and requirements
Correct Reqmt
Faulty Reqmt
Reqmt Definition
System Specifn
Correct Specifn
Specifn Errors
Errors induced from reqmts
Induced errors from
Correct Design
Design Errors
Design
Reqmts
Specficn
Induced errors from
Correct Program
Program Errors
Coding
Reqmts
Specficn
Design
Known Uncorrected errors
Testing Integration
Correct Operation
Corrected Errors
Unknown Errors
Software with known and unknown faults
Source Wallmuller Fig 1.3
45Percentages of fault costs compared with
development costs
Management 9
Quality Assurance, Configuration Mgt 6
CORRECTIONS 39
1
5
4
10
6
12
10
Rqmts
10
18
Sys Specn
9
Detailed Design
Coding
Integration System test
Adapted From Moller
in Software Quality Reliability
Ed. Ince
46QUALITY PLANNING
Quality Management System
Methodology
Development Environment
Documentation Practices
Standards
Configuration Management
CASE tools
Review Procedures
Quality Plan
Test Plan
Project Plan
47CONTENTS OF THE PLAN
- Purpose
- Reference Documents
- Management
- Documentation
- Standards, Practices, Conventions, and metrics
- Reviews and Audit
- Test
- Problem Reporting Correction
- Tools, techniques, and methodologies
- Code Control
- Media Control
- Supplier Control
- Record Keeping
- Training
- Risk Management
48USE OF SOFTWARE METRICS
- Types
- Effort Used
- Productivity Rate
- Lines of Code
- Defect Data
- Complexity
- Mean Time To Failure
- Change Requests
- Uses
- Compare with Plan/Expectations
- Identify Problem Areas
- Identify Areas for Using Tools
- Improved Information for Future Projects
- Implementation Decision
49RISKS
- System will never be delivered
- System will be delivered late
- System will exceed budget
- Project will divert user resources to an
unacceptable extent - System will lack functionality
- System will contain errors
- System will present difficulties to users in
using it - System will be difficult / costly to support /
enhance
Anyone of these risks could lead to project
failure
50COUNTER MEASURES
- Objective
- to reduce / eliminate risk that something will
cause the project to fail - Examples
- Extra tasks
- eg develop prototype to check user interface is
okay - Contingency
- eg extra time available
- Ensure controls in place
- eg contracts signed off
- Avoid assumptions
- eg excellent programmer from last project will
join you on new project - Have options available
- eg if performance problems then have extra
machine time available - Avoid promises
- eg use windows for implementation dates
51QUESTION / METRIC
- Where are the errors found?
- Error location
- What type of errors are they?
- Error classification
- What is our productivity Rate?
- Effort
- Deliverables Signed Off
- Number of lines of code
- How many more test runs do we need?
- Number of outstanding errors
- Error location
- How successful are our inspections?
- Effort
- Number of defects found
- How can we improve the development process or
what training is required? - Origin of Error
52Analysis of Defect Metrics
Defect Density
No. of Defects
Size of program
53ORIGIN OF DEFECTS
54RELIABILITY
No. of Defects Outstanding
Time
Cumulative Defects
Failure Intensity
Time
55TARGETING MAIN PROBLEMS
Pareto Chart
56PRINCIPLES FOR USING METRICS
- Pragmatism and Compromise
- Measuring People - Dont!
- Modelling Simplification
- Ask not for whom the bell tolls - ask why?
- The sum of the whole is greater than the
constituent parts - Culture Shock!
57REVIEW OF DELIVERABLES
- Team Leader Review
- Eg. Programming Team Leader
- Check for conformity, consistency and
completeness - Peer Review
- Eg. Another designer within team
- As with team leader review
- Walkthrough
- Eg Designer gt Programmer
- To confirm understanding and allow customer to
ask questions - Inspections
- Several people
- (Eg. Moderator, Author, Customer, Specialist,
Peer, User) - To trap and correct defects
- To review against requirements
58INSPECTION PROCESS
Input Documents
Exit Criteria
Deliverables
Checklists
INSPECTION
Correct Material
Defect and Process Data
59INSPECTION CYCLE
Produce Deliverable Moderator checks
suitability Choose inspection team Overview
meeting Preparation Inspection
Meeting Rework Moderator Sign-off
Reinspection if gt25 changed
60Walkthrough Vs Inspection
Walkthrough None Sometimes Implied Usually
Author No 10 7
Inspection Compulsory Essential Explicit Neve
r Independent Yes 25 1
Precise Entry / Exit Criteria Checklists
Used Rework Stage Defects discussed/ corrected
in meeting Leader of meeting Defects formally
recorded and analysed Defects found per
review Defects found per man hour
61CLEANROOM APPROACH
- More effective than debugging
- 90 defects found before test
- Total defect count drops
- Forces problems out early
- Based on statistical quality control
mathematical verification - Error reduction based on areas of most frequent
usage
62TEST STAGES
Black Box Test
Requirements Specification
Acceptance Testing
Black Box Test
Systems Specification
System Testing
White Box Test
(sub)System Design
Integration Testing
Black Box Test
White Box Test
Module Design
Module Testing
Black Box Test
Coding
Source Wallmuller
63TEST DOCUMENTATION
Quality Plan
System Documentation
Project Plan
Test Plan
Test Design Specification
Test Cases Procedures
Test execution
Test Log
Test Incident Report
64TEST PLAN
- Overall strategy for testing system
- shows how tests will prove the system,
including such things as - stress/performance testing
- recovery
- regression testing
- Objective for each kind of test
- avoid overlaps
- Criteria for completion
- how to decide when to stop
- Test schedule
- tasks dependencies
- Responsibilities
- team organisation
- Resources
- eg. automation tools
- Test procedures documentation to be produced
- test details
- eg. conditions, data, expected results,
instructions, tools - evidence
65AUTOMATING TESTING
- Capture Playback
- data input
- Comparator
- file/DB
- program code
- output vs expectation
- Input Generation
- for stress testing
- use of random numbers
- Verification (static analysis)
- eg compilers, spell checkers, style checker
- Simulator
- simulates real world
- Test Harness / Test Driver
- enables tests to be run unattended
- Test Coverage Measurement
- checks if all conditions/paths tested
- Debugging
- observation of variable states
66Software management topics
67People Management (1)
- In software development, talented programmers
are known to be ten times more productive as the
less talented members of a team - Cusumano (1997) How Microsoft makes large teams
work like small teams, Sloan Management Review
68LEADERSHIP STYLES
- Autocratic (Boss-Centred)
- Manager makes decision and announces it
- Manager sells decision
- Manager presents ideas and invites questions
- Manager presents tentative decision subject to
change - Manager presents problem, gets suggestions, makes
decision - Manager defines limits, asks group to make
decision - Manager permits sub-ordinates to function within
limits defined by superior - Democratic (sub-ordinate centred)
69TEAM BUILDING
- Ensure commitment to goal
- Team loyalty to one another
- Obtain team agreement
- Encourage contributions and views
- Listen to views - take action!
- Organise team to give clear responsibilities and
structure - Optimise team size
- 5 - 10 people per team
- Breakdown of team should minimise need for
co-ordination - Realistic but positive leadership
- Work closely with customers
- Manage conflict
70COMMUNICATION
- Within Team
- Team Meetings
- Newsletters
- Noticeboard / Wallchart
- Top / Down Bottom / Up
- Peer to Peer
- Formal System Information
- eg change requests, new CASE tool
- External to Team
Management
Users Team Other Teams
Suppliers
71PRODUCTIVITY
Perfectly partionable task (with no communication)
months
People
Unpartionable Task
months
People
Task with complex interrelationships
months
People
No of links n (n-1) / 2
72GOAL SETTING
- SHORT TERM
- Use of work plans
- Work Plan for Ian
- LONG TERM
- Use of job reviews / Appraisals
- frequency?
- major objectives
- development of staff
- review objectives
- No shocks
Task Prepare for interview Interview Marketing
Manager Write up interview Update data
model Update DFDs
Deliverable Questionnaire Completed
Questionnaire Minutes Data Model DFD
Estimate 8 hours 4 hours 6 hours 2 hours 8
hours
Target 23/11 24/11 25/11 25/11 27/11
73HOW DO WE MANAGE THE CUSTOMER?
- Know their business
- Set clear responsibilities
- Communicate frequently
- Involve them throughout
- Give low expectations
- Use contracts
- Plan for changeover
74COMMUNICATION
- Plan Involvement
- Users involved throughout project
- Inform of changes to plan or design
- Demonstrate system early
- Report progress
- Ensure users report problems
- Communicate information on new releases
- Use of contracts / service level agreements
- Measure satisfaction
- Get to know the customers
75MANAGING EXPECTATIONS
- The users views of what to expect develop
throughout the project - 20 of programming will give 80 of functionality
- Code this first! - Some Guidelines
- Tell them the worst
- Keep the good news until it is certain
- Prepare users for problems
- Be clear on essential vs. desirable
- Do not assume functions should be computerised
76MANAGING THE IMPLEMENTATION
- Preparation for live running
- user procedures
- operation procedures
- training
- control procedures
- conversion planning
- regression plan
- Going Live
- Conversion of data, etc..
- Technical environment
- Software release
- version control
- Hardware installed
- Customer Acceptance
- sign off contract
77WHY DO IMPLEMENTATIONS FAIL?
- System does not meet requirements
- Lack of planning
- Lack of management action after implementation
- No success factors to judge by
- Lack of training
- Poor user morale / no desire
- Over expectations
- Not making full use of the system
- Benefits not achieved
- Resistance to change
- Fear
- absenteeism
- avoidance of system
- redundancies
- Result
- Effect on Business
- Internal
78COST / BENEFIT ANALYSIS
- COSTS
- Installation
- Running
- BENEFITS
- Tangible
- measurable now
- Indeterminate
- measurable afterwards
- Intangible
- not measurable
- Simple Payback Equation
- Time Installation Costs
- Period Benefits (p.a.) - Running Costs
(p.a) - eg. 100,000 4 years
- (30,000-5,000)
79PRESENTATION OF COST/BENEFIT ANALYSIS
- Simple Presentation
- eg graphical
- eg charts
- Year 1 Year 2 Year 3
- Costs 10,000 5,000 3,000
- Benefits 0 12,000 15,000
- Cash flow -10,000 7,000 12,000
- Put detail in back up documents
- Agree management requirements first
-
Implementation
Break even point
80ENSURING THE REWARDS ARE REAPED
- Maximising Benefits
- Winning over the users
- Training / Procedures
- Plan to gain benefits (rigorously
manage accordingly) - eliminate functions
- regroup staff
- Contingency plans
- Selling to multiple customers or other companies
- Minimising Costs
- Good planning and control
- Being effective in development
- Controlling suppliers
- Managing risks
- Reducing maintenance
- minimising cost of making change
- minimise number of changes
81Why the productivity paradox?
- Amount of money spent
- Benefits not matching investment
- IS over hyped?
- Competitive advantage - disaster dichotomy
- Difficulty in estimating costs and measuring
benefits - Timing of returns
82Types of justification
- Cost / benefit
- Payback period
- RoI
- Cashflow
- Business Value
- RoM
- Information Economics
- Strategic Value
- CSF
83Changing nature of IS justification
Repositioning
Making money Saving money
Differentiation
Effectiveness
Efficiency
time
Source Lincoln (1990)
84Moving from a rational to interpretive view
Viewpoint Objective / Rational
Efficiency Zone
Effectiveness Zone
Understanding Zone
Viewpoint Subjective / Political
85Transforming the IT function
From Monopoly Supplier to Mixed Sourcing
From Systems Analysts to Business Consultants
From Craftsmen to Project Managers
From Business to Industry Standards
PROCESS
PEOPLE
PURPOSE
From Decentralized Bias to Centralized Topsight
From Large Function to Lean Teams
From System Provider to Infrastructure planner
Transformation of the IT function at British
Petroleum, Cross, Earl and Sampler, 1997
86The Software Process
Plans
Tools
Requirement
Product
Activities
People Management
Standards Procedures
87The Problem ...
- For every six new large-scale software systems
that are put into operation, two others are
cancelled. The average software development
project overshoots its schedule by half larger
projects generally do worse - W. Wayt Gibbs
88Software Process Improvement
- SEI believes the quality of software is largely
determined by the quality of the software
development and maintenance processes used to
build it - ESI focuses on the organisational and management
challenges of producing software, as it is
increasingly recognised that purely technological
solutions yield benefits that are difficult to
sustain
89The Capability Maturity Model
Maturity levels
Process capability
Contain
Key process areas
Goals
Organised by
Common features
Implementation or institutionalisation
Contain
Key practices
Activities or infrastructure
90The Capability Maturity Model
CMM Level
Focus
1 - Initial 2 - Repeatable 3 - Defined 4 -
Managed 5 - Optimised
Competent people heroics Project management
processes Engineering processes and
organisational support Product and process
quality Continuous process improvement
91Process Improvement Cycle
Build executive support
Implement action plan
Build improvement infrastructure
Develop improvement action plan
Assess the organisations software process
92Process Improvement Infrastructure
Steering Committee
Division Executive
Program Manager
S/w Engineering Process Group
Software Manager
Technical Working Groups
Software Staff
93Software Process Improvement and Capability
dEtermination
- SPICE is an attempt to draw together the CMM,
Bootstrap and other approaches to date. - The SPICE project has three goals
- to develop a working draft for a standard for
software process assessment - to conduct industry trials of the emerging
standard - to promote the technology transfer of software
process assessment into the software industry
world-wide
94Process Improvement - the Benefits
- According to a survey by SEI
- Productivity gains/year 35
- Time to market (reduction/year) 15-23
- Post release defects 39
- Business value ratio 51 (benefitscosts)
- Savings at Raytheon
- Rework cost reduction 16m
- Productivity gains 130 over 5 years
95The impact of maturing
Customer Satisfaction
100
Productivity
80
60
Staff morale
of companies good / excellent
40
20
Initial Repeatable
Defined Maturity Level
96Process Improvement - the Pitfalls
- Cost time exceed expectations
- Most difficult aspect appears to be project
planning - Keeping the people on board
- Im a programmer, I dont want all this!
- Using the metrics to improve
- Organisational politics
- Turf guarding
97Current Status
- SEI
- 1991 81 at level 1 none at 4or 5
- 1999 approximately 100 at level 4 or 5
- ESI benchmark of European companies
- 66 have common coding standards
- Only 56 track actual project costs
- 75 had post implementation review
- UK one of leading European countries in software
management practice
98Some Key Aspects of Improving (1)
- Senior management need to actively monitor SPI
progress - Set clear SPI goals
- Staff time dedicated to improvement
- Clear, compensated assignment of responsibility
- SEPG staffed by respected people
- Technical staff involved in improvement
99Some Key Aspects of Improving (2)
- Team work
- Learn from own experience
- Starting from where you are not where you would
like to be - Introduce new ideas in order of hit rate
- Start to measure the processes as soon as
possible - Focus on early removal of defects
100A Typical Approach to SPI
- Single champion
- Motivated by current problems
- Diffusion is ad-hoc
- No corporate view
- Will often fail
- cost gt expected
- champion leaves
- benefits take time
101IDEAL model
Acting
Leveraging
Initiating
Diagnosing
Establishing
102Product Management Issues
- Rapid changes in the market place
- First product often wins significant market share
- IS function needs to be seen to be profitable
- Applications are developed as one-off activities
- Reuse limited to cut and paste approaches or
low level components
103Software Maintenance
- Types of maintenance
- corrective
- adaptive
- perfective
- Significant cost of maintenance
- Poor perception
- Lacks good staff continuity from development
team - Patchwork changes not strategic re-engineering
104Moving from Backroom to Boardroom
- Build a responsive IT infrastructure to enable
change - Use business level components as well as low
level components - helps executives relate to reuse
- Components
- clear interfaces and behaviour reusable
- Manage the risk of poor components
105A Packaged Software Organisation
- Market leader in demographic data analysis
software - Multiple products targeted at different markets
- Previous experience with OO and technical level
components - Key changes in the business leading to multiple
products and high levels of reuse
106Product Portfolio
Customer Relationship Management
Data Mining
Sales Management
Market Profiling Packages
Bespoke Solutions
New Prospect Finder
Vertical Market Products
Level of Sophistication
Local Area Marketing
Relationship Marketing
Market Analysis
107Component Architecture
Packaged Applications
Bespoke Applications
Business Portfolio
Reporting
Mapping
Profiling
Multimedia
Business Components
Databases
Statistical Models
KBS Models
Internet Browser
Technical Components
108Organisational Structure
Source of Software
Ownership
Application Teams
Executive Strategy Group
Application Portfolio
Component Teams
Business Components
Technical Steering Group
External Sources
Technical Components
109A Flexible Approach
- Build for change
- Components reduce repetitious work
- Reduces lead time to market
- Avoids mass legacy systems
- Involve executives in maintenance decisions for
added value of current products
110Conclusion
- We need to manage people, process and product
- We need to reconsider some traditional views of
project management - The future chaos not panaceas (Baskerville and
Smithson, 1995)