project planning n.
Skip this Video
Loading SlideShow in 5 Seconds..
Project Planning PowerPoint Presentation
Download Presentation
Project Planning

Loading in 2 Seconds...

play fullscreen
1 / 40

Project Planning - PowerPoint PPT Presentation

Download Presentation
Project Planning
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Project Planning Dindin Sjahril Departemen Teknik Informatika Institut Teknologi Bandung

  2. Objectives • Project Design • Estimating • Project Initiation • Starting the Project • Creating a Work Breakdown Structure • Planning Techniques

  3. Project Design • Lifecycle Choice : • Waterfall Model • Systems Engineering Lifecycle • Overlapping Phases • Prototyping • Joint Application Development (JAD) • Iterative Lifecycle

  4. Waterfall Model (1) • The classical SDLC model first described by Royce in 1970 • Requirements Definitions • Specifications (what must be done/delivered) • Design (how the specifications will be met) • Implementation (building the product) • Integration (making sure all components work together) • Operations (when the product is deployed into its working environtment) • Problems : • assumption that the phases are discrete, which we find in practice that they really are not • Major difficulty is that the specification may contain serious errors which will only be discovered very late, at the integration or operations phase. (This is very expensive to correct) • The huge maintenance effort (and hence cost) is attributed to poor requirements definition and specifications • Implications : • We must be rigorous in producing quality through every stage • We must try to choose lifecycles and techniques which will reduce errors of requirements definition and specification.

  5. Feasibility Analysis Design Build Implement Operation Waterfall Model (2) Waterfall Model Effort on Correction of Errors Source : Adapted from Martin 1993

  6. Initiate Defined Deliverables Requirements Definition Technical Design System Construction Installation Production Formal Reviews System Engineering Lifecycle • Variation of the waterfall model • Resulting products must have very high reliability and integrity

  7. Estimating • Project Success : • Meeting requirements • Delivering on time • Remaining within budget • Develop realistic estimates of cost and delivery date • To estimate accurately, we would need the following factors: • The size of the job being tackled • The productivity that can be expected (i.e., how quickly can we perform the work?) • The resources available to us • The environment and constraints under which we will work

  8. Certainty VS Project Stage • We need to do estimates at several levels: • At the strategi level – high degree of accuracy is not required, but the estimates must give a relative cost and duration to allow sensible selection of projects • At the feasibility stage – this must accurate enough to allow a cost/benefit decision to be taken as to whether to proceed with the project • Estimate per phase of the project (feasibility is established) • Micro estimating for individual tasks and deliverables within the current phase

  9. Factors Affecting Effort and Duration • Complexity • Skill of team members • Elapsed time of project/degree • Staff turnover • New methods/techniques/technology • Size of team • Development environment/language • Motivation of team members • Time pressure • Quality and documentation requirements

  10. Estimating Principles • Separate the estimators from the doers • Estimate at several levels • Quote a range • Use techniques appropriate to the phase • Use several tehcniques • Qualify your estimates • Revise your estimates • Collect data • Check reasonableness • Add an overall contingency • Monitor your effectiveness

  11. Phase 3 Costs $18,200 Phase 3 Phase 2 Costs $45,000 Phase 2 Phase 1 Costs $33,600 Phase 1 Bottom-Up Cost Estimates • Some issues to consider to create budget • Divide project into phases • Address the integration phase • Consider the fully burdened workload required to complete each phase of the project • Consider the costs for any specialized services • Consider the costs of equipment • Consider production costs A project divided into phases allows each phase to be assessed a cost value

  12. Allowance for Change • Create an average estimate for each phase of the project by factoring best-and-worst case scenarios • Factors that you should call upon to estimate budget: • Prior experience • Experience of others • Fixed quotes • Standard costs • As the cost can fluctuate, we must agree on a tolerance level for the project’s budget to be plus or minus a percentage of the predicted costs

  13. Budget at Completion • Budget at Completion (BAC) is the sum of the budget for each phase • If project divided into phases, then each phase can be reflected with a dollar amount that needs to be allotted to that phase • Benefit : a company doesn’t need to allott all of the BAC at the project’s conception, but rather the initial amount required to set the project in motion, and an amount as each phase is completed • Advantage : • An entity can continue to use the capital earmarked for the project until the next phase of the project is ready to proceed • It allows everyone involved to get their arms around a project by looking at the costs of each phase of the project and then its grand total

  14. Budget Built from Zero Training = $12,900 Hardware = $38,900 Software = $47,000 Labor = $24,000 Zero at Genesis Zero-Based Budgeting • Budget to be created must always start at the number zero, rather than a dollar amount from a similar project, and then the new expenses factored in. • It forces you to ensure the cost of goods and services have not changed, and it they have to reflect the change in costs. • Creates a sense of accountability in regard to getting an accurate cost of the service and hardware to be purchased

  15. The Cost of Goods Factors to consider when allowing hardware to be assembled through the manufacturer: How long will the assembly take? What other tasks can the tehcnician do? Will the vendor guarantee the work? Is it worth the headache? Software Licensing Software licensing modes: Per station Per connection Per station (server based) Per usage Outsourcing Questions to consider outsourcing: Is it cost effective? Is it productive?Is the vendor reputable? Estimating Work Hours Time is the most difficult to predict, the hardest to manage, the easiest to lose control of Use the worst-and best-case scenarios for predicting team members’ time Determining Project Expenses

  16. Time Cost Worksheet

  17. Tracking Budgetary Expenses • Runaway projects : starts out well, gains speed, momentum, and scope, and then causes runaways with your budget, man hours, and possibly your reputation to career • Runaway project happen for several reasons: • Lack of planning • Lack of vision • Scope creep • Lack of Leadership • Keeping track of Expenses • Work hours • Purchased items • Software licensing • Workstations and servers

  18. Project Initiation First things we need to do is to define the Project including: • The company or organization name • The area, division, section or other organizational unit requesting the project • The individual who originated the project request • The date that the definition was drafted • The project sponsor – the person who will take overall business responsibility for project funding and success • A title for the project • A unique project code • The project goal (must clearly stated, preferably in one sentece) • Priority in terms of Quality, Cost and Time (Schedule) • Terms of Reference • The Business Deadline • Assumptions which have been made in the project definition and planning • The project budget should be specified in the form of a range and in resource units • Identify related projects • Moral, ethical and legal concerns or issues which must be addressed sensitively should be detailed to sensitize project members to their existence and ensure they are not overlooked

  19. Project Feasibility • Business issues • Feasibility from a business perspective can be judged in several ways, depending upon the organization culture and the type of project • Technical issues • Unstable, old technologies, which is no longer reliable • Performance of the old system may be inadequate to cope with business volumes, and the architecture may not allow an upgrade in the same environment • Time • There are tasks which cannot be shortened, regardless of how much we spend, or how many resources we apply • We must therefore check that the business deadline is feasible one, even if all the other project paramateres are acceptable

  20. Executive Summary Objectives Scope Possible Courses of Action Pro’s and Con’s Recommendations Decision Criteria Source and Reliability of Data Outline Requirements Alternatives Comparison of Alternatives Recommendations Alternative n Operational Attributes Economic Implications Technical Approach Risk Resource Implications Organizational Implications Feasibility Report

  21. Team Technology Profits Productivity Project Management Starting the Project • Gathering, Project Information • Seeking the clear vision • Possesing multiple personas • Interviewing management • Interviewing users • Defining the Project Goal • Establishing the Completion Date • Creating the Project Charter Project Managers must question all aspects of a project

  22. Project Charter Elements • Any information on the project that you’d like. Generally though: • Official Project name • Project sponsor and contact information • Project manager and contact information • Project goal • Business case for the project • The high-level results and deliverables of the project • General statement about how the team will approach the work • Basic timeline of when the work will be implemented • Project resources, budget, staff and vendors

  23. A WBS is made up of work tasks at the lowest level. It is a timeline and roadmap of each phase of the project. A WBS allow a project manager to dissect any project into smaller accesible parts A WBS consists of the project, phases, work units and tasks A phase is a portion of the project that typically must be completed before the next phase can begin (each phase has a set deadline). A work unit is a chunk of work that must be completed to ensure that the phase ends on schedule so the next phase can continue A task is the single unit of activity that collectively builds a work unit Project Scope Phases Work Units Tasks Defining Work Breakdown Structure

  24. Why You Need a WBS • A WBS defines the required work to complete the project • A WBS creates a sense of urgency • A WBS can prevent scope creep • A WBS provides control

  25. Creating a WBS • Top down • Approach uses deductive reasoning • starts with the general and moves to the very specific • requires more logic and structure, and is generally the preferred method for creating a WBS • Bottom up • moves from the very specific towards the general • ideal for brainstorming for a solution to a problem

  26. The Process of Creating a WBS • Determine what the project phases by asking these questions: • Are there logical partitions within this project (such as dates or activities?) • Are there identifiable milestones that could represent phases? • Are there business cycles within your organization that need to be considered during this project? • Are there financial obligations or restraints within this project that could signify phases?What factors within the company project life cycle will impact the project?What process are currently in place for system development within your organization?

  27. Work Breakdown Structure Task Estimated Duration Select Topic 2 weeks Locate Literature 8 weeks Draft Outline 1.5 weeks Write Draft 4 weeks Revise Draft 4 weeks Produce Final Copy 4 weeks

  28. Establishing Realistic Timetables(1) • Realistic project deadlines arise from facts of careful planning, facts gleaned from the research phase, and past experiences of the project team and the project manager • Avoid any change to the current project scope unless it is vital to the project implementation • Additional features should be delayed and rolled into a follow-up project after the current project’s deliverables have been met.

  29. Establishing Realistic Timetables (2) • Examine the Deliverables • Breakdown project into phases,each phases should also be deliverables that signify the end of phase and the start of another • Organization of Labor • Establishes confidence between the team member and the project manager • Establishes a sense of trust between the team member and the project manager • Allow the team member to realize his value to the project • Allows the team member to fully realize the commitment required by the project manager to the project’s success

  30. Presenting WBS to the Project Sponsor Explain any phase of the WBS to the sponsor Failure in creating the WBS does nothing to gain the confidence of your project sponsor and the project team Presenting to Management Presentation doesn’t need to go into great detail for each task represented within each phase Start at the deliverables of the project Working with Managers Confirms to a team member’s manager that the team member will be committing a set number of hours to the project Confirms to the project manager that the team member is involved in the project Confirms to the team member that her immediate manager and the project manager have met and have discussed her involvement with the project Assign a level of responsibility to the project manager for the number of hours delegated to the team member on the project Obtaining Management Approval

  31. Building the Project Plan • Defining the Project Schedules • Has definite set of deliverables that mark its end and also a finish date • Deadline-Oriented Projects • Working with units of time (hour,day, weeks, months etc) rather than specific dates for each tasks • Creating a Project Network Diagram • WBS decomposes the project into smaller, accessible work units (tasks) • Network Diagram demonstrate the relationships between tasks • Network Diagram provide detailed information on work units and allow project managers to analyze tasks, resources, and the allotted time for each task

  32. Gantt and Milestone Charts

  33. Network Diagrams • Detailed project planning • See the entire project plan from a high-level view, and then zoom in on a specific portion of the project plan • Implementation tracking • Illustrate impact on dependent task’s over time within the project and allow project manager to react to the changes by adjusting resources or other dependent tasks. • Contingency plans • Play out “what if” scenarion with any work unit within the project plan. • Resource control • Shows the flow of work and the impact of the finished task on the rest of the project

  34. Network Techniques • Task on Line Notation • Scaled Network Diagram • Predence Diagram

  35. Dependencies Between Tasks • Finish to start (FS) • Tasks are successors and cannot begin until the predecessor task is completed • Start to start(SS) • Tasks are usually closely related in nature and should be started but not necessarily completed at the same time • Finish to finish(FF) • Tasks require that predecessor task and the successor task be completed at the same time • Start to finish • Tasks require that the predecessor doesn’t begin until the successor finishes (could be used with accounting incidents)

  36. Boundary or limit based on the relationship between tasks Date constraints : avoid using specific dates for tasks unless it is absolutely required No earlier than No later than On this date Managerial Constraints Dependency relationships imposed because of a decision by management Technical Constraints Discretionary constraints Experience constraints Resource constraints Organizational Constraints There may be multiple projects that are loosely related The completion of another project may be a key milestone for your own project to continue. Implementing Project Constraints

  37. Building the Network Diagram • Are there adequate resources to complete the project? • Are the time estimations accurate? • Are there too many concurrent tasks? • Are resources spread too thin? • Is this a proven plan? • Is the plan realistic?

  38. Analyzing the Project Network Diagram • Find the critical path from Network Diagram • Critical path is the sequence of events that determine the project completion date • Adjust and readjust the critical path (schedule compression): • Analyze the critical path to move tasks earlier in the workflow • Consider relationships between tasks to change FS to SS • Identify tasks that require lag time and evaluate the predecessor task to move it earlier in the workflow • Consider any tasks and the level of acceptable risks by changing relationships types • Consider adding additional resources to tasks to shorten the duration required to complete tasks

  39. Critical Path Method Program Evaluation and Review Technique(PERT) optimistic time + 4 (most likely time) + pessimistic time 6 te = pessimistic time – optimistic time 6 SD= Critical Path Analysis

  40. The Completed Plan • Table of contents • Overview • Sponsors • Team members • Requirements • Scheduled tasks • Expected resources • Environmental issues • Business requirements • Implementation plans • Training plans