Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
A New Take on Standup Meetings
Categories:
Agile
Categories: Agile
| Short daily meetings are a cornerstone of agile project management. Team members usually address three questions: 1. What did they do yesterday? 2. What will they do today? 3. What roadblocks stand in their way? Some teams use an alternate format with a quicker flow. Looking at a task board, an appropriate team member says how many hours are left on each task. Once a task is complete, it's moved to the next state (test or done). If the team has capacity to take on more tasks, another one is pulled from the queue. At the end of the meeting, the team can see if someone needs work, can help another person or determine if there are any hindrances. This meeting format emphasizes little wins as tasks are moved from state to state. People get some positive feedback and congratulate each other -- which is important to the long-term functionality of the team. This type of meeting also keeps people from discussing work not related to the teams' tasks. It still allows space to discuss impediments and team utilization -- but only if necessary. Teams using this approach can complete their daily 15-minute standup meeting in 10 minutes. More importantly, there's a feel of energy and drive in such meetings. The three-question format is tried and true. If you find your meetings feel sluggish, give this format a try. You may find it turbo-charges your meetings. Which approach do you prefer? |
Managing Projects and Teams with Velocity
Categories:
Teams
Categories: Teams
| Velocity measures the rate of motion. In the context of projects, velocity is about teams accomplishing work faster, with less resources, better quality and greater satisfaction. As project teams get used to each other and adjust to the organization's processes, culture and communication methodology, team members' potential for contribution increases. As team engagement increases and members align themselves toward the goals and objectives of the project, overall performance increases. Velocity is achieved when team interactions are completely in sync with the project goals, the rationality behind the target dates and the planning it takes to meet those dates. In a project environment conducive to velocity: • There's a clear direction, everyone's roles are clarified and there's flexibility for team members to contribute in other parts as appropriate. • Members manage their own time, guided by their mandates or objectives. • Teams choose their own method of communication. It could be acquired from other similar projects or specifically designed for the given team. • Team interactions -- phone calls, meetings, workshops, etc.-- are managed as the needs arise, rather than "boxing" teams into preset parameters. On a project with velocity, the force behind the team executing the work gets to be so powerful that it's not the project manager who ends up giving the power to the team. The team itself generates that power and project execution moves with subsequent velocity. Are you managing with velocity? |
Project Management: An Organizational Competency
Categories:
Education
Categories: Education
| Competency-based management is a tactic that some organizations are using to recruit, hire, train, develop and manage employees. Competencies are sorted out in three categories: Organizational competencies combine the skills, information, performance measures and the corporate culture that an organization uses to achieve its mission. All employees must demonstrate these proficiencies. Job role competencies include the abilities needed to perform a specific role in the organization. A field supervisor, for example, must have similar skills to supervisors in accounting, customer care or sales. Although they are in different department functions, they must exhibit a common set of supervising skills. Position competencies are specific to the position you perform in your organization. An account manager, for example, must demonstrate capabilities that include proficiency in sales. An IT support engineer, for example, must be a master supporting the core systems an organization uses. It's common for organizations to think project management is a skill at the position level and that it is just for project managers. The reality is that project management is an organizational competency. If organizational strategy drives strategic changes and those changes are executed as projects, project management must be an organizational capability rather than a job skill. If project management is an organizational competency, it's required to define a training program within the organization to develop everyone's project management knowledge and abilities. I suggest starting with an awareness meeting for all employees. Once that's completed, host specific teaching sessions for executives who will support projects and then for people who participate in projects. Both must deliver non-technical project management knowledge. What do you think? Is project management an organizational competency? |
When Is Program Management the Right Choice?
Categories:
Program Management
Categories: Program Management
| Project managers often ask me: When is a program needed? Under what circumstances is program management appropriate? What's the difference between running multiple projects at the same time and running a program? In terms of delivering a benefit or generating a synergistic outcome, program management can help. This is especially true when you're managing interdependent projects. Say you're running four projects at the same time: a hardware development project, a 3-D character animation project, an exterior design project and a controller project for a game console. You can indeed manage these four projects separately with shared resources and technologies. But if two of the projects come from the same client, you should have a program. Or if your company plans to own the game console -- which requires you to produce a product by integrating the deliverables of each individual project -- you need a program. Take Nintendo's Wii. Development of the console definitely calls for the centralized, coordinated management of a program, or at least, a program-like logic to run it. Making the Wii requires coordinating the component supply, system coding, and exterior and hardware design, including the controller. There is also storyboard planning for plots and characters for Nintendo-owned licenses to help launch the console, layouts for different language versions, etc. Of course, the design and production of each specialized component will have to be done through individual projects. Yet they end up being part of a wider program because they are interdependent with all the other components for the final console. A program is also necessary because to deliver the final console on schedule, a greater degree of governance has to be used. It must ensure that the projects run as planned so individual delays do not hamper the overall output of the program: a finished, completed Wii console. What do you think? How do you know when program management is your best option? |
When Project Decisions Get Difficult
Categories:
Teams
Categories: Teams
| Two important members of your project team recently ended a six-year romantic relationship. While they're both trying to keep their domestic problems out of the workplace, the inevitable tensions between the two ex-partners are obvious and are causing the team to split into two camps. The situation is affecting the team's ability to achieve a successful outcome on a high-stakes, high-pressure project to deliver critical capabilities to a customer. You've tried working with both team members and sought assistance from the HR department to minimize the issues with limited success. Each of them is vital to the delivery of the project's objectives. However, you've suggested to both that perhaps the team would be better off if one of them moved onto another job. Unfortunately, neither have a viable option. Your analysis of the situation is as follows: If either of the people leaves, the team's ability to deliver the project will be reduced by 10 percent. If both of them leave, the team's ability to deliver the project will be reduced by 20 percent. If both stay, the team's ability to deliver the project will be reduced by 25 percent and will get worse over time. The customer cannot afford any reduction in the team's capability to deliver this business-critical outcome. As the project manager, what would you do next? Post your comments below, and in my next blog, I'll summarize reader reactions and look at the options. |