- What is Project planning?
- What is involved in Project Planning?
- Planning Processes and Outputs for Project Integration and Scope Management
- Project Integration Management
- Project Scope Management
What is Project planning?
- Project planning is a discipline addressing how to complete a project in a certain timeframe, usually with defined stages and designated resources.
- After a project is initiated, it goes into the Planning stage.
- One view of project planning divides the activity into these steps:
- setting measurable objectives
- identifying deliverables
- scheduling
- planning tasks
Project Planning Should Guide Project Execution:
- Planning is often the most challenging and unappreciated process in project management
- Often, people do not want to take the time to plan well, but theory and practice show that good planning is * *crucial** to good execution
- The main purpose of project planning is to guide project execution, so project plans must be realistic and useful.
What is involved in Project Planning?
- Planning starts with the scope where it is decided what needs to be done.
- It is followed by time planning where we decide how we will deliver the scope and how much time that would take.
- Then we estimate the detailed cost of the project work which is followed by planning quality, human resource and communication requirements.
- The various risks on the project are identified and managed
- Finally, procurement documents are created in case the project requires the purchase of products or services from outside vendors/suppliers/sub-contractors.
Planning Processes and Outputs for Project Integration and Scope Management
| Knowledge area | Planning process | Outputs |
|---|---|---|
| Project integration management | Develop project management plan | Project management plan |
| Project scope management | Plan scope management Collect requirements Define scope Create WBS |
Scope management plan Requirements management plan Requirements documentation Requirements traceability matrix Project scope statement Project documents updates Scope baseline Project documents updates |
Project Integration Management
- Project integration management involves coordinating all the project management knowledge areas throughout a project’s life span
- The main planning output is a project management plan
Project Management Plans
- A project management plan is a document used to integrate and coordinate all project planning documents and to help guide a project’s execution, monitoring and control, and closure
- Plans created in the other knowledge areas are subsidiary parts of the overall project management plan and provide more detailed information about that knowledge area
- Project management plans facilitate communication among stakeholders and provide a baseline for progress measurement and project control
- A baseline is a starting point, a measurement, or an observation that is documented so that it can be used for future comparison
Attributes of Project Management Plans
- Project management plans should be dynamic, flexible, and receptive to change when the environment or project changes
- Just as projects are unique, so are project plans.
- For a small project involving a few people over a couple of months, a project charter, team contract, scope statement, and Gantt chart might be the only project planning documents needed; there would not be a need for a separate project management plan
- A large project involving 100 people over three years would benefit from having a detailed project management plan and separate plans for each knowledge area
- It is important to tailor all planning documentation to fit the needs of specific projects
Common Elements in Project Management Plans
- Introduction/overview of the project
- Project organisation
- Management and technical processes (including project lifecycle description and development approach, as applicable)
- Work to be performed (scope)
- Schedule information
- Budget information
- References to other project planning documents
Project Scope Management
Scope Planning
- In order for us to deliver a project, the first and the most important thing to know is what the scope of the product is.
- The product scope includes the features and characteristics of the product.
- Scope Planning is one of the most critical areas because all the other aspects of planning depend on it.
- If some scope is missed out or defined incorrectly or ambiguously, then the entire plan could be incorrect and may have to be redone later on. This could lead to huge time and cost overruns in the project.
Project Context of Scope Planning
- Scope planning is one area that might work differently for different kinds of projects.
- Some projects are simply given a business case or a project charter with high-level requirements, and the detailed scope is planned later.
- Some other projects are won through competitive bidding. In such projects, the detailed scope is already produced before the project is given to a contractor.
- In IT project, the customer usually issues an overview of the project and expects the solution provider to do the entire scope planning.
Requirements Gathering
- Once the project charter has been issued and stakeholders have been identified, the next step is gathering of requirements.
- Requirements may be gathered either by visiting the customer premises, over emails, over phone, or various other means.
- This will obviously require project resources.
- How the requirements will be gathered, and which templates will be used is defined in the project plan.
Project Scope Statement
- Once the requirements have been collected and documented, we need to finalize the scope.
- This is done using a scope statement.
- A project scope statement describes product characteristics and requirements, user acceptance criteria, and deliverables.
- Work not included in the scope statement should not be done, and you can explicitly state what is out of scope for the project under a section called project exclusions.
Structure of Project Scope Statement
- Product Scope Description
- Detailed description of the characteristics of the product of the project
- Project Deliverables
- Detailed list of the various things that the project will deliver
- Product Acceptance Criteria
- The measurable characteristics/tests that need to be fulfilled/passed to accept the product of the project
- Project Exclusions
- List of items not included in the project scope (for purposes of clarity)
- Project Constraints
- Detailed list of constraints that need to be kept in mind while managing the project
- Includes schedule, cost, resources, technology, quality and other expectations that limit the project manager’s options
- Project Assumptions
- All assumptions made during scope planning that need to be shared with all stakeholders to get them on the same page and for their buy-in
An Example of Project Scope Statement
- Product Description
- The product of the project is a website that provides access to potential and existing customers. It gives company details, description of the company’s products and services etc.
- Project Deliverables
- Website opening with the Home Page showing a video file
- “About Us” page
- Login functions - Create, login, logout, view/edit profile
- Pages showing additional information about the company after login
- Product Acceptance Criteria
- All pages of the website should open without any error in IE 6.0 and Mozilla 11.0.
- Some pages that require login should only open after user logs in.
- Users should be able to manage their login online - creation, update.
- Al pages should open within 5 seconds of clicking on the hyperlink for the page.
- The website should be able to support at least100 concurrent users.
- The website uptime is guaranteed to be at least 99.9%.This will be verified over a 1week period by giving it maximum load.
- Project Exclusions
- This project will only provide the development of the new website.
- Regular maintenance work of the website is not included in this scope.
- No ongoing support would be provided within the scope of the project once the project has been signed-off.
- All hardware and software procurements are out of scope of this project. They are to be provided separately by the customer on their premises
- Project Assumptions & Constraints
- Customers will provide all required hardware and software licenses to develop and host the website.
- The project will use open-source software, wherever possible, in order to keep the total development and operational cost low.
- No automated load testing will be performed. The customer agrees to provide several users for manual load testing.
Work Breakdown Structure (WBS)
- Once the scope has been finalised in the scope statement, it then needs to be well understood, estimated, allocated, and monitored by the project team.
- This can only be done by breaking it down into smaller, more manageable pieces of work.
- Such a process of decomposing scope creates a hierarchical structure called Work Breakdown Structure (WBS).
- The WBS is a document that breaks all the work required for the project into discrete deliverables, also called work packages and groups them into a logical hierarchy, su.ch as tasks and subtasks.
How to create a work breakdown structure
- Define the scope and objectives. Record the overarching objective you are trying to accomplish.
- This objective could be anything from developing a new software feature to building a complex product.
- Document these details in your project charter. This will be your guiding reference.
- Break it down into key phases and deliverables.
- Depending on the nature of your project, start dividing by project phases, specific large deliverables, or sub-tasks.
- Divide the overarching project into smaller and smaller pieces but stop before you get to the point of listing out every action that must be taken.
- Remember to focus on concrete deliverables rather than actions.
- Organize deliverables into work packages.
- Break down each major deliverable into all the tasks and subtasks required to complete them.
- Organize the subtasks into work packages. Work packages, sometimes are called Deliverables are the lowest level of the breakdown and should define the work, duration, and costs for each task, as well task owners.
- Each work package should provide assignments that can be completed within a reporting period.
WBS Hierarchy
WBS is an outcome-focused tool for determining all deliverables and tasks required for a project.
Tips for making a work breakdown structure
As you make a work breakdown structure, use the following rules for best results:
- The 100% rule: The work represented by your WBS must include 100% of the work necessary to complete the overarching goal without including any extraneous or unrelated work.
- Also, child tasks on any level must account for all the work necessary to complete the parent task.
- Mutually exclusive: Do not include a subtask twice or account for any amount of work twice.
- Otherwise, it would violate the 100% rule and will result in miscalculations as you try to determine the resources necessary to complete a project.
- Outcomes, not actions: Remember to focus on deliverables and outcomes rather than actions.
- For example, if you were building a bike, a deliverable might be “the braking system” while actions would include “calibrate the brake pads”.
- The 8/80 rule: There are several ways to decide when a work package is small enough without being too small.
- This rule is one of the most common suggestions: a work package should take no less than 8 hours of effort, but no more than 80.
- Other rules suggest no more than ten days (which is the same as 80 hours if you work full time) or no more than a standard reporting period. In other words, if you report on your work every month, a work package should take no more than a month to complete.
- Three levels: Generally speaking, a WBS should include about three levels of detail.
- Some branches of the WBS will be more subdivided than others, but if most branches have about three levels, the scope of your project and the level of detail in your WBS are about right.
- Make assignments: Every work package should be assigned to a specific team or individual.
- If you have made your WBS well, there will be no work overlap so responsibilities will be clear.
Examples of WBS
WBS for the Website Development
WBS for Building a House
More Examples: Free WBS examples
- If you look closely at the WBS examples shown, you will notice that there are no verbs, as verbs represent action, and a WBS is not about action, but rather about deliverables.
- As the definition of a WBS has fluctuated over the decades, sometimes you may still come across a definition that shows activities on the WBS.
- However, it is incorrect to show activities on the WBS, according to PMI, so try to consistently use deliverables on your WBS. — Activities should be shown on the schedule and not on the WBS itself.
Creating a Good WBS
- It is challenging to create a good WBS
- The project manager and the project team must decide as a group how to organise the work and how many levels to include in the WBS
- It is often better to focus on getting the top levels of the WBS done well to avoid being distracted by too much detail
- Many people confuse tasks on a WBS with specifications or think it must reflect a sequential list of steps
- You should focus on what work needs to be delivered, not when or exactly how it will be done
WBS dictionary
At the bottom-most level of the WBS we have work packages. A project usually has several work packages, and, hence, it might be difficult to remember the description of each work package for future reference. Hence, a one-page document is generally maintained to capture the description of each work package. This is called a WBS dictionary. It may contain anything the project manager wishes to document about each work package.
