Rules to Better Software Consultants - Happy Clients - 10 Rules

Just like how a beautiful house is more than the bricks, a software project is more than the sum of the coding tasks.

Let's see what should be included :

In fact, for every 1 hour of 'application building' coding tasks there is between 1 and 4 hours of other work which SSW will charge for. This other work includes administration, testing and bug fixing.

Here is a list of the items which SSW considers when estimating a release.

We’ve all experienced that awkward silence in a Sprint Review when the boss joins the call, expecting features to be done... and they’re not. Maybe the requirements weren’t clear, maybe a "quick fix" exploded into days of debugging. Whatever the cause, the result is the same: another commitment missed, and another dent in trust.

When teams consistently overcommit and underdeliver, it breaks confidence with clients and stakeholders. Trust is hard-earned and easily lost, especially in high-budget, high-pressure environments.

The planning fallacy is real

Humans are naturally optimistic when estimating how long tasks will take. This is known as the planning fallacy. We consistently underestimate our own work by 20–50%, and the more complex the task, the worse we get.

What’s interesting is we’re better at estimating how long others will take. This means we often set unrealistic expectations for ourselves.

Why underpromising works

Underpromising and overdelivering flips this dynamic. Instead of making excuses later, you can:

• Build trust with consistent, reliable delivery
• Create positive surprises that strengthen client relationships
• Give your team breathing room for the inevitable unknowns

Tips to apply this rule

1. Estimate realistically

Avoid “sunshine estimates”. Add buffer time for the unknowns—because they will happen. Don’t just plan for the best-case; include the expected and worst-case as well.

2. Communicate clearly

If you’re ahead of schedule, tell the client. If you're falling behind, say so early. Clients are forgiving when you’re transparent—radio silence is what causes frustration. This will help minimize surprises at the Sprint Review. See our rule on having Corridor Conversations

3. Prioritize consistency over perfection

You don't have to wow every Sprint. What clients value more is predictability. Be the team they can count on.

“It’s not about hitting every target perfectly. It’s about reliably delivering over time.”

– Michael Smedley, SSW

Final thought

Software development is about more than code. It’s about building trust. And nothing builds trust faster than consistently delivering more than what you promised.

Video: The Secret to Client Trust (2 min)

Estimating time and complexity in software is hard. By its nature, almost all software development is attempting to solve problems no one else has done before. Industry veterans broadly agree that up to 60% of time and effort in software development is consumed by resolving unanticipated issues. Developers call these unanticipated issues "unknowns". Businesses call them "risks".

When you're scoping out a piece of work, it's important to help the business understand and manage those risks, and help shine a light on areas where risk can quickly snowball.

The initial estimate

When estimating a piece of work, the first thing to do is come up with a baseline estimate before applying any risk multipliers. This is the initial estimate.

How big/complex is the change?

While this is probably the most obvious area of risk, it is still risk and therefore worth remembering. Perhaps the feature or change you're being asked to do is merely changing the colour of a button (hey, it happens!). Maybe the feature is adding a shopping cart to a website. Don't take things at face value: ask questions, describe the flow. More often than not, you'll start teasing out additional requirements that you didn't know about.

A typical conversation around something like "add a shopping cart" might play out like this:

One of the best ways to identify these complexities is to run an "Event Storming" session. This approach is highly recommended for all medium to large projects, as it’s proven effective in identifying complexity and clearly demonstrating it to non-technical stakeholders.

The risk multipliers

Once you have your initial estimate, it's time to examine which (if any) risk multipliers apply to the piece of work.

How well do you know the codebase?

If you've been working on a project for a suitable length of time, you should know your way around its architecture and code flows. This will provide significant context when gauging the required effort to build out the feature you're estimating.

On the flipside, if you're a contractor, consultant, or simply new to a project, the existing codebase is a massive unknown and holds a great deal of potential risk. The feature you're estimating may seem simple at the surface, but when you discover a mess of spaghetti code and zero documentation, you will find yourself burning huge amounts of time just trying to grok what's currently happening before you can write a single line of code.

How often have you done this work?

If you're a back-end web developer, and the feature you're estimating is some simple CRUD endpoints, you've probably done this type of work hundreds of times before. You know what's required, and you know can confidently gauge how long it will take.

Alternatively, if you're being asked to build something exotic, or even just outside your wheelhouse, confidence can drop quickly. Maybe what's being asked is simply not possible, or requires significant infrastructure or iteration before meeting requirements. Know your strengths, and more importantly, know your blindspots.

