Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Turn Chaos Into Success
Categories:
Complexity
Categories: Complexity
| Project managers usually advance in their careers by managing small, then medium and ultimately large projects. What project managers may not be prepared for is the complexity that comes with taking on bigger projects. Left unmanaged, this complexity leads to chaos and ultimately project failure. Why does this happen? A business system is characterized by processes and activities that work in tandem to deliver a specific result that benefits customers. Throughout a project's life cycle, it can encounter a number of business systems -- such as leadership systems (how leaders set values and organizational performance and governance) and customer systems (engagement strategy to meet customer needs and support that relationship) -- that independently and jointly put pressure on the project. As you segment the business systems further, you will find underlying, interrelated business processes and activities that create even more complexity. And as the project traverses along the value chain, more strategic tensions apply, such as competing research and development priorities or sales quotas. Projects that disrupt these systems and value chains promise new and improved approaches. But project managers must mediate the chaos this disruption generates to achieve project success. Organizations with less mature processes and fewer performance measures tend to put more pressure on project teams. In these organizations, the project team is responsible for navigating the chaos caused by increased complexity. Projects often devolve into uphill battles and ultimately fail. This demonstrates an inherent "inverse tension" between process maturity and project complexity. Reduce complexity by relaxing tensions. By understanding tensions, project managers can develop a management discipline that shapes the project plan and enables success. To create that discipline, follow these foundational steps:
I use APQC's Process Framework as one source to identify common organization business systems and processes, and their potential pitfalls. A team should identify the system's performance gaps to manage mediations and avoid negative impacts proactively. To assess the performance of business systems, I generally rely on the CMMI model (Capability Maturity Model Integration). I define the performance criteria according to the following maturity levels:
I also use simple checklists to assess the project capability of an organization and team to determine any preventative actions I can take in the planning phase. For example, asking a series of assessment questions that identify process maturity levels allows me to consider any gaps I need to mitigate to improve project performance. To analyze team-related project complexity, I leverage the characteristics outlined by U.S. authors Kathleen B. Hass and Amit Kumar:
I used these frameworks to reduce complexity and increase predictability when I managed a big project team that was working with a large number of suppliers. The project was highly complex, behind schedule and expected to go over budget. The team managed supplier payments by sending invoices to accounts payable once the related work was complete. Using assessment questions, I discovered the main problem was related to a large global transformation initiative, in which the purchasing team worked within limited regional relationships. I classified this as a high complex engagement because the team:
In my management improvement plan, I was able to clearly demonstrate what business system was failing, where in the system it was located and why it was underperforming. I created a clear path forward to restore performance, which resulted in reduced complexity, better alignment and lower costs. How do you create a framework to get a handle on complexity? Learn more about complexity on PMI.org. |
7 Steps to Project Planning Acceleration
Categories:
Project Planning
Categories: Project Planning
| What's a reasonable amount of time to devote to planning a project? I use this rule of thumb: If it is a low-uncertainty project (i.e., we've completed another with similar conditions in the past, with known technology and firm assumptions), devote at least 10 percent of the expected duration of the project to planning it. If it's perceived as a high-uncertainty project (i.e., one with new technology, new approach, uncertain conditions), devote at least 20 percent. But let's face it. Often, organizational pressure will not allow us to devote that much time to planning. So is there an approach that lets us reduce planning time but still do good work and come up with a complete, useful plan? Many organizations I've worked with use a project planning acceleration workshop (PPAW). This is an organized, closed-door, multiday session with the whole project team to focus exclusively on producing the project plan -- something that usually takes several weeks, completed in a few days' time. There are different ways of organizing such an event, but I usually follow these seven steps: 1. Plan the plan. Share with team members all of the project's background information. Send invitations with enough lead time and clearly state the session's sole objective, which is to produce a solid project plan. I often kick off the session stating that once we are finished, we will have a project plan that is roughly 75 to 85 percent complete -- and that we are going to accomplish this in a very short period of time. Therefore, total commitment is required from all participants. 2. Set the stage. What you want is an environment conducive to teamwork without distractions. Secure a room to host the workshop, preferably outside of the office. And don't forget to include a lot of food and beverages for the duration of the workshop. When people are tired, food helps! 3. Define the agenda. Depending on the complexity of the project, different workshop durations will be required, but three days is adequate for most projects. I often use an agenda that looks like this:
4. Use collaborative working techniques. Don't just project steps on a screen; make team members work together. When producing the WBS or the project schedule, use the participatory cards on the wall (COW) technique. For the risk management plan, brainstorm together to identify risks and ask participants to pin different risks on color-coded charts according to their assessment of probability and impact. 5. Document everything. Assign someone in the team to document everything produced. You may use Post-its to draft the WBS or the schedule, but these elements need to be recorded formally for when the project starts. 6. Assign tasks for completion. After the workshop is finished, the project plan won't be completely finalized. Usually certain parts need more research or analysis. Assign specific team members to complete outstanding pieces and establish a deadline for completing these elements that were initiated at the PPAW. 7. Kick off the project. Once the project plan is deemed completed, host one more session to make a final review of all the elements, especially those that needed further research. Combine this activity with a formal project kick-off meeting -- the end of PPAW and the beginning of your project. In my experience, when a team is co-located and completely focused for a specific period of time to create a plan, it yields better results. Have you ever run a PPAW? How has it improved your project? |
Adjusting to Team Time Warps
Categories:
Stakeholder Management
Categories: Stakeholder Management
| Have you ever wondered why one person is always late for meetings while another one is always early? Chances are you're dealing with people who see time differently. For some, time flows from the future into the present and on to the past at a steady rate of 60 minutes every hour. Others see time as a river carrying them forward to an uncertain future. And while everyone is aware of the three elements of time -- the past, the present and the future -- cultures see these in different ways. Western European cultures tend to have a strong future focus -- what's happening in the present is focused on securing a good future outcome. The past is relatively unimportant, since "you can't change history." Cultures with a present focus let go of the past, don't worry about the future and fully enjoy the experience of the present. This focus can be a wonderfully relaxing experience, but it can also lead to the need for immediate gratification and short-term payoffs -- traits of many "youth" cultures. More traditional societies -- for example, those found in Africa, Asia and southern Europe -- tend to have a past focus, looking to preserve their history and respect family and society elders. For them, the present is a continuation of the past, and there's not much point in doing too much planning for an uncertain future. In these societies, the Western view of time as a strictly linear function of seconds, minutes, hours and days is seen as very limiting. Understanding these different perspectives can help you in a project environment. For example, someone with a strong present focus will see the discussion they're currently engaged in as important and consider it inappropriate to cut it off just to be on time for a meeting. But if that meeting is organized by a forward-looking person with a strong time focus, there will be problems. One way to decipher where you and your team members are in the "time warp" is to use U.S. psychologist Thomas J. Cottle's Circle Test. Grab a sheet of paper and draw three circles on the page, arranging them in the way that best shows how you feel about the relationship between the past, present and future. Use different size circles to indicate relative importance and separate or overlap the circles depending on how much influence each one has on the others. Here are two examples that illustrate the different ways people view time: The purple circles represent a strong future focus with the present feeding into achieving future outcomes. There's little connection to the past. This is typical for a lot of time-conscious project managers focused on planning their projects (a future focus) and then implementing the plans (a present focus). The blue circles show a strong present focus firmly grounded in past experiences and traditions. The present is a bit more important than the past, but the future is not really connected to the present and of lesser importance. Don't expect someone with this perspective to be very interested in planning for an uncertain future or being on time for meetings. Their view of success is built on the strength of existing relationships and systems. The Western/project management focus on time can be effective, but it can also be dangerous, particularly in cross-cultural teams and when dealing with clients with a different time focus. The stress of missing an impending deadline can affect people's health, cause then to sacrifice their relationships and lead to shortcuts in quality and missed opportunities. Is it really worth destroying value by de-scoping a project just to achieve a deadline (especially if it's artificial)? A more balanced view may be that while the deadline is missed, there are opportunities to deliver 100 percent of the scope, identify additional hidden value, and maintain a healthier and happier project team. The optimum answer depends on the circumstances of the project and the time focus of key stakeholders. What's your time orientation and how does it fit with the rest of your team and other stakeholders? |
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? |
4 Signs to Pull Over and Stop a Project
Categories:
Project Delivery
Categories: Project Delivery
| Photo: Courtesy of tequilamike Have you ever seen the award-winning movie Rush? In it, Austrian Niki Lauda, Formula One World Champion racing driver, lectured fellow competitor from England, James Hunt, on risk management. Mr. Lauda states that he manages to a risk factor of 20 percent; any conditions that produced risk over this factor could lead to a deadly accident. At the last race of the season, Mr. Lauda pulls over in a rainstorm as he feels there is too much risk. While this action hands the top prize to Mr. Hunt, Mr. Lauda is unrepentant in his action to pull off the road. He goes on to win more racing world championships than Mr. Hunt. Projects are like racecars -- both are complicated and exist in environments where there are many moving parts. That's why, as with a race, knowing when to put the brakes on a project will be best in the long-run. Here are four warning signs that you need to pull over:
We are typically judged by the amount of progress we make as well as the outcomes from our projects. But we should also be judged on our ability to cease projects when the level of risk is too high. Although it might seem like a sign of weakness, stopping and re-directing a project incurring too much risk can reduce the potential overall cost and preserve its value proposition. Under what conditions have you had to stop a project due to too much risk? |