Your software project fails for the same reasons a surprise party does

Sofía turns 25 on Saturday, November 14. Her three best friends want to throw her a surprise party: 30 guests, 9,000 pesos and four weeks. Nothing extraordinary. And yet almost every party that goes wrong does so for the same three reasons:

• Nobody was quite sure what had to be done. "Someone was going to bring the ice." Who? Nobody.
• They found out too late. On Friday night they discover the venue needed a deposit by Tuesday.
• Nobody checked. Everyone assumed someone else had already done it.

Replace the party with the integration of your invoicing system, the new customer app or the move of a process into the ERP, and the three reasons are still there, under another name. Technology carries its own risks, and those are handled with engineering. But many software projects stall for the same reasons a party does: tasks without an owner, problems that surface late and decisions nobody makes.

The good news is that the same practices fix it in both cases. Let's start with the party, because anyone gets it right away, and at each step I will show you what it looks like in your project.

1. A goal you can check with a yes or a no

"Let's throw a party" is not a plan; it is a wish. With a wish, Ana pictures a dinner for 10, Beto a party with a DJ for 60 and Carla a backyard barbecue. All three are working, but on three different parties.

So before lifting a finger, they write down what success means:

Sofía did not find out beforehand · at least 25 guests came · we spent no more than MXN 9,000 · at 8:30 p.m. everything was ready.

It does not say "everyone has fun," because that cannot be checked. It says four things that, on Sunday, can be answered with a yes or a no.

In your project, these are the project's success criteria and, one level down, the acceptance criteria of each deliverable. "Make the portal more agile" is a wish. "A customer already signed in to the portal on their phone downloads their invoice in three clicks or fewer" is a goal: on delivery day it is tested with real users, and the discussion is over.

If it cannot be checked with a yes or a no, it is not a goal yet.

2. Every task: a verb, one person, a date and proof

The party list starts as a brainstorm: venue, food, cake, music, ice. Those are not tasks yet; they are topics. "Food" is not something anyone can do on Tuesday.

A real task has four parts:

The fourth part, "it is done when…", is the one almost everyone forgets and the one that prevents the most problems. "I already talked to the venue guy" is not "it is booked." No receipt, no booking.

And the rule that saves the most parties: a task with two owners belongs to nobody, because each one believes the other is doing it. Several people can help; one person answers for it.

In your project, this is the difference between "we are making progress on the integration" and "the order flows from the portal to the ERP, with its reference number, in the test environment, and your finance team validated it." The first sentence can be repeated for three weeks in a row. The second is either true or it is not.

3. The chain that sets the pace

Some tasks cannot start until another one finishes. You cannot book without money, you cannot invite without a venue, and you cannot tell the taco caterer how many people are coming until the guests confirm:

money → venue → invitation → confirmations → final headcount to the caterer.

That chain is the critical path: the sequence of linked tasks that sets the final date. If one of them slips and nobody recovers it, the date is at risk, and since the party cannot be moved, something else is lost instead: guests, food or money. Everything else, such as the playlist, has slack. That is why the first week of the party is loaded on purpose: what unblocks everyone else gets done first, while there is still time to correct course.

In your project, the critical path does not run only through the code. It often runs through access to your systems, an outside vendor's test environment, the agreement on which data is delivered and in what format, or the person on your team who knows the current process. If nobody requested them for the date the plan needs them, the project is already late, even if nobody has noticed.

4. Planning is not organizing

With the goal, the tasks, the order and the budget, the three friends have a very nice plan. And they are still only halfway there.

Planning is deciding what will be achieved, what has to be done and when.

Organizing is deciding who does it, with what, who decides and how they coordinate.

Planning is writing the recipe; organizing is assigning the kitchen. A recipe without an assigned kitchen does not get cooked. To organize the party, they make six decisions:

1. Owners. Each block (venue, guests, food, money) has one person who answers for all of it. If something new comes up in that block, everyone already knows whose it is.
2. Resources. The money sits in a separate account and Carla manages it; nobody pays out of pocket without telling the others.
3. Who decides what. Within their block and their budget, the owner decides. Spending more or moving the date is decided by all three. And from the start they name an event lead, Carla, who has the final word when the three cannot agree.
4. How they coordinate. A group chat to talk, a meeting to decide and a shared sheet as the single source of truth: if it is not in the sheet, it did not happen.
5. Who watches the whole. One person, by name, from day one.
6. Who covers for whom. Every owner of something critical has a backup who knows enough to carry on without calling them.

In your project, these are the questions a good kickoff answers in writing: who owns each workstream, on your side and on ours; who approves a change in scope; where people talk, where decisions are made and where the truth lives; who tracks progress; and what happens if the key person goes on vacation. If any of them is left unanswered, the project has a plan, but nobody to carry it out.

5. One person who watches the whole

This is the point most often forgotten. Each owner looks after their own task and rarely sees anyone else's. Beto is happy because his speaker has been tested, and does not notice that nobody has confirmed the guests. If everyone checks, nobody checks.

At the party, that person is Carla. She checks in one or two days before each deadline, not after. When someone says "it's done," she asks for the proof. She raises a problem the same day, without waiting for the meeting. And she does not do other people's tasks, because then she stops watching everything else.

Carla looks at two different things:

• Compliance: was each task done, and done right? It is checked task by task, with its proof.
• Progress: are we on pace? On Monday, October 26, according to the schedule, 6 tasks should have been done and 4 have proof: 4 of 6, 67%. "Almost everything is done," and yet the week is red, because one of the two missing tasks is on the critical path: the venue they chose was no longer available that Saturday, and without a venue the invitation cannot go out.

To avoid arguing over opinions, they use a traffic light with written rules:

• Green: done, with proof. "Almost," "I've got it covered" and "I already talked to them" are not green.
• Yellow: not done yet, but it will be done on time.
• Red: it will not be done on time, or it is stuck. Something gets decided at the next meeting, not later.

In your project, that traffic light either exists or it does not. If your vendor reports "90% progress" for a month, there is no traffic light: there is an opinion. Ask how many deliverables should have been accepted by today, according to the plan, how many have been, with proof, and whether any of the missing ones is on the critical path.

6. An early red is good news

Seeing the red is monitoring. Acting on it is control. With the venue lost, at Monday's meeting they go through four questions: what exactly happened, what it affects, what options there are and what they decide. The decision comes out with a name and a date: Beto books venue B the next day. It costs MXN 400 more, so the contingency reserve drops from MXN 700 to MXN 300, and from that day on they know they can no longer upgrade the food.

What makes this work is not the meeting: it is that the red showed up with three weeks to go, not on the eve of the party. That is why the worst mistake is hiding a red "so as not to worry anyone": the problem grows in silence and arrives when there are no options left.

And a detail almost nobody plans for: people fail too. They get sick, their phone dies, they do not answer. The party's plan B says what happens if Carla gets sick the week of the event, and who starts decorating if at 6:30 p.m. nobody can reach Beto. For a backup to work, the phone numbers, receipts and agreements cannot live on one person's phone.

In your project, the uncomfortable question is: what happens if the person who knows the most leaves tomorrow? If the answer is "we get stuck," the project depends on nothing happening to that person.

7. The issues nobody decides

Not everything that stalls is a red task. There is something quieter: the issues nobody decides. "We'll see later." "We need to talk about it."

"Gift" came up in the brainstorm, but it never became a task. On November 5 Ana brings it up: she wants the three of them to give one together, worth MXN 1,500, and Beto suggests each of them give their own. They cannot agree and leave it at "we'll see later." If nobody does anything, on Saturday they arrive without a gift, or someone pays for it out of the party money and breaks the budget. Not deciding is also a decision, and usually the worst one.

The fix has two parts. First, no issue lives only in someone's memory: it goes on a list of open issues, with an owner and a date to be decided, and the list is reviewed at the end of every meeting, oldest first. Second, if an issue goes through two meetings without agreement, the lead decides, in six steps:

1. She announces that she will decide, and when.
2. She listens, within limits: one short proposal from each person, with its reason, before Sunday at 8:00 p.m.
3. She decides with the information available. A MXN 1,500 gift did not fit in the MXN 300 left in the reserve, and that was enough.
4. She explains why.
5. She writes it down: what, why, who and by when.
6. She does not reopen it unless new information appears. "I thought about it again" is not new information.

The decision: no gift comes out of the party money. Each person gives their own with their own money, and Ana organized a separate collection, outside the MXN 9,000, for the headphones Sofía wanted. Sofía got her gifts and the party stayed within budget.

In your project, loose issues are the ones that cost the most time: the business rule nobody on your side quite finishes defining, the field that department A wants and department B does not, or the approval that waits on someone who is never at the meeting. Each one needs an owner, a date and someone with the final word, agreed at kickoff.

8. Close properly so the next one goes better

On Sunday, the three of them check the four conditions from the start. Sofía did not find out, 27 guests came and they spent MXN 8,850, under the cap. But the cake arrived at 8:50, not 8:30. Result: three out of four.

Then they look for the cause: the cake was ordered "for the afternoon," with no exact time. And the action for next time fits in one line: every delivery is ordered for an exact time, with a margin before it is needed.

In your project, the first step is the review against the success criteria; the second, the retrospective: what went well, what went wrong, why, and what changes next time, with an owner. It is almost always skipped because "it has already been delivered," and it is precisely what makes the second project with the same vendor go better than the first.

Six questions to ask about your project on Monday

You do not need to be a software expert to know whether your project is on track. Ask your vendor or your team these questions:

1. How will we know, with a yes or a no, that the project succeeded?
2. Does every task have a single owner and proof that it is finished?
3. Which chain of tasks delays everything if it slips? What in that chain depends on my side?
4. How many deliverables should be ready by today, and how many are, with proof?
5. Which issues are open, who owns each one and who has the final word?
6. What happens if the person who knows the most about the project leaves tomorrow?

If any of them lacks a clear answer, with an owner, a date or proof, you have already found where the risk is.

What about the methodology?

None of this depends on whether your project moves in stages, in sprints or in a mix of both. Choosing the approach is a separate decision, which we explain in Waterfall or Scrum: how to choose. Any approach fails if nobody owns the tasks, if reds are seen late or if issues go undecided. And any approach works much better when those six questions are answered from day one.

What Hábil does

Hábil is a Mexican engineering consultancy, founded in 2006, that builds and integrates systems that cannot fail. When a project starts, we agree with you on the answers to those six questions and put them in writing. From then on, you see progress on a shared task board —ClickUp, Jira or your own—: every task with its owner, its date and its proof of completion, and the open issues with their owners. You do not have to wait for the end-of-month meeting to know how it is going. See the page How we work. If your project is an app or a portal for your customers, see also Web, mobile and desktop apps.

The first conversation is at no cost. Let's talk about your project: the one about to start, or the one already under way that is not moving as you expected. Write to us on WhatsApp.