Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
5 Things I Learned from My First Project Manager
Categories:
Risk Management
Categories: Risk Management
| In the early days of my career as system analyst, I had my first assignment working directly for a project manager. My project manager -- let's call her Rita -- was assigned to turn around a failing software package project. Over the next several months, under Rita's direction, the project was implemented with great success. When we parted ways at the completion of the project, I asked Rita for her keys to project management success. While tools and processes have changed over the years, what she said has served me well managing all types of projects. Following her advice has led to successful delivery outcomes and helped me mitigate risks along the way: 1. Schedule project meetings on Mondays Rita maintained that Mondays are better than Fridays to catch up on project progress. Her rationale was that you could better forecast and make the work for the current week visible. It also had the extra benefit of re-charging our minds for project work after a weekend. 2. Enable progress Instead of providing input on how the system would function, Rita spent time orchestrating the actual work of the project to enable progress. For example, during the project's design phase, she provided useful requirements and design templates that allowed us to better organize and align our efforts. In addition, rather than assigning risks and issues to others on the team, Rita took personal ownership of solving them. This allowed team members more capacity for work while Rita worked in parallel to mitigate issues. 3. Functional design is everything Rita always stressed that it was essential a project have sufficient time to complete a full functional design process with no shortcuts. She mandated that a full functional design process would also include the tracking of the design back to the requirements. On the project I worked on with Rita, this additional focus ensured that the software package was configured properly to meet all requirements. Rita also directed us to exhaustively pursue the design of interfaces. One of her constant comments was, "The value of what we implement is tied to the success of how it interfaces with everything else." 4. Use prototypes where possible Rita often said, "It's easier to see a system than to talk about it." Presenting system functionality by drawing pictures on a marker board is not an effective method of conveying how a system will work. Rita acquired access to a prototype software installation. This prototype not only allowed the project team to readily show what the software would do, it also enabled quicker design of the software configuration. 5. Manage delivery first, then costs Presenting a complex analysis of project budget during steering committee meetings is okay sometimes, but you must be able to answer fundamental questions around project progress. During her steering committee meetings, Rita would present escalated risk, issues and mitigation strategies for review and approval. This shifted discussion to delivery-related topics, which accelerated the progress of the project. "If you deliver successfully, the costs take care of themselves," she said. What are some project management principles you learned from your first project manager? |
6 Ways Agile Keeps Projects on Track
Categories:
Agile
Categories: Agile
| Using an agile approach allows project managers to spot right away when things are falling behind. Here's how: 1. Different levels of planning. Agile gives us the best of both worlds: a broad strategic picture and a real-time focused view. In Scrum, for example, teams plan at three levels: release, sprint and daily commitments. The release plans are designed to be risk tolerant and prevent teams from missing strategic goals because you can change 'in-flight' during the product release. The sprint plan pauses the changes so teams can focus for two weeks. At the daily stand-up meeting, individuals commit to their team members to finish something that day, which helps people collaborate when needed. 2. Blocker busting. One of U.S. statistician W. Edwards Deming's 14 principles for management is "remove barriers." Agile implements this at the daily stand-up meeting, where team members are encouraged to voice any blocker impending the project so that the team can assist in eliminating it. 3. Visibility. Agile uses tools like the release burn-down and sprint burn-down charts, as well as the task board to immediately show trouble in projects. Having them, using them and taking action when they highlight problems results in getting the most benefit. 4. Story flexibility. The waterfall approach assumes that all requirements can be explicitly defined at the start. Care is taken to create a solid plan and then control scope. In agile, it's an iterative and incremental approach. We admit pressure for scope changes will occur. Agile builds the ability to deal with change into its approach. A story, which is a means to show current and new project requirements, can be added during the release between sprints, and stories that are likely to suffer quality problems can be dropped from a sprint or release. 5. Empirical planning adjustment. Agile plans look at previous results with the current team and environment to better estimate how much work to do in the future. Every sprint and release teaches the team more about how much it should plan for future iterations. 6. Retrospective actions. Agile has a built-in step to openly discuss the difficult parts of the team's process and focus on actions to improve in the future. Rather than wait until the end of the project when it's too late to improve the outcome, agile features 'retrospectives' or 'lessons learned' at the end of each iteration.These meetings review what went well, what went wrong, and how to improve for the next iteration. Given these six opportunities to spot problems during all stages of the project, it's unlikely trouble will escape undetected for long. How else do you think agile helps keep projects on track? |
Denial in the Project Environment
| In the children's story, The Emperor's New Clothes, a vain emperor hires two people who promise to make him a new suit of clothes that will be invisible to anyone who is unfit for his position. The emperor cannot see the clothing himself, but pretends he can so as not to appear unfit for his position. Instead of questioning or pointing out the truth, his subordinates do the same, choosing to consciously deny a truth, praising and congratulating the emperor. In this story, the emperor's men displayed a common behavior -- denial -- that stems from the human need to protect oneself. I believe that this behavior exists in today's project environments, too. Often in project environments, for example, there is frustration over meetings and discussions that fail to address or acknowledge the proverbial "elephant in the room." These are the unproductive meetings that review irrelevancies, repetitive issues and problems, but never the actual root cause. Participants stay silent and indirectly endorse the status quo, but then proceed to gather in "safe" groups to discuss real problems and sentiments away from the ears of managers and leaders. Failing to challenge, speak up or change a situation are all behaviors stemming from denial. Project professionals may choose to deny something out of fear of consequence or feeling embarrassed if deemed wrong. Sometimes it's out of self-preservation because it's easier to be a "yes" person than to challenge the status quo. Behaviors stemming from denial can also result from over-optimism -- especially when it comes to risk identification. Overly optimistic people tend to deny anything is wrong or can go wrong. Denial can also cause negative consequences for individuals, teams and projects. If left unchecked, denial can become part of an organization's culture. Project leaders must recognize and reform denial behaviors. Doing so can uncover deficiencies, eliminate blind spots and help an organization become more efficient and competitive. By removing the root causes for denial, individuals will align their interests and act in favor of the team, project and organization. In my opinion, the best way to do this on your project team is to lead by example. Set standards by being decisive in day-to-day management. Implement and insist on good, documented work processes. Listen and understand colleagues, and work with the differences and opinions. Individuals on the project team should know what is expected of them and be made to feel valued, secure and included. Tell the truth about a situation, even if it is bad news. This encourages others reporting to you to do the same. Create a culture that encourages and rewards team members to flag issues and ask questions because problems that are visible stand a better chance of getting resolved. Do you agree that denial behavior can be a problem in the project environment? How do you root out the negative effects of denial behavior? |
Motivate Stakeholders on the Project Team
| When it comes to stakeholder management, many project managers forget to consider the project team members. Every project manager and team leader wants to direct a team of motivated people. And many team leaders probably know that the most powerful forms of motivation -- autonomy, mastery and purpose -- center around self-actualization. So as a project manager or team leader, it's up to you to facilitate these circumstances for each member of your project team. To do this, you need effective communication in three key areas: 1. Comprehension. Make sure the person assigned to a task understands the work and measures of success, and agrees he or she can achieve the desired outcome. Asking the team member questions and listening to his or her suggestions on how to best accomplish the work helps develop the team member's sense of ownership associated with autonomy. 2. Acknowledgement. Everyone likes to feel they have accomplished something in their workday. Facilitating this feeling is part management -- minimizing interruptions and diversions -- and part communication. Make sure a team member's progress is acknowledged on a regular basis and "accidentally" catch the person doing something right. You have to notice and rectify errors in performance. Balance this negativity by acknowledging positives. This is a daily process to keep the team motivated and focused. 3. Purpose. Change is inevitable in project management, and it's up to you to maintain a sense of purpose throughout a project's lifecycle. The challenge usually comes when you have to move a project team member to another role or change his or her objectives. This can be especially frustrating if the team member has developed a sense of purpose around his or her overall project objectives and work. If you simply instruct people to change, you risk damaging or destroying motivation. Instead, communicate these four points:
Above all, communicating to motivate has to be authentic to be effective, and it need not require too much time and effort. Plus, the extra time spent motivating will be more than repaid in better team performance. How do you keep stakeholders happy on your project team? |
To Create, Learn to Borrow — and Other Lessons from PMI® PMO Symposium
| The 2012 PMI® PMO Symposium closed with a wake-up call on innovation, delivered by author and speaker Fredrik Härén. People significantly overestimate their ability to create and innovate, he said. So much of what passes for "an idea" isn't really anything new, but rather a combination of things that already exist. In his equation, ideas arise when people combine new knowledge with information they already have. Mr. Härén cited an Estonian innovator who created a combination urinal and sink that saved time, water and space. "If something 2,000 years old like a urinal can be improved," he said, "what else can we improve on?" Yet while most people agree creativity is important in their jobs, Mr. Härén mentioned that only a tiny fraction say their organizations do enough to encourage it, especially at that combination stage. Mr. Härén argued that Asia will driving creativity in the future. "They are better positioned to innovate because they live where the change is happening," he said. There may be some truth to the idea of innovation being based on "stealing," but he reiterated the notion that all creation comes from copying some part of something existing. Instead of worrying about "copyrights," he said, worry about "copying right." The final day of the symposium also featured Treasury Board of Canada Secretariat Greg Kenney discussing his organization's new plan for a principles-based, risk-sensitive, results-based management regime. At the heart of the endeavor is an assessment designed to determine each department's project capacity and class. This, in turn, helps the Treasury Board determine the oversight level required on projects within each department. By implementing these new assessments, the board can ensure resources are allocated with consideration to risk and strengthen the link between spending and results. As in previous days, the symposium's last day included breakout sessions. In one, Carol Church, director of the PMO at CareFirst Blue Cross Blue Shield, discussed how her organization used project management software to save US$29 million a year. She also reminded attendees that PMOs can gain visibility and support across the organization by pitching themselves as a partner looking to help people succeed. Though this symposium is done, stay tuned for details on next year's event when PMI is slated to reveal the results of a seminal study on PMOs. |