- Focus on action. A project schedule is all about how deliverables will be produced. So after you break down work packages and deliverables, use active verbs to describe the smaller work tasks. For example, say "design webpage" instead of just "webpage designed."
- Keep tasks simple and compact. For a clear, clean project schedule, make task names short. If necessary, go into more details in an appendix or separate document to elaborate on each task and its outcomes.
- Create context. Also in a separate log, briefly document assumptions and constraints that accompany tasks. This helps in sequencing, linking and managing the tasks. For instance, if you know that a task needs to be executed in a certain timeframe, then you can better link, sequence or parallelize tasks.
- Diagram. A visual illustration of the task sequencing and relationship will help the team understand the task dependencies and anticipating when these dependencies should kick in. Additionally, a visual breakdown can help identify tasks that can be done in tandem (i.e., those that have no dependencies).
- Use the critical path. Apply information gleaned from the critical path to the schedule. The critical path is most helpful in monitoring delays or identifying opportunities to accelerate the schedule. If a task located on the critical path slips, the project can be delayed. If a task on the critical path can be shortened, the project schedule can get shorter. If the critical path's duration exceeds the project deadline, then reduce scope, reassess durations, improve estimates or increase team resources.
- Assess duration properly. When estimating task duration, distinguish between effort, duration and required calendar time to complete a task. The effort relates to the actual work required to complete the task (i.e., How many hours?). The duration refers to how many work periods are required to complete the effort (i.e., How many work days?). The required calendar time means mapping the work days on a calendar that includes holidays and vacation periods.
- Combine duration methods. Related to the sixth tip, combine multiple methods to assess duration. Take into account estimations from past projects and apply parametric estimation. For instance, if you use the three-point estimation (i.e., pessimistic, optimistic and most likely), find the theoretical estimation based on current expectations — but in addition, incorporate estimates from similar past tasks or projects.
- Plan. Identify which sources and resources will provide the project schedule information, such as the scope baseline, scheduling takeaways from similar previous projects and subject matter experts. Select the appropriate software tool to manage the schedule. This could be a standard project management tool used by your company, or it can be one you have selected considering your project's level of complexity, reporting automation needs and team collaboration requirements.
- Develop. Break down the work packages and deliverables into actionable tasks. Identify key milestones, such as completion of major deliverables or project phases. Sequence tasks logically, depending on their execution order and dependency on other tasks. Match team members to each task with their corresponding skills. Assess task efforts and all project time based on historical data from a similar project, or using techniques such as the Program Evaluation and Review Technique (PERT).
- Validate. Work with subject matter experts to review and validate the developing schedule.
- Follow through. After creating a baseline project schedule, track the completed tasks and achieved milestones. Developing a project schedule is not a final destination -- it has to be maintained.
- Adjust. You will rarely finish the project by following the exact schedule plan you began with. Adjust the schedule as you go by exploiting the opportunities that arise (such as fast-tracking activities or finishing work earlier, if possible), or taking corrective actions when faced with delays or unexpected activities (such as enlarging the team or "crashing" activities).
- Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
- Spreading deliverables across knowledge areas. Project teams organized by areas of expertise (such as operations, legal or finance) usually use this technique in their projects.
- Spreading deliverable across processes. This is typical for process-oriented projects.
- Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole.
- Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
- Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
- Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
- Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results.
- Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
- Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it.
It is quite rare that projects are conducted without time, scope and budget constraints. Most projects will likely need requirements prioritization.
Sometimes the prioritization process can lead to conflicts between the project beneficiaries. You might have to scope in requirements that address one person's needs, while de-scoping other requirements that address someone else's needs.
This five-step approach can help a project manager master requirements prioritization without getting into conflicting situations:
1. Prioritize as a common practice
Make it clear from the beginning that requirements prioritization is a common and required practice for any project that deals with constraints. Without prioritization, a constrained project could fail to reach its objectives.
2. Involve stakeholders
Not everyone on the project team should be involved in prioritizing requirements, but not involving the right people in this decision-making process could lead to project conflicts or missed project objectives.
The project's beneficiaries -- such as product owners, end-users or business departments -- should prioritize their own requirements. But project sponsors or organizations outside the project, such as legal departments, can be involved in your prioritization process.
3. Qualify requirements
Identify and apply key qualitative dimensions that support prioritization, such as priority, severity, urgency, complexity or mandatory requirements. Then identify and apply key quantitative dimensions, such as weight or grades.
Use numbers to reflect the possible grades for each qualitative dimension. For example:
- 0.1 = low
- 0.5 = medium
- 0.8 = high
- 1 = critical
- Factor 0.2 for complexity
- Factor 0.4 for priority
- Factor 0.7 for urgency
- Factor 1 for severity
Based on the qualitative and quantitative values, define a formula or matrix to apply when prioritizing requirements.
For example, a requirement with high severity will get a 0.8 rating (0.8 x 1) and will be prioritized ahead of a requirement with a high urgency (0.8 x 0.7= 0.56)
5. Document the approach
Document the prioritization approach in the requirements management plan as part of the project management plan. This leaves no room for interpretations, doubts or subjective biases during the prioritization process.
How do you prioritize requirements on your projects?
Brainstorming can be similarly effective and efficient when applied to solving challenges in a project. Project managers can gather the project team together and brainstorm for creative ways to address the issues.
In a brainstorming session, the project manager can take on the planner role, as well as the facilitator role.
As a planner, project managers might consider the following guidelines:
- Clearly outline the problem or the idea to be explored.
- Define basic ground rules, such as no criticizing, analyzing or judging ideas during the session. Criticism inhibits creativity. The ideas evaluation should be done at the end of the session.
- Depending on the complexity of the targeted problem or idea, plan the session with no more than five to 10 people. In a larger group, it's challenging for everyone to participate.
- When looking to develop new ideas or concepts, gather a mixed audience to gain a wider perspective. On the other hand, if looking to solve a problem, gather people from a focused or specialized group.
- Schedule sufficient time so that people won't feel constrained. Factor in time for breaks so that people can feel refreshed.
- Have someone capturing the generated ideas and the underlying notes.
- Plan the logistics such as use of flip charts, pin boards, snacks, etc.
- Create a relaxed atmosphere that stimulates creativity.
- Start the session with an icebreaker, a warm-up exercise or something funny.
- Allow open brainstorming but keep the focus on the initial idea or problem.
- Encourage everyone to participate and ensure a fair participation from each attendee.
- Accept all ideas positively and appraise them equally.
- Encourage people to be constructive, as well as to build on people's ideas.
- Keep the session unstructured and unconstrained.
On the contrary, mastering the project management basics is a prerequisite for project success.
PMI's 2012 Pulse of the Profession revealed that organizations that use basic, standardized project management practices have a 71 percent success rate, compared to the average success rate of 64 percent.
One of these basic pillar practices is taking the time to create a realistic implementation plan. But how do we build a comprehensive, yet realistic project implementation plan? Here are a few tips:
1. Start the project plan while keeping the final objective in focus. Write down and highlight why the project is being conducted and what the project objectives are.
2. Make sure that the project's requirements and overall project scope are clearly captured, along with the project deliverables and the given constraints.
3. Implement a well-defined change management process, agreed upon by all stakeholders. The Pulse report revealed that of the projects that used change management, 71 percent were successful.
4. Document the estimated project costs, the funding approach, how the actual costs will be monitored and how cost deviations will be handled.
5. Plan how project communication will be managed. Who are the project stakeholders? What are their project roles and responsibilities and how can they influence the project?
6. Do not underestimate the risks the project can encounter. The Pulse also showed that 72 percent of successful projects used risk management. Assess and document risks throughout the project and plan for mitigation and contingency approaches.
What role does project management basics and the project plan play on your projects?
To discuss Pulse of the Profession on Twitter, please use #pmipulse.
See more on the Pulse of the Profession.
A few creative group techniques allow a project manager to get the most out of a requirements workshop. They include mind mapping, brainstorming, affinity diagram, nominal group technique and Delphi technique. (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Chapter 5.1.)
The rigor, the number of applied techniques and the sequence in which these techniques are applied depend on the project's complexity, the workshop audience and the available time for gathering and prioritizing requirements.
Nevertheless, the following approach can be constructive and fruitful for collecting project requirements in a facilitated workshop:
1. Start gathering requirements by using the mind mapping technique.
Start with a topic, an issue or an area that you want to collect requirements for and develop ideas around it. Group the ideas visually, as a mind map, by writing down each idea and drawing how it relates to the initial topic. Ideally, you let anyone in the workshop create his or her own mind map.
2. Continue the process with a brainstorming session.
Allow anyone in the workshop to generate an unstructured requirements list for each idea captured on the mind map. To ensure that the brainstorming remains focused on the initial topic, lay basic ground rules and let anyone freely generate fresh ideas and requirements on the topic.
3. Use the list of unstructured ideas and requirements to build an affinity diagram, where your ideas are organized into groups based on their natural relationship. Let anyone in the workshop participate in organizing the items in the most natural group they can.
4. Identify the most important requirements by applying the nominal group technique. Allow each member or group in the workshop to identify which requirements are the most important for him or her. Rank each requirement on the affinity diagram with a priority: low, medium, high or from one to five. To avoid conflicts, facilitate an anonymous priority appraisal and ranking. Finally, tally the results and identify the most important requirements.
5. Close the process by running several rounds of independent feedback through the Delphi technique. Let any individual or group revise the list of requirements. Share an anonymous outcome from each review round and continue with further rounds, keeping in mind the objective to reach consensus and convergence.
Which of the group techniques are you using for collecting requirements? How do you apply them on your projects?
PMI Members: Learn more about mind mapping in our Knowledge Center.
Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements.
On the other hand, requirements that are clear, complete and understood by all the parties are of "high quality." They build a solid foundation for the project work.
Collecting high quality requirements can be a challenging endeavor for several reasons:
• Stakeholders often don't speak the same language (business vs. technical)
• Stakeholders have different understandings and views of the product
• Stakeholders have different backgrounds and expertise on the matter
It may not be the project manager's role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted.
The following guidelines should help in collecting high-quality project requirements:
1. No requirements without a use case
Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements' context and purpose.
2. Requirements language
Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently.
You might consider using a glossary of terms to ensure common understanding.
Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use "shall" or "must" instead of "should" or "might."
Remove any room for interpretation. Avoid the usage of "and/or" together or "including but not limited to."
3. Requirements characteristics checklist
Build a checklist of requirements characteristics that are relevant to your project's quality standards. Evaluate each requirement against the checklist.
Here are 10 characteristics that I successfully use to evaluate the quality of requirements:
Atomic: Is this a single requirement or multiple requirements in one?
Complete: Is this comprehensive enough to start working on it?
Traceable: Is this related to a use-case or need?
Logical and Clear: Does it make sense? Does it leave no room for interpretation?
Consistent: Is this consistent with the project objectives and other related requirements?
Measurable: Is this measurable once a solution is delivered?
Compliant: Is this aligned to the current product features, system architecture and legal framework?
Feasible: Is this realistic and doable given the complexity and the project context and constraints?
Necessary: Is this really required given the project objectives and constraints? Or is it more of a want than a need?
Prioritized: What are its criticality, urgency and priority?
What best practices do you use to ensure that project requirements are of high quality?
Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework.
Well-planned and well-managed project requirements are common characteristics of successful projects.
This simplified framework can be a guiding requirements checklist for project managers:
Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point.
Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements.
Categories: Identify and categorize the requirements types that are to be elicited, such as:
- Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
- Product requirements: Technical requirements, product features, functional requirements, etc.
- Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets.
Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals?
Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc.
Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.
Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process.
How are you planning and managing your project requirements?
See more posts from Marian.
See more on project planning.
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.
- Overview: Why the project is being conducted and its primary objectives
- Scope: Business needs, requirements, deliverables, constraints and work breakdown structure
- Schedule: Activities schedule and project milestones
- Costs: Project budget and its funding approach
- Quality: Quality measurement and control approach
- Project team: The people working on the project, their roles and responsibilities
- Communication: Communication type, channels and the reporting approach
- Risks: Risk index, methods to identify and evaluate risks, risk mitigation and contingency planning
- Procurements: Required procurements and purchase processes
- Closure: Closure approach, including the deliverables hand-off protocol
- Changes: Procedures used to track changes in the project
- Baselines: Scope, schedule and budget baselines
- The master document approach is where the entire project, with all the underlying planning details, is documented within the same master plan.
- The index approach, when all subsidiary planning documents are written as separated documents and linked or referenced in an index-like plan.
In my previous post, I offered five steps to assist in planning the project-planning phase. One of those steps involved preparing planning documents.
To foster a successful planning phase, here are seven planning documents I believe most project managers will find indispensable. This list certainly might vary depending on the project setup, project size, complexity and organizational planning guidelines.
1. Project management plan -- This is used as a reference index, encompassing all planning and project documents.
2. High-level project schedule plan -- This document captures high-level project phases and key milestones. It is the document most project stakeholders will see or want to see.
3. Project team planning -- This document provides a "who-is-doing-what" view of the project. This document fosters efficient project execution and effective project communication.
4. Scope plan -- The scope plan documents the project requirements, the agreed scope and the Requirements Traceability Matrix (RTM) summary.
5. Detailed project work plan -- This keeps track of the activities, work packages, resources, durations, costs, milestones, project's critical path, etc. It will be an essential document and work guideline for your core project team.
6. Quality assurance planning -- This document tracks the quality standards your project deliverables will have to align to. These may typically include product testing approach and tools, quality policies, quality checklists, deviations definitions, quality metrics, product defect severity grades, acceptance criteria, cost of poor quality, etc.
7. Risk planning -- This document contains the project risks and the related mitigation plans; as well as the project opportunities and the related exploiting plans. The importance of this document is one of the most underestimated in project planning. Be prepared to have a contingency plan in case something goes wrong or to take advantage of opportunities when they arise.
Start with this checklist when you sit down to plan for your next project-planning phase. Depending on your project's needs, fine tune the checklist and tailor it by adding and removing planning assets, determining the planning time frame, the underlying details and rigor.
Revisit this planning exercise, learn from it and enhance it, to continuously improve your project planning skills.
What project planning documents do you find indispensable?
See other posts from Marian.
Planning is not just a one-off activity completed in the early stages of a project. Planning is a process (or rather a group of processes), conducted throughout the project. And like every process, planning itself requires a plan and a setup, which defines the planning scope, details and deliverables.
So how do we plan the planning? Here is my five-step approach:
1. Decide on the project management methodology, framework or practice you will use on the project. Depending on the approach, you might require different planning styles, deliverables, details or rigor.
You might have to go ahead with a detailed planning process if you will use a waterfall approach. Conversely, you might have to keep the planning thin if you will use an agile approach, such as scrum. Or, your planning might be predefined and framed if you have to use your organization's proprietary methodology.
2. Plan project time for planning. In average, at least 10 percent of management time should be allocated to project planning.
3. Write down a checklist of all project documents you plan or need to deliver. The list will mostly depend on your project's complexity, organization and methodology. (More on this in my next post.)
4. Start planning early and continue planning throughout the project.
Some of the planning documents, such as the high-level schedule or scoping documents, might have to be kept frozen upon sign-off. Other documents, such as the risk management planning or rollout planning, will typically require updating as the project progresses.
5. Continuously improve your planning.
Improve planning by communicating the planning outcome with your project team and by collecting their feedback regarding your planning performance. You can use this feedback for continuous planning improvement.
As the project progresses, keep a log of your planning issues to track gaps you encounter along the way. This is the "planning lessons-learned" document that you can also use for continuous improvement.
What do you think? How do you plan for project planning?
See more on project planning.