Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Marian Haus
8 Strategies for Gathering Requirements From Execs
Categories:
Project Requirements
Categories: Project Requirements
| Project requirements are usually collected through an elicitation process, which requires employing various techniques and methods, such as discovery, analysis, understanding and validation. These methods can be applied in interviews, focus groups, questionnaires or requirements workshops. Typically, one or more business analysts will carry out the requirements elicitation process, while the project manager will be generally responsible for planning and setting up the requirements elicitation and management framework and for its outcome. This approach might be applicable for various types of projects, but when gathering requirements from high-level executives — who don’t have the time nor need to know the details but who focus on the big picture — a special tailoring of this process might be needed. Here are eight strategies you or your business analysts should consider when collecting requirements from executives: 1. Prepare. Try to understand what their business priorities and objectives are. Find out in advance their preferred communication style. Get ready to collect the requirements in a short time and in an atypical environment — i.e., during a coffee break or lunch — due to their busy schedules (more on this point in number 5). 2. Simplify the process. Avoid going through checklists or elaborate discovery techniques. Instead, use a conversational approach, understand, guide and offer solutions and project pros and cons. Use visual depictions and summaries. 3. Simplify the language.Use simple and straight communication. Avoid technical language; instead, use examples or stories that relate to business problems and solutions. 4. Remain positive. Maintain a trustworthy attitude, be an adviser and be proactive. Instead of talking about issues or problems, talk about solutions and give details of what will work. 5. Focus on time.Consider that executives have many challenges to deal with, and hence the amount of time and attention they can allocate on a single topic is limited. Therefore, once you get their attention, stay focused and avoid wasting time. Remember: Time is money, especially for the C-suite. 6. Start with the outcome.The best advice I heard about communicating up is starting with the outcome. When you present solutions to their requirements, engage their attention by providing them an overview of the results first. Then they usually become more interested, creating an opening for you to tell them about the “how.” 7. Manage risk. Consider that some execs are sensitive to risk or can be risk-averse. If any of their requirements pose risks, prepare to develop risk mitigation and risk response options. 8. Maintain a strategic orientation.Focus on what the executives mostly care about — what impacts the business. In most cases, they’ll focus on a business vision, a product concept, innovation or financials (e.g., the outcome with the highest ROI). What’s your experience with collecting requirements from executives? Have you employed any of these strategies? How did they work? For more on requirements management, check out PMI's Pulse of the Profession® In-Depth Report: Requirements Management or visit the Requirements Management Knowledge Center of Excellence. |
6 Obvious Budget Overruns to Avoid
Categories:
Project Planning
Categories: Project Planning
| Nowadays, we rarely hear about projects that finish below a given budget. On the contrary, we hear about projects that need more people, more material resources and more time, which ultimately translates into additional costs that strain the project budget. Although it is clear that project costs can be influenced by external factors beyond the project manager's control, there are at least as many factors that can be controlled from within the project, through appropriate project cost planning. Here are six simple reasons that projects incur cost overruns -- and how to prevent them: 1. Underfinancing. You've probably heard about projects that start with an undersized budget ("We could only allocate that much for this project..."). Such projects will have a high risk of overrunning the initial budget, as well as a high risk of failure. Mitigation: Clarify with the project sponsor from the very beginning how cost overruns, which are very likely to occur, will be handled -- for example, through scope reduction or additional funding. 2. Unrealistic costs estimates. Projects that have costs estimated based on gut feelings or inexperienced personnel are poised to face budget overruns. Biased and inaccurate cost estimates are likely to look unrealistic at a later stage in the project. Mitigation: Break down the work into smaller and more assessable packages. Get help from subject matter experts and experienced personnel when estimating costs. Make the cost estimations comprehensible, by applying different estimation techniques (e.g., three-point estimates, parametric estimating or bottom-up). 3. Underestimated complexity. Many projects nowadays, especially larger ones, have constantly growing complexity. The Berlin Brandenburg Airport and Terminal 1 of Munich Airport, for example, were quite similar in scope, but conducted at different times (25 years apart). Yet Berlin Airport, the more recent project, continues to have considerable budget overruns and delays. One of the reasons: the underestimated complexity concerning the financing of the project, the construction of futuristically designed facilities and newer regulations. Mitigation: Split the project in smaller work packages or phases. Avoid planning everything extensively from the very beginning (the planning alone of the Berlin airport project took 15 years). Plan iteratively -- per work package or phase -- and throughout the project. 4. Extended project schedule. Just because the project schedule is met doesn't necessarily mean the budget will be met as well. On the other hand, it is highly likely that if the project schedule is not met (for example, due to a project time extension), then the project budget will be blown thanks to additional costs that may pile up, since the project team and resources will be needed for longer. Mitigation: Manage the project time and schedule well. Focus especially on the tasks on the critical path, which can have the most impact on both project schedule and costs. If you get asked to extend the project time, explain to your stakeholders that this probably will cost more. Remember the scope-time-budget project triangle. Time is money! 5. Improper buffer planning. If you don't plan (or plan improperly) for a budget buffer, the smallest deviation in scope or schedule will cause an overrun. Mitigation: A budget comprises estimated cost and some contingency. Plan the contingency for unexpected scope changes, unusual weather changes or possible problems with suppliers. Consider a buffer for the costs that cannot be accurately or predictably estimated. Some of the cost estimates will be more accurate than others -- for example, commodity prices will be more predictable than labor costs for a specific service. 6. Improper resource planning. Labor resource costs could be one of the project's biggest expenses. If the project lacks labor resources, a later labor force acquisition will be an unexpected project cost. It can also mean a higher cost since the contracting conditions might not be the same as when initially planning the project. Similarly, resources allocated in excess will mean unnecessary allocated costs, plus unnecessary blocked resources that could have been useful on other projects. Mitigation: First plan the scope, then the required work to be done, and then the related assumptions, dependencies and risks. This will facilitate a better understanding of the work needed to be done and hence will help better assess the right equipment, amount of resources and required skill sets. How do you manage costs on your projects, and which measures do you apply to avoid cost overruns? |
3 Techniques for Breaking Constraints
Categories:
Project Planning
Categories: Project Planning
| In my last post, I wrote about the importance of a project schedule plan and the fact that a project schedule is generally constrained by various factors. In this post, I'll take a deeper dive into the three techniques that can be applied to address resource and time constraints. Resource leveling This technique can be applied to a project's schedule plan when the project is facing resource constraints or when you need to allocate resources consistently and most effectively throughout the life cycle (e.g., all resources utilized at 100 percent capacity by project completion). You'll need to apply this technique when resources are available only for a certain time or when you have resources over-allocated in parallel project activities. The basic idea behind resource leveling is to recognize tasks, priorities, dependencies and constraints. Tasks with the highest priority will be scheduled first. Others, depending on their dependencies and constraints, will be moved for later or assigned other resources available during this time. Logically speaking, resource leveling is applied in this order:
Once you have identified resource bottlenecks and over-allocated or under-utilized resources, set task priorities and apply resource leveling. In some cases, resource leveling can lead to critical path changes -- for instance, if you have to extend the duration of a task on the critical path, due to the reduced availability of a critical resource. Schedule crashing This is a schedule compression technique for dealing with time constraints without sacrificing project scope -- for example, when you have to meet a hard deadline for one of your project's deliverables. This technique focuses on the tasks on the critical path. Shortening them reduces the total duration for meeting a given deadline or milestone. And delivering a project in its entirety, with no scope change, in a reduced time can only be achieved by increasing or improving the resources allocated for that task. As an example, let's take a software project aimed at creating a new system, and migrating functionality and data from an older system. You could reduce task time by allocating more programmers to develop in parallel the functionality of the new system. Similarly, to shorten the data-migration time, you could replace a regular computing machine with a more powerful one. Be aware that crashing the schedule will generally increase costs. And sometimes, there will be tasks that will have the same duration, no matter how efficiently they can be performed (e.g., monitoring the stability and reliability of a component for a fixed time). Fast-tracking This is another schedule compression technique that can help reduce project time without changing the scope. The focus of fast-tracking is on expediting certain tasks by overlapping their execution, despite their dependencies. Let's take the same software project as an example. Chronologically reversed, programming the new functionality (task number one) depends on designing it first (task number two), which depends on a gap analysis task (task number three). By applying fast-tracking to these three tasks, instead of executing the tasks in a sequence, you can overlap them. You can start the design (task number two) in parallel and lagged with the gap analysis (task number three). Similarly the programming (task number one) will start lagged while the design (task number two) is in execution. Fast-tracking is one of the most-used tactics to deal with time constraints, but it does have a few downsides. By not waiting for the complete results of preceding deliverables, fast-tracking could lead to delivering lower quality or even reworking some tasks, which can result in additional costs and delays. The project environment can get very dynamic with tasks conducted in parallel. This can be a challenge for project managers, who might lose sight of the bigger picture or get overwhelmed with managing overlapping activities. What is your experience with these techniques? Which do you think is most effective? |
Keep the Schedule Plan Strong -- and Constraint-Free
Categories:
Project Planning
Categories: Project Planning
| The project schedule plan is probably one of the most important project management assets a project manager has to develop, maintain and manage throughout a project. Why? Because compared to other planning documents -- such as the resources plan, costs plan or risk management plan -- a project schedule will generally have widespread visibility within the project's environment and among stakeholders. For instance, your project sponsors will want to see your project schedule and understand whether you are on track to deliver it on time. The beneficiaries of your project will want to see it to understand your next deliverables or key milestones. Your core project team will seek it out to find out how work activities are planned and relate to one another, and how resources are allocated. And, probably most important, you as the project manager will need it to be your map throughout the project, guiding you to drive the project to its target. Now, if your project schedule is incomplete or flawed -- for example, it's missing work tasks or it features wrong dependencies between project tasks -- you will most likely steer your project into a wall. And even if you put everything right into it (i.e., all work activities, the right durations, right resources assigned, right dependencies), that still might not be sufficient for a successful delivery. That's because, as you know, a project schedule is not a linear sequencing of work tasks that perform exactly as initially planned. In addition, your project schedule will be subject to the project's challenges and constraints, such as resources scarcity, work overload, aggressive milestones or delays. It's these unexpected or imposed factors that will constrain your project schedule and demand that you react quickly, applying various tactics and techniques, to adapt the project schedule and make it ultimately work. There are several techniques that can help in analyzing, adapting and improving a constrained project schedule. Among these, three stand out for their effectiveness:
In my next post, I'll dive deeper into what these three techniques are, when to apply them and how to do so. How do you manage constraints to your project schedule? |
Multi-Project Schedule Planning, Part II
Categories:
Project Planning
Categories: Project Planning
| In my previous post, I set the stage for what it means to manage a project in a multi-project management (MPM) context. In this post, I will share some best practices in the form of do's and don'ts that I hope will provide you with some basic guidance on how to steer and manage a project in an MPM environment. Here are a few do's: Be present. First and foremost, your project needs to be represented by you as a project manager during the MPM community's key shared events. There will be status meetings, where all project managers will report their progress, achievements or issues. There will be decision meetings, where overall decisions will lead to a shift in gears and put projects on new tracks, or where projects' priorities will be reassessed. You'll have to be there to understand the implications of these changes to the MPM environment and contribute to MPM developments. Show commitment. The last thing your counterparts want to see from you, in a complex project environment, is the team committing for a milestone or deliverable and then not seeing it through. Show commitment and responsibility for your part of the project and demand the same from your counterparts. Shed light. When odds are against your project and your commitments are threatened, make this visible in the MPM environment and shed light on the underlying impacts with strong communication management. Failing to communicate MPM-relevant results could generate ripples in related projects. For example, if you don't communicate on time a slight delay in the MPM project, this withheld information could cause huge delays in related projects. Request orchestration. Request that the MPM project's overall coordination/orchestration is done by an independent person, a person other than the project managers of the underlying sub-projects. This is a prerequisite for attaining common project goals and avoiding project conflicts, due to the various project interests that are put in place. Inform your team. Since your project team members will mainly be focusing on the project's inner scope, keep your project team informed about developments in the related MPM projects. I recommending avoiding these don'ts: Silo planning. In an MPM setup, where scope, timeline or resources can overlap, silo planning can jeopardize your project and the correlated projects. Plan jointly and agree on high-level planning with your MPM counterparts. Adversity to change. To respond to changes external to your project, which can be critical for the overall projects' success, your project and stakeholders will have to be resilient to change, not adverse to it. Inform your stakeholders and enhance your change management process to allow changes that support and facilitate overall goals. Disregard risks. When you have hard dependencies on or with other projects, do not underestimate or neglect managing risks. A tiny risk in your project can have significant impact on the related projects. Identify risks, quantify their occurrence probability and impacts, plan responses and share your risk management plan in the MPM community. Demand the same from your MPM counterparts. Information overload. Although on one hand it's critical that your team is informed about what happens in the related projects, information overload from the MPM community can disturb your team's focus. Filter the information from the various MPM project teams, and share the significant information within yours when the time is right for your project. Sluggish steering. While multiple forces from the MPM setup might influence your project course, do not permit your project role and influence to fade out. You are still the project manager; you are still the one holding the reins of your project. Do these do's and don'ts apply in your multi-project management setup? |