Managing risk

Okay, so you've done your best to identify as many risk factors as possible. How do you manage that risk?

Option 1: Overestimate everything

The old "think of a number and double it" approach has been a common estimation strategy for decades. While this definitely has its place, your doubled estimate is still at risk of being wildly incorrect. Humans are terrible at estimating. If you're leaning on this approach, you still leave yourself open to risk when your doubled value should have been tripled, or quadrupled.

This can be acceptable when the work you're estimating is building on previous features, or when you already have a lot of the context front of mind and can already "see" the solution in your head. Just be conscious of the fallout if your estimate is off by a factor of 4 (or more). How does that affect the delivery of this PBI? A 2-hour estimate ballooning into a day is far less devastating than a 1-day estimate ballooning out to a week.

Use this approach when:

• The scope is known
• The codebase is known
• The complexity is low/moderate

Option 2: Spike or PoC

One of the most reliable ways of reducing risk is to invest some R&D time into the task before committing to an approach and estimating the effort. There may be more than one potential way to solve a given problem, but you aren't sure which method will work best for the current project. Having time to investigate these options can save you hundreds of hours of pain further down the development cycle. The more variables there are in a given problem, the stronger the case for a Spike and/or PoC.

Use this approach when:

• The scope is known
• The codebase is known/unknown
• The complexity is moderate/high

Option 3: Narrow the scope

Sometimes, a piece of work is simply too large to adequately identify and manage its risk. In these cases, the best thing to do is break the work down into smaller chunks, and repeat the process outlined above for each subsequent chunk. This may need to be an iterative process (maybe the resultant chunks still have too many unknowns), but breaking down herculean tasks into smaller, more manageable pieces, is a tried and true way of making the impossible possible.

Use this approach when:

• The scope is unknown
• The codebase is known/unknown
• The complexity is moderate/high

Summary table

Scope	Codebase	Complexity	Recommended approach
Known	Known	Low/Moderate	Overestimate everything
Known	Known/Unknown	Moderate/High	Spike or PoC
Unknown	Known/Unknown	Moderate/High	Narrow the scope

---

Guidance for large or complex projects

If you're in the enterprise space, or working on projects that have many moving parts, follow this high-level plan:

1. Select a single business goal/process
2. Run one or more Event Storming workshops to map out the business flow
3. Create epics for each Key Event
4. Perform a Specification Review for each epic
5. Decompose the epics into PBIs
6. Use the strategies above to identify high risk areas

"I love deadlines. I like the whooshing sound they make as they fly by."

• Douglas Adams

Do not wait until you have started to exceed your estimate before you notify the client that the release is running late.

An oversized invoice with no warning is never a good experience. A client will always prefer to be told ahead of time if a piece of functionality is going to take longer than anticipated. It gives them more control of what is going on.

Never keep the client in the dark when you exceed your estimates, it will only arouse suspicion and mistrust when they see the project deadline woosh past. It's best to tell the client as soon as the risk is identified to inform them of what's going on and ask "Do you want us to continue?".

For this reason, blowouts should be reported in the Daily Scrum, as well as any major delays being told to the client as soon as possible, so that they don't get a big surprise in the Sprint Review. This will ensure that the client is fully aware of any problems and has a chance to decide an alternative action.

Keep clients informed and avoid conflict by informing them ASAP and documenting estimates overrun in an 'as per our conversation' email:

"Sometimes it's better to ask forgiveness than permission" Tony Abbott

The trouble is that the above is predicated on the notion that you're doing something wrong and are happy spending time putting out fires that needn't have been lit.

Let's see how to live without stomach ulcers...

