Chapter 8: Walking Away
Just as important as completing a project is knowing when to walk away. To start, let’s outline why knowing when to walk away is so important. Here at Benmore we have a metric called a Cap Ratio, and it essentially outlines how much money each forward-deployed developer is bringing into the company over their team’s cost. It’s a great indicator of value, but also a cornerstone of sorts to tally projects up against. Specifically, if a project is going to be burdensome, it will eat into the time that you are able to allocate to other projects. Deviation from our process will directly burn you out, lower your performance, and make your life miserable. Project load hygiene rises as being extremely important in this sense. Beyond the impact on forward-deployed developers, this is important for the clients as well. If expectations are misaligned, the client will never be satisfied. In addition, other clients will be impacted if a project is burning you out. It’s a tough concept to grasp, but knowing when to walk away and maintain proper load hygiene will impact yourself, the problematic client, other clients, and the business as a whole. Yes, in an abstract way — but in an extremely impactful way. Here are general indicators that you can follow when determining when to walk away from a project.
Project Health Scorecard
Use this ongoing assessment to determine when a project needs intervention or separation:
| Health Indicator | Status | Notes |
|---|---|---|
| Can we complete within allocated time/resources? | YES / WARN / NO | |
| Will the client be satisfied at completion? | YES / WARN / NO | |
| Does the client pay, and pay on time? | YES / WARN / NO |
If ANY indicator is NO, call an emergency meeting to realign or separate.
Early Warning Signs → Required Action
| Warning Sign | What It Likely Means | Action |
|---|---|---|
| Client rejects all recommendations | Trust issue or mismatched expectations | Discussion to realign |
| Client missing meetings / tardy | Low urgency/importance or disrespect | Flag and discuss |
| Constant criticism / never satisfied | Unrealistic expectations | Flag and discuss |
| Client brings AI to push back on you | Trust degradation | Reinforce expertise |
| Scope creep without change orders | Boundary erosion | Hard stop and realign |
Hard Stops (Immediate Escalation Required)
| Boundary Crossed | Response |
|---|---|
| Client is dishonest or acts in bad faith | Escalate internally → likely terminate |
| Client is demeaning or disrespectful | Address directly → terminate if repeated |
| Client forces you to compromise your integrity | Terminate immediately |
| Client doesn’t respect your expertise | Discussion → terminate if unchanged |
| Engagement becomes employee-employer dynamic | Offer staff placement alternative |
At Benmore, we typically follow three main criteria when tallying up macro success for a project. Can we complete this project within the allocated time frame and resources? Will the client be happy? Does the client pay, and pay on time? If any of these compile to false, then it is our duty to call an emergency meeting with the client and discuss the issue and either realign or separate. However, the above criteria are more of an ongoing compass to keep in the back of your head throughout the project lifecycle. There are some indicators early on that can give insight into one of these boundaries being crossed. First, if during the recommendation phase the client is unwilling to accept our recommendations or enter into collaborative discussions surrounding the determination of what to build. Sometimes something went wrong in the sales process and the client was looking for an employee. Sometimes there’s a trust issue. Sometimes it’s a personal reason. Who knows, but if the client is unwilling to collaborate, the project is pretty much blocked, and if after a discussion or two outlining the issue at hand nothing changes, it’s just best to move on. Another indicator is clients missing meetings or being tardy and unorganized in communication. Typically this represents a lack of urgency or importance in relation to the project, or diminished respect for you and your team. Due to the collaborative nature of the engagement, this also blocks or severely hinders project progression and needs to be flagged. It can also indicate difficult payment collection as well. Another issue is a general position of being unsatisfied. Not every client is going to be jumping out of their seats every meeting, and constructive feedback is often helpful, but constant denial of our work and criticism just gets demeaning over time. Some people just can’t be satisfied, and that’s okay — but we don’t have to be subject to it. Again, these are indications and typically warrant a discussion to realign but let’s discuss some crossed boundaries that would require immediate escalation, essentially hard stops that need to be fixed before project continuation.
Values, this is key, anything that encroaches on company or personal values. We do include personal values in this, because we understand that being who you are and true to yourself directly will impact your level of confidence, performance, and satisfaction. As a reminder, Benmore values are: honesty, operating in good faith, care and pride in work, expertise, long term business decisions, and collaborative long term partnerships. If a client is not acting honestly in good faith, or forcing us to not act honestly or in good faith, major issue. If a client does not seem to be treating the project with care and pride or is diminishing the care and pride that we put in projects, big problem. If a client is not respecting our expertise, big problem. If a client is impeding on long term business goals, big problem. If the client does not see a Benmore engagement as a long term partnership (not necessarily that they must never leave us, but more so that they see us as means to an end) big problem. Beyond that, if the client is ever demeaning or disrespectful, huge issue. Typically project separation will need to be approved internally, but if the decision is made to pursue separation there are some guidelines to follow.
Navigating project separation is different on a case by case basis, and it typically helps to involve peers or senior members to portray a united front of sorts. Once the decision is made, it’s important to prepare for the conversation and mentally prepare yourself for potential hostility. Ideally, at this stage, you have already had a discussion or two that outline the red flags you are seeing with the project. Regardless, rationale for project separation does not need to be communicated, and many times should not, especially if a series of discussions has already taken place. Beyond that, prepare yourself for hostility or retaliation from the client, and understand that, in these cases, the worst thing you can do is return the hostility. If hostility is encountered and is blatant, disturbing, or an extreme outburst - state that you will be sending written notice of project termination, any future correspondence in relation to separation logistics will be conducted via email, and leave the situation. From a demeanor standpoint it’s important to stand your ground, do not backtrack, do not allow for realignment, this decision has been made and for better or worse it’s not changing. It’s important to note that communication of willingness to separate is different from notice of separation. Willingness to separate can be communicated professionally in realignment meetings or discussions surround red flag identifications and need to correct behavior. Notice of separation is final.
Project Separation Process
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ │ │ │ │ Red flags │ │ Realignment │ │ Decision: │ │ identified │───────►│ meeting(s) │───────►│ Separate? │ │ │ │ (with examples) │ │ │ └──────────────────────┘ └──────────────────────┘ └───────────┬──────────┘ │ ┌────────┴────────┐ │ │ YES NO │ │ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ Prepare & │ │ Continue with │ │ get internal │ │ new boundaries │ │ approval │ │ │ │ │ └──────────────────┘ └────────┬─────────┘ │ ▼ ┌──────────────────┐ │ │ │ Deliver notice │ │ (FINAL) │ │ │ └────────┬─────────┘ │ ┌────────┴────────┐ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Offer staff │ │ Refer to │ │ placement │ │ dev agency │ │ │ │ │ └──────────────┘ └──────────────┘Separation Checklist:
Sometimes, as we have encountered many times, it helps to provide alternative methods of project progression when communicating project termination. One method that we utilize and often ends up working out is staff placement. In situations where the client is basically expecting an employee or treating you as one you can offer an FTE placement as a solution to project termination. Most of the time where we see this working out is in situations where the relationship with the client is solid, however, they aren’t looking for consulting and we are unable to progress past the recommendation phase. Typically, we’ll say that what they need is just someone to do their bidding, which again is fine, we explain the risks associated with staff allocation, we explain project outcome ownership transfer, and most of the time, this is exactly what they were looking for anyways. This way the relationship stays intact, partnership continues, but ownership and risk is transferred. Another proven path forward is a handoff to a development agency or shop. A firm that specifically doesn’t do consulting, but does act as implementors. If you have a solid relationship with an agency, this can be a fluid continuation of the project and you can get a referral fee as well.
Wrapping this up though, what this all boils down to is project terminations are extremely important, as important as completing projects - but they must be handled with grace. When done properly, you can protect yourself, your company, your other clients, and, most of the time, the client of the separated project as well.







