1 / 39

Project Planning The Basic Questions

Project Planning The 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?.

lotus
Download Presentation

Project Planning The Basic Questions

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related