Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Kevin Korterud
Three Reasons to Dim Project Stoplights
| Hardly a project status report goes published without at least one stoplight indicator. As the name suggests, stoplight indicators show the status of key project progress measurements: green (good to go), yellow (use caution) and red (stop or danger ahead). In recent projects, I have noticed recurring instances of "stoplight overkill." Project status reports now include all manner of stoplights, such as how the last status meeting turned out or the happiness level of every single customer group. In fact, I have even seen a stoplight indicator that, through a complex calculation, was intended to show the aggregate status of 40 stoplights. The colors on that report made my head spin. Beyond avoiding a headache, here are three major reasons why project managers should limit stoplights:
I favor more progressive and consistent modes of status presentation that indicate position, direction and pace. For example, use a remaining budget marker to show the position of budget against a broader range of tolerances. For deliverables, you can show a scatter plot of projected and actual completion dates to reveal pace and true progress. Highlighting customer satisfaction on a timeline is a good way of showing the impact of a project on a sponsor's business. What do you consider the limitations and dangers of project stoplights? What alternate methods have you used on project status presentations? Share your thoughts below along with your Twitter handle, and Voices on Project Management will publish the best response as a blog post. |
Three Timeless Project Management Rules
Categories:
Reflections on the PM Life
Categories: Reflections on the PM Life
| We all seem to have our own set of "durable" project management rules. We rely on them again and again to help guide us to a successful project outcome, regardless of the type of project, technology or environment. Years ago, I read Kelly's 14 Rules & Practices, which to me made sense for any project. Authored by Kelly Johnson, the founder of Lockheed Martin's Skunk Works® for Advanced Development Projects, the rules helped teams on pioneering aircraft projects produce innovative deliverables under budget and on schedule. I plucked three from this list and adapted them to apply to my project management career: 1. The number of people connected to the project must be aggressively restricted. For me, it has been quite common to have people seek a connection to a project, especially if it has had a high degree of executive visibility. Project managers who invest in aggressive stakeholder management -- that is, blocking non-essential roles -- have clearer communication in their projects and better-defined roles, which also helps new team members know their role relative to others on the team. 2. There must be a minimum number of reports required, but important work must be recorded thoroughly. I have been on some projects where the effort put into status reporting almost exceeded the effort put into project activities. Too much in the way of project reporting is just as dangerous as too little. Based on the type of project, the most successful project managers focus on a small number of essential metrics (schedule, budget, milestone, deliverable variances, etc.) that are easily understood by both the project team and the stakeholders. 3. There must be a monthly cost review covering not only what has been spent and committed, but also projected costs to the conclusion of the program. It is typical for project managers to host meetings to review prior project spend as future spend forecast. The crucial term in this rule is "what has been committed" to the project, both in terms of funding and resources. Many times, project managers fail to include funding and project resource commitments during a cost review. Even though I read them long ago, Johnson's rules still resonate today. This October marks the 70th anniversary of the 14 Rules & Practices. Talk about durability! What are your "durable" project management rules? Skunk Works and the 14 Rules & Practices references courtesy of Lockheed Martin. |
A Project Management Wish List for 2013
| Another year for project managers has come and gone. And while this is the time for all the usual year-end activities (budgets, status reports, etc.), it's also a good opportunity to look toward the future. To project managers around the world, I wish you health and prosperity. I also thought I would share a few other dreams I would like to see come true in the New Year: 1. Talking project plans. From GPS systems to smartphones, just about every device offers a verbal communications mode nowadays. The same technology should be applied to project plans. They could alert you to urgent issues: "Your resources are overloaded" or "You need to add more tasks." A talking project plan could even present an entire status report without you speaking a word. Think how much fun your meetings would be when the project plan says, "Just go home because your project will never make its projected end date." 2. Project issues that solve themselves. Project managers know that early detection of project issues is the key to staying on schedule and budget. We hold resolution meetings. We collaborate with leadership to craft brilliant solutions. Yet every so often, it would be great for issues to just solve themselves. For example, say your project is over budget. Then suddenly you get an e-mail from your project sponsor that grants extra funding due to your company's outstanding performance this year. A project manager can dream, right? 3. Resources ready, willing and able to jump into the action. We spend a considerable amount of time identifying resources and negotiating for their availability on a project. And still, we see our schedules fall apart when they're pulled away by other demands. Just once I'd like to have a project where everyone is fully dedicated, with no other distractions to threaten the schedule. It would make me very happy to hear a project team member turn down a meeting with the company president to work on my project. 4. No change requests. During the early phases of a project, we work to create the most accurate set of requirements possible. We consider it all — the many functional needs and the hidden complexities. After all that work, wouldn't it be nice if everything remained precisely the same throughout the life cycle of the project? Think of the time you could save by canceling those painful weekly change-request meetings. 5. Give back all contingency funding in the project. We typically reserve contingency funding to guard against unforeseen events. Imagine the sheer joy of having no project risks that required budget or schedule relief. Just think of the satisfaction of telling your project leadership "We have no weather, people, software, hardware or network risks, so we are returning all contingency funds!" What's your project management wish for 2013? |
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? |
5 Overlooked Project Risks
| Experienced project managers frequently encounter common project risks, such as lack of available resources or slipped deliverable dates. But what about those risks that people don't often think of? While often overlooked, these risks might be more real than you think and can often reveal other project challenges. Here are five unusual, but real, risks that I've heard from project teams. If yours ever brings one up, don't be so quick to dismiss it. 1. Weather The first phase of a software solution deployment targeted several cities with a generally temperate climate. The project team reported a risk of weather delays and asked for a two-week schedule contingency, which was greeted with laughter and objection by the steering committee. Sure enough, the deployment cities experienced their first snowstorm in decades, which resulted in delayed deployment--as predicted. Future deployment planning included a contingency for weather-related changes. 2. Video conferencing capacity A project team presented a report showing it was behind schedule. Team members blamed a lack of robust video conferencing capability, which the steering committee responded to with shocked silence. After the meeting, the project manager discovered that the original project plan did not consider the risk of requiring frequent communications to coordinate development at multiple sites. Identifying it as problem not only fixed the issue, but it led to resolving additional communications issues. 3. Lack of project experience One project team declared that its own project manager was a risk because he didn't have any experience leading projects. As a short-term solution, a senior team member was asked to assist the project manager. Examining this risk further revealed that there were several staffing challenges, including replacing the senior team member assisting the project manager. Had the project manager not been identified as a risk in the first place, they never would have recognized resourcing issues. 4. Vacations and holidays A project team with limited global deployment experience scheduled a European deployment milestone during the month of August. It later reported a risk of difficulties finding local resources to help with deployment due to vacations. After realizing that August is typically a vacation month for Europe, the steering committee not only approved a schedule change, but it also examined the vacations and holidays of the other countries on the deployment schedule. Based on this input, the project team adjusted the schedule and successfully achieved the remaining milestones. 5. Termites One project team declared termites as a project schedule risk. After the steering committee brushed off the need for insecticide, the team shared that termites had chewed through the supports of a mobile office trailer. The damage caused the trailer to be declared unsafe and prompted an unscheduled office move. Moreover, the team members also revealed that they were working in separate mobile trailers, which hampered productivity. Thanks to the initial schedule impact, the project team was relocated to contiguous indoor office space and increased productivity. Have you ever overlooked any risks? What were they? |