Database Project management
4 likes3,190 views
This document discusses physical database design and project management planning. It covers scheduling project tasks using Gantt charts, estimating task timelines, assigning resources to tasks, and tracking progress. Milestones are defined and the project plan is reviewed periodically or when major changes occur. The document also touches on risk management, identifying and mitigating risks throughout the project lifecycle.
Database Project management
- 1. 1 Physical Database Design: Project Management and Planning John Whitfield (Paul Crowther)
- 2. 2 Scheduling and Control • Gantt Charts - Timeline Chart • Development of – activities – milestones – deadlines • With resources – people – equipment – money
- 3. 3 Gantt Chart example Aug Sept Oct Feasibility Identify Need meet users………… find objectives……. establish product statement…………. Milestone product statement defined today
- 4. 4 Planning • Break the project into components (Compartmentalization) • Check interdependencies • Allocate time (person-days) • Validate time allocation (<= number on team) • Assign tasks to team members • Define outcomes • Define milestones • Draw Gantt chart
- 5. 5 Planning • Refine Major Tasks • Define a task network PERT chart • Microsoft Project will convert between GANTT and PERT • NOTE – Easier to estimate time for small things then add them up – Easier to estimate if you have done it before – There are estimating metrics
- 6. 6 Estimate • Most optimistic time (OT) – nothing goes wrong • Most pessimistic time (PT) – everything that could go wrong does • Most likely time (LT) • estimate = OT + 4*LT + PT 6
- 7. 7 Microsoft Project - Gantt Chart View
- 8. 8 Resources for Task: Clean Plunger Pot
- 9. 9 Chart with resource allocations
- 11. 11 For Each Activity on the Gantt Chart, Need To Specify: • Resources • Who will do it • What they will do it with • How much it will cost • OR • Break it down into a sub chart
- 12. 12 Planning • The plan should be reviewed: • When a milestone is reached – Was it on schedule? – Was it within budget? – Did anything happen that will affect the rest of the project? • If a major change or unanticipated event arises
- 13. 13 User Imposed (Unrealistic) Deadlines • Perform detailed estimates • Identify critical functions • Develop an implementation strategy • Negotiate with clients
- 14. 14 Industry View • Project Management is a good thing to do !!! • Anything that is unmanaged will probably fail to deliver • PRINCE2 (but have you a certified practitioner?) • So .... how to choose a plan?
- 15. 15 PRINCE2 a Project Management Methodology Directing a Project 4 Directing a Project 1 Directing a Project 2 Directing a Project 3 Directing a Project 5 Starting up a Project Initiating A Project Managing Stage Boundaries Managing Product Delivery Controlling a Stage Closing a Project Planning
- 16. 16 Methodology • A methodology is simply a series of checklists and procedures so that nothing is forgotten • You can use as much or as little of the methodology that is sensible • Methodologies are a good idea
- 17. 17 The Process • Choose a methodology... • Linear Sequential Model • Prototyping Model • RAD Model • Incremental Model • Spiral Model • Component Assembly (Object Oriented) Model
- 18. 18 Problem solved by Process • The 90 - 90 rule • first 90% of a system absorbs 10% of the allotted effort and time • last 10% of a system absorbs 90% of the allotted effort and time • Hence a lot of project are 90% complete • It always takes longer and costs more than originally estimated (but it should not!)
- 19. 19 Pre-requisites • You must understand the context of the project you are about to manage • There must be a set of agreed project objectives and a strategy of how to achieve them • The organisation must properly define what it needs otherwise the project will fail • The objectives MUST be achievable
- 20. 20 The Project (problem) • Criteria – size of the project – number of users – criticality – longevity – stability – user / developer relationship – performance requirements – developer team numbers
- 21. 21 Risk Management Reactive v Proactive • Reactive – do nothing until something goes wrong – move into fire fighting mode – move into crisis management mode • Proactive – identify and analyse risks – avoid risks
- 22. 22 Types of Risks • Product size • Management or marketplace constraints • Users • Level of project definition • Development tools (environment) • Newness of the technology (early v late adoption) • Team size and experience
- 23. 23 Risk Assessment • Identify risk and its type (eg User) • Estimate the probability it will occur • Estimate its severity – catastrophic – critical – marginal – negligible • Develop a risk mitigation (avoidance), monitoring and management plan
- 24. 24
Editor's Notes
- #2: 1