Lucas' Laws of Project ManagementLucas' Laws of Project Management<br>21st of June, 2026 — Lucas Fernandes da Costa at São Paulo, Brazil🇧🇷<br>1 A project succeeds when it solves the problem. Compliance with the original specification is merely one possible way to get there.<br>A project's goal rarely has anything to do with implementing a list of features. It is usually about solving a problem for users, the business, or both.<br>The original specification is a guess about what will solve that problem. It is almost certainly wrong, and it will change as the team learns more about the problem and the solution, as explained in Law 2.<br>Considering that the original specification is likely wrong, the only way to materially influence the outcome of a project is to understand the problem it is trying to solve so that you can adapt the solution as you uncover more information. If the team does not understand the problem, it cannot change the solution without risking failure.<br>Recommendation: Make sure the team understands the problem before it starts working on the solution. Keep the problem in mind as the work progresses, and be willing to change the solution when new information is discovered.

2 Scope cannot be known before the work begins. It can only become less wrong as the work proceeds.<br>A project's initial scope is based on what the team knows before it starts doing the work. That's when the team knows the least about the problem it is trying to solve. The initial scope is therefore a guess, and it is almost certainly wrong.<br>As the project progresses, the team will discover constraints, missing requirements, and incorrect assumptions. Some parts of the solution may be more expensive than expected, while others may turn out to be unnecessary.<br>The scope must change to account for those learnings. Otherwise, the project remains committed to decisions made without enough information.<br>Recommendation: Don't plan for too long before starting the work. You will uncover more information as you go, and the scope will change. The team should be able to adapt the solution to what it learns.

3 A fixed date requires variable scope. A fixed scope requires a variable date. Pretending both variables are fixed does not make it so.<br>Committing to a particular scope and an exact date may seem reasonable at the start of a project. However, if you accept that you don't know the scope before the work begins, you must also accept that it's impossible to know how long it will take to complete that scope. The target date is therefore a guess, and it is almost certainly as wrong as the scope.<br>Consequently, if you must meet a fixed date, like a product launch or a marketing campaign, the scope must be flexible. The team must be able to reduce the work to meet the date.<br>On the other hand, if the project must meet a fixed scope, like a legal requirement or a database migration, the date must be flexible. The team must be able to take as long as necessary to complete the work.<br>If you insist on both a fixed date and a fixed scope, the only variable left to trade will be quality because that's the only way to deliver the same amount of scope in less time.<br>Recommendation: Decide which variable is more important: the date or the scope. Make the other variable flexible so that the team can adapt to what it learns as it works.

4 A product built as successive working versions works every day. A product built as parallel parts works on the last day, if you're lucky.<br>The first version of a product should be the smallest version that works from beginning to end. It does not need every interface, safeguard, or improvement. It only needs to perform one useful action, even if some of the surrounding steps are still manual.<br>Assume you are building a system to import contacts from a CSV file, for example. In that case, the first version might be a single consumer that processes a file uploaded manually to S3. There is no API or dashboard yet, but the system can already import contacts.<br>This lets the team test the most important parts of the solution first. It can find out whether the file can be processed correctly, whether the expected volume is viable, and where the real difficulties are before building the rest of the product around it.<br>Each following version should preserve that working path and improve it. The team may add an API, validation, retries, and a user interface, but the product remains functional after every step.<br>The alternative is to build several parts in parallel and connect them near the end. Until that happens, the team does not know whether the product works as a whole. Problems are discovered later, feedback arrives later, and there may not be enough time to turn all the unfinished parts into something that can ship by a reasonable date.<br>To summarise: you can always ship a working product, even if it is small and incomplete. You cannot ship a product that does not work, no matter how enterprise-ready it looks.<br>Recommendation: Build the...