Paul Ticher Project Management Presentation
Upcoming SlideShare
Loading in...5
×
 

Paul Ticher Project Management Presentation

on

  • 575 views

 

Statistics

Views

Total Views
575
Views on SlideShare
575
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Paul Ticher Project Management Presentation Paul Ticher Project Management Presentation Presentation Transcript

  • Project Management 16th May 2006 Richard Collings, Consultant Sue Fidler, CTO Phone: 020 8880 0188 Charity Technology Trust Email: rcollings@cix.co.uk Phone: 0845 456 1823 Email: sue@ctt.org Richard Collings: Database Workshop
  • 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 2
  • Project Health Check © Richard Collings (rcollings@cix.co.uk) Multiple parties Multiple parties Multiple parties Multiple parties; Multiple parties; Singe party involved, involved, some involved, some involved, mostly single decision maker single decision maker single decision maker Politics actively hostile; no apathetic; no/weak keen; acceptable but poor with good with good decision making decision making decision making understanding understanding understanding process in place process in place process in place Good representative Users neutral but Users and Single good user Users hostile and not users freed up for Management very limited management keen actively involved, User/management involved; dictatorial project, effective delegated to ‘wrong’ involvement; very but do not have time consults with others; involvement management with participants; users limited management to get effectively management poor understanding management fully engagement involved effectively involved engaged Complex change Complex change System and business Complex change Simple system with Understanding of Nobody has thought required and not required; no piloting changes already required but being small business problem/business about the business understood; change but effective business effectively piloted; done separately from change involved; change change needed to be forced through change planning change programme system development some planning done by new system being undertaken worked out Project being Big bang roll out; Big bang roll out; Big bang roll out; Big bang rollout; Staged rollout staged/piloted; fixed functionality; fixed functionality; fixed functionality; functionality; possible; functionality Timescale/budget functionality flexible; impossible timescale; impossible timescale; acceptable timescale timescale flexible; flexible; tight, fixed budget and timescale insufficient budget large budget and budget budget fixed budget and timescale fixed but adequate New unknown Previously used New unknown Previously used Previously used Referenced supplier supplier using new supplier with supplier using new supplier, experienced supplier in new with substantial Supplier/ technology for first substantial technology for first in application area, application area experience of Technology time in known (to experience of time in new working with new using known technology and them) application technology and application area technology technology application area area application area Requirement likely to Requirement stable; Requirement likely to Requirement stable; Requirement likely to Stability of change; have not have not change; have not have not Stable requirement; change; but similar to requirement/ implemented similar implemented similar implemented similar implemented similar similar to previous previous projects (us Previous project (nor has project (nor has project (nor has project (nor has projects (us and and supplier); staging experience supplier); big bang supplier); big bang supplier); staging supplier); staging supplier) possible rollout rollout possible possible Large amounts of Large amounts of Large amounts of complex data to complex data to Small amount of data Data transfer/data complex data to No data to migrate/ Data migration migrate; have not migrate; detailed to migrate/load; plan take on extensively migrate; some initial load (are you sure?) thought about how to planning done but no in place trialled already investigation done do trials
  • Project Health Check © Richard Collings (rcollings@cix.co.uk)  Multiple parties Multiple parties Multiple parties Multiple parties; Multiple parties; Singe party involved, involved, some involved, some involved, mostly single decision maker single decision maker single decision maker Politics actively hostile; no apathetic; no/weak keen; acceptable but poor with good with good decision making decision making decision making understanding understanding understanding process in place process in place process in place Good representative  Users neutral but Users and Single good user Users hostile and not users freed up for Management very limited management keen actively involved, User/management involved; dictatorial project, effective delegated to ‘wrong’ involvement; very but do not have time consults with others; involvement management with participants; users limited management to get effectively management poor understanding management fully engagement involved effectively involved engaged  Complex change Complex change System and business Complex change Simple system with Understanding of Nobody has thought required and not required; no piloting changes already required but being small business problem/business about the business understood; change but effective business effectively piloted; done separately from change involved; change change needed to be forced through change planning change programme system development some planning done by new system being undertaken worked out  Project being Big bang roll out; Big bang roll out; Big bang roll out; Big bang rollout; Staged rollout staged/piloted; fixed functionality; fixed functionality; fixed functionality; functionality; possible; functionality Timescale/budget functionality flexible; impossible timescale; impossible timescale; acceptable timescale timescale flexible; flexible; tight, fixed budget and timescale insufficient budget large budget and budget budget fixed budget and timescale fixed but adequate New unknown Previously used New unknown Previously used Previously used Referenced supplier  supplier using new supplier with supplier using new supplier, experienced supplier in new with substantial Supplier/ technology for first substantial technology for first in application area, application area experience of Technology time in known (to experience of time in new working with new using known technology and them) application technology and application area technology technology application area area application area  Requirement likely to Requirement stable; Requirement likely to Requirement stable; Requirement likely to Stability of change; have not have not change; have not have not Stable requirement; change; but similar to requirement/ implemented similar implemented similar implemented similar implemented similar similar to previous previous projects (us Previous project (nor has project (nor has project (nor has project (nor has projects (us and and supplier); staging experience supplier); big bang supplier); big bang supplier); staging supplier); staging supplier) possible rollout rollout possible possible  Large amounts of Large amounts of Large amounts of complex data to complex data to Small amount of data Data transfer/data complex data to No data to migrate/ Data migration migrate; have not migrate; detailed to migrate/load; plan take on extensively migrate; some initial load (are you sure?) thought about how to planning done but no in place trialled already investigation done do trials
  • 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 5
  • London Ambulance Service • Ridiculously short timescales • Poor risk management • Belief that system could solve major • Inexperienced supplier organisational problems • New/unproven technology • Fear based culture • Inadequate/non-existent testing & QA • Insufficient budget • Poor system performance • No engagement with staff • Poor change control • Lack of management understanding • No contingency planning/fall back • Responsibilities not defined options • Lack of project management • No/poor training experience • Staff hostility • No independent review 6
  • Other things that can go wrong • Insufficient buy-in from management • Technically driven project • Organisational politics • Insufficient attention to data take on • Conflicting requirements • Transferring poor data from existing systems • Untested ideas • Supplier overcommitted • Changing business environment • Supplier goes bust • Poor choice of package • Users not committed • Over complicated design • Unusable system • Wrong users involved • Interface problems 7
  • Reasons projects fail (1 of 2) The Chaos Report, Standish Group, 1995 Survey of 365 IT Managers 8
  • Reasons why projects fail (2 of 2) OASIG study, 1995 45 ‘experts’ in academia and consultancy 9
  • 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 10
  • Budget vs Functionality, Risk and Timescale Timescale/Risk Functionality Budget 11
  • Waterfall approach Requirements capture Analysis and design Implement and module test Freeze Integrate and requirements test Freeze design Deploy 12
  • 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 13
  • PRINCE2 - Elements • Processes – Activities to be carried out during project • Components – Things generated/used by processes • Techniques – Used throughout the approach • Roles • Plans 14
  • PRINCE2 – Processes Directing a Project Initiating a project Managing Starting up Controlling Closing a stage a project a stage project boundaries Managing product delivery Planning Managing Successful Projects with Prince2, Pg12 15
  • PRINCE2 - Components • Business case • Organisation • Plans • Controls • Management of risk • Quality in a project environment • Configuration management • Change control 16
  • PRINCE2 - Techniques • Product based planning • Change control • Quality reviews 17
  • 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 18
  • 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 19
  • 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 20
  • 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) 21
  • PRINCE: Good things (5 of 5) • Issue Log – Issues: Request for change; Off-specification; Question; Statement of concern – Capture: • Description • Priority • Impact analysis • Decision 22
  • 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 23
  • 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 24
  • 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) 25
  • 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 26
  • 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’ 27
  • 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 28
  • 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 29
  • 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 30
  • 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/ 31
  • 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: rcollings@cix.co.uk – phone: 020 8888 0188 • Sue Fidler – IS Strategy, Requirements preparation, Supplier Evaluation, Contract Negotiation – Solution provision – email: sue@ctt.org – phone: 0845 456 1823 32