In my previous posts, I laid out the basics, the framework and the key documents for planning a project end-to-end. Now it's time to dive deeper.
One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project.
Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units.
The building blocks of project work planning have four main steps:
The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information.
Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs.
The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries.
The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project.
Do you agree with these steps? How many steps do you use for project work planning?
Read more posts from Marian Haus.
One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project.
Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units.
The building blocks of project work planning have four main steps:
- Collect the project requirements
- Facilitate a requirements workshop
- Define the project scope
- Break down the work in small work units
The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information.
Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs.
The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries.
The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project.
Do you agree with these steps? How many steps do you use for project work planning?
Read more posts from Marian Haus.
For me, project planning starts with the "why" rather than the "what". It's not the responsibility of the PM to define a project's reason(s) for being; but business drivers, problem to be solved, benefits to be realised, objectives and outcomes are what should drive the project planning process.
Project planning also requires at least an element of technical exploration: proofs of concepts, vertical slices of architecture, targeted work on non-functionals and other high-risk areas. A risk-based architecture-first approach.
And finally, build-in iterations to elaborate and refine these plans. Even at the very outset, planning is not a one-time activity.
Enjoyed the post. Thanks.
I completely agree with the steps, yet have concerns with premise that it is the PM who has sole responsibility for this role. Just as PMs have struggled for years to have the PM profession taken seriously, now business analysts (BAs) are in the same position.
PMs do have responsibility to facilitate planning, execution, and control of requirements processes. However, they should rely on the expertise of a business analyst to conduct the activities.
A PM acting in the BA role compares to acting in the QA or development roles. There may be some projects where combining of roles makes sense, but this should be the exception rather than the rule. A true collaborative relationship between the PM and BA will yield the best results for achieving business value.
The International Institute of Business Analysis has their own BA Body of Knowledge and certification that is on par with PMI's own. The business practices described agree with this article but the processes and tools to support business analysis, requirements, and solution verification are much more in depth. Please visit www.iiba.org for more information.
I look forward to the day when PMs and BAs work collaboratively in establishing and communicating project best practices.
Vicki James, PMP, CBAP
project-pro.us
@VickiPPS