Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Lynda Bourne
Making the Right Call
| Making decisions is a central part of any project management role, but some decisions are tougher to make than others. Problems have one right answer that can be reached by analyzing the information you have. Dilemmas don't have one right answer. Any solution will be at least partially wrong, unfair or harmful to some stakeholders. But not making a decision will be harmful to all stakeholders. The challenge is to minimize the damage and, occasionally, to optimize the benefit. Mysteries are often hidden within too much information. Understanding them is closely aligned to the ideas contained in complexity theory and risk management. Accepting your inability to know the answer to a mystery is critical: Make the best decision based on the limited information available while staying prepared for surprises. Puzzles can often be resolved through measurement and research. Gather the right information and skills, and you reduce a puzzle to a problem and can then calculate the optimum answer. If there's insufficient time to gather and analyze all of the necessary information, though, you may be forced to deal with the decision as a mystery, When confronted with a difficult decision, recognize the differences between the types of possible decisions and then use the best approach to reach your conclusion. Many issues around decision making stem from a false hope that we just need a little more information to reduce a complex decision to a problem with just one right answer. Yet in many cases, this is just not possible. All project managers make decisions. The difference between good project managers and great ones is the percentage of decisions they get right. |
Deliverables Are Only the Beginning
Categories:
Teams
Categories: Teams
| Simply supplying a project's deliverables is not enough. Project managers must understand the goal of the project, the objectives to support that goal and the deliverables needed to fulfil those objectives. Goals describe a project's overarching purpose. They tend to be wide-reaching and related to senior management and client expectations. A project's success depends on achieving its goals. Objectives fall into two broad categories: • Objectives achieved by undertaking the project work in an appropriate way, such as addressing safety, sustainability, work force development and stakeholder management. • Objectives achieved as a consequence of completing the work of the project -- successfully creating the deliverables transferred to the customer to meet the requirements defined in the project's scope statement, for example. Objectives are the direct responsibility of the project manager, and he or she should be assigned the authority, responsibility and resources to achieve them. Deliverables are the final product from either the project management processes or the performing organization. A successful delivery hinges on achieving the specified requirements of time, cost and scope while satisfying the key stakeholder's requirements. There's more to project management than just deliverables. Focusing on them exclusively to the detriment of the project's objectives and the organization's goals is counterproductive. Project managers must understand how their deliverables will contribute to overall goals of the organization. |
Unrealistic Detail Only Sets You Up for Failure
Categories:
Project Failure
Categories: Project Failure
| It's impossible to accurately predict the future. Yet, many project managers continue to try. They create schedules that implicitly state a task will be completed at 3:30 on a Tuesday afternoon, in four months. Or they predict that the total cost of their project will be precisely $10,986,547.55. Yet these pseudo-accurate estimates based on detailed calculations are no more accurate than estimates made in more general terms and covered with an appropriate range indicator. Achieving a detailed estimate for an $11 million-plus project to within -5 percent to +10 percent indicates a very careful estimating process in a stable, well-understood environment. Attaching a precise number calculated to the nearest cent only raises stakeholder expectations about the degree of accuracy possible. And that leads to perceived "failure" when the stakeholder's unrealistic expectations are not realized. Similar problems arise if a project is scheduled in hours, and the work extends for more than a few days. Planning a project over several months on an hourly basis produces a mass of inaccurate data once you get beyond the first few days. And again, when the project fails to achieve the degree of control over the future implied by the excessively detailed schedule, it will seem like it failed. Pragmatic estimating at an appropriate level of detail sets realistic expectations. But beware: Your stakeholders may already have unrealistic expectations of what is possible from previous projects that "failed." Dealing with this issue requires skills in managing upward -- a topic for a future post. |
There's an App for That
Categories:
Innovation
Categories: Innovation
| For most of human history, skills have been passed from master to apprentice on an "as needed" basis. As the apprentice encountered a problem, the master would demonstrate the solution and the apprentice learned. Early academic institutions operated along similar lines. It's only in the last century that learning has moved to a "book-and-exam" model. But many researchers have questioned the effectiveness of this method of learning for skills that involve contextual variability. Instead, they advocate developing communities of practice, mentoring and other options to replicate the master and apprentice approach. The problem with these approaches is timing: Can the master be available when needed by the apprentice? Most of the time, it seems the answer is no! Project management involves a very high level of contextual variability, particularly in the area of interpersonal relationships, motivation and leadership -- the so-called soft skills. Learning these skills in the "school of hard knocks" is not fun and has significant costs for the inexperienced project manager and organizations that rely on them. Advances in modern technology may offer a solution. Intelligent agents can already deliver context-sensitive information based on what an application has learned about you. Looking forward a year or two, it's not difficult to envisage applications on your iPad or smartphone that can understand the knowledge you're likely to need for each task or meeting. It could make the one or two relevant items in the organization's knowledge management system available to you as needed -- plus, of course, the relevant project information. If the context is not clear, advanced links could even find a "knowledge master" who's immediately available for additional advice. The smart systems then learn from your interaction and update the corporate knowledge banks. Add the ability for you and your colleagues to then input lessons learned and you have the basis for a true learning organization. Many of the elements are already in place. The question is, are we, as a profession ready to make effective use of the potential? |
Put the Pen Down and Trust Your Team
| In one of my last posts, "How Much Proofreading Is Too Much?" I wrote about another hypothetical situation involving Sebastian and his habit of correcting everything written. As a number of commentators correctly suggested, the appropriate quality for the documentation depends on its intended use. Certainly information sent outside the organization should be as close to perfect as possible and "two sets of eyes are better than one." This wasn't the core issue, though. Sebastian is proofreading and correcting minutes, notes and other internal, short-lived documents to the same high standard. The purpose of technical documentation within a project is to get ideas across in a way the concerned audience can understand. Sebastian's team may need training and support to create effective documentation, but striving toward perfection doesn't add value. The key to solving this problem is helping Sebastian understand that continually criticizing people for not achieving perfection can be extremely debilitating and will reduce his team's effectiveness. This is not his intention, but is the perception of people who receive Sebastian's heavily corrected documents. The ideal solution is to get Sebastian to understand how detrimental his behavior is. Achieving this may require people who Sebastian sees as experts and advisers to coach him to improve his team-management skills. Alternatively, effectively "advising upwards" by focusing on Sebastian's real interests, such as product delivery, may be a solution. Neither of these options, however, is likely to provide a quick solution. Changing habitual behaviors can take years and requires the person making the change to want to change. A more practical alternative may be to reframe the problem. Written communication is only one way of conveying information. Alternative approaches may include scheduling brief discussions to resolve issues, using web portals to make documents shared resources where everyone contributes or changing the media to something where grammatical structures are less important. Unfortunately there are no easy answers to this problem. For those on the receiving end of Sebastian's corrections, recognize that a criticism of a document you have written is not a criticism of you and use the opportunity to improve. (You should see what the editors do to our posts...LOL) |