In a previous post, I referred to brainstorming as one of the most constructive and fruitful techniques to collect project requirements.

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:

1. Clearly outline the problem or the idea to be explored.
2. 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.
3. 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.
4. 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.
5. Schedule sufficient time so that people won't feel constrained. Factor in time for breaks so that people can feel refreshed.
6. Have someone capturing the generated ideas and the underlying notes. 
7. Plan the logistics such as use of flip charts, pin boards, snacks, etc.
   

As a facilitator, project managers might consider the following best practices:

1. Create a relaxed atmosphere that stimulates creativity.
2. Start the session with an icebreaker, a warm-up exercise or something funny.
3. Allow open brainstorming but keep the focus on the initial idea or problem.
4. Encourage everyone to participate and ensure a fair participation from each attendee.
5. Accept all ideas positively and appraise them equally.
6. Encourage people to be constructive, as well as to build on people's ideas.
7. Keep the session unstructured and unconstrained.

Do you use brainstorming on your projects? What is your experience and results?

In project management, if basic technical knowledge is lacking, or the basics are ignored or underestimated, a project's success is not guaranteed.

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.


The months of July and August have a few events that can put kinks in your project plans in the Gulf Cooperation Council (GCC) countries.

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:

1. 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.
2. 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.
3.  Employ more staff to compensate for loss of productivity. 
4. 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.
5. Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
6. 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.
   

How do you plan for special events in your project calendar?
 

In my previous post, I discussed gathering requirements through a facilitated requirements workshop, conducted as part of the scoping phase.

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.

Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project.

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.

Why?

Here are some reasons a charter is left out, based on my experience:

1. 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.
2. At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
3. 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.
4. Requirements and other changes to the project deemed the existing project charter obsolete.
5. The project has been initiated or is continuing without real executive commitment. 
6. The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.' 
7. A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
8. Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
   

However, without a charter, a project is headed for problems including:

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?

Carl Phillip Gottfried von Clausewitz, (1780-1831) a Prussian soldier and German military theorist, wrote:

"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.
 

Project requirements derive from concrete business needs or business-use cases and constitute the foundation for the project work. Without requirements, projects cannot exist.

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?

Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor.

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.
  

Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

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.

On a project management forum I frequent, someone asked whether or not it was rude to use digital devices during meetings.

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.

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:

1. Collect the project requirements
2. Facilitate a requirements workshop
3. Define the project scope
   
4. Break down the work in small work units
   

Collecting requirements is the process of understanding the customer needs, the business use-cases or the required product features and functionality that the project will deliver. It's an elicitation process, a discovery and analysis endeavor, rather than just a gathering effort.

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.

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?

We can all boast of great methods of managing people and project deliverables. But what gets the job done is discipline.

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.

Solid project planning is a prerequisite for project success. Poor planning, meanwhile, can lead to missed deadlines, budget overruns, poor quality deliverables, frustrated project teams and even project failure.

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.

There is a saying: "Every minute you spend planning will save you 10 minutes in execution." As a project manager, I've learned that along with communication and execution, planning is one of the three key ingredients for project success.

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.