Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Plan and Facilitate a Requirements Workshop
Categories:
Project Planning
Categories: Project Planning
| Every project manager knows that there is no single best way to collect project requirements. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition identifies several tools and approaches for collecting requirements. They include interviews and focus groups, facilitated workshops, group creativity and group decision-making techniques. Combining some of these tools and techniques with a requirements workshop can be the most efficient and effective requirements elicitation approach. But only if the workshop is planned and facilitated well. Planning a requirements workshop is no different than planning any meeting or event. Some simple steps to follow: 1. Define the scope and establish an agenda The scope and agenda should make it clear to all participants the reasons why they are attending the workshop. 2. Invite the right people Generally, you want to keep the guest list short, but make sure to invite key stakeholders. These include representatives from teams or user groups that will benefit from the project's outcome, project sponsors, product or system owners, and business and technical consultants. 3. Plan the logistics To facilitate an open and constructive working session, make sure that the workshop's location and environment has sufficient capacity and appropriate equipment for hosting the workshop. Now that we have a good plan, how do we facilitate the workshop? 1. Lay ground rules Establish basic ground rules. For example, start on time, stay in scope, and respect and build on other people's ideas. 2. Gather requirements Get everyone involved through questioning and individual interviewing. Apply group creativity techniques, such as brainstorming and mind mapping. And for topics that require in-depth and focused discussions, organize dedicated breakout sessions. 3. Record the workshop Make sure that someone attends the workshop solely to write the protocol during the workshop. He or she should capture all requirements, ideas, assumptions, risks and open items. 4. Pre-qualify and pre-prioritize requirements To facilitate the scoping process at a later stage, try to leave a requirements workshop with pre-qualified and pre-prioritized requirements. 5. Review the protocol and develop a follow-up plan At the end of the workshop, plan sufficient time to review the written protocol and the derived action items. Develop a follow-up plan to address the open items. Identify the owner of each item, and establish deadlines and next-steps. Do you hold requirements workshops? If so, how do you plan and facilitate them? |
A Project With No Project Charter?
| 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:
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? |
Nontraditional Ways to Get Feedback for Lessons Learned
Categories:
Lessons Learned
Categories: Lessons Learned
| When capturing lessons learned, feedback can come from anywhere. Don't dismiss comments because of how you receive them. Consider that you may want to receive feedback from the quality assurance manager who's always on the run. Talking on a mobile phone while he or she is driving from site to site may be illegal, though. Or consider the database administrator who transitioned off your project in phase one, who no longer has security access to the project, and is now busy on her next project. So how do you get their feedback? It isn't easy to reach out and receive the lessons your stakeholders may want or need to share toward improving the next project. These two unconventional communication methods can be used to help in lessons learned:
How do you identify stakeholders on your projects and get feedback for lessons learned? |
Use Military Ideas to Get Buy-in From Your Project Team
Categories:
Project Planning
Categories: Project Planning
| 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. |
Are you a Technologically Reliant Project Manager?
| In the professional world where technology is omnipresent, we as project and program managers are used to tying our personal and professional lives to technology and gadgets like smart phones, tablets, GPS, etc. As a result, some organizations are trying a "day without email" on Fridays and/or weekends to encourage more face-to-face and phone contact with customers and colleagues. How do you think this would be received by a multigenerational project team? For baby boomer and silent generation team members, face-to-face may be a preferred communication method. But for members of Gen Y, not communicating by email may make them feel like a fish out of water because of their preference for virtual communication. As the "day without email" idea progresses gradually, employees in these organizations are probably realizing that business functions are about human relationships. This is an opportunity to foster a coaching environment in which Gen X and Gen Y will be able to hone their interpersonal skills supported by senior project team members. For those project team members who use technology frequently, discuss alternatives that will reduce the dependency of email in their daily activities. How much do you depend on technology for your daily activities? How would your project team survive the "day without email" policy? Would you enjoy having a day free of email? |