Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Understand Your Place on the Project Team
| Have you ever been at a meeting where someone tries to tell you what you should be doing and how? Even though you are the project manager -- the one who guides the team and makes decisions -- you still have people offering their two cents. The advice can come from a project team member or a credentialed project manager on a different project. I have actually done this myself as a project team member. As someone technical, and who also has project management experience and knowledge, I have tried to impart that wisdom to my project manager. I clearly remember one project manager I would advise on a number of things. It's in my nature that when there's a gap -- whether in communication, documentation, project planning -- I want to point it out. The dilemma is that if you impart your knowledge too forcefully, you are possibly invalidating the project manager. In certain situations, that advice becomes unmanageable and puts more pressure on the project manager, not only to manage the project but also to manage you. If we feel there's a need to bring something to the table that is going to add value to the project, it needs to be brought up as such. You should not expect that the project manager would just implement it because you said so. Before you even do that, consider asking yourself why you are thinking a particular way about a situation. Why are you asking for the changes? How does it resolve a specific issue that you are dealing with? Challenge yourself. See if you can adapt and work with your team, deliver what you are required to deliver and, as appropriate, bring up the items that you feel can add value to the project. Understand the value of your place in the project and fulfill on the expectations others have of you. How do you handle project team members who forcefully suggest their ideas? |
Group Creativity Techniques to Collect Requirements
| 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. |
Project Skills Improvement Through Formal Plans
|
It is very likely that you have some members on your project team who are more talented or experienced than others. As project managers, we tend to utilize their skills as much as possible because we know that more often than not, they will be able to produce excellent results and meet expectations. Nevertheless, this group of people still needs the opportunity to improve their skills and knowledge. This is especially true when an organization needs to stay relevant in the current economic conditions. According to PMI's 2012 Pulse of the Profession report, a critical success factor of projects was staffing the team with the appropriately skilled people. Organizations that had a formal process for developing project/program competency saw a 70 percent success rate on projects, versus a 64 percent overall average. Unfortunately, Pulse of the Profession also showed that in 2011, only 47 percent of organizations had a formal "talent management" process, down from 52 percent in 2010. But we must have formal talent management processes to develop project managers and team members, and you must tailor it to the people involved. An effective project manager is only as good as the information that he or she has. An "accidental project manager," for example, might not have attended formal project management training courses. But fundamental knowledge helps project managers achieve effective and high-quality deliverables. For this group, it would be good to start them off with proper training on the core skills they'll need to grow and succeed as project managers. Team members who are familiar with project management fundamentals might need help developing in other areas, such as soft skills. Since 90 percent of a project manager's job is communication, maybe you will help them improve in that area. Have the team member sign up for a communication course, for example. Choose topics such as influencing skills, which is important in convincing clients and partners. Or, suggest courses on negotiating skills, which is helpful in negotiating a more achievable schedule. Refresher courses could be helpful for everyone on the team. Look for training that zooms into specific project management areas, such as effective cost and scheduling control, risk management or quality control management. Aim for at least one training session every quarter. Do you have a formal talent management system? How do you develop your project managers? To discuss Pulse of the Profession on Twitter, please use #pmipulse. |
Finding the 'Flaw' in Projects
| The next time your boss asks you for a number, a deadline date or another fixed value, remember anything you say will be wrong. The reason is 'the flaw of averages.' Discussed in a book of the same name by Sam L. Savage, the flaw of averages basically explains why everything is behind schedule, beyond budget and below projection. For example, you're developing two software modules. Both are expected to take between eight and 12 weeks to complete. When both modules are finished, your organization can start a new process, which requires four additional staff. Your boss asks you for a completion date so the additional people can be brought 'on-board' and the new profitable line of business started. You say, "Eight to 12 weeks," and your boss replies, "Give me a date!" You estimate that a safe date would be 10 weeks, the average of eight and 12 weeks. Everyone is happy. But should they be? Let's look at the flaw of the average: Based on your projected date, your boss works out his profit forecast for the next quarter based on an estimated profit of US$1,000 per week. You take the first seven weeks developing the application, and the new team uses the application for the remaining five weeks. This sounds sensible, but the estimate of US$5,000 profit is the best that can be achieved. If you finish early, there is no upside. The new people will not be available. If you finish late, however, sales will be lost. The cost of the unproductive new staff will be an added expense until both modules are working. On average, the profits achieved are likely to be significantly less than US$5,000. Plus, you're more likely to be late than early. The probability of finishing each of the modules in 10 weeks or less is 50 percent. It's like tossing a coin - there is always a 50 percent chance of it landing on 'heads.' Since two modules need to be finished in 10 weeks or less, think of the options when you toss two coins: Tails + Tails Tails + Heads Heads + Tails Heads + Heads There is only a one in four chance of you achieving the 'average.' That 25 percent probability means there is a 75 percent probability of being late. Therefore, on average, you can expect to be late. All you did was assess a reasonable number based on your expected average time to complete each module. The problem is not your estimate, but the way it is being used. This is the flaw of average. The next time you are asked for a 'number,' use your skills in managing upward to build flexibility into the conversation. For example, offer your boss a safe date with an option for improvement. "We will definitely be finished in 12 weeks, and there is a possibility of finishing sooner." Point out the cost risks of being early and late. Keep the boss updated as you work through the project. Or, do some serious analysis. Offer your boss a range of dates with different levels of probability. You need tools for this, but you want a target date with an 80 percent probability of achieving. Effective stakeholder management needs more than simply complying with a request -- however reasonable it may appear on the surface. |
Project Risks + Proactivity = Success
| Risk management as a best practice is critical to project success. It forces the team to consider the deal breakers on a project, and to proactively prepare and implement solutions. PMI's recent 2012 Pulse of the Profession report found that more than 70 percent of respondents always or often use risk management techniques to manage their projects and programs and these practices lead to higher success rates. Here's an example of how risk management could have saved a project: A project manager oversees an electrical team that is responsible for installing electrical and audio-visual equipment. The construction and civil engineering teams hand over the completed and decorated site, ready for the final phase of the project. To the project manager's dismay, the projectors do not align with the screens, rendering them not fit for the purpose. What went wrong? The civil and construction teams had altered the dimensions of the rooms; the customer failed to communicate the changes to the electrical team. Assuming the project was executed according to plan, the project manger planned and submitted the electrical drawings based on the original dimensions of the room. These plans were made redundant when the room dimensions changed, which upset the equipment's position. To correct the situation, the project manager drew and submitted new electrical drawings. The site's walls and ceilings had to be reopened to accommodate the changes, which caused delays and increased cost, rework -- and frustration. Had there been a robust risk identification and implementation plan, they would not be in this situation. Too many assumptions were left unchallenged and risks pertaining to the many external dependencies were overlooked. As part of this risk management, proactive communication with the customer and other teams should have been planned. For example, the project manager should have considered and asked questions about how the contractors and sites would be monitored and controlled. What would the frequency and type of communication be like with stakeholders? There should have been an assessment of 'what if' scenarios. What happens if the deliverables are not as expected? What are the risks if there are problems with contractors? What is the impact of not having dedicated resources on the team? These types of discussions and questioning would have alerted the project manager and team to proactively plan to manage the quality of contractor work and employ the necessary resource on the project team. Do you practice risk management? How does risk management planning make your projects successful? To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |