- First day: Devote the morning only to the human elements of the project -- for example, for introductions and team integration activities. It'll set the stage for the rest of the workshop. In the afternoon, analyze the project background and produce a thorough project charter that includes scope statement, time and cost constraints, major deliverables, key stakeholders, expected benefits, restrictions and assumptions.
- Second day: In the morning, develop the work breakdown structure (WBS). Make the whole team work on defining the major deliverables and then break into smaller groups to further decompose these major deliverables. Produce the project's schedule in the afternoon.
- Third day: The planning elements needed for your project might vary, but I usually devote this day to producing the budget, a roles and responsibilities matrix (mapping the team members to work packages on the WBS), a key resources plan and a risk management plan.
More posts in Project Planning
- Develop the schedule.
- Consider work tasks, dependencies and constraints.
- Identify the critical path of your project schedule.
- Allocate resources.
- Resource leveling, to be used when you have resource constraints or are aiming for more efficient and effective resources utilization
- Schedule crashing, for reducing tasks' duration by applying multiple or better resources to the same tasks
- Fast-tracking, to reduce the project duration by overlapping tasks that otherwise would have been sequential and dependent on one another
- What is due?
- When is it due?
- Funding. A low budget usually means a small work effort is expected. A higher budget will allow for more effort and charge-outs. This means you may become responsible for purchases and expenses that will require an authorization above and beyond your own.
- Resources. If your project involves other people or outside vendors, you need to consider whom you may need to retrieve something from. For example, if data is required to get the work done, factor this into the project's effort. Your timing to receive it and the timing you will need to respond to what you receive is important. Global projects and virtual teams as well as a geographical scope require technology advances. So remember to factor in costs for equipment, connections and any possible barriers that need to be handled.
- Known risks and issues. These put a constraint on timing. So, being aware of when the project is due will most likely dictate if a certain task can be done in a certain timeframe and if something else can be pushed slightly to another timeframe. Be cognizant that unknown risks and issues could cause further problems and delays.
- Lessons learned. Previous lessons learned provide information on how other projects with similar indicators fared.
- Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
- Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them.
- Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase.
- Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need.
- Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources.
- Design the work plan around the core outcome of the project. In my haste to become adept with a work-planning tool, I neglected to consider the project's core outcome -- and how it would be delivered. Before starting to build a work plan, you need to determine whether the project's primary outcome depends on the completion of tasks, orchestration of resources or creation of certain deliverables. For example, if the project objective is to implement a newly defined process across multiple teams, consider organizing the work plan around teams and their needs.
- A project's complexity can affect your progress-tracking method. A classic mistake project managers make is employing a progress-tracking method that's not in sync with the complexity of the project. In my experience, projects with low complexity, for example, are better served with a straightforward percent-complete scheme. But I have noticed that a project with added complexity (i.e., interfaces, dependencies, resource mix) requires a more robust tracking method, such as earned value, to ensure a precise measurement of progress. Aligning the progress-tracking method to the complexity of the project also helps you avoid unnecessary effort in reporting project progress.
- Capture and use resource commitments. The senior project manager who advised me could not say enough about the benefits of this. She observed that by not accurately capturing to what degree resources were dedicated to my project, I was creating an overly optimistic project schedule. And my project was running late as a result.
- Aligning project stages and deliverables depending on their interrelated dependencies
- Reaching agreements and locking down commitments for respective conditions, such as the quality of deliverables, meeting deadlines required for the touch points between projects
- Sharing risks and planning required measures together, in case one project negatively impacts the other
- The silo approach: Avoid developing the schedule in "silo" mode -- that is, without input from key stakeholders or subject-matter experts that can validate and confirm the schedule's content.
- Inappropriate tasks decomposition: When decomposing work in tasks, avoid an overly detailed decomposition or under detailed decomposition. In my experience, each task should not be shorter than two days and not longer than two reporting periods (typically two weeks). A task of this length is generally explicit, focused, actionable, assignable and traceable.
- Too many milestones: Limit milestones to significant project events or decisions -- for example, the project start, completion of major deliverables or phases and the project's end.
- Overly ambitious schedule: Everyone wants to please the customer, but an aggressive schedule can have the opposite effect if unrealistic deadlines are continually missed. Instead, aim to exceed expectations by delivering the project in a realistic timeframe, with solid execution. If you inherit an overly ambitious schedule, you could "fast-track" (i.e., make work parallel) or "crash" the schedule by assigning more resources to reduce task duration.
- Loops: A project schedule is not a flowchart, and time cannot flow in reverse. Therefore, loops, a circular task dependency, are not possible or validated by most project management scheduling software. Do not confuse loops with iterations. Iterations of tasks --such as design, implement and deploy -- are allowed on a project schedule.
- Danglers: These are the dependency links between tasks. Only one task will have no predecessor (the project start task) and only one will have no successor (the project end task). All the other tasks should have a successor and predecessor.
- Confusing tasks efforts with schedule time: Don't just ask team members: "When can you complete this task?" Instead, ask for the estimated effort to complete the task in labor hours or days. Then, transform the effort into work periods (the work days the team member can carry out the task) and map this to the project calendar (considering business days, holidays and vacation periods).
- Allocating schedule buffer instead of effort buffer: Don't allocate buffers to a certain schedule time. Task estimation is a three-step process: effort, duration and required calendar time. Allocate buffers primarily on a task's effort and not on the overall required calendar time.
- Depending on overall buffers: Avoid relying on sweeping buffers, like the classic "20 percent." When assigning buffers, consider the project-specific risks (for example, unfamiliar technologies), the experience of the project team and non-project related factors, such as resources allocated to parallel projects or team members' involvement in non-project activities.
- Wrong tasks on the critical path: Project management tasks, effort estimation tasks and other schedule planning activities should not be located on the critical path. They have nothing to do with the actual project work tasks.
- Secure executive support for major issues. Initial project documentation, such as a project charter and communications plan, will classify your project sponsors and champions, their roles and responsibilities, and escalation procedures. Rely on that, but also position yourself for frequent project status meetings with executives.
- Keep communications with sponsors and key stakeholders at a level that allows you to reach out to them when you may need them.
- Be aware of your project environment at all times. Regularly review project plans against where you are and what's planned to come. It will help minimize the risk of an issue arising when you least expect it — a resource pushed to the point of no return, for example.
- Look for lessons learned. Review the project history for potential concerns you may want to monitor and document in your risk log. Meet with other project managers in and outside of your organization to learn about pitfalls they may have encountered and how they handled them.
- 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.
- Stoplights are not progressive. Project stoplights typically have only three indications of status. They can't show a range of progressive tolerance, trends or rates of change. For example, a yellow stoplight can be overly optimistic if the value for that stoplight is just shy of the range for red.
- Stoplight bands mean different things to different measurements. Stoplights break down into bands of tolerance ranges. For example, zero to 5 percent variance would be green, 5 to 10 percent variance would be yellow and above 10 percent would be red. The problem is, project measurement indicators might not follow a common range. For example, how realistic is it to measure customer satisfaction with the same band as test case validation? While test case validation might make sense at 7 percent, it would be discouraging if just 7 percent of your customers were happy with your project.
- Stoplights can be "gamed." A major vulnerability of project stoplights is that they can be manipulated by project managers and sponsors when either wants to defer an unfavorable status. Despite the actual value of the project measurement, the project manager or sponsor will leave the stoplight to a green (favorable) value. This "gaming" of project stoplights usually precedes the inevitable -- rapid acceleration of stoplights to a red (danger) value when hidden details are discovered.
- 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.
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.
During the summer, for example, temperatures can reach as high as 122 degrees Fahrenheit (50 degrees Celsius).
Project managers working with or in the Muslim world also need to plan for Ramadan, when the majority of the population fasts between sunrise and sunset. Then there's Eid al-Fitr, a national holiday that marks the end of Ramadan. Its importance is similar in scale to Christmas or Yom Kippur.
These combined events mean project managers must plan meticulously to ensure minimum disruption to their project schedules.
During this one month, the expected impact on the construction sector alone is a reduction of productivity by 40 to 60 percent. The main causes are heat and a fasting workforce that is unable to work at full capacity.
Additionally, project managers in construction face government constraints, which forbid laborers to work more than six-hour shifts in the day. They must stop working at noon and wait until it gets cooler to start again.
To keep project schedules moving during the very hot weather and major holiday, the key is to plan, plan -- and plan some more. These planning best practices can help:
- Begin planning for special events about three months prior. The project manger should meet with the customer, contractors and suppliers to agree on expectations, tasks and deadlines.
- Determine activities that can be moved up or delayed to compensate for risks during the special event, such as climate, absent staff and lower productivity.
- Employ more staff to compensate for loss of productivity.
- Keep a sharp eye on daily logs. Doing so will minimize risk -- especially in cases where work hours or the calendar have been altered and extra resources have been employed.
- Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
- Ensure health and safety of employees in the work place. In the case of heat, plan for generators to cool work sites, for example. Provide plenty of water, appropriate clothing and equipment.
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.
Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.
However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.
Here are some reasons a charter is left out, based on my experience:
- Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
- At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
- The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
- Requirements and other changes to the project deemed the existing project charter obsolete.
- The project has been initiated or is continuing without real executive commitment.
- The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.'
- A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
- Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.
Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.
Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.
Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.
Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.
Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.
Do you know of any other reasons why a project charter would not be created? How can the lack of a charter plague a project?
"War is the realm of uncertainty; three quarters of the factors on which action in war is based are wrapped in a fog of greater or lesser uncertainty ... The commander must work in a medium which his eyes cannot see; which his best deductive powers cannot always fathom; and with which, because of constant changes, he can rarely become familiar."
Projects aren't much different.
Military leaders and project managers both need the active support of their teams to be successful. But support involves more than just following orders. Active supporters work with you to achieve success in difficult circumstances.
Here are a few theories I've adapted from the military that may help project managers running a large project:
The right of one objection
This doctrine says that regardless of the rank of the person giving the command, if you have information that shows the command may be wrong, you are obliged to share that information with the issuer. Once the objection has been properly considered, the objector is expected to comply with the final decision.
Unfortunately, many project team members tend to keep information to themselves rather than risk getting in trouble with authority. To reduce the concern, adopt a policy guaranteeing no sanctions against a team member who raises the one objection. More importantly, information withholders become liable to an equal share of the consequences if they have kept quiet.
Decentralize execution planning to the lowest possible management level. This way, those who must execute the work have the freedom to develop their own plans.
At each level of management, the plan should dictate a subordinate's actions only to the minimum degree necessary. Ideally, rather than dictating a subordinate's actions, a good project plan should create opportunities for the subordinate to act with initiative.
Effective planning should facilitate shaping the conditions of the situation to our advantage while preserving freedom to adapt quickly to changes in the project's circumstances.
Planning should be participatory and evolutionary. The main benefit of planning is engaging in the process -- the planning matters more than the plan.
We should view any project plan as merely a common starting point from which to adapt as required -- and not as a script that must be followed. Plan far enough into the future to maintain the initiative and prepare adequately for upcoming phases, but not so far that plans will have little in common with actual developments.
Adapt these ideas to the circumstances of your project, and they should help you make your internal stakeholder management more effective and your projects more successful.
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.
Some responses were flat out rejections of using digital devices. Other responses were accepting of using technology while others are speaking.
Personally, if you are not being disruptive, I don't think it's rude to use your digital devices in a meeting. I think what's more important to note is why people are using their digital devices during the meeting.
As a new project manager, you will probably be hosting many meetings for a project. It's up to you to stay focused even if the participants aren't captivated the entire time.
As project managers in general, we should really take a good look at why we call meetings at all.
You may think you've called everyone together to get their input. But how many people did you invite? What often happens is that a few people talk at once, and several people are left out and unable to contribute.They will inevitably find a more useful way to spend their time.
You may think you've called a meeting at a good time because everyone was available on the calendar at the same time -- finally. But realistically, almost everyone has something going on before and after your meeting. Your meeting isn't the only thing occupying their attention. An empty space on a calendar really isn't an empty space.
As project managers, we need to ask ourselves what kind of meetings we are calling, what's the purpose, who must be invited and why to determine if a meeting is the absolute best way for you to impart or gather a particular type of information. The reason for calling a meeting should not be because it's the easiest way to give information or to get input.
If you do find that you must meet, consider having several smaller meetings in small spaces that engage your core audience. Invite three to five people instead of a huge group. You can even adopt the agile practice of having 15-minute stand-up meetings to encourage groups to focus and get through agenda items quickly.
Sitting in a room waiting to be engaged is bound to lose anyone's attention. If you keep your attendee list short, even if the meeting is long, there is more audience engagement and less individual downtime. Most importantly, there is less opportunity for someone to tune out because they feel no one is paying attention to them.
How do you engage team members during meetings, and do you care if they use digital devices?
Read more posts from Taralyn.
Read more about 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.
Editor's note: The title of this post was changed on 9 December 2011.
Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?
It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.
For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.
When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.
When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.
Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.
Take time as the project manager to set your requirements for running the project. And do so as a high priority.
What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?
And it's interesting to note how the team follows the leader: The more disciplined the leader, the more disciplined the team. A disciplined leader gives others an anchor -- a sense of stability and accountability.
You may wonder why some people are disciplined and others are not. I believe it's a choice. Disciplined project managers strongly believe that delivering on the project result is a function of project management science and disciplined execution.
Here are some ways to become a disciplined project manager:
- Plan the next work week's activities a day or two ahead of time
- Confirm activities the day before
- Conduct daily reviews of what you did or didn't accomplish
- Follow through on your commitments
- Avoid time-wasters, such as unrelated conversations
- Practice staying within the time allotted to the meetings, tasks and activities
- Hold yourself accountable for your own deliverables by using a daily tracker document
- Communicate with stakeholders and sponsors regularly, regardless of the results
What are the ways you've become a disciplined project manager? And how has it helped you deliver better results?
See more posts from Dmitri.
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.