Project Planning The Basic Questions - PowerPoint PPT Presentation

lotus
project planning the basic questions n.
Skip this Video
Loading SlideShow in 5 Seconds..
Project Planning The Basic Questions PowerPoint Presentation
Download Presentation
Project Planning The Basic Questions

play fullscreen
1 / 39
Download Presentation
Project Planning The Basic Questions
408 Views
Download Presentation

Project Planning The Basic Questions

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

  1. Project PlanningThe Basic Questions • Questions too ask before planning • What is the managers role in Planning? • Who is the author and how involved is the team? • Combining the efforts of the Project Team. • What is covered by Planning? • When do we begin Planning? • When do we stop Planning? Computer Engineering 203 R Smith Project Planning 1/2009

  2. The Project Survival test and why is it important? • The test focuses attention on those elements of project planning identified as classic mistakes. • Management has the responsibility to guide the project away from making the classic mistakes. Computer Engineering 203 R Smith Project Planning 1/2009

  3. A Survival Test • Requirements • Is there a vision and does the team view it as realistic? • Where is the project going and what are you delivering to the customer? • Does the project have documented, clear, unambiguous and complete requirements? • Does the project team have access to the customer? Computer Engineering 203 R Smith Project Planning 1/2009

  4. A Survival Test • Planning • Does the project have a detailed, written Software Development plan? • Was the plan updated at the completion of the last project phase? • Does the project have a quality plan? • How is quality defined for this project? • Are the projects resources allocated at 100%? • Was the plan approved by all the stakeholders? Computer Engineering 203 R Smith Project Planning 1/2009

  5. A Survival Test • Project Control • Are resources allocated to manage the project? • Does the project have well-defined binary milestones? • Does the project have a documented change control plan? • Risk Management • Does the project have a written risk management plan? • Does the project have a written change control plan? Computer Engineering 203 R Smith Project Planning 1/2009

  6. The Relationship between Process and Planning • Without some process effort is wasted in thrashing. • Planning not only helps define the project and the resources needed to complete the project, but it defines what processes will be used. • The key is to plan for only the minimum amount of process needed, but this requires understanding your project. Computer Engineering 203 R Smith Project Planning 1/2009

  7. When does Project Planning begin? • Some level of planning needs to occur as soon as resources are working on the project. • Early planning is intended to get answers to the following questions: • How long will the requirements process take? • How will requirements be gathered? • Who needs to be involved? • Preliminary estimates are needed to assure that requirements are realistic. Computer Engineering 203 R Smith Project Planning 1/2009

  8. When does Project Planning end? • Have all steps been completed? • Has the product been delivered? • Is it being supported? • Can it be ordered? • Have you recorded what can be learned from the project? Computer Engineering 203 R Smith Project Planning 1/2009

  9. Project Planning the Traditional View • Project management is concerned with planning and allocating resources to ensure the delivery of quality software systems on time and within budget. • Project communications • Project organization • Estimating resources required • What processes are used Computer Engineering 203 R Smith Project Planning 1/2009

  10. Project Planning the Traditional View • Determining the schedule • Ensuring the completeness and correctness of requirements • Tracking progress • Determining the project’s lifecycle • Identifying and managing risks • Ensuring that the product has a correct design • Ensuring delivery of a quality product • Controlling change Computer Engineering 203 R Smith Project Planning 1/2009

  11. Software Project Plan as a communications tool • The software project plan identifies all stakeholders for the project and their relationship to the project. • The software project plan serves as a repository of project information. • The software project plan informs all stakeholders what is expected of them and what they can expect of others. Computer Engineering 203 R Smith Project Planning 1/2009

  12. The relationship between project planning and the project plan • Project planning and the project plan serve have different objectives • Project planning is a series of steps that establishes what we intend to do. • The Project Plan documents the results of the planning process for all stakeholders. Computer Engineering 203 R Smith Project Planning 1/2009

  13. SPP as a communications tool • It is critical to inform others of their roles and expected timeframes for their participation. • Software Publications • Peer Development groups • Support • Sales Computer Engineering 203 R Smith Project Planning 1/2009

  14. SPP as a communications tool • As a communications tool the SPP can only be effective if it reflects the current state of the planning process. • Therefore since project planning is dynamic the SPP also must be dynamic to remain current. Computer Engineering 203 R Smith Project Planning 1/2009

  15. Project size and scope affect the planning and process needed. • Number of communications interfaces • Number of locations • Project length • Project control direct or influence? • Who does decide • What does it take to make a decision Computer Engineering 203 R Smith Project Planning 1/2009

  16. Core Teams and Their Role in Project Planning • Core Teams provide input from peer and support groups. • Core Teams spread the responsibility among major stakeholders. • Core Teams facilitate communications. • Core Teams spread ownership. Computer Engineering 203 R Smith Project Planning 1/2009

  17. Sample Project Plan template • Introduction and project scope • Project stakeholders and organization • Project requirements • Resource estimates • Project technical lifecycle • Project schedule • Technical description and software design Computer Engineering 203 R Smith Project Planning 1/2009

  18. Sample Project Plan template • Project standards and procedures • Development processes used • Review process • Change control boards • Quality Plan • Test plan • Documentation plan • Risk management plan Computer Engineering 203 R Smith Project Planning 1/2009

  19. Sample Project Plan template • Training and support plans • Configuration management plan • Communications plan Computer Engineering 203 R Smith Project Planning 1/2009

  20. SPP notes • It is better to list topics and say no action is required rather than to not list a topic and have the reader wonder if it was just ignored. • SPPs are dynamic • There must always be a discrepancy between concepts and reality, because the former are static and the latter is dynamic and flowing. • Plans need to change to reflect actions taken to correct problems. • Reference other documents rather than repeating the information. Computer Engineering 203 R Smith Project Planning 1/2009

  21. Project Phases • Project initiation, creating the plan • Definition and requirements • Identify stakeholders and project organization • Initial project design and resource estimates • Communications plan and project infrastructure • Iterate on the initial steps until a working plan is ready Computer Engineering 203 R Smith Project Planning 1/2009

  22. Project Phases • Steady state, following the plan • Status monitoring • Project tracking • Risk assessment • Periodic replanning and estimation • Project development Computer Engineering 203 R Smith Project Planning 1/2009

  23. Project Phases • Project completion, final wrap up • Release readiness • Installation • Training and support • Postmortem • Learning from experience Computer Engineering 203 R Smith Project Planning 1/2009

  24. Project Life Cycle • Business lifecycle versus technical lifecycle • A business lifecycle generally follows a funding model and only flows in one direction. • You can not unspend money that has already been spent. • Technical lifecycles are much more dynamic and allow for decisions to be changed and rework as more information becomes available. • Lifecycles for Software Projects differ greatly from the lifecycles of other types of projects. Computer Engineering 203 R Smith Project Planning 1/2009

  25. Project Lifecycle Models • Waterfall • Waterfall variants • SCRUM • Spiral model • Sawtooth/Shark Tooth Model • Unified Software Development Model • Staged Delivery • Extreme Programming Computer Engineering 203 R Smith Project Planning 1/2009

  26. Why is the Technical Lifecycle Important and how is it different from the Business Model? • The Business Model follows a budget flow, but it does not typically follow the flow of work products. • The Technical Lifecycle communicates to everyone how the development will progress. • Is changed expected? • Will earlier decisions be revisited? Computer Engineering 203 R Smith Project Planning 1/2009

  27. Waterfall Model • Classic development model that parallels a typical business lifecycle. • All stages flow forward, rework is not expected. • Stages • Concept • Requirements Analysis Computer Engineering 203 R Smith Project Planning 1/2009

  28. Waterfall Model • Architectural design • Detailed design • Coding and Debugging • System test • Does not work when change is expected. • Requirements change • Changes in the project environment Computer Engineering 203 R Smith Project Planning 1/2009

  29. Waterfall Model • On real projects often you complete some phase under the Waterfall Model only to realize later the need to go back and redo phases. • This often has a major impact on management who believed that once something is complete it is done. Computer Engineering 203 R Smith Project Planning 1/2009

  30. Spiral Model • The need to define “risk” • Poorly understood requirements • Performance issues • New technology • Incomplete design • Basic cycle • Determine objectives Computer Engineering 203 R Smith Project Planning 1/2009

  31. Spiral • Identify and resolve risks • Evaluate alternatives • Develop and verify deliverables for this iteration • Plan next iteration • The key is to know when to stop the spiral and complete the project • Iterations do not produce customer deliverables • Project management is more important than in other models. Computer Engineering 203 R Smith Project Planning 1/2009

  32. Extreme Programming • Development methodology that stresses customer involvement. • Methodology that plans and designs only near term deliverables • Stress refactoring of previous work. Computer Engineering 203 R Smith Project Planning 1/2009

  33. Choosing the correct Lifecycle • Staff factors • Level of experience • Willingness to accept change • Business factors • Critical constraints • Senior management • Willingness to trust and live with uncertainty Computer Engineering 203 R Smith Project Planning 1/2009

  34. Choosing the correct Lifecycle • Technical factors • Maturity of the technology • Completeness of the requirements • Risk factors • Customer factors • Involvement • Willingness to expend resources Computer Engineering 203 R Smith Project Planning 1/2009

  35. Project Change Control • Why is it needed? • How much is needed? • Typical ways to implement Computer Engineering 203 R Smith Project Planning 1/2009

  36. Why Change Control • Knowing what you will deliver • Being able to get agreement and inform everyone when changes are made. • Controlling resources • Commitments are made with knowledge of the consequences. • Making sure all pieces integrate together Computer Engineering 203 R Smith Project Planning 1/2009

  37. How much change control is needed? • Not all elements of the project need the same level of control. • Requirements • Features to be tested • Features to be documented • Design Computer Engineering 203 R Smith Project Planning 1/2009

  38. Change Control Boards • One board or many • Focus on areas of interest • Availability of resources • Knowledge base • Document Decisions • Inform stakeholders Computer Engineering 203 R Smith Project Planning 1/2009

  39. The Role of MOV • Most projects that first time project managers are responsible for have a well defined MOV, their value is generally unquestioned. • As project managers become more experienced they will need to define the MOV for their projects. • What an project manager never wants is a project that has an unrecognized MOV. Computer Engineering 203 R Smith Project Planning 1/2009