I Took Over Someone Else's Project and Nobody Knows What's Going On - How to Quickly Regain Control of Tasks, Decisions, and Risks When the Documentation Mostly Says "Ask Tomek" ebook

Cover

I Took Over Someone Else's Project and Nobody Knows What's Going On

How to Quickly Regain Control of Tasks, Decisions, and Risks When the Documentation Mostly Says "Ask Tomek"

Max Paradox

PROBLEM? RELAX. YOU'VE GOT THIS!

ISBN: 978-83-8483-816-7

ALL-IN Rafał Płonkowski

Table of contents

Title page

INTRO

Chapter 1 - Congratulations, You're in Charge. Now Find Out What You're in Charge Of.

Chapter 2 - Everyone Agreed. Unfortunately, Not on the Same Thing.

Chapter 3 - The Schedule Is Green. The Work Has Other Ideas.

Chapter 4 - Everything Is Urgent, Which Is Why Nothing Is Moving

Chapter 5 - Everyone Is Responsible. Which Means Nobody Is.

Chapter 6 - No Risks Reported. Several Disasters Already Underway.

Chapter 7 - The Entire Project Lives Inside One Person's Head. Let's Hope They Never Take a Holiday.

Chapter 8 - Your Predecessor Promised the Moon. You Have a Ladder.

Chapter 9 - One Page of Truth in a Building Full of Reports

Chapter 10 - From Monday's Ambitions to Friday's Actual Results

Chapter 11 - The Decision Was Due Yesterday. The Facts Are Still in Transit.

Chapter 12 - The Budget Looks Fine. The Invoices Have a Different Opinion.

Chapter 13 - The Rescue Plan Needs Rescuing

Chapter 14 - Finished According to the Supplier. Unusable According to Everyone Else.

Chapter 15 - The Team Is at War. You're Apparently the Peace Negotiator.

Chapter 16 - The Plan Is Impossible. Management Would Prefer You Not Mention That.

Chapter 17 - The Project Has No Sponsor, No Customer, and a Remarkable Will to Live

Chapter 18 - Chaos Doesn't Send a Calendar Invitation When It Returns

Chapter 19 - They Changed the Rules Again. You Don't Have to Start From Scratch.

Chapter 20 - The Next Project Manager Won't Have to Ask Tomek

Landmarks

Cover

Title page

Table of contents

Start of content

INTRO

The meeting invitation says "Quick Project Handover - 15 Minutes." That is your first warning. Fifteen minutes is barely enough time to explain the office printer, yet apparently sufficient to transfer responsibility for a project involving six departments, three suppliers, a substantial budget, and a deadline nobody seems particularly eager to discuss. Your predecessor shares their screen, opens a folder containing documents with encouraging names like "Latest Version" and "Latest Version NEW," then explains that everything is reasonably straightforward. Halfway through, they mention a few outstanding issues. Five minutes later, you discover that one of those issues involves a customer waiting for something that was supposed to be delivered last month. The meeting ends with a cheerful "You'll figure it out!" You now own the project. Congratulations on your promotion to Chief Archaeologist of Other People's Decisions.

At first, you assume the missing information must exist somewhere. A project of this size surely has a proper record of decisions, responsibilities, dependencies, and commitments. You search the shared drive. There are hundreds of files, several contradictory schedules, and a presentation in which every milestone appears to be progressing beautifully. You ask where to find the explanation behind a particularly mysterious decision. Someone replies, "Tomek handled that." You ask whether Tomek documented his reasoning. Apparently, he preferred a more personal approach to knowledge management: remembering everything himself. Unfortunately, Tomek has moved to another company, and the project's institutional memory has effectively resigned along with him.

This is where an ordinary management assignment becomes something considerably more interesting. You are accountable for outcomes you did not promise, dates you did not negotiate, and decisions made under circumstances you do not understand. People expect you to provide direction, while you are still discovering where the project is supposed to be going. Worse, everyone seems to possess a different version of reality. Finance believes spending is under control. The delivery team expects additional funding. The customer considers a feature essential, while the technical team believes it was explicitly excluded. Nobody is necessarily lying. They may simply be working from different assumptions, some of which have survived so long that people now treat them as facts.

Your natural instinct may be to investigate everything before making a move. You request old emails, meeting minutes, contracts, presentations, and every document containing the project name. Within days, your inbox resembles the storage room of a company that has been investigated by several governments. You know who attended a workshop eighteen months ago, but you still cannot explain what must happen before Friday. Information gathering feels productive because it is measurable. You can count the files reviewed and the meetings completed. Unfortunately, understanding the project's entire history is not the same as knowing how to manage its immediate future. Some historical details matter enormously. Others are merely fascinating evidence that human beings should not be allowed to name their own spreadsheet versions.

The opposite instinct is equally dangerous. Perhaps you decide to establish authority immediately by introducing a new reporting system, demanding daily updates, and announcing that things will be different from now on. There is a certain satisfaction in replacing chaos with rules. However, changing the furniture while the building's structural problems remain unresolved rarely improves its stability. If responsibilities were unclear before, transferring them into attractive new software will not automatically clarify them. If two departments disagree about what was promised, adding a deadline to their disagreement will not make either interpretation correct. Effective control begins with understanding the situation sufficiently well to distinguish the problems that need decisions from the noise surrounding them.

You also need to resist an uncomfortable expectation: that being appointed project manager means you should already know every answer. It doesn't. Taking responsibility gives you an obligation to investigate, communicate, coordinate, and make appropriate decisions. It does not provide supernatural access to conversations you never attended. When someone asks whether the launch date is secure, a professionally useful response might be, "I can confirm the current target, but we still need to verify two dependencies before treating it as achievable." That may sound less impressive than an enthusiastic promise. It is also far more valuable than offering certainty you cannot support, then spending the following month inventing explanations for why reality declined to cooperate.

The people around you deserve a fair assessment too. The colleague who cannot explain a decision may never have been included in the discussion. The person who appears uncooperative may be protecting an already overloaded team from another impossible commitment. Someone who keeps saying "That's how we've always done it" might be defending a pointless habit, or might know about a serious limitation nobody bothered to document. Your task is not to assume everyone is incompetent until proven otherwise. It is to understand which obstacles come from missing knowledge, conflicting incentives, limited authority, insufficient resources, or genuinely poor decisions. Those problems can look remarkably similar during a tense meeting, but they require very different responses.

Throughout this book, we will treat project control as something practical rather than ceremonial. A task matters when someone knows what result is required and has a realistic way to produce it. A decision matters when the appropriate person makes it, its consequences are understood, and the people affected know what to do. A risk matters when identifying it changes how you prepare or act. A schedule is useful when it helps anticipate what will happen, rather than merely displaying what everyone once hoped would happen. These distinctions may sound obvious, yet they are exactly what disappears when a project becomes a collection of disconnected promises held together by meetings.

There will also be moments when the sensible answer is uncomfortable. You may discover that a deadline is unrealistic, that an apparent saving hides unpaid commitments, or that a project no longer serves the purpose for which it was originally approved. You cannot always solve these problems personally. You may lack the authority to change funding, renegotiate contracts, or redirect staff who report to someone else. What you can do is make the constraints visible, prepare meaningful alternatives, and bring decisions to the people authorized to make them. That is management, not a failure of leadership. Pretending to control things beyond your authority merely postpones the moment when someone notices you do not.

For now, imagine opening a simple page and writing down what you can genuinely confirm about the project. What result is it supposed to deliver? What needs to happen next? Which commitment could cause the greatest trouble if your understanding is wrong? Who can provide evidence rather than another reassuring opinion? You do not need perfect answers immediately. Even identifying the gaps accurately is progress, provided you distinguish facts from assumptions and give the important unknowns a path toward resolution. A manageable project is not one without uncertainty. It is one where uncertainty stops hiding inside confident sentences.

And that is the real promise of this book. You will not become an all-knowing project superhero capable of repairing eighteen months of accumulated confusion during a particularly productive Tuesday afternoon. You will learn to recognize the mechanisms that keep inherited projects confused, make better decisions with imperfect information, and build a way of working that does not depend on one exhausted person remembering everything. You will still encounter delays, difficult conversations, and the occasional meeting that could have been an email. But you will have a clearer idea of what deserves your attention and what can safely remain somebody else's historical mystery.

One day, someone may inherit this project from you. They will open the documentation, examine the current commitments, understand the outstanding decisions, and begin working without needing a private detective. They may never appreciate what an extraordinary achievement that is. That's fine. The highest compliment for a well-managed handover is that the next person finds it remarkably unremarkable.

And if someone asks where Tomek is, you can finally give the most satisfying answer in project management: "We don't need to know."

Chapter 1 - Congratulations, You're in Charge. Now Find Out What You're in Charge Of.

At 9:30 on your second morning, you attend a meeting about the company's new customer service platform. The project has been running for eleven months, involves eight departments, and has already consumed a considerable amount of money. You inherited it yesterday. The operations director opens with a question about whether the first regional rollout can begin next month. Before you can answer, the technology lead says the platform is technically ready. The training manager explains that nobody has approved the training materials. Someone from customer experience mentions that several essential functions are missing. The supplier insists those functions were never included in the agreement. Everybody turns toward you, presumably because your job title contains the words "project manager," which apparently qualifies you to settle disputes involving events you have never witnessed.

You could respond with confidence. You could promise to review the situation, confirm the date, and circulate an updated plan. In fact, you will probably need to do all three eventually. But there is something more important to understand first: accepting responsibility for a project does not automatically give you an accurate understanding of what that project has become. You have inherited a moving system of commitments, assumptions, activities, and relationships. Some parts are documented. Others exist in conversations, individual memories, and agreements that nobody thought to record. Your predecessor may have understood how these pieces fitted together. Unfortunately, the organization has not necessarily inherited that understanding along with the project.

This is why the first stage of taking over a project is less about demonstrating authority and more about establishing reality. That sounds disappointingly unheroic. Nobody announces a new manager by saying, "Please welcome the person who will carefully distinguish confirmed facts from unsupported assumptions." They prefer phrases such as "drive transformation," "accelerate delivery," and "take ownership." Those ambitions may become useful later. Right now, however, accelerating a project before understanding its direction is rather like taking over the controls of an unfamiliar aircraft and immediately deciding that the previous pilot was flying too slowly.

The Project on Paper and the Project People Actually Experience

Most inherited projects have an official identity. Somewhere, there is a business case explaining why the work began. There may be an approved budget, a scope statement, a delivery schedule, and a list of stakeholders. These documents matter because they establish what the organization originally intended to achieve and which commitments may have been formally accepted. The mistake is assuming that they necessarily describe what is happening today. A project can change considerably without its foundational documents being updated. People accommodate new requirements, respond to operational difficulties, and make practical compromises. Eventually, the original plan becomes a respectable historical artifact that everyone continues referencing out of professional courtesy.

Consider the customer service platform. Its original objective was to replace several disconnected systems with one shared solution. That objective sounds straightforward until you ask different departments what success means. Technology wants the platform installed, integrated, and stable. Customer experience wants shorter response times and consistent service. Operations wants employees capable of using the system without disrupting daily work. Finance expects the promised savings to materialize. Each perspective is legitimate, but they describe different outcomes. A technically successful installation might still leave employees processing requests manually. A smooth launch could still fail to produce the expected financial benefits. Unless you understand these distinctions, you may eventually celebrate completing the wrong version of the project.

Start by establishing the current objective rather than automatically adopting the first objective you find. Ask the sponsor or appropriate business owner what result the organization expects now, who will use it, and what conditions would make that result acceptable. Then compare those answers with the approved scope and the expectations of people responsible for delivery. Disagreement is not necessarily evidence of incompetence. It may indicate that requirements changed, that different groups understood the original goal differently, or that nobody ever resolved an important ambiguity. What matters is identifying the difference while there is still time to address it.

One useful distinction is between completing an activity and producing the intended result. A training session can take place without employees becoming ready to operate a new system. Software can be deployed without meeting the needs of its users. Equipment can be delivered without being installed or accepted. When someone tells you a task is finished, find out what has actually been produced and whether the relevant recipient considers it usable. You do not need to personally inspect every minor deliverable. You do need enough evidence to distinguish genuine progress from the administrative comfort of a completed checkbox.

Be careful not to turn this investigation into an accusation against the people who were here before you. An outdated document may reflect a genuine oversight, but it might also have been superseded by an approved agreement stored elsewhere. A team member who cannot explain a requirement may never have been included in the conversation that created it. Ask what happened, what evidence exists, and which facts remain uncertain. There will be plenty of opportunities to examine performance later if necessary. Your immediate purpose is to understand the system, not to assemble a prosecution case against your predecessor.

Find the Boundaries Before Exploring Every Detail

When information is scattered, it is tempting to investigate the entire history of the project. You read old emails, inspect previous presentations, and schedule conversations with everyone who might remember something useful. The problem is that inherited projects contain almost unlimited opportunities for historical research. You could spend an afternoon discovering why a particular supplier was selected and still have no idea whether next week's delivery can proceed. Some historical decisions will matter. Others will be interesting only to future scholars of corporate civilization.

A more useful starting point is to identify the project's boundaries. You need to understand what it is supposed to deliver, what falls outside its approved scope, which resources are available, and who has authority to change important commitments. These questions reveal what you can reasonably manage. They also expose responsibilities that may have been assigned to you without the authority or resources required to fulfil them. Being accountable for delivery does not necessarily mean you can approve extra spending, assign employees from another department, or alter a contract. If those limitations remain invisible, they tend to become painfully obvious at the worst possible moment.

Next, look for the commitments whose failure would have the most immediate consequences. Perhaps the company has promised a customer a particular launch date. Perhaps a supplier needs confirmation before reserving installation resources. Maybe a temporary contract expires soon, or a decision must be made before further work can begin. These matters deserve attention before you reconstruct the complete history of every minor task. Ask what could go wrong during the next few working days if nobody intervenes. The answer often reveals the project's most important immediate vulnerabilities.

For example, the service platform's first regional launch may depend on transferring existing customer records. The migration team says preparations are progressing, but nobody has confirmed whether the receiving system can correctly handle several unusual record types. That uncertainty matters considerably more than discovering who originally selected the colour scheme for the user interface. You can investigate the selection process later if it becomes relevant. The immediate priority is establishing whether the data transfer is ready, who must verify it, and what happens if the verification fails.

Information quality deserves the same attention as information content. A date copied from an old presentation is not necessarily a confirmed commitment. A colleague's recollection can be valuable without being conclusive. A document marked "approved" may refer to an earlier version of the scope. When recording important findings, distinguish between confirmed facts, reported claims, reasonable assumptions, and unresolved questions. This need not become an elaborate classification system. Even a simple note explaining who provided the information, when it was last checked, and what would confirm it can prevent expensive misunderstandings.

Suppose a team lead assures you that external testing is complete. Instead of asking whether they are absolutely certain, ask what evidence demonstrates completion. Was a report issued? Were the agreed test cases executed? Did the appropriate person accept the results? The answer may reveal that testing was performed but several exceptions remain unresolved. This does not automatically mean somebody misrepresented progress. Different teams sometimes use the word "complete" differently. Your job is to make the operational meaning clear enough that people can act on it.

Listen to the People Doing the Work

Project documents tell you what the organization intended. The people performing the work reveal how those intentions encounter reality. Speak with representatives of the major delivery areas, including those who depend on the project's results. Avoid making every conversation a general invitation to complain. Questions about specific dependencies, obstacles, expected results, and upcoming commitments usually produce more useful information. You are trying to identify where work moves smoothly, where it stops, and where people are compensating for gaps that the formal plan does not acknowledge.

You may discover that employees have developed informal arrangements to keep the project moving. One colleague manually corrects information that should be generated automatically. Another regularly obtains approvals through a personal contact because the official process takes too long. Such workarounds may have prevented serious delays, so dismissing them immediately would be unwise. They may also conceal weaknesses that make the project dependent on individual goodwill. Understand why each arrangement exists before deciding whether it should continue, change, or become part of a properly supported process.

Remember that people's accounts are shaped by their responsibilities. A supplier may emphasize completed deliverables, while an internal user emphasizes remaining difficulties. Neither perspective automatically captures the whole situation. If the accounts conflict, compare concrete events and expected results rather than choosing the most persuasive speaker. This is particularly important when one participant has significantly more organizational influence than another. Seniority may determine who has authority to decide, but it does not automatically determine whose description of a technical problem is accurate.

Your manner during these conversations establishes an important expectation. If you react to every unwelcome finding with visible frustration, people may learn to offer reassuring summaries instead of useful facts. You do not need to congratulate someone for revealing that a critical activity is late. You can, however, acknowledge the information, establish its consequences, and concentrate on the next appropriate action. A manager who can hear difficult news without immediately searching for someone to blame is more likely to learn about problems while there is still time to respond.

Your First Useful Picture of the Project

By the end of your initial investigation, you should be able to describe the project's current condition without relying entirely on the confidence of other people. You may not understand every historical decision or technical detail. That is acceptable. You should know the intended outcome, the next significant commitments, the most consequential uncertainties, and the people capable of resolving them. You should also understand where your own authority ends. That last discovery may be disappointing, particularly if your new title sounds impressive, but it can save you from promising changes you cannot authorize.

A brief initial assessment is often more useful than a large replacement plan. Explain what you have confirmed, which assumptions still require verification, and what needs immediate attention. Where necessary, identify decisions that belong to the sponsor, relevant managers, or other authorized people. Resist the urge to announce a definitive completion date before the underlying dependencies have been examined. You can provide a provisional forecast and explain its conditions. That is different from offering a guarantee simply because someone wants a date for tomorrow's executive meeting.

If the project is especially disorganized, concentrate first on the few matters capable of causing significant damage through delay. Protecting an essential delivery, clarifying a costly commitment, or obtaining a necessary approval may have greater immediate value than redesigning the entire reporting process. Once urgent exposures are under control, you can improve the broader way the project is managed. The sequence matters because organizational repair also consumes people's attention, and that attention is already being used to deliver the actual project.

You may feel uncomfortable admitting how much remains unknown. Yet discovering uncertainty is useful when it changes what you investigate and how you decide. The dangerous situation is not having unanswered questions. It is making commitments as though those questions had already been resolved. An inherited project rarely becomes understandable all at once. It becomes manageable as the most important information is confirmed, responsibilities become clearer, and unsupported assumptions stop masquerading as agreements.

At your next meeting, somebody may ask whether you finally have the project under control. You can answer without performing the traditional corporate ritual of enthusiastic overconfidence. Explain what is established, what needs a decision, and what your team is doing next. That answer may contain fewer comforting adjectives than your predecessor's reports. It will also be considerably more useful.

Taking ownership is not the moment when you suddenly know everything about the project. It is the moment when you begin making sure the organization no longer has to pretend that somebody does.

Chapter 2 - Everyone Agreed. Unfortunately, Not on the Same Thing.

The trouble begins with a sentence that sounds entirely harmless: "We settled this months ago." You are reviewing the launch arrangements for a new membership programme across a chain of cultural venues. The customer experience team believes memberships will be digital from the first day. Front-desk employees expect physical cards to remain available. Finance has budgeted for neither card production nor additional customer support. The supplier has built a digital-only registration process, while marketing has already prepared promotional materials showing a handsome little membership card. Everyone assures you that the launch arrangements were agreed during an earlier workshop. The workshop notes contain a photograph of enthusiastic participants standing beside a whiteboard. Unfortunately, somebody is standing directly in front of the part containing the conclusions.

You ask three people to explain the agreement. The marketing manager remembers a commitment to preserve physical cards because some customers prefer them. The technology lead recalls that physical cards were discussed as a possible future enhancement. The operations representative remembers being told that venues could decide individually. These accounts cannot all describe the same final decision, yet each person sounds entirely sincere. Nobody has necessarily fabricated anything. They may have remembered different parts of the conversation, interpreted conditional statements as commitments, or continued working on assumptions that nobody later challenged. The disagreement has survived for months because the project kept moving without requiring anyone to confront it.

This is one of the more fascinating weaknesses of organizational communication. People can attend the same meeting, hear the same words, and leave with different understandings of what has been decided. The problem is especially common when discussions move quickly, authority is unclear, or participants are reluctant to challenge someone senior. A statement such as "We should be able to support both options" may be interpreted as a promise, a technical possibility, or an invitation to investigate. During the meeting, everybody nods. Weeks later, the nodding has somehow been promoted into an official project decision.

Inherited projects are particularly vulnerable because the people who understood the original context may no longer be available. Even those who attended may struggle to distinguish an actual agreement from a proposal they personally preferred. You cannot resolve this reliably by asking who remembers most confidently. Confidence makes for an entertaining presentation, but it is not proof. The task is to reconstruct what can reasonably be established, identify the remaining uncertainty, and decide whether the project needs a fresh, properly authorized resolution.

A Discussion Is Not Necessarily a Decision

An important first distinction is between something that was discussed, something that was recommended, and something that was approved. These stages frequently become blurred because everyday language treats them casually. Someone says, "We agreed the digital option looked best," and another person hears, "The digital option was approved." The difference may be substantial. Participants can agree that a proposal is attractive without possessing the authority to adopt it. They can recommend a solution while leaving important conditions unresolved. They can also approve a principle without confirming the detailed requirements needed to implement it.

In the membership programme, a previous workshop may have concluded that digital registration should be the preferred approach, subject to confirmation that all venues could support it. That condition matters. If nobody completed the assessment, the recommendation did not automatically become an unconditional approval. Similarly, a supplier's demonstration of digital cards does not prove that the organization accepted a digital-only customer experience. A demonstration shows what a system can do. A decision establishes what the project is supposed to do, within the relevant authority and agreed conditions.

When trying to reconstruct an important choice, follow the evidence rather than the loudest recollection. Look for the original question, the alternatives considered, the person entitled to decide, and the communication that recorded the outcome. Emails, approved change requests, signed documents, and subsequent instructions may all help. Their meaning depends on context. An email saying "Fine with me" might express a personal opinion rather than formal authorization. A purchase order may establish that a particular service was ordered without proving that every feature discussed in an earlier meeting was approved. Evidence must be interpreted according to what it actually establishes.

This is not an invitation to spend the next fortnight excavating every electronic conversation since the project's inception. Work backward from the current consequence. If the membership-card dispute affects customer expectations, operational readiness, and supplier costs, it deserves attention. An unresolved historical debate about the preferred colour of staff lanyards may not. Your investigative effort should reflect the impact of the uncertainty. Otherwise, you risk becoming extraordinarily knowledgeable about matters that no longer affect a single decision.

There will also be occasions when the evidence remains incomplete. Perhaps the original decision-maker has left, the meeting was never recorded, and later messages contradict one another. The temptation is to assemble the most plausible story and declare the mystery solved. Resist it. You can establish that a digital solution was developed, that printed cards were discussed, and that formal approval of their exclusion has not been found. That is a useful finding even without a perfect historical reconstruction. It tells the organization which assumptions cannot safely support further commitments.

What Silence Actually Means