Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Stick to Project Management Basics
| The importance of fundamentals in project management is obvious, but easy to lose sight of. As professionals who constantly strive to improve, we study, read, take courses, attend seminars, listen to podcasts and more -- all to become better project managers. Ironically, sometimes this desire to learn causes us to lose focus on the fundamentals. Instead, we look to novelty, the latest trends and perhaps even the latest fads in the interest of improving. Likewise, we might embrace sophisticated techniques without ensuring that we've properly implemented the basic things on which the sophisticated techniques depend. I've often heard great sports figures and musicians emphasize the importance of fundamentals in their success. Project managers would do well to place similar emphasis on the basics of our profession. I'd go even further to suggest that before we embrace any new or sophisticated technique, we should first look at how well we are implementing the fundamentals. For example, what good does it do us to implement the latest agile techniques on a project where we haven't adequately implemented rudimentary change management disciplines? Similarly, what good would it do to implement Monte Carlo simulations in a context where we haven't adequately identified basic risks? In my estimation, our success depends almost entirely on how well we have implemented fundamental risk and change management processes. Things go wrong and plans change -- yet we often charge ahead without adequately planning and preparing for those realities. Certainly, our intuition tells us this is true, and our experience validates our intuition. Yet it still often happens that we lose sight of the obvious fact that the basics matter and matter most. If you should ever waiver in your conviction, look no further than PMI's 2012 Pulse of the Profession. The report notes that change management and project management basics are among the most critical project success factors. New and sophisticated techniques have their place, but the best thing to do in any profession is to go back to basics. Don't let the allure of the sophisticated or the novel, distract us from the value of fundamentals. To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |
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. |