Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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? |
Two-In-One Success
Categories:
Strategy
Categories: Strategy
| Throughout the evolution of the project management profession, project performance has been scrutinized to determine success and failure rates. This is especially true for IT projects. Since the mid-1980s, many organizations have shared their IT project results for one study in particular, The Standish Group's CHAOS report. The survey typically includes questions about project requirements, project budget, project schedule, project stakeholders expectations and use of new technology. This "state of IT projects" report has been used as a reference by the project management and IT communities as a lessons learned guide, even when IT projects have failed. This led me to wonder: In which context is an IT project failure analyzed? Let me explain. If the success or failure rate of an IT project is analyzed in the IT context only, then the analysis may ignore the organization and its vision, mission and strategy. Analyses that are not supported by a holistic approach may propose an incomplete diagnosis that may lead to misinterpretation of project success or failure. A holistic analysis integrates other factors, either internal or external, that affected schedule, budget, requirements, etc. For example, a project's scope may be impacted by a new government regulation or a sudden change in the organizational strategy. Factors such as these may trigger a domino effect on the schedule and budget, too. And that would call for changes in the scope, schedule and budget -- otherwise, the organization is at risk of not achieving its strategic goals. While changing those project attributes make the organization successful, it might result in the project itself being considered a failure. But organizational success doesn't need to come at the expense of project success. That's why more organizations are using projects as enablers to reach organizational goals. One way to make that happen is by adopting the Organizational Project Management Maturity Model (OPM3®). OPM3 translates organizational strategy into a portfolio's components (i.e., programs, projects, operations, initiatives, etc.) and aligns them to overall strategy. This alignment can create the required synergy to produce the products and benefits to achieve strategic goals and meet or exceed the stakeholder's expectations. OPM may be in the early stages of adoption, but so far I have seen it provide value to the organizations that use it. I know this from first-hand experience. While I was working for a global leader in logistics, OPM3 was embraced with excellent results:
What would you promote as a way to holistically assess project success or failure within your organization? |