Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Improve Burndown Charts for Your Projects
Categories:
Agile
Categories: Agile
| Agile teams use burndown charts to show the amount of work completed over time to monitor their progress. There are three common patterns to look for in a burndown chart. When progress stalls, the line becomes flat. When work is added, the line shoots up. And sometimes, the rate of work slows and floats above an ideal trend line. Let's look at some baseline data, reflect on the meaning revealed by the charts and see where teams can improve. The following burndown charts show how many task hours are left for the team. The goal is to drive the remaining work down to zero by the end of the time-box. We'll start with a graph of three iterations completed by one team in two weeks. Sprint three is still underway, which you can tell because the line for it is unfinished. But what happened in these other iterations? In sprint one, there is a catch-up pattern. The team stalled in its progress from days 8 to 11, and then made a push to finish. As a result, the team signed up for fewer hours in sprint two. This is common, as teams plan for more work than they can get done at first to help them plan for the next sprint. In sprint two, the team faced a different problem. A bubble of work formed at the beginning because the team didn't plan the sprint process correctly and had to add work. Both of those issues in the normal rate of work can confuse efforts to forecast the rate of progress based on the first few data points, allowing for improvements down the line. Instead of looking at the trend from the first day's allocated work, for example, take the maximum amount of work anticipated and plot that from day one. Ideally, the maximum amount of work will be accomplished on the first day. But in the case of "bubble" sprints where work is added mid-course, drawing a line from the sprint's maximum workload as though it were known on day one will give a better presentation of the ideal trend line. The next problem is a plateau every few days. The graph originally provided data for 14 days including weekends, not just the 10 working days in the sprint. It looks like the team is unproductive every few days, but it is simply a reflection that they took the weekend off. Adjust the burndown chart, as I've done below, by accounting for added work and masking non-workdays and your team will have a clearer picture of its iteration's progress. What adjustments do you make to burndown charts to ensure an accurate depiction? |
Excel as a Project Team
Categories:
Teams
Categories: Teams
| What makes projects move and people excel? In my opinion, there are three characteristics that are consistently found in great project practitioners: 1. Urgency 2. Persistence 3. Desire Executing projects with a sense of urgency means you and your team must really apply yourselves. Every day has to be productive. Tools must be properly utilized. The work needs to be completed with quality and according to the requirements. Don't look at the future as a way to fix the mistakes you might make today. Address items immediately and effectively so that you don't make them again. Persistence means not giving in or giving up. Nor should we quit when things get tough. Don't let it slide when you feel less productive: You and your team should encourage each other to be in motion at all times. After all, we are hired to perform a specific job. The more we stick to being professional and complete in the work we do, the higher level we will reach in our daily execution of project tasks. Finally, have the desire to be great. That means don't settle for second best or for a "good enough" result. You should want to outdo yourself, to be more effective than in the past. Strive to complete more work through effectiveness and with higher quality than you think you can. It's the only way to improve yourself. When the entire team is aligned to such a work ethic and mindset, it no longer is a job for a project manager. It becomes a game and a challenge that everyone on the team takes on and is excited to be part of. Together aligned we achieve more, have fun, constantly grow and become better at what we do. What do you do on a project team to add value to the team effort with your own individual effort? |
Build a Business Case for Lessons Learned
Categories:
Lessons Learned
Categories: Lessons Learned
| If you are not having project reviews and meetings to address lessons learned, it may be that your project sponsors do not count these as valuable activities. You know better, but how do you make a convincing argument to have project reviews? You must take the discussion with your project sponsor to a different level. It's not "we just need to know what happened." It's "we want to take action and get better results the next time around." The lessons learned meeting could make you aware of changes that may be needed to turn business from being bleak to being more successful. Give your sponsors succinct reasons to pursue assessing projects to make improvements. Consider these tips to influence your supporters: Gather statistics and determine what you need to measure. If your company is concerned about quality, chart examples of projects where quality was lacking. If ROI for projects has not been good, share those examples. Share success stories. Bring up achievements that occurred because of the attention on improvement. Discuss the situations that will make a difference to the bottom line. Make a plan. As a project manager, you already know that planning is important. Prepare a well thought-out plan for gathering and presenting the lessons learned. Then use the newly acquired knowledge. How have you built a business case for lessons learned and project reviews? |
Why Getting Mad Can Benefit Your Projects
Categories:
Human Aspects of PM
Categories: Human Aspects of PM
| "Get mad, then get over it." --Gen. Colin Powell, USA (Ret.) Generally, people consider anger to be a negative emotion. But it doesn't have to be. Let's review the positive side of anger: Anger can benefit relationships. Many of us are told to hide our anger, but doing so could be detrimental to your relationships. For example, if you're angry because of a mistake that a project team member has made and you don't speak up, he won't know that he has done something wrong. He will probably keep doing it and enter into a vicious cycle. On the other hand -- if justifiable and aimed at finding a solution --expressing dissatisfaction can strengthen relationships. Such honest communication can help solve problems among stakeholders and build cohesiveness into your team. Anger can motivate. Anger can prove to be a powerful motivation force, helping you "go the extra mile" and keep working despite problems or barriers. For example, if you're criticized for your work, you may feel further motivated to do better because you are angry and want to prove that you can improve your level of performance. In project management, if we are able to produce what is called "positive anger" in our team, they will be more motivated to achieve results. But don't make a team member mad just for the sake of it. Find the right words to push them in the right direction. Anger can indicate an optimistic personality. Ironically, happy people have something in common with angry people. Both tend to be optimistic. Take the study of risk management, for example. Dr. J.S. Lerner, professor of public policy and management at the Harvard Kennedy School of Government, found that angry people expressed optimistic risk estimates. Estimates of angry people more closely resemble those of happy people than those of fearful people. It's okay to get mad, but always behave professionally and treat people respectfully. Don't let wrong behavior undercut a right message. At the end of the day, we're all human. We all have feelings, one of which is getting mad. Use positive anger when you can. Above all, be able to communicate when you're angry in a way that doesn't undercut your message. Have you ever used anger in a positive way in your projects? Read more from Jorge. |
Craft "High-Quality" Requirements
Categories:
Project Planning
Categories: Project Planning
| Project requirements derive from concrete business needs or business-use cases and constitute the foundation for the project work. Without requirements, projects cannot exist. Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements. On the other hand, requirements that are clear, complete and understood by all the parties are of "high quality." They build a solid foundation for the project work. Collecting high quality requirements can be a challenging endeavor for several reasons: • Stakeholders often don't speak the same language (business vs. technical) • Stakeholders have different understandings and views of the product • Stakeholders have different backgrounds and expertise on the matter It may not be the project manager's role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted. The following guidelines should help in collecting high-quality project requirements: 1. No requirements without a use case Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements' context and purpose. 2. Requirements language Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently. You might consider using a glossary of terms to ensure common understanding. Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use "shall" or "must" instead of "should" or "might." Remove any room for interpretation. Avoid the usage of "and/or" together or "including but not limited to." 3. Requirements characteristics checklist Build a checklist of requirements characteristics that are relevant to your project's quality standards. Evaluate each requirement against the checklist. Here are 10 characteristics that I successfully use to evaluate the quality of requirements: Atomic: Is this a single requirement or multiple requirements in one? Complete: Is this comprehensive enough to start working on it? Traceable: Is this related to a use-case or need? Logical and Clear: Does it make sense? Does it leave no room for interpretation? Consistent: Is this consistent with the project objectives and other related requirements? Measurable: Is this measurable once a solution is delivered? Compliant: Is this aligned to the current product features, system architecture and legal framework? Feasible: Is this realistic and doable given the complexity and the project context and constraints? Necessary: Is this really required given the project objectives and constraints? Or is it more of a want than a need? Prioritized: What are its criticality, urgency and priority? What best practices do you use to ensure that project requirements are of high quality? |