Project Planning What The process of defining preparing

Project Planning - What The process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan. a central document that defines the basis of all project work

Project Planning – What • • • What is in scope What is out of scope Tasks to complete (WBD) The schedule The budget The risks • How project changes will be managed • Plan for communications throughout the project • Team roles and stakeholders

Project Planning - When At the beginning of the project, but then the “plan” is continually updated as changes happen in your project. As phases end and new ones begin, you may work through more planning.

Project Planning - Why https: //projectmanagementaca demy. net/articles/images/Proce ss-Groups. png

Project Planning - How • Analysis tools • SWOT • Quantitative and Qualitative Risk Analysis • Meetings and Conversation • Facilitation technique to elicit responses • Scheduling techniques • Estimating techniques

Project Planning Tools - PMWG Project Management Plan: https: //wikispaces. psu. edu/display/ITSPMWG/Project +Management+Plan Project Management Plan Templates: https: //wikispaces. psu. edu/display/ITSPMWG/P roject+Management+Templates+and+Information

Undercover Project Planning ELISHA BARONE, PMP PROJECT MANAGER, HUMAN RESOURCES

Give them everything they knew they needed but never wanted… (without them really knowing).

Planning is a Conversation What are the big chunks of work for this project? ◦ WBS Work Packages Fill in the details for each chunk of work. ◦ Work Packages Activities Ask leading questions and clarifying questions. Create a project schedule (i. e. project plan), review as a team, update, obtain verbal buy-in.

Don’t forget to… Lose the PM-speak Build strong relationships Pick and choose your battles

Plan Business Analysis Approach The purpose of Plan Business Analysis Approach is to define an appropriate method to conduct business analysis activities. • Planning Approach (predictive vs. adaptive) • Formality and Level of Detail of Business Analysis Deliverables • Business Analysis Activities • Timing of Business Analysis Work • Complexity and Risk • Acceptance (Who needs to review and agree to the planned approach? )

Plan Stakeholder Engagement Approach The purpose of Plan Stakeholder Engagement is to plan an approach for establishing and maintaining effective working relationships with the stakeholders. • Perform Stakeholder Analysis • Define Stakeholder Collaboration • Stakeholder Communication Needs

Plan Business Analysis Governance The purpose of Plan Business Analysis Governance is to define how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization. • Decision Making • Change Control Process • Plan Prioritization Approach (for requirements and designs) • Plan for Approvals

Plan Business Analysis Information Mgmt The purpose of Plan Business Analysis Information Management is to develop an approach for how business analysis information will be stored and accessed. • Organization of Business Analysis Information • Level of Abstraction • Plan Traceability Approach • Plan for Requirements Reuse • Storage and Access • Requirements Attributes

Requirements Classification Schema Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative. Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements. > > Need to be communicated and validated with sponsor and stakeholders Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development an implementation of BA translates and adapts for audience the solution. Solution requirements can be divided into two sub-categories: ◦ functional requirements: describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage, and Need to be ◦ non-functional requirements or quality of service requirements: do not relate directly to the behavior of communicated functionality of the solution, but rather describe conditions under which a solution must remain effective or and validated qualities that a solution must have. Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity. with solution team, QA, OIT, and training