Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Coaching Through Process Improvements
| Being involved in process improvements can feel similar to being audited -- not pleasant. So how do you make the period of process improvements more manageable for your team members, especially when they are project managers themselves? When creating process improvement initiatives, look at it as an opportunity to motivate your team members. Morale is likely low and improvements should be made. Hand-hold your team members during the process. Instead of sitting in front of them like an interviewer would, sit next to them -- be a peer. This will help them see that you're making things better, not making their lives messier. For example, I'm currently spearheading a process improvement initiative where the objective is to improve the current project management techniques for project implementation. Before I even started this project, I was told that I'd face some adversity. But I have a plan. I want to make the initiative as painless as possible, so I plan to turn the investigative process into a learning process -- both for my team members and myself. I will take on a student's point of view, rather than as the instructor, because I'm learning, too. I'll also try to be more open. I want my team to share their plights and success stories with me. I'd like to construct a scenario in which my team members learn new things from their experiences, seeing the areas that can be improved or approached differently for themselves. It is a common saying: Things will get worse before they get better. Managing team members during process improvement period is like that. They will dislike you before they like you. Adversity is to be expected, but as the saying goes, impossible odds make achievements more satisfying. What do you think a project manager should do to garner cooperation from team members during a process improvement initiative? How do you turn process improvement initiatives into a learning process? How do you manage team member resistance to change or idea makeovers? |
Mitigating Risk with Project Advocacy Consultants
| Besides scope, time and budget, the core of project management success is stakeholder acceptance of project deliverables. As such, the risk of stakeholders rejecting deliverables should be identified and mitigated in a project's early stages. For example, stakeholders in infrastructural development projects, like members of a surrounding community, make certain choices about project execution, such as location, quality and schedule. But, this doesn't always happen. If residents, say, are denied vehicular access to their homes because of an ongoing road re-construction, it's clear there was no stakeholder representative during the execution planning of the project. African governments often rely on public private partnerships (PPPs) for utility and infrastructure projects. But most proponents of PPPs settle for a design-bid-build business arrangement, in which a single vendor may win concessionary bids to develop, operate and transfer utility infrastructure schemes. In this instance, a concessionary bid is a solicitation process for PPP projects. This kind of business arrangement increases the risk of eroding the values and interest of that community. Sponsors and vendors could decide to satisfy themselves to the detriment of the residents or other project beneficiaries. One way to mitigate the risk of communities rejecting infrastructure projects could be to use project advocacy consultancies, which are composed of community and government representatives. The committees ensure that infrastructure projects address the needs of the communities and are accepted by them. In Africa, it would be a major stride in project management if stakeholders approved of the deliverables of PPP infrastructure projects. Of course, projects would be more widely accepted if communities were involved during the planning and execution of deliverables. In my opinion, highly leveraged infrastructure projects that are initiated under concessional business arrangements and executed without the involvement of the would-be users should be discouraged. In turn, profits made by promoters and vendors from infrastructure projects could be better justified vis-Ã -vis community acceptance of the deliverables. If communities approve of infrastructure projects, post-project operations and facilities management, it would benefit everyone. Promoters would smile at the projected cash flows, vendors would satisfy both contractual and project obligations, and ultimately, the project would be successfully completed. Do you think involving stakeholders at the outset eliminates project risks? If so, how? What do you think about using a project advocacy consultant? Read related posts: "Different Perceptions of Risk on Projects" from Lynda Bourne. "Use Project Management Tools in the Right Context" from Saira Karim. |
Different Perceptions of Risk on Projects
| The July Project Management Journal includes an interesting paper highlighting two approaches to understanding risk: 1. Risks as facts: Risks are treated as objective, technical, neutral events that can be managed based on the knowledge produced by objective analysis using probabilities and expected values. The outcome is rational decision making. 2. Risks as subjective constructions with multiple dimensions: Risk managers choose the context and perspective they adopt. This allows multiple rationalities to coexist, depending on the values and perspectives of the observers. (This explains why some people find jumping out of an aircraft fun.) From a project perspective, risks are uncertainties that matter. All estimates about future project outcomes incorporate a degree of uncertainty. This includes the three key dimensions of project management: timing, cost and quality of future project deliverables. The project manager cannot be certain that the estimates that make up the project schedule or cost plan will prove to be correct, or that the project team will create deliverables to the appropriate quality standards. The rational management approach is to assess the risk factors and develop appropriate time and cost contingencies, backed by appropriate reviews and tests to ensure optimum quality. This approach is highly objective and rational. However, you cannot rely on your stakeholders having the same view as you. If a stakeholder sees your project in a different context, their perspective on risk will be different. For example, if you created a contingency plan using a Monte Carlo analysis, an executive may interpret the plan as a sign you don't understand the project because he or she expects a single definitive result. From this stakeholder's perspective, the precise calculation of a critical path method schedule offers certainty and minimum risk. The authors of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) have a different perspective, which understands the benefits of 'three-point estimating.' You cannot assume your stakeholder will have the same view. The challenge is to accept that a range of stakeholder perspectives will occur. Stakeholders may derive completely different opinions from the same data. You should anticipate this possibility and adjust the way you package your project information to communicate more effectively and ensure both you and your key stakeholders have a common understanding of the risks and issues confronting you project. How do you deal with the challenge of managing different stakeholder perspectives on risk? Read more on risk management. Read more on stakeholder management. |
10 Years of Agile Practices in Project Management
Categories:
Agile
Categories: Agile
| One decade ago, 17 people who were well-known software leaders met to figure out a better way to build software. Frustrated with traditional methodologies, they brainstormed, argued, discussed and analyzed how the future should look. The result was The Agile Manifesto, which is comprised of four values and 12 principles. In August, Laurie Williams, PhD, led the Agile 2011 Conference, where most of those leaders reunited for a panel discussion. Dr. Williams conducted a worldwide, open survey of 335 members of the agile community across the world to research possible changes to the manifesto. She announced her conclusion that the original manifesto remained valid, saying that the original creators of the manifesto "nailed it" -- even 10 years later. The manifesto authors each talked about the initial meeting held 10 years ago and how agile is trending today. Bob Martin said, "our original meeting was probably the only meeting in my career that actually worked." Ken Schwaber poured water from a pitcher as a visual metaphor for the last use of waterfall. Jeff Sutherland described how developers he's met in the past 10 years have been moved to tears by having a process that worked. But the panelists warned that not all teams do agile well. Some teams call themselves agile but don't do the harder practices. The consensus during the panel session was that the moniker of "agile'" will fade away and simply be how we manage projects. Not just for software, but beyond. The agile conference was impressive because of the growing diversity of tracks. In addition to the usual technical sessions for software testing and development, many sessions covered people skills, including ones on coaching, cultural mapping and distributed teams. Information on the new PMI Agile Certified Practitioner (PMI-ACP)SM certification was also popular. What will the next 10 years bring? New leadership will expand from the original signatories of the manifesto to those doing agile project management today. And as expressed in the Japanese concept of kaizen, many small improvements will add up to more streamlined productivity in many steps and many teams. How do you see agile advancing over the years? Read more about agile. |
Take a Purposeful Break from Your Project
Categories:
Reflections on the PM Life
Categories: Reflections on the PM Life
| Project managers take various breaks throughout the work day: lunch breaks, coffee breaks, meeting breaks, and so on. Maybe you need a break after reading an intense project plan, or conversely, you need to take a break from working on a project to read the plan. No matter the break's impetus, it ultimately comes down to having a distraction from what you were doing. Consider taking a purposeful break -- one that isn't simply a distraction or escape from a previous activity, but, as the name implies, that has a purpose and therefore achieves a desired result. I find that doing so allows you to be more productive and to re-energize faster. It's the same approach that we use for effective project meetings. Making sure that we focus on the agenda, follow all the topics and cover the intended elements. What works best in this case is staying focused on the task at hand, remembering the purpose and the planned or expected outcome. To take a purposeful break, I suggest you do exactly what you want to do. For example, if you need five minutes to unwind after an intense meeting, do nothing else but listen to music. Don't try to figure out something about the project activity you were just involved in or what you are about to do next. Just sit quietly. By allowing your mind to truly rest and disconnect, I find you are more effective at whatever activity you take on next. When we focus on an activity completely, it reduces multitasking, and we are able to complete the activity in less time, at a higher quality and with a sense of accomplishment. It's contagious: the more you get done in less time, the more you feel you can do. This information may seem like common sense, but taking purposeful breaks regularly is what is going to contribute to one's effectiveness in project execution and time management. |