Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
How Project Professionals Will Shape the Future PMO
Categories:
PMI PMO Symposium 2012
Categories: PMI PMO Symposium 2012
|
Executives need the project management office (PMO), according to speakers at the PMI® PMO Symposium. It's the primary enabler of change -- a powerful force in today's constantly shifting marketplace, said Terry Doerscher of BOT International, the featured speaker on Tuesday night. As a result, he argued that PMOs of the future would include all aspects of the business, not just projects and programs. And that could mean a whole new career path for project professionals with the right skills. "It's not a huge leap to go from a portfolio project manager to an executive project manager," he said. But it's up to PMO leaders to take action to fulfill their vision. "The best way to predict your future is to create it," said Greg Miller, vice president of the PMO at CareFirst Blue Cross Blue Shield, during a panel discussion on the strategic PMO. Mark A. Langley, PMI president and CEO, moderated the panel, which also included Human Systems International Limited's Terry Cooke-Davies, PhD, and Microsoft's Bill Dow. Dr. Cooke-Davies asked attendees to remember that portfolio management is about aligning project and program costs with business value, and program management is about delivering strategy. When organizations forget those roles, though, PMOs become nothing but process police. Mr. Miller outlined what PMOs need to show executives to be viewed as a strategic player:
Between the panel discussion and the featured speaker, attendees networked with peers and participated in breakout sessions. At one of those sessions, Jim Furfari, PMP, of Colorado Springs Utilities, led a discussion on how to prioritize projects. At his organization, the process begins by checking the availability of resources. This prompted lively discussion, as many attendees suggested the availability of funds was a more appropriate place to start. "It makes no sense to prioritize projects that you don't have the resources to do," he explained. In another breakout session, Joseph Sopko of Siemens, co-author of The Guide to Lean Enablers for Managing Engineering Programs, said lean principles make "good sense, but they're not common." These principles are often lost in complicated processes and with a "we've always done it this way" attitude. Among the best lean practices he outlined were defining value to the program stakeholder and making imperfections visible while pursuing perfection at the same time. |
Uncertainty Calls for Agility, Courage, Strategy — and Some Fun, Say Experts at the PMI® PMO Symposium
Categories:
PMI PMO Symposium 2012
Categories: PMI PMO Symposium 2012
| Extraordinary, unprecedented change in the business world requires bold new thinking -- with project management offices (PMOs) helping lead the charge, according to opening day speakers at the PMI® PMO Symposium 2012 in Las Vegas, Nevada, USA. High uncertainty and constant change is the new normal -- and it's here to stay, declared featured speaker Roch Parayre, PhD, teaching fellow at the Wharton School of the University of Pennsylvania. "We live in a world of high uncertainty." Yet organizations still plan for the predictable -- and then are unprepared for what actually unfolds. Instead, organizations should stick with their core, but always have a "portfolio of micro-investments bubbling away on the back burner so you're ready for changes," he said. Procter & Gamble, for example, may try out a new scent, but it won't roll it out to its megabrands until it's been proven on its secondary lines. "Strategy is about balancing commitment with flexibility," said Dr. Parayre. That delicate balance may require some painful decisions, however. PMOs must be willing to act like venture capitalists, absolutely ruthless about quickly getting rid of projects before they invest too much. "Our inability to kill things is probably the number-one barrier to adapting to change," he said. "Every organization should have a VP of killing stuff." Dr. Parayre pointed to 3M, which actually honors its failed projects at a ceremony, with winners based on how much learning came from the failure. For truly breakthrough projects and programs, organizations must have the "courage to try risky concepts" backed by a belief they will succeed, said keynote speaker Burt Rutan. A pioneering force at Virgin Galactic, Mr. Rutan is also the man behind the legendary Voyager, the first aircraft to circle the globe nonstop without refueling, and SpaceshipOne, the world's first privately funded spacecraft. Yet just pouring funding into a program doesn't ensure innovation. Teams must know that "confidence in nonsense is allowed" -- that they can try things that may not work. Mr. Rutan also suggested:
"It's not enough for kids to look forward to an iPhone with new features," he said. "We need to look forward to real adventure and real discovery." And even in an understandably risk-averse business climate, Mr. Rutan said organizations can't just issue "flowery words" about innovation. "They won't have breakthroughs unless they're willing to take in-your-face risks," he said. Organizations must be able to respond to market shifts -- and PMOs can be the enablers of that organizational agility, said opening speaker Mark A. Langley, PMI president and CEO. "All strategic change happens through projects and programs," he said. Yet despite wider adoption of PMOs, CEOs remain confused about projects and programs. PMO leaders must speak the language of business; instead of focusing on the activity, talk about the outcome. Mr. Langley also called for new thinking on talent. There will be an average of 1.2 million project management positions open annually through 2016, according to the Anderson Economic Group. The result is a massive talent gap that will demand different approaches to talent management. And that should include a willingness to build the next generation of business leaders from the project portfolio management space. Mr. Langley also announced a new seminal research project on PMOs, with the results to be revealed at next year's symposium. |
Gain Executive Buy-In for Project Requirements
Categories:
Project Requirements
Categories: Project Requirements
| No matter what industry you work in, chances are you've had to build a long list of specific requirements to help define project success and to identify project risks. In many cases, you're required to align with your primary stakeholders on these requirements before you can move to the next project phase. These stakeholders are likely high-level executives who come from the sales or marketing side of business, or who are senior enough to have bypassed getting into the fundamentals of a project. Whatever the case, you're now left with the challenge of presenting them with these requirements. If they don't agree or understand your direction, you can't proceed on the project. If you're lucky, your stakeholders believe they hired you and your team because you're the experts. In this case, the presentation is more about showing them you've done the work and the next steps, instead of actually having to get their buy-in. Conversely, you may find yourself in a situation where many of the requirements need to be discussed and debated among the stakeholders. No matter which of these situations you're in, I've found that this three-step approach works best when presenting requirements to executives: 1. Divide the requirements into categories that will vary depending on the type of project. For example, if you're producing a software solution, your categories may be "security," "user interface," "connectivity," and "primary functionality." 2. When you have determined your categories, summarize the high-level direction being defined by each of the micro-requirements under each category. If there is a particularly divisive requirement and you anticipate debate, you should pull that requirement out and highlight it with its own slide. For instance, if you have decided to develop using Java and this needs to be discussed, or specifically approved, make sure that item is highlighted. 3. For all categories of requirements, create a list of pros and cons for the recommendation, and provide justification for the choice the team made. For documentation purposes, I would also include a check box that indicates agreement or disagreement from the stakeholders. Presenting detailed requirements to executives, especially in a limited time frame, is always a delicate operation. In my experience, following this approach will ultimately help you get the support you need to move forward in your project's next phase -- without risking a drawn-out approval process. What techniques have you used successfully to gain executive-level buy-in on project requirements? |
5 Overlooked Project Risks
| Experienced project managers frequently encounter common project risks, such as lack of available resources or slipped deliverable dates. But what about those risks that people don't often think of? While often overlooked, these risks might be more real than you think and can often reveal other project challenges. Here are five unusual, but real, risks that I've heard from project teams. If yours ever brings one up, don't be so quick to dismiss it. 1. Weather The first phase of a software solution deployment targeted several cities with a generally temperate climate. The project team reported a risk of weather delays and asked for a two-week schedule contingency, which was greeted with laughter and objection by the steering committee. Sure enough, the deployment cities experienced their first snowstorm in decades, which resulted in delayed deployment--as predicted. Future deployment planning included a contingency for weather-related changes. 2. Video conferencing capacity A project team presented a report showing it was behind schedule. Team members blamed a lack of robust video conferencing capability, which the steering committee responded to with shocked silence. After the meeting, the project manager discovered that the original project plan did not consider the risk of requiring frequent communications to coordinate development at multiple sites. Identifying it as problem not only fixed the issue, but it led to resolving additional communications issues. 3. Lack of project experience One project team declared that its own project manager was a risk because he didn't have any experience leading projects. As a short-term solution, a senior team member was asked to assist the project manager. Examining this risk further revealed that there were several staffing challenges, including replacing the senior team member assisting the project manager. Had the project manager not been identified as a risk in the first place, they never would have recognized resourcing issues. 4. Vacations and holidays A project team with limited global deployment experience scheduled a European deployment milestone during the month of August. It later reported a risk of difficulties finding local resources to help with deployment due to vacations. After realizing that August is typically a vacation month for Europe, the steering committee not only approved a schedule change, but it also examined the vacations and holidays of the other countries on the deployment schedule. Based on this input, the project team adjusted the schedule and successfully achieved the remaining milestones. 5. Termites One project team declared termites as a project schedule risk. After the steering committee brushed off the need for insecticide, the team shared that termites had chewed through the supports of a mobile office trailer. The damage caused the trailer to be declared unsafe and prompted an unscheduled office move. Moreover, the team members also revealed that they were working in separate mobile trailers, which hampered productivity. Thanks to the initial schedule impact, the project team was relocated to contiguous indoor office space and increased productivity. Have you ever overlooked any risks? What were they? |
How To Evaluate Lessons Learned
Categories:
Lessons Learned
Categories: Lessons Learned
| A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is useful both for navigating the fundamentals of project management and for evaluating lessons learned. It can help you determine if you focused on the right things in your project and where you could have improved. Consider each knowledge area of the PMBOK® Guide as you review your project. In the planning stage, for example, let's say you used brainstorming to develop your charter. Was the brainstorming effective? If so, what made it effective and if not, why wasn't it? Address these things in your lessons learned session. Or, think about the risk management tools you used in your project. The PMBOK® Guide highlights such tools as 'The Probability and Impact Matrix' or the 'Data Quality Assessment.' If either was used during your project, in the lessons learned session you could analyze the ratio shown on certain risks or the integrity of the data. Here are three other ways you could apply the PMBOK® Guide principles to your meetings:
Have you used the PMBOK® Guide for lessons learned? How? |