Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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? |
What Are Your Project Management Career Goals?
| People with clear, written goals, accomplish far more in a shorter period of time than people without them could ever imagine. - Brian Tracy, CEO of Bryan Tracy International, a leadership development firm What are your career goals? Have you examined them recently? Do they still make sense given that you or your position may have changed since setting them? Do they still make sense given that the world around you has no doubt changed since you set them? If you're having a hard time deciding what your career goals are, remember this: Every goal you choose should be based on how it will or will not contribute to your career success. I learned from both my own career, and from having spoken to hundreds of people about theirs, that difficulties in setting career goals are almost invariably tied to not having a clear and internally derived definition of career success. Some possible goals you might have, though you will certainly have others to add to this list, include: • Flexibility in your career • Self-employment • Employment (if unemployed or self-employed) • Greater or lesser responsibility • Better clientele • More fun projects • Promotion • Early retirement • Better work-life balance • Skills improvement • A credential or certification Before you set your career goals, think about what constitutes success for you. Does this definition come from you or is it something you got from someone else? Have you documented this definition? Once you know your own definition of success, choosing goals becomes much easier. In my opinion, if you want to achieve greater success in your project management career, these steps can help: 1. Define and understand what success means to you personally 2. Articulate it in writing 3. Identify the goals that will move you closer to success 4. Document your goals so as to activate your Reticular Activating System (RAS) 5. Share them with your network so as to activate its RAS 6. Make a plan to implement your goals 7. Reevaluate your goals periodically 8. Adjust them accordingly 9. Go back to step one In my next post, I'll give some pointers for what to do after you've identified your goals. In the meantime, I would be interested to know what success means to you personally. Which goals would you add to my list of possibilities? Which goals have you identified for yourself? |
How to Manage Multiple Stakeholders on a Program
| Programs are formed by projects with stakeholders from both similar and different backgrounds. Therefore, program managers must be able to work with diverse personalities. For example, Taiwanese fashion designer Sun Hua Chen wanted to get young people interested in the fashion industry. He saw an exhibition by fashion photographer Su Yi Liang, which spurred the idea that a fashion photography exhibition would be a good way to interest upcoming generations in fashion. "The Big Shot Charity Photography Exhibition" first held in 2011, will hopefully become an annual event held at the Fubon Cultural & Educational Foundation in Taiwan. The foundation is known for its work in supporting young people. The end result that first year was 111 designers, photographers and non-profit workers who collaborated to make the exhibition a success. The event raised US$308,200 to support young adults' work in art and design. But reaching that level of success wasn't easy. For starters, Mr. Chen found it challenging to get the foundation to understand his vision, mainly because of the vast difference between the fashion industry and charity work. To secure buy-in, he presented a benefits realization plan in a way that the foundation would understand. They translated the potential effect of the fashion event into how much money could be raised, which would in turn benefit the foundation's stakeholders. The stakeholders also had different concerns based on their interests. On one hand, there were artists and designers seeking perfection and impact. On the other, there were volunteers and professionals seeking efficiency and effectiveness through non-profit. However, both groups understood that they needed each other's strengths to make the event a success. In this case, that meant utilizing one group's creativity and the other's business sense. It was the eventual synergy of both groups that resulted in the event becoming an annual success. How have you managed a large, complicated program successfully? Do you have any tips for managing multiple stakeholders? |