Leonard ByrdProject Manager| Consultant - Partially RetiredMansfield Center, Ct, United States
When one takes a 30,000 foot elevation look at scheduling we are simply documenting failure rather than creating progress through the planned path forward. When one realizes a Project Schedule is a copulation of many smaller schedules of other subs, manufacturers, fabricators that are brought into the Project after the original schedule. Plus, the Project Schedule is usually based on 80 % design, 10% Procurement and 5% Construction and its only one's best guess at the future so the only guarantee is it will change. Then add to that a single project has say 50,000 project deliverables (Specific documents - actions required prior to any installation such as permits, submittals, certificates, samples, shop drawings, test reports, safety plans , financial - insurance plans and multiple product data confirmation packages that are not sufficiently identified in the schedule activities and typically are not contracted for until 2 to 3 months into the project so is it any wonder a schedule review accomplished on day 150 (5 months in) is not going represent any form of management if you are tracking schedule activity completions. Your Schedules are tracking less than 5% of critical activities, all the quality control predecessors are not being confirmed or even tied to the schedule ..... so why would think anything would happen on a tool that tracks completion and does nothing for progress. Wouldn't it be better to track starts and include all the deliverables? What's the chance for success if a NTP is issued and EPA permit is not in place, or an excavation firm cannot get a bond, or get a safety plan accepted ... or any of the safety, code, financial, or quality control permission request required to get on site much less begin work. Should we not be compelling action weeks before the Mobilization milestone on the Project rather than waiting 3,4,5 months to simply blame someone for noncompliance at the 1st schedule review. It's simply common sense to define the 5Ws for the predecessors for all participants associated with Mobilization and check them off in sufficient time so that the Schedule Milestone can be met
Aaron don't get me wrong but what is the difference between a "Lesson's Learned" and a "Risk Register" other than when they are accomplished. Both simply list problems that have a potential to crash your project with little or no mitigation impact and are poorly communicated to the level of product activity. Utilizing my Construction experience - I hired on with Bechtel Inc in 1980 and while in the office I was given the "Make Work" project of compiling the "lessons learned" for the Mining & Metals Division - you can't imagine how many "unforeseen soil conditions" items were included yet not a single cure. In construction we have a huge problem with communications (5Ws). We need a mechanism to tell the responsible entity what they need to do in a timely manner to allow the schedule to be maintained or succeed. We need to compel action as well as accommodations to the schedule. While listing or identifying issues is good, if it fails to achieve motion - probably not worth the effort.
Leonard, to your point, the difference between a lessons learned document and a risk register doesn't matter if nobody is taking action on either. If your lessons learned documentation only looks backwards it has limited usefulness. If your risk register is just a list of risks it's not much better - maybe even worse. Neither scenario is a "document" problem. I've been there and understand the frustration.
My preferred approach for lessons learned, that I don't assume works for everyone and can't say that it works for megaprojects, is to capture them throughout the project, not waiting until the end, and maintain a 1-page max document of things that will need to be considered on future projects. Once it no longer matters on future projects, it drops off the list. Not everything on it is a risk. But, when a risk is on it, if it is relevant on a future project, it goes on the risk register and a risk analysis is performed - probability of it happening, impact of it happening (because it can be different on each project) - and a decision is made regarding how/whether to address it. If the decision is to take action, the action becomes part of the project plan. These are the highlights; you can find a post about my approach to lessons learned on my blog, here on projectmanagement.com. (I should write a new post that ties it into risk management)
Let me try and rephrase what I understand about what you need. You need a process where risks are identified, probability and impact are assessed and communicated, somebody in authority makes a decision about how to proceed, and action is taken. This is complicated by the fact that you're dealing with multiple entities and even when it's clear who the decision-makers are, that doesn't mean they're willing to take action or act like they're paying attention. Is this a fair assessment? You can use lessons learned documentation and a risk register in this process, but they're useless without the process, communication, and decision-making, and will likely be invisible to most of your stakeholders.
I can't tell you how many projects I've run where I created the project schedule, ran the project using the schedule, and had to create something different using the data in the project schedule to communicate status, risks, and issues with executives and stakeholders in order to get decisions made and escalate needed actions. Not everyone outside of project management speaks in project management terms or shares our interest in the tools we use; a critical part of a project managers job is communicating effectively and making sure the decision-makers have the information they need in a format they understand how to use. If you do that and they're still not taking action or making the needed decisions, and you don't know why, you need to dig deeper. You may not be able to dig deeper for political reasons or you may not have time to dig deeper for various reasons, but that doesn't change the need or the fact that your frustrations and outcomes are unlikely to change if things remain the same. At this point I feel the need to restate that this is from a global IT perspective, which is going to miss key points in a large scale construction context. Saving Changes...
Leonard ByrdProject Manager| Consultant - Partially RetiredMansfield Center, Ct, United States
Jun 07, 2026 6:57 AM
Replying to Luis Branco
...
You raise an important question.
Perhaps part of the answer is that activities are easier to schedule than readiness.
For decades, project controls have been very effective at representing work packages, durations, sequencing, and completion status. What has been much harder to represent are the hundreds of approvals, permits, submittals, quality gates, financial commitments, and stakeholder decisions that determine whether work can actually start.
In many projects, those conditions are treated as assumptions rather than managed deliverables.
As a result, teams often discover readiness problems only after they have already become schedule problems.
Maybe the real opportunity is not simply combining Primavera and Excel, but making readiness visible, measurable, and accountable in the same way we manage activities today.
After all, a Mobilization milestone is not achieved when the date arrives.
It is achieved when all the conditions required for mobilization have been systematically removed as constraints before that date arrives.
The last time we were able to manage all the Project Deliverables as we did schedule activities was in the 1980's (Pre- Personal Computers). The PC allowed and promoted segmentation and fragmentation of the EPC industry, All of a sudden we had dozens of engineers as well as Contractors and the one stop services of a single design firm or Contractor was gone. Now the participants moved from 1 - 2 to 100 - 300. All of a sudden coordination and communication became exponentially more difficult and Primavera couldn't help - for many reasons but most importantly the cost and complexity of the system limited the number of users and ease of communications. Consequently, neither were addressed. Still cost $5,000 + and its hard to mail three fifty-pound rolls of schedule activities. What we needed was simpler and cheaper software that could reach the installer rather than management. Add to this, procurement went from your local suppliers to world-wide accessibility. The business model no longer worked for project control of projects - too many participants, too expensive software, no communications - big problem and more importantly no respect for historical tracking software (Scheduling). We moved from design - build software to legal litigation software. Saving Changes...
Leonard ByrdProject Manager| Consultant - Partially RetiredMansfield Center, Ct, United States
Jun 07, 2026 7:15 AM
Replying to Leonard Byrd
...
Aaron don't get me wrong but what is the difference between a "Lesson's Learned" and a "Risk Register" other than when they are accomplished. Both simply list problems that have a potential to crash your project with little or no mitigation impact and are poorly communicated to the level of product activity. Utilizing my Construction experience - I hired on with Bechtel Inc in 1980 and while in the office I was given the "Make Work" project of compiling the "lessons learned" for the Mining & Metals Division - you can't imagine how many "unforeseen soil conditions" items were included yet not a single cure. In construction we have a huge problem with communications (5Ws). We need a mechanism to tell the responsible entity what they need to do in a timely manner to allow the schedule to be maintained or succeed. We need to compel action as well as accommodations to the schedule. While listing or identifying issues is good, if it fails to achieve motion - probably not worth the effort.
Arron you are absolutely correct - both in IT and Construction - Communications is critical and it's something we don't do well, certainly not in construction. The answer we typically get for a problem is "I didn't know it was a problem" and reluctantly with so many people to talk to between craftsman and management and so many managers - it's no doubt most don't know. So similar to combining P-6 and Excel to tackle the predecessor problem, one must look at our easily accessible Communication Software - PDF to easily reach the biggest audience. Once you break down the predecessor list, assign responsibility and communicate it to the participants in sufficient time to act those 50,000 items become a dozen each week for each responsible entities. Saving Changes...
Community Champion
