Richard Collings: Database Workshop
Project Management
16th May 2006
Sue Fidler, CTOCharity Technology TrustPhone: 0845 456 1823Email: [email protected]
Richard Collings, ConsultantPhone: 020 8880 0188Email: [email protected]
2
Approach – Project Management Question Time
• Project health check
• Introductions
– Who you are
– Your current/planned project
– Problem/question that you have a the moment OR Issue you want to talk about
• Identify issues, prioritise and discuss
• Further material on
– Why projects go wrong
– Effect of budget on functionality, timescale and risk
– Project management approaches
Politics
Multiple parties involved, some actively hostile; no decision making process in place
Multiple parties involved, some apathetic; no/weak decision making process in place
Multiple parties involved, mostly keen; acceptable decision making process in place
Multiple parties; single decision maker but poor understanding
Multiple parties; single decision maker with good understanding
Singe party involved, single decision maker with good understanding
User/management involvement
Users hostile and not involved; dictatorial management with poor understanding
Management delegated to ‘wrong’ users
Users neutral but very limited involvement; very limited management engagement
Users and management keen but do not have time to get effectively involved
Single good user actively involved, consults with others; management effectively involved
Good representative users freed up for project, effective participants; management fully engaged
Understanding of problem/business change
Nobody has thought about the business change needed
Complex change required and not understood; change to be forced through by new system
Complex change required but being done separately from system development
Complex change required; no piloting but effective business change planning being undertaken
Simple system with small business change involved; some planning done
System and business changes already effectively piloted; change programme worked out
Timescale/budget
Big bang roll out; fixed functionality; impossible timescale; insufficient budget
Big bang roll out; fixed functionality; impossible timescale; large budget
Big bang roll out; fixed functionality; acceptable timescale and budget
Big bang rollout; functionality; timescale flexible; budget fixed
Staged rollout possible; functionality flexible; tight, fixed budget and timescale
Project being staged/piloted; functionality flexible; budget and timescale fixed but adequate
Supplier/Technology
New unknown supplier using new technology for first time in new application area
New unknown supplier using new technology for first time in known (to them) application area
Previously used supplier, experienced in application area, working with new technology
Previously used supplier in new application area using known technology
Referenced supplier with substantial experience of technology and application area
Previously used supplier with substantial experience of technology and application area
Stability of requirement/ Previous experience
Requirement likely to change; have not implemented similar project (nor has supplier); big bang rollout
Requirement stable; have not implemented similar project (nor has supplier); big bang rollout
Requirement likely to change; have not implemented similar project (nor has supplier); staging possible
Requirement stable; have not implemented similar project (nor has supplier); staging possible
Requirement likely to change; but similar to previous projects (us and supplier); staging possible
Stable requirement; similar to previous projects (us and supplier)
Data migration
Large amounts of complex data to migrate; have not thought about how to do
Large amounts of complex data to migrate; some initial investigation done
No data to migrate/ load (are you sure?)
Large amounts of complex data to migrate; detailed planning done but no trials
Small amount of data to migrate/load; plan in place
Data transfer/data take on extensively trialled already
Project Health Check © Richard Collings ([email protected])
Politics
Multiple parties involved, some actively hostile; no decision making process in place
Multiple parties involved, some apathetic; no/weak decision making process in place
Multiple parties involved, mostly keen; acceptable decision making process in place
Multiple parties; single decision maker but poor understanding
Multiple parties; single decision maker with good understanding
Singe party involved, single decision maker with good understanding
User/management involvement
Users hostile and not involved; dictatorial management with poor understanding
Management delegated to ‘wrong’ users
Users neutral but very limited involvement; very limited management engagement
Users and management keen but do not have time to get effectively involved
Single good user actively involved, consults with others; management effectively involved
Good representative users freed up for project, effective participants; management fully engaged
Understanding of problem/business change
Nobody has thought about the business change needed
Complex change required and not understood; change to be forced through by new system
Complex change required but being done separately from system development
Complex change required; no piloting but effective business change planning being undertaken
Simple system with small business change involved; some planning done
System and business changes already effectively piloted; change programme worked out
Timescale/budget
Big bang roll out; fixed functionality; impossible timescale; insufficient budget
Big bang roll out; fixed functionality; impossible timescale; large budget
Big bang roll out; fixed functionality; acceptable timescale and budget
Big bang rollout; functionality; timescale flexible; budget fixed
Staged rollout possible; functionality flexible; tight, fixed budget and timescale
Project being staged/piloted; functionality flexible; budget and timescale fixed but adequate
Supplier/Technology
New unknown supplier using new technology for first time in new application area
New unknown supplier using new technology for first time in known (to them) application area
Previously used supplier, experienced in application area, working with new technology
Previously used supplier in new application area using known technology
Referenced supplier with substantial experience of technology and application area
Previously used supplier with substantial experience of technology and application area
Stability of requirement/ Previous experience
Requirement likely to change; have not implemented similar project (nor has supplier); big bang rollout
Requirement stable; have not implemented similar project (nor has supplier); big bang rollout
Requirement likely to change; have not implemented similar project (nor has supplier); staging possible
Requirement stable; have not implemented similar project (nor has supplier); staging possible
Requirement likely to change; but similar to previous projects (us and supplier); staging possible
Stable requirement; similar to previous projects (us and supplier)
Data migration
Large amounts of complex data to migrate; have not thought about how to do
Large amounts of complex data to migrate; some initial investigation done
No data to migrate/ load (are you sure?)
Large amounts of complex data to migrate; detailed planning done but no trials
Small amount of data to migrate/load; plan in place
Data transfer/data take on extensively trialled already
Project Health Check © Richard Collings ([email protected])
5
Introduction
• Who you are
– Your current planned project
– What you would like to get out of the session
– Problem/question that you have a the moment OR Issue you want to talk about
• Further material on
– Why projects go wrong
– Effect of budget on functionality, timescale and risk
– Project management approaches
6
London Ambulance Service
• Ridiculously short timescales
• Belief that system could solve major organisational problems
• Fear based culture
• Insufficient budget
• No engagement with staff
• Lack of management understanding
• Responsibilities not defined
• Lack of project management experience
• No independent review
• Poor risk management
• Inexperienced supplier
• New/unproven technology
• Inadequate/non-existent testing & QA
• Poor system performance
• Poor change control
• No contingency planning/fall back options
• No/poor training
• Staff hostility
7
Other things that can go wrong
• Insufficient buy-in from management
• Organisational politics
• Conflicting requirements
• Untested ideas
• Changing business environment
• Poor choice of package
• Over complicated design
• Unusable system
• Wrong users involved
• Interface problems
• Technically driven project
• Insufficient attention to data take on
• Transferring poor data from existing systems
• Supplier overcommitted
• Supplier goes bust
• Users not committed
8
Reasons projects fail (1 of 2)
The Chaos Report, Standish Group, 1995Survey of 365 IT Managers
9
Reasons why projects fail (2 of 2)
OASIG study, 199545 ‘experts’ in academia and consultancy
10
Approaches to project management
• Traditional approach
– ‘Waterfall’ based
– Large amount of documentation/formal procedures
– PRINCE2
– Tends to be used on larger projects – particularly in government
• Agile approach
– AKA: Lightweight, RAD, DSDM, eXtreme Programming (XP), RUP, SCRUM
– Iterative approach
– Timeboxed development
– Delivery in small stages
– Focus on user engagement
– Small teams
11
Budget vs Functionality, Risk and TimescaleF
unct
iona
lity
Tim
esca
le/R
isk
Budget
12
Waterfall approach
Requirements capture
Analysis and design
Implement and module test
Integrate and test
Deploy
Freeze requirements
Freeze design
13
PRINCE2 - Background
• Process based approach to project management
• Commissioned by CCTA (now OGC) – launched 1996
• Developed from PRINCE (1989) which was based on PROMPTII (1975)
• Mandated for government projects
• Widely used in private sector
• Certifications
– Foundation
– Practitioner
14
PRINCE2 - Elements
• Processes
– Activities to be carried out during project
• Components
– Things generated/used by processes
• Techniques
– Used throughout the approach
• Roles
• Plans
15
PRINCE2 – Processes
Directing a ProjectDirecting a Project
PlanningPlanning
Starting up a project
Starting up a project
Initiating a project
Initiating a project
Controlling a stage
Controlling a stage
Managing product delivery
Managing product delivery
Managing stage
boundaries
Managing stage
boundaries
Closing a project
Closing a project
Managing Successful Projects with Prince2, Pg12
16
PRINCE2 - Components
• Business case
• Organisation
• Plans
• Controls
• Management of risk
• Quality in a project environment
• Configuration management
• Change control
17
PRINCE2 - Techniques
• Product based planning
• Change control
• Quality reviews
18
PRINCE2: Good things (1 of 5)
• Business case
– Contains: Reasons, Options considered; Benefits; Risks; Costs and Timescales; Investment appraisal
– Sensitivity analysis: Good, Average, Poor
– Need to (continue to) make sure that system is going to deliver a cost effective solution
• Project Board
– Consists of:• Executive: representing the Business: does the project meet the needs of the business overall• Senior user: representing the Users: will the project deliver a useable result (‘fit for purpose’)• Senior supplier: representing the Supplier(s): responsible for delivery of system• Project assurance: see below
– Need to make sure that above three constituencies are adequately represented
– Meets periodically review progress/risks/issues
19
PRINCE2: Good things (2 of 5)
• Project manager (personal view)
– Understands business and technology
– Good communication skills
– Experienced
– Good communication skills
– Efficient and well organised
– Driven
– Good at delegating
• Project assurance
– Independent assessment of the project
– Understands business and technology
– Experienced
20
PRINCE2: Good things (3 of 5)
• Project initiation document
– What, why, who, how and when
– Project definition: Objectives, Approach, Scope, Deliverables, Exclusions, Constraints, Interfaces, Assumptions
– Project organisation structure: Team structure, Job descriptions
– Communication plan
– Quality plan
– Project controls
– Initial Business case
– Initial Project plan
– Initial Risk log
21
PRINCE: Good things (4 of 5)
• Stage boundaries
– Set points at which to review previous stage – confirm viability of project
– Review business case
– Plan next stage
• Risk Log
– Risk log:• Risk Description• Impact• Likelihood• Mitigation: Prevent, Reduce, Transfer, Accept, Provide contingency• Status• Outstanding actions
– Brainstorm
– Periodic reviews (eg Stage boundaries)
22
PRINCE: Good things (5 of 5)
• Issue Log
– Issues: Request for change; Off-specification; Question; Statement of concern
– Capture:• Description• Priority• Impact analysis• Decision
23
PRINCE2: Weaknesses
• Bureaucratic/labour intensive
• Focus on project management process; not on project itself
• Focus on deliverables rather than on delivering business benefit
• Focus on wrong things
– What needs to be done rather than how should we do this?
– Focus on paper rather than on actual deliverables
– Concerned with protecting one’s ‘rear end’ rather than on getting the job done
• Still dependent on the skills and knowledge of the individuals
• Delivers false sense of security
• Assumes that you know what you are doing
24
PRINCE2: Resources
• Books
– Managing Successful Projects with PRINCE2, OGC, 2002
• Websites
– http://www.prince2.org.uk/
– http://www.btt-research.com/prince_2_project_failures.htm
25
Agile - background
• Originated in mid/late 1980s
– Response to ‘big’ methodologies (SSADM, Information Engineering)
– Spiral (Boehm, 1986); Evo Development (Gilb, 1988), RAD (Martin, 1991)
• Mid 1990s
– DSDM – UK based initiative
• Late 1990s/Early 2000s
– Object community
– eXteme Programming (Beck/Cunningham – 1999)
– Agile Software Development (Alastair Cockburn – 2002)
– Scrum (Jeff Sutherland, 1993; Ken Schwaber, 2004)
– RUP/EUP (Jacobson 1988; Ambler 2000-2002)
26
Agile - overview
“Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Agile Manifesto, 2001
27
Agile: Approach/Good things (1 of 3)
• Iterative
– high benefit/low cost first
– focus on high risk areas
• Short development phases
– 1 week - 2 months
– Timeboxing
– Descope to deliver on time
– Deliver real working systems
• Face to face communication
– Small teams
– Pair programming
– ‘Onsite user’
28
Agile: Approach/Good things (2 of 3)
• Keep it simple
– Focus on immediate requirements
– Don’t overcomplicate
– ‘Refactor’ where necessary
• Focus on business benefit
– Be clear why you are doing something
– Try and measure benefits
• Lightweight documentation
– Minimal specifications/documentation
– No modelling (or throw away)
– System/code is the documentation
29
Agile: Approach/Good things (3 of 3)
• Testing driven
– Prepare tests before starting to code
– Test all the time (every build?)
– Automated testing
• ‘Human approach’ to system development
– Reasonable working hours
– Build team spirit
– Open/honest approach
– Accept people make mistakes
30
Agile: Weaknesses
• Works best on projects where
– Requirements are uncertain
– Better to have something sooner with some certainty
• Less good on
– Replacement/Big bang projects
– Projects with known requirements
• Problems with passing risk onto supplier (fixed price contracts)
– ‘House with no roof’
• Issues with
– Stability
– ‘Project memory’
• Need a risk taking culture
– Works less well where there is a blame culture
31
Agile: Sources
• Books
– Agile Software Development, Alistair Cockburn, 2002
– DSDM, The Method in Practice, Jennifer Stapleton, 1997
– Principles of Software Engineering Management, Tom Gilb, 1998
– eXtreme Programming explained, Kent Beck, 2000
– Agile Project Management with Scrum, Ken Schwaber, 2004
• Websites
– http://xprogramming.com/
– http://www.extremeprogramming.org/
– http://www.gilb.com/
– http://www.dsdm.org/
– http://www.enterpriseunifiedprocess.com/
32
Contact details
• Richard Collings
– IS Strategy, Requirements preparation, Supplier Evaluation, Contract Negotiation
– User engagement facilitator, Acceptance Test planning, design and execution
– Project planning, project mentoring, project review
– email: [email protected]
– phone: 020 8888 0188
• Sue Fidler
– IS Strategy, Requirements preparation, Supplier Evaluation, Contract Negotiation
– Solution provision
– email: [email protected]
– phone: 0845 456 1823
