Are we scheduling backwards?

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.

In construction we have evolved into a "permission slip" environment where nothing is incorporated into a Project until that slip has been reviewed and approved. So if you don't begin at the start and remove all those gate checks - tracking a schedule activity is useless. We need to recognize the beginning is much more important as that is the most important step to the end and Primavera can't do that efficiently. We need to compel those first steps by systematically removing all those predecessors and alerting those responsible participants in a timely manner so that they can support the schedule and this is done with a coordinated spreadsheet at the start not at the end.

Execellent, now one must consider why we have spent a half century allowing this to happen? PC available in the early 1980's along with Primavera and Excel so why didn't we combine them earlier? That is also an easy problem to understand and answer - it wasn't easy or profitable for the software industry so we have been on our own from day one.

To give you a better perspective, I've have 50+years of experience on some of the largest and most complex projects and have found most baseline schedules are so conservative, success is relatively easy to achieve since our schedules have been developed on ignoring the early steps (doing it wrong) so each time we fail it gets longer. Add to that, there is typically only one individual in a position to achieve this - the PM and he's battling 100s of corporations, untold silo's and now AI. The fact is we have splintered or fragmented the industry so much, our Project Managers are tasked with the complexity of a Fortune 500 company with virtually no authority or support. My first Mega-Project success was a Disney Theme Park and all I did was tie an excel submittal spreadsheet to the Project Schedule and delivered an on time, under budget project where few if any had done before. I have subsequently completed 5 more successful Mega Projects by simply managing the process - not the ficility..

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.

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.

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.