Get permission for the work you do *before* you do it. Usually get permission verbally, confirmed with an email (or with a signature, although that's sometimes a whole lot harder).

The natural time for this conversation to occur is in the Daily Scrum

Always get permission for:

• Additional Items
• Investigation time for scoping out additional items
• Adding additional resources onto a project
• Exceeding estimates
• Data migration

Having said that, you need to manage two potential problems with seeking permission on work before acting:

• Increased dead time while waiting for approval
• Discouraging initiative to fix problems quickly

This rule is not generally applicable if:

• You are working on an ad hoc basis on a client managed project
• The task is an obvious task which you would reasonably assume the client would approve and is not likely to take more than half an hour.

When you are working on a project, you need to follow the get work approved before you do it rule. However, you should assume some tasks will be approved by a client and do them anyway. This of course depends on the size of the task (e.g. half hour or less) and the obviousness of the task.

If you reasonably assume that the task you are working on would be approved by the customer, and it will take less than half an hour, you should go ahead with that task.

To: ScottSubject: QWI - Aqua UI Improvements from Adam

Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes.Please approve.Figure: Bad example.To: ScottSubject: QWI - Aqua UI Improvements from Adam

Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes.

I have made these small changes. Test please.Figure: Good Example.

Each Sprint has a "Sprint Forecast" email that details what will be worked on during this Sprint.

At the end of the Sprint, this should be replied to with a "Sprint Review" email that shows a breakdown of what was completed.

If you're using GitHub to manage your project, create repeatable templates that can easily edited and emailed out.
See GitHub Issues - Do you create a template for your Sprint Reviews, Retros and Forecasts? for more details.

Each Sprint has the following stages:

1. Planning meeting

   • Sprint Forecast email: "Northwind - Sprint 5 Forecast"
   • See Do you send "Sprint Forecast" email to the client? for more details

2. Work in progress

   • "Done" emails are sent asking for specific functionality to be tested
   • See Rules to better Email for details

3. Review and Retro meetings

   • The Sprint review/retro email: "Northwind - Sprint 5 Review/Retro"

When you are about to finish a client project, it is a good idea to prepare a "thank you" email, have it checked and send it to your customer (usually the Product Owner) on the last day. In this email include:

1. Make sure you have completed all requirements
2. Thank for the time and tell them the reasons why you enjoyed working on this project
3. Prepare a list of future improvements you can think of that can be done

There are a number of reasons why this is important:

• It shows that you care about your client/project
• Give them something to think about. They might get you back to fix the problems you have identified
• Show that you will be supporting them after the project ends

Below is a template email you can use:

Email Template

It is really important to understand the difference between a Proof of Concept (POC) and a Minimum Viable Product (MVP). It is also important that clients understand the difference so they know what to expect.

POC: Proving feasibility

A POC is developed to demonstrate the feasibility of a concept or idea, often focusing on a single aspect of a project. It's about answering the question, "Can we do this?" rather than "How will we do this in production?" POCs are typically:

• Quick and focused: Developed rapidly to test a specific hypothesis
• Experimental: Used to validate technical feasibility, explore new technologies, or demonstrate a concept
• Disposable: Not intended for production use; often discarded after proving the concept

POCs should be built, tested, and thrown away. They are not intended to be used in a production environment.

MVP: Delivering value

Conversely, an MVP is a version of the product that includes just enough features to be usable so stakeholders/users can provide feedback for future product development.

• End-to-end functionality: Covers a single feature or user flow in its entirety
• Production ready: Developed with more attention to detail, as it will be used in a live environment
• Foundation for iteration: Serves as a base to gather user feedback, validate assumptions, and guide future development

Examples

Consider a startup exploring the use of AI to personalize online shopping experiences. A POC might involve creating a basic algorithm to recommend products based on a user's browsing history, tested internally to prove the concept's technical viability.

Building on the POC's success, the startup develops an MVP that integrates this personalized recommendation engine into their shopping platform, deploying it to a segment of their user base. This MVP is monitored for user engagement and feedback, shaping the future roadmap of the product.

Best practices

• For POCs: Clearly define the concept you're testing. Limit the scope to essential elements to prove the hypothesis. Remember, POCs are not mini-products
• For MVPs: Focus on core functionality that delivers user value. Engage with early users for feedback and be prepared to iterate based on what you learn

Sometimes people get in the bad habit of reacting poorly when they receive some negative feedback, bad news or disappointing results.

These habits are not good as they lead to negative emotional responses.

To get out of this habit, you can try to separate the initial emotional urge from the actual behavior and break the connection.

Next time you are in a situation where you have the urge to respond negatively, instead of reacting immediately set a timer for 30 minutes.After this time, you can decide if you still want to proceed once your head is clear.

This technique can help you:

• Avoid saying things you don't mean
• Make more logical decisions
• Overcome bad habits
• Manage your emotions

This concept applies at work and at home.

Video: A useful tool for quitting bad habits and poor emotional reactions (3 min)

Example

Imagine John implemented a nav menu on a website, and he receives this email from the client.

Option 1 - React immediately

Option 2 - Set a time for 30 min, then respond

You will be able to respond calmly and logically.