Rules to Better Software Consultants - Dealing with Clients - 56 Rules
Being a software consultant involves more than just coding. How you manage and communicate with your clients is vital to your success.
The other half of being the best consultant possible can be found at Rules to Better Software Consultants - Working in a Team.
The 3 A's for being a good consultant:
- Having Ability
- Being Affable
- Being Available
Video: The 3 A's of Being a Good Consultant (1 min 23 sec)
Being available may be hard sometimes, but it doesn't mean right away. As long as you can give a deadline and do it customers will be happy.
The first impression given to a prospective client or employee is essential to forming their image of a company. A bad impression means they are unlikely to be interested.
The scenario
Consider the situation where you jump in an elevator and start chatting to the other person and they ask "What does your company do?"
There is probably under 60 seconds to give an answer that will excite them about your company.
This conversation is called the "elevator pitch", and knowing how to do it is crucial.
This doesn't just happen in elevators, this can happen when you meet a new client, it can happen at an event, it can happen when you're at a barbecue with a friend. The more effort you put into doing this well, the better you will sound.
Although not everybody is in sales, we all will have to convince others at different times.
How to form an elevator pitch
To form an elevator pitch, it is important to collate your thoughts about the ethos of the company. Consider these areas:
#1 The What
Think about what your company does and for whom, focus on the problems they solve.
For example:
- We build enterprise custom software for businesses.
Tip: You might have 15 great points, but start the conversation with a couple of important ones. Consider who you are speaking to when choosing the highest value points.
#2 The Unique Value
Now think about the unique value the company delivers to clients and note it down too.
For example:
- We work in Scrum teams
- We build with Microsoft technologies
- We use and publish best practices
#3 The Where
Finally, where do you do business?
For example, the company might have offices in:
- Sydney
- Melbourne
- Brisbane
- Newcastle
- Hangzhou
- Strasbourg
#4 Now practice
Now you have a few bullet points, go outside and record a quick video from memory. Here's a few tips to get it right:
- Hook people in - Make sure to mention the question at the start, so people have a little context.
- Practice and perfect it - Do a few takes until it feels right
There you go, that's your elevator pitch!
Let's take a look at some examples of an elevator pitch for SSW:
Video: Piers does an elevator pitch Video: Uly does an elevator pitch Video: Matt does an elevator pitchThe scenario
Consider the situation where you jump in an elevator and start chatting to the other person and they ask "What does your product do?"
There is probably under 60 seconds to give an answer that will excite them about your product.
This is similar to an elevator pitch, it can happen when you meet a new client, at an event, when you're at a barbecue with a friend. The more effort you put into doing this well, the better you will sound.
Although not everybody is in sales, we all will have to convince others at different times.
How to form a pitch
To form a pitch, it is important to collate your thoughts about the product. Consider these areas:
- The what
- The unique value
- Call to action
#1 The What
Think about what your product is, focus on the problem it solves. Also, remeber that whether they're technical people or not, always try to use laymen terms and keep it simple.
For example:
- TinaCMS is a Headless CMS where your content is stored as Markdown in GitHub
Tip: You might have 15 great points, but start the conversation with a couple of important ones. Consider who you are speaking to when choosing the highest value points.
#2 The Unique Value
Now think about what your product does and its competitors don't. What makes your product special?
For example:
- GitHub enables version control and great approval workflow
- Great editing UX
#3 The call to action
Think about where people would go to get more information or to buy the product.
e.g. "If you want to learn more, check out the demo on tina.io"
Now practice
Now you have a few bullet points, go outside and record a quick video from memory. Here's a few tips to get it right:
- Hook people in - Make sure to mention the question at the start, so people have a little context.
- Practice and perfect it - Do a few takes until it feels right
There you go, that's your pitch!
Let's take a look at some examples of a pitch for TinaCMS:
Video: Piers pitches TinaCMS (Developer's perspective) Video: Gert pitches TinaCMS (Business persons perspective) Video: Adam pitches TinaCMS (History perspective)Existing clients should always be the first thing on your mind. Any work relating to existing clients should be done before looking into anything else, including prospective client work.
In order to gain a good reputation in the industry, it is vital to make existing clients happy. If you are seen as being more interested in getting new clients than satisfying old ones, not only will you not receive return business, but you may have lost credibility in the industry and the chance of referrals from their contacts.
A good saying pertaining to keeping your existing clients happy is: "A bird in the hand is worth two in the bush".
Why is it important
Keep in mind these statistics (2024):
- Existing customers are more likely to make repeat purchases: Existing customers are 50% more likely to try new products and spend 31% more compared to new customers.
- Retention is cheaper than acquisition: Acquiring new customers is anywhere from 5 to 25 times more expensive than retaining existing customers .
- Retention boosts profitability: Increasing customer retention rates by just 5% can increase profits by 25% to 95%, depending on the industry .
- Revenue from loyal customers: 65% of a company’s business comes from existing customers . Also, they tend to spend about 67% more on average than new customers .
- Retention impacts growth: Businesses with strong customer retention see up to a 50% higher revenue growth rate compared to those focused mainly on acquisition .
How to retain customers
One way to keep existing clients happy is making sure the client is never waiting for you to do something.When emailing a client, especially when an engagement is coming to an end, always include a clear request or action. Make sure the ball is always in their court 🎾
Lee Iacocca, the legendary automotive executive, believed in closing any business discussion with an "ask" to maintain momentum and focus on outcomes. He emphasized the importance of always having a clear request or actionable step at the end of a conversation, whether it was for commitment, resources, or next steps, to drive progress and ensure accountability.
It is extremely important to demonstrate to potential clients a high level of quality service and attention to their needs; Whenever you receive an email from a potential client in relation to possible consulting work, you should make sure they receive an answer within 5 minutes of you receiving it. This is for 2 reasons:
- To show you are keen and to give an indication of the level of service they will receive
- To stop them "shopping around"
They will quickly recognize that they will not receive that kind of service anywhere else!
If you have followed the previous rule and the ball is always in their court, you need to make sure that they keep playing.
The best way to do this is to make sure you follow up all communications that require a reply, whenever you feel that a bottleneck is forming.
The best ways to follow up a client are:
-
Use email
If there is no response, find the original email and resend.
See our Rules To Better Email - Use IM or Skype
See our Rules To Better Instant Messenger - Use the phone
Call them
Tip: You can use FollowUpThen.com for your follow up emails.
-
A lot of time in a consultancy can be taken up by producing estimates for clients so they can see a ballpark of what they will be spending. Because this time is not billed, it is easy to end up with rushed and inaccurate estimates, leading to problems later in the project.
A better way to go about it is to spend a little more time, and really get down in detail to what needs to be done. This is called a Specification review and is billable.
The exception to this rule is if the client is happy to invest some of their own time to help you come up with a ballpark, then you can spend some time on it for free as this should help to get the client feeling invested in you and therefore more likely to go ahead with the work.
Fixed-price, fixed-scope projects sound good but rarely end up with the expected results, either for the client or the developers. This type of project generally demand a sequential design process, and often, the waterfall methodology is chosen. Most likely the key players will end up disappointed.
First, let's define what is meant by "fixed price" and "waterfall" in software development:
- Fixed price: A pricing model where the client pays a fixed amount of money for a predetermined scope of work. The scope of work is typically defined in advance, and any changes to that scope can result in additional charges or renegotiation of the contract.
- Waterfall: This is a traditional project management approach where the development process is broken down into distinct phases, such as requirements gathering, design, implementation, testing, and deployment. Each phase is completed before moving on to the next, and changes to requirements or design are typically not allowed after a phase has been completed.
Now, let's look at the main reasons why fixed price and waterfall can be dangerous in software development:
1. Lack of flexibility: You can’t predict the future. Fixed price and waterfall approaches are typically very rigid, with little room changes. Since it's knwown that requirements frequently change as the project progresses, and new information can come to light that requires a change in direction. The "Cone of Uncertainty" shows the range of cost changing at different stages through a project:
2. Extra cost and slow progress: With a fixed price and waterfall approach, any changes to the scope of work or requirements can result in additional charges or delays.
3. Limited collaboration: Waterfall projects often involve siloed teams, where each team works on their part of the project independently without much collaboration. This can lead to a lack of communication and understanding between teams, which can result in delays and mistakes.
3. Delayed feedback: In a waterfall approach, feedback is typically only received at the end of each phase. This can lead to costly mistakes, as any issues or bugs may not be discovered until much later in the development process.
4. Reduced quality: With a fixed price and waterfall approach, the focus is often on completing each phase on time and within budget, rather than on producing a high-quality end product. This can lead to corners being cut and the final product being of lower quality than it could be.
5. Increased risk: Fixed price and waterfall approaches can increase the risk of project failure. With little room for flexibility or changes, any issues or problems that arise can quickly become insurmountable, leading to project delays or even project failure.
In summary, a fixed price and waterfall approach can be dangerous in software development consulting because they lack flexibility, limit collaboration, delay feedback, reduce quality, and increase risk.
The solution
The use of an iterative agile methodology (like Scrum) provides constant feedback and collaboration, giving the necessary agility to implement features while allowing adjustments during the project. This iterative development process can help mitigate the risks and lead to a more successful project outcome.
If you have an existing client, who is already impressed with your work, you don't need to go to the trouble of meeting then to show them an estimate. However, you should at least call them. When you're competing for someone's business, what could be worse than losing the work simply because the client either didn't receive your email, or was too busy to read it? For this reason, always call the client before you send a quote. This way, they know you are about to send them something so will look out for it.
Hi Mr.Northwind,
As per our conversation today, here is a ballpark schedule for the work we talked about. As you can see all the items are listed separately so you can identify how the estimate is put together. I'm very happy to discuss these estimates with you so feel free to give me a call.
Figure: Always call the client to let them know that you are about to send a quote across, then send an "As per our conversation" email
With the convenience and cost-effectiveness of email, it is tempting to rely on emails for all client contact. Don't forget that clients are people too, and they need human interaction to ensure everything is OK. So it is essential that you maintain verbal contact before, during, and after a project.
Avoid going more than 3 days without a phone call to your client.
Set the expectations early. Let the client know what to expect in terms of communication. For example:
"Hi Bob,
We will run your project using Scrum. Expect emails and phone calls that we need responses to:
- Planning - we will agree on a Sprint Plan at the beginning of each Sprint
- Every morning - expect a Daily Scrum meeting or video call with a list of tasks the developers will be working on that day
- Every time a task is done - you will get an email with information about what was done, often including screenshots and code snippets"
If you use the phone instead of email when it is appropriate, you maintain an open channel of verbal communication with your client. This helps to break down communication barriers, lets the client know that you are friendly and involved, and makes them feel confident in your ability to deliver the project.
New resources
If you are put onto an existing project, it is good practice to call the client and introduce yourself. For example:
"Hi Bob,
I'm Andrew. I'll be taking over from Mark on your project. Mark has filled me in on the specifics and I'm keen to get involved."
There are two fundamental ways any consultant can bill clients:
Time and Materials
Time and materials is the standard mode of operation where the client is billed for the time spent by the consultant. There is no warranty on time and materials work.
Fixed Price
Fixed price is where the client is billed a fixed amount agreed between the client and the consultant. Fixed price contracts have the following conditions:
- All specification work to be conducted on a Time and Materials basis
- All screen mock-ups and business rules must be signed by the client
- A fixed price can only be done on a release by release basis, not on an entire project (this protects everyone)
- A 20% premium is added to the release estimates - just like an insurance premium because the consultant is carrying the risk
- Variations/change requests have to have separate written approval. e.g. Hi John, You've asked for XXX. This is not covered in the original scope and so will be charged extra. Our estimate is YYY hours at $ZZZ + GST per hour. Please approve.
- Development is conducted off-site (to prevent unauthorised scope-development)
- 50% of the fixed price is payable before work commences, the balance is payable at the delivery of the first external test please.
- There is a 7 days warranty on bugs which commences when the first external test please is issued.
- Warranty only applies to development / staging environments (once the work is deployed to Production, no waeeanty applies).
- The following release cannot commence until the prior release is signed-off.
This set of conditions ensure a fair distribution of risk for both parties. It's perfectly fine to be unhappy about a feature and requesting some changes, but once approved, a piece of work shouldn't be worked on again for free.
Analogy
The warranty process is similar to what happens at a restaurant; if you look carefully when your meal is served and realise it's not what you ordered or there's something wrong with it, it's perfectly fine to send it back. However once you've started to eat your burger, it's too late to send it back and ask it to be changed 🧑🍳
When working on a Time and Materials basis there are two different management arrangements depending on what the client requires.
A. Ad-Hoc Work (The Client is agreeing to the time)
Working on an ad-hoc basis allows tasks to be done as they are requested without any formal approval process. This is a simple approach but provides little in the way of management or accountability. This may be suitable for ongoing work such as application maintenance with longstanding clients OR working under a client manager.
The ad-hoc work approach should not generally be used for project work where the client wants you to manage project elements such as time, scope, quality, and cost.
This approach can be useful for problems where time or effort is not immediately known and not possible to estimate with the information at hand. The types of work this may include would be support jobs or investigatory work.
There should be an agreement of the time allowed to be spent ahead of time, even if what is being worked on has no scope.
B. Managed Work (using Scrum, the Client is agreeing to an outcome that the consulting company controls)
The alternative is to work with a Scrum Master, or a Project Manager, with specification, and Sprint plans. In this approach, management is applied to provide control and additional communication and controls of the elements of time, scope, quality, and cost.
This method is recommended for any work which is substantial and where the client wants a greater degree of control. In this approach, backlog items are created during the Spec Review process while creating the project estimates, which can be used to create the Sprints.
As a consultant, it is important to realise that all of your time is valuable.
In the situation where you are at a client site and your time is being billed, don't be conscientious and quiet. You need to make sure that there are no bottlenecks slowing you down. Make sure you have everything you need and, if you need to ask a question, keep asking until you get an answer.
Clients will always prefer a slight irritation at the time rather than an inflated invoice with no result later on.
You need to be persistent. You should make sure that you don't let good ideas go because you get *one* 'No'. Instead put it on a 'My Good Ideas for the Boss' list and bring it up with your boss a few times.
This is a very important concept, just because you get answered 'No', it does not mean that it is a bad idea, or that it will not benefit the company. You may get the answer 'No' for reasons that you do not know about, such as financial difficulties, or it is too busy at the moment to worry about. So put these ideas onto a list, and remember to bring them up with the boss at a more appropriate time, say a couple of weeks later. If you are not satisfied with the result after a few times, consider going a level higher and talking to your boss about your idea, so you understand why they made the decision they did. It is important however to realize that not all your ideas are going to be good ideas, so accept that after you get a few 'No's.
Print "My Good Ideas for the Boss" sheet and have it ready for your bright moments. In case you don't have one in hand, draft an email or a note, but don't let good ideas go.
If you don’t make another appointment to see a client before you leave you may forget, and the client may forget. Make sure they are thinking about your next visit by booking the next appointment there and then, even if it is not for many months.
Use your mobile phone to book an appointment rather than remembering it later. If the systems are down, you may forget it entirely and that would be worse than never having made it.
See the best way to book yourself in using the CRM Service Calendar.
Is your price:
- $100 per hour + GST (the $100 being the amount exclusive of GST)
- $110 per hour (the $110 being the total amount)
We say the first one. When providing quotes to prospects/clients, it is always better to display the net value + 10% GST rather than the total.
The reasons for this are:
- It avoids any confusion as to whether GST is included.
- This net amount is the REAL cost to the customer, as they get the tax back (in Australia).
- The net value is lower and appears more attractive to the client.
- The 10% GST charged to the client is not income for your company. In Australia, we collect this 10% on behalf of the Australian Taxation Office.
- The client will receive back this 10% GST from the Australian Tax Office when they do their quarterly BAS/GST Return.
The total fixed price total is $AUD 66,000 - please find quote attached.
Figure: Bad example - GST is not mentioned
The total fixed price total is $AUD 60,000 + GST (10%). Please find quote attached.
Figure: Good example - net amount + GST
Note #1 : SSW and other Australian companies do not charge GST to external clients outside of Australia.
Note #2 : This only applies for business to business transactions. When selling goods or services to individuals for domestic or personal use in Australia, prices must be quoted inclusive of GST as per the Competition and Consumer Act 2010.
While you are writing out a quote, make sure you know when to use a round or exact figure.
Often clients will call up asking for a short task to be performed. You need to know how to let them know that the time will be charged.
"Let me remote into the server to investigate"
Figure: Bad example - they don't know this will be billed
"If it was a quick 5 mins I would do it for free, however I need to do a little investigation. First impression is that it might take me a couple of hours... if that is OK, let me know."
Figure: OK example - Making sure you won't work for free
"Let me see if I can get you a booking for tomorrow"
Figure: Good example - Booking in a day of work minimises context switching, and trains the client to book you for 1 day at a time.
The least pleasant part of the consulting industry is dealing with clients who don't want to pay for your services.
It's important that the client is *always made aware* from the beginning what they will and will not be charged for. That way, they will never receive an invoice they are not expecting and so will be happy to pay them.
If an issue does come up, make sure you come to an agreement quickly and don't let the issue fester as it can lead to a lack of customer satisfaction and people can start digging their heels in, leading to a lot of time wasted on working out whether the client will pay or not.
If someone else needs to be consulted for approval (e.g. the boss) get them on the phone straight away, rather than speaking to them later and then having to organize yet another meeting with the client.
When a client arrives, your job is to make them feel comfortable and impress them with your professionalism. It is important that clients have a consistent experience in their contact with your company.
- Leaving the client standing at the reception while finishing what you were doing
- Offering them tea, coffee or biscuits (not everyone likes tea/coffee)
Figure: Bad example - This could start the meeting poorly
- Be dressed appropriately
- Greet them warmly
- Have a firm handshake
- Make eye contact and smile
- Direct them to wait in the waiting area (so they can learn about the company through our tv screens)
- Notify the project manager/developers who are included in the meeting
- Ask someone to bring a couple of glasses of water into the meeting (as everyone drinks water)
-
Join the meeting in the boardroom:
- Show some enthusiasm when meeting with the client
- Hand over, and collect, business cards - (organize in front of you, to help you remember their names)
- Use their names a few times early on to help you remember their name
Figure: Good example - You are starting off the meeting well
Tip: You should do a role-play with your manager being the client. Then get feedback on how he/she found the experience.
Meetings are an area some clients think will be free, so always mention it.
As stated in SSW's Terms and Conditions:
In an hourly work agreement, the initial meeting with the customer will be conducted by SSW at no cost. Subsequent meetings are considered as specification time and will be charged at the agreed rate. The minimum time chargeable for on-site work is 2 (two) hours per person per visit. The minimum time chargeable for off-site work is 15 (fifteen) minutes per person per request.
In some occasions it may be necessary to compromise by charging for the developer's time but not the project manager's.
Before you attend a meeting you must come prepared with as much information as possible about the client; meaning no unnecessary questions. You should already have the answers to most generic questions. Extensive research is impressive to clients.
For example, when talking to a client about their ice cream chain...
How many outlets do you have?
Where is the main outlet?
Figure: Bad example - You should already know the answers to these questions by visiting their website
I noticed you have x amount of outlets, are you planning to open up more, when and where?
Which of your products contribute most to your gross profit?
How do most of your customers hear about you?
Do you have a customer loyalty program? Is it working?
Where are some of the biggest challenges / opportunities for you at the moment / in the future?
Figure: Good example - By asking questions, you show interest as well as initiating conversation - remember to get the customer talking
Look for points of pain and build on them - if there's no pain it's hard to fix the problem properly.
Tip: Google the client's name before the meeting. Customers' ears prick up when they hear that you googled them.
Anchoring is a cognitive bias where an initial piece of information (the "anchor") heavily influences subsequent judgments and decisions. This bias can infiltrate various aspects of our lives, including workplace interactions and negotiations. Recognizing how anchoring works is crucial to making informed and unbiased decisions. Custom software is difficult to estimate and using an anchor too early or without the necessary rigour can create issues.
For example, in meetings, it's vital to be aware of anchoring, as the first opinions can shape entire discussions. Seniors and experts can influence a meeting's direction and create anchoring effects; therefore, they should offer their ideas last.
Video: Jeff Bezos: Truth is uncomfortable | Lex Fridman Podcast Clips (6 min)Negative impacts of anchoring
An anchor can limit adaptability, making it harder to find mutually agreeable solutions. For instance, a developer’s best guess on a project budget might discourage the client from choosing your solution looking for other options that could be better suited and more cost-effective.
Key reasons to avoid providing an anchor
- Limited information: Early estimates often lack the detailed requirements and complexity analysis needed for an accurate price. Setting an anchor prematurely creates a false sense of precision and sets unrealistic expectations
- Loss of flexibility: A strong initial anchor can stifle negotiation and make it harder to adapt your proposal as more information becomes available. This can hurt your ability to arrive at a price that's fair for both you and the client
- Damaged trust: If the final estimate varies significantly from the initial anchor, it can erode the client's trust in your process. Transparency and an open discussion of uncertainties upfront are key to building a strong client relationship
How to deal with anchoring
Sales need to establish the client’s anchor, if they have one, by asking:
- "Can you describe the process you need improved and its main challenges?"
- "How does this issue impact productivity or costs?"
- "What's your decision-making process and who's involved?"
- "What's your timeline and budget for a solution?"
When asked for an early estimate on a new project, a developer might say "I reckon it'll cost around $50,000". This off-the-cuff estimate sets an unverified anchor that might restrict further discussion and lead to budget constraints based on a premature guess.
Figure: Bad example - Premature estimation without due diligence can lead to inaccurate budgeting and client expectations
Conversely, when asked for an early estimate, a more experienced developer might respond, "To give you an accurate estimate, we should conduct a Specification Review where we can consider all aspects of the project. This way, we can provide a detailed and reliable estimate that reflects the project's complexity".
Figure: Good example - Suggesting a Spec Review ensures that any estimates provided are well-informed and considered
Key Takeaways
- Be aware of how anchoring bias can influence decisions, both within yourself and others
- Proactively seek diverse perspectives to mitigate the bias
- Approach initial information critically, even if it seems compelling, to avoid getting overly 'anchored' in one viewpoint
- Use anchoring strategically for setting expectations or initiating negotiations, but be prepared to adjust as needed
Clients often have an implicit budget or value anchor in their minds when discussing projects. This anchor can be based on a budget set by their business or a perceived value. If you don't uncover this anchor early, it can lead to misaligned expectations and project dissatisfaction.
Understand the Client's Perspective
Clients might not always communicate their budget or value expectations openly. It's crucial to ask the right questions to uncover these hidden anchors.
- Ask direct questions: Questions like "Do you have a budget range in mind for this project?" or "What value do you expect this project to deliver?" can prompt clients to reveal their anchors.
- Understand their constraints: Discussing their financial constraints and priorities helps in understanding the flexibility of their budget.
- Look for cues: Pay attention to any indirect hints about their budget or value expectations during conversations.
Common Types of Anchors
Clients typically come to meetings with one or more of the following types of anchors:
Budget Set by the Business
Often, clients have a budget set by the board or a financial decision-maker within their business. This budget is closely linked to the problem being solved.
Example: If the problem is driving to the shop, but the only solution presented is buying a Lamborghini, and the client doesn't have the funds, this high cost will act as an anchor preventing the purchase.
Experience-Based Anchor
Clients might have previous experience with software or services that set their expectations. These experiences create a benchmark in their minds.
Example: A client who has previously developed software with a specific budget might use that experience as a reference point for current projects.
Techniques to Uncover Hidden Anchors
Using the right techniques can make it easier to identify the client's budget or value anchor.
Direct Inquiry
Directly ask about the budget in a professional manner. This can clear any ambiguities from the start.Be careful, often clients think revealing this can limit negotiations and that if a budget is revealed this will create its own anchor. Clients will either avoid or be misleading within this approach.
"Can you share your budget limitations for this project so we can tailor our proposal accordingly?"
Figure: Good example - Directly asking for the budget range
Comparative Questions
Ask questions that compare their project with similar past projects.
"How does this project compare in scope and budget to others you've done recently?"
Figure: Good example - Comparing with past projects to gauge budget
Value-Oriented Questions
Focus on what the client values most in the project. This can often reveal their budget priorities.
"What are the most important outcomes you expect from this project?"
Figure: Good example - Asking about expected outcomes to understand budget priorities
Indirect Inquiry Techniques
Directly asking a client for their budget is not always effective. There's a fair bit of gamesmanship in sales, and clients may not always be truthful about their budgets and expectations. In these cases, use indirect inquiry techniques to uncover the hidden anchor.
Estimating Size and Value
Clients are less likely to give deceptive answers about the size and value of the problem being solved.
"Can you describe the impact this project will have on your business if successful?"
Figure: Good example - Asking about the impact of the project to gauge its value
Scenario-Based Questions
Ask scenario-based questions to understand their priorities without directly discussing money.
"If this project could only address one major issue, which one would be the most valuable to solve?"
Figure: Good example - Scenario-based question to identify priorities
Historical Comparisons
Clients can provide insights based on their past experiences without directly revealing their budget.
"Can you tell me about a similar project you've done and the key factors that influenced its success?"
Figure: Good example - Asking about past projects to understand budget and expectations
Intelligent Inquiry Based on Client Size
The approach to uncovering hidden anchors should vary depending on the size of the client.
Large Multinational Companies
For large clients, the problems they face and their budgets are typically substantial. However, direct questions about budget can still be met with resistance or deceptive answers. Focus on understanding the scope and impact of the problem.
"For a company of your size, what scale of solution are you envisioning to solve this issue?"
Figure: Good example - Understanding the scale of the solution for a large company
Small Businesses
Small businesses often have strict budget constraints. Directly asking about their budget might make them self-conscious. Instead, discuss the size of the problem and practical constraints.
"What are the key areas where you need the most help within your current budget constraints?"
Figure: Good example - Addressing budget constraints without direct inquiry
Aligning Expectations
Once the hidden anchor is uncovered, align the project scope and deliverables with the client's budget and expectations.
- Set realistic expectations: Clearly communicate what can be achieved within the budget.
- Adjust the scope if necessary: If the client's budget is lower than required, discuss possible adjustments to the project scope to fit their budget.
- Provide value-based proposals: Offer different options that provide varying levels of value and cost, helping clients choose the best fit for their needs and budget.
Conclusion
Uncovering the hidden anchor with clients ensures that both parties are on the same page regarding budget and expectations, leading to a successful project outcome. By asking the right questions and aligning project goals, you can avoid misunderstandings and deliver value effectively.
There is often a bit of confusion about what constitutes a brief proposal and what constitutes a Specification Review.
Brief proposal - free:
- Information about your company
- A basic overview of what you'll do for them
- The next steps
Specification Review - billed:
- A technical document listing in detail what technologies will be used and how
- Most likely includes initial release plans and ballparks
Read Do you know the outcomes from your initial meeting (Spec Review or Ad Hoc work)?
At the end of a Spec Review, when you've finally finished all your documentation, it can be tempting to chuck it in an email to the client and call it a day... but you need to remember that you're now at the most important part of the process... and this is the key part to make sure you get right!
The findings of the Spec Review (architecture and estimates) should always be presented at a meeting (or a Teams meeting) with the key decision makers of the project for review and acceptance, generally in the form of a PowerPoint presentation, or a Word doc. It is important that all the required people are in a room together to review the findings.
It is important to build a relationship of mutual respect with clients. A natural and simple way of doing this is through exchange of names. You introduce yourself and give them a card and in response they introduce themselves (giving details, including name and position, which you MUST ALWAYS remember).
For meetings with clients, aim for a ratio of 70% to 30% - that is, 70% of the time the customer should be talking. Remember the purpose of the meeting is to meet the client's needs. You can still convey your message to your clients by adding to what they have to say, rather than presenting a prepared speech to them.
It's important to ask probing questions and then listen to the answers.
Client: We had a problem in China...
You: Can you tell more about the problem?
Figure: Good Example - Ask probing question
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:
- Make sure you have completed all requirements
- Thank for the time and tell them the reasons why you enjoyed working on this project
- 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
To: Bob Northwind Cc: [Account Manager] Subject: [Project Name] - Thank you Hi Bob,
Thank you very much for your time for the last xxx weeks. I think you must be the best Product Owner I have worked with at SSW (always available for me when needed). I really enjoyed this project.
I believe I have completed all of your most important requirements. I had good look at the source code and while it's fresh in my mind, I thought I might send you the following suggestions that would make it easier for myself and other developers in future:
Improvement Area 1:
- Do this: because of this
- Do this: because of this
Improvement Area 2:
- Do this: because of this
- Do this: because of this ... ...
Please feel free to contact us if you have any questions.
Regards, <yourExternalSignature>
Figure: Good Example - Nice 'thank you' email with a list of future improvements
Here are the first things you should do EVERY time you come off client work:
-
Get a reference from the last client
- It is a good way to check the client is happy
- If your company is a Microsoft Gold Certified Partner, these references can lead to competencies such as Custom Development Solutions and ISV/Software Solution
- An example of what to say to the client is: "We are a Microsoft Gold Certified Partner and I would like to submit a short description of the project to Microsoft, you will receive an email from Microsoft asking you to approve the reference. How does that sound?"
- Get a testimonial: We would also love a testimonial to add to our website. Would you be happy to give a testimonial for the work we've done for you? Can you please email it to me?
- Get a Google Review: It would be awesome if you could rate us and leave a Google Review
- If there is going to be further work down the line, ask to pencil in a booking for say a month's time or so, so that you don't get too booked out by other clients.
-
The next thing to do is to call your last few clients. You should always be in contact with them at least every 6 months
- Before the call always prepare.
- Refresh your memory about the company, project and contact before calling (have a look at their website; have a look at their competitors etc.)
- Check the upcoming events (Check the calendar on the Home Page to see what's coming up)
- Know the topic of the upcoming user group
- Draft out some suggestions in an email (don't send yet)
- Decide on what value-add opportunities you are going to offer them. Some examples:
- A relevant and useful URL of an article
- Mention something relevant to their project from a User Group presentation you saw
- Maybe you can also invite them to a free Tech Breakfast
- Maybe an upcoming User Group would be useful. It's a good place to have free training, and to build contacts and socialize (lots of IT managers and developers). Email the User Group link
- Ask them about their website. See if any work needs to be done - Mention the need for maintenance
- Call and chat to them about the work you did with them. Ask how everything's going, and if the application was successful
- If yes - great, see what else you can do.
- If not - then find out why (was it a technical issue, or the app not meeting the business needs) and offer to improve it. You can offer them a free consultation with one of our account managers.
- Take some notes on what they liked about the solution.
- Always ask if they know of some other projects we could help them with, or if they know of anybody that may need some software development gurus.
- Send a follow up email
- Send an "as per our conversation". Include some of your notes, a thank you for the time, and CC the Account Manager. If they were interested in a consultation, then ask the Account Manager to follow up
Don't forget to leave the Microsoft Team so that you don't continue getting emails and calendar appointments
-
When you seek advice or help from another, firstly, you need to establish with them:
- Your understanding
- Methods you have previously attempted in order to resolve the problem
Tip: Be aware that you don't want them to reply with LMGTFY 🙂
...or the bing version letmebingthatforyou.com
By not stating what you have previously attempted to resolve the problem, the person you are seeking advice from may be wasting time if they suggest methods you have already done.
How do you {{do this}}?
Figure: Bad example - Not stating what you have previously attempted to resolve the problem
By stating what you have previously attempted to resolve the problem, the person you are seeking advice from will not suggest for you to do the same methods again, and will look for other ways to resolve the issue.
I have searched Google and Stack Overflow but no luck... How do you {{do this}}?
Figure: Good example - Stating what you have previously attempted to resolve the problem
Another rule that closely links to this can be found in Interruptions - Do you investigate your question for 2 minutes before asking someone on IM?
Some tasks are either time-critical or you give a promise to do them promptly. It's very important that these tasks are given a high priority.
If you're not going to be able to deliver a task on-time, you should let the appropriate people know right away.
You could use your Inbox as a priority list by sending yourself emails with an estimate and the priority. Remember to Cc others who should know about the task, so that they could easily know what is going on and give advice/feedback.
It is essential that a company keeps a record of how much time its employees are spending on billable and non-billable work. This helps at invoicing time, and to make sure the clients see exactly where their time and money is being spent. One of the primary responsibilities as a developer is to complete timesheets.
See Rules to better timesheets for more.
A common mistake for developers is to say "See you later, call me sometime next month".
On your last day of consulting with a client, you should always book on the next date. Be aware of the main blockage people get, which the client is saying "How about I check my calendar and get back to you?". And often this never happens.
A better approach is to reduce the risk by:
- Saying that you are only penciling it in and it can be canceled, and
- Bringing some urgency (by saying your calendar fills up quick)
So try something like "My calendar fills up really quick, how about I pencil you in... How about we say 2 weeks' time? Don't forget you can cancel it anytime."
Note: If, at the end of the day, work hasn't been fully tested or is incomplete and you haven't been booked in for the next day, tell the Product Owner (PO) that issues may arise and further work is likely to be required. After the conversation, email the PO and Cc your manager to confirm that further work is required.
E.g. "As per our conversation, this work has not yet been tested and may still include bugs. At this stage, you would prefer if we did not continue to work tomorrow, but I do recommend that we come in and finish soon."
It's often easy to lose track of what you're doing, especially if you have a busy day full of meetings and rushing around, it can often be easy to sign off and not think about tomorrow until you have to. But what if you're not coming in to the office the next day? You might be booked in to work at a client site first thing in the morning.
For this reason, it's a good idea to end each day by having a quick glance at your calendar. If you're especially busy, it can also be a good idea to have a paper printout of your week so you can look at your appointments in the car or on the move.
At times we have to work overtime on a project and the client is not charged for the total hours worked. When this occurs it is important to let the client know. If a client does not know, how can they be grateful? A happy client is achieved in small bite sized steps. Informing the client of overtime that is not charged is just one of those small steps.
On occasion, you may be asked in the morning or even halfway through the day, to pause your work by the client.
Scenario:
- Developer X shows up in the morning and starts working on feature Y as per CRM Service Calendar
- Client calls and says “We’re sorry but we have to pause the development of feature Y because XYZ”
The reaction from Developer X should be:
“OK, I will call my Account Manager and make sure future bookings are cancelled until further notice. For today, is there anything else I can work on so you get the best value out of the rest of my day?”
Note: Same-day cancellations still incur that day's costs. If there is nothing more you can work on, and the client is unhappy, refer the client to your Account Manager.
People are not mind-readers (unless they are telepathic!), so when you get good feedback from a client, make sure you get the recognition for it. There is nothing wrong with getting brownie points for the work you have done and making sure the boss at the client site and your manager know about it.
From: Sophie Belle - SSW Developer To: John Smith - CEO Qwerty Organization Cc: Adam Cogan - SSW Manager Subject: FW: .NET Development Work for Qwerty Organization by SSW Hi John
FYI - see the email below. As you can see, I am loved :)
Regards,
Sophie BelleTo: Sophie Belle - SSW Developer
From: Amanda Panda - Qwerty Organization
Subject: .NET Development Work for Qwerty Organization by SSWSophie
Thanks for the latest release.
It is fantastic! Thank you for all your hard work and commitment to helping implement this solution.
Regards,
Amanda Panda
Qwerty OrganizationFigure: Developers, when you get good feedback from anyone at the client's company, forward their comments onto the boss at the client's company and CC your manager
It’s not good enough just to do good work. You’ve gotta do good work and be visible.
Assuming you are an awesome worker, there are a whole bunch of smaller ways of getting brownie points and they are all around good communication:
- Doing or sending a Daily Scrum
- Sending a "To myself" after taking requirements from a client
- Sending a Done with a screenshot after you have completed the task
- Doing a Done Video
- Preparing and doing a great Sprint Review and sending an email
- Sending an invoice with plenty of comments
- Sharing your knowledge at a user group or presentation
- Recording or live-streaming your user group presentation and uploading it to Youtube
A sentence can be expressed in various ways, and it holds significance to utilize positive language when communicating with clients. Rather than stating "I will NOT do X until you do Y", a more constructive approach would be to say "When you do Y, I will be happy to proceed with X".
We will not be able to develop the report until you are happy with the mockup.
Figure: Bad example - Negative tone
We will develop the report once you are happy with and have signed off the mockup.
Figure: Good example - Positive tone
Having your clients as Instant Messenger contacts can improve your efficiency in project work. You can get a fast solution to road blocks and solve little problems quickly, as well as develop a better relationship!
Of course any important chats should be confirmed via email.
Hey Simon,
I find having my clients available on Skype is extremely useful. Are you on Skype? If so, can I please add you as a contact? I'll add the above email address, let me know if you use a different one.
Cheers Ulysses Maclaren
Figure: It's easy to get your clients on IM, you only have to ask!
Frequently when you are working on an ad-hoc basis or under tight deadlines managers or clients will "shoot from the hip" and ask for tasks without necessarily thinking much about them. Some of these tasks will be critical, some will be less so. It's important you don't waste time on unimportant tasks. There are plenty of important tasks to keep you busy!
If you think the task you have been given is going to take more than 2 hours, stop work, call the client and confirm they'd like you to keep going on that task. Sometimes the client will say keep going; sometimes they will say thanks for checking with them and ask you to work on something else.
If you can, don't wait until two hours is up before checking - check as soon as you realise it is likely to take more than two hours.
Figure: bad example: Don't keep working on a task until it's too late!
Figure: Good example: Calling the customer to tell them that "changing that function hyperlink is going to take more than 2 hours. Actually more like 2 days, do you want me to go ahead?"
If you call a client or team member, and for some reason they do not attend your call, then leave a message to ensure a response.
The advantages of leaving messages when your call is unanswered:
- They will know who called and be able to return your call
- If your message is urgent, they may return your call straight away (even though they're busy)
Your messages must contain:
- Your first name and last name
- Purpose of calling
- Your contact number
Create a sense of urgency by giving them explicit time frames when you are available.
"Hi Ms. Emma, this is Alvin. Please call me back, thanks."
Figure: Bad Example - lacking in communication details, reason for calling and sense of urgency
"Hi Ms. Emma, this is Alvin Shen from SSW. I am calling to follow up our meeting yesterday about your company website. Please return my call on 02 9953 3000. The best time to reach me is between 9 and 11am today, or between 3 and 5pm tomorrow. My number again is 02 9953 3000. Thank you."
Figure: Good Example - This communicates important contact details, a reason for calling and implies a response is needed in the next day or so
You may want to confirm the voice message with an email.
Most people do not like conflict, and so some people may shy away from dealing with a potentially uncomfortable situation, rather than addressing the problem.
When someone brings to your attention that they are not happy with something, it's important to address it so that it doesn't happen again in the future. Keep in mind, this problem is particularly important for time sensitive tasks.
I am shocked I still have miscommunications with my wife almost everyday... something minor seems to pop up, and that's with someone I get along with, understand and have been married to for 20 years.
Many people speak English as a 2nd language. I believe miscommunications are not limited to the English language... it's a human thing... different experiences, intentions, and expectations will end up with different interpretations of words... so it is more uncommon to have 2 people understand each other perfectly on an issue. If a day goes by without a miscommunication, that would be a shock.
Have ❤️ and patience.
Adam Cogan, SSW
Scenario - Missing a deadline
Consider a scenario where your Product Owner is unhappy that you missed a deadline, although you thought there were good reasons for missing it. Don't get bogged down in the justification for why it happened. Instead, acknowledge what happened, and drop everything (within reason) to prioritize this work until it's done.
Do not ignore the problem (by continuing business as usual) as it will only escalate. Fix it now (by prioritizing this work)!
An issue ignored is a 😕
An issue actioned after a reminder is a 👍
An issue ignored after a reminder is a 🚨
Adam Cogan, SSW
Always find out the priority and expectation of a task's deadline. If you've been reminded about a task you thought was of lower priority, that is a good time to have that conversation - better late than never 😊.
Read through Communication - Do you have professional integrity? (Be a person of your word).
Common Symptoms
Unresolved conflict is bad enough with colleagues, and you can be sure if it's happening with colleagues, it's happening with clients too. Some consequences of unresolved problems with clients are:
- Dissatisfaction and loss of trust
- Cancelled bookings
- Unpaid invoices
If you are getting warning signs such as the above, you need to escalate to your manager ASAP!
Tips
- Being chased - If someone has followed you up, get back to them as soon as possible with a response as it shows that you care. If you get a second follow up on the same issue, it's generally way more important
- Communicating progress - If you are not able to fix the problem immediately, let the person know how long the issue will likely take to fix
- Fix bugs first - Bugs become more expensive and complex over time
- Make client complaints a positive experience - Retain customer loyalty
Avoid bad blood
If a conflict was unpleasant, it's often a good idea to offer an olive branch after... by sending a quick message later on to clear the air. Emojis (e.g. 🫒🌿) are a great way to lighten the mood, you could even indicate you're giving them an olive branch.
When to push back
When you're in the heat of the battle, it is often not the right time to push back. When a team member needs to get something done, you should work as a team to get it done.
Bugs or things not working are things people expect actioned quickly. Therefore when not fixed, people follow up such items. If they do, fix them quickly.
You can work to resolve any conflict afterwards.
- One-off tasks - Most of the time, even if you're unhappy with some work you've been given, but it's a one-off task, don't stress the small stuff, and just get it done
- Recurring tasks - However, if it's something you're being asked to do repeatedly, and you're unhappy with it, still do that task right away, but make sure you clearly communicate your concerns later on, when the pressure's off
Note: If after raising the problem, you are still not happy, consider sending a "For the record email"
When you call a client, always try a second time straight away. Sometimes they are not at the phone, sometimes there is a technical issue or some other reason, and you should try to call again to make sure you give the client enough time to pick up your call.
Start the day on a good foot by asking:
- The plan today is XXX?
- What do you want to cover today?
- What do you already know?
- Do you want lectures/Hands on labs/mixture?
When working on an hourly basis, you can confuse clients when sometimes you try to talk about a few hours here and a few hours here or there.
Simply things and just give them these 3 numbers:
|
$ Billed to date __$xx__(accurate on Tuesday) Burndown Days Remaining __8__ Calendar Days Booked __4days x 2__ Next meeting (for Review and Retro) | || |
Hi Andrew,Please find the Burndown report below. I have looked at a few tasks with Zune and re-estimated them.
- Product owner:Andrew
- Scrum master:Paul
- Team:Mark L,Zune,Tristan,Trevor
- $ Billed to date:$20,000
- Days remaining:(around 50 hours based on chart below)=7+days
-
Days booked in are 4 days x 2
- ML and ZV - Mon 5th
- ML and ZV - Tue 6th
- ML and ZV - Mon 12th
- ML and ZV - Tue 13th
-
Only the 14th we will
- Move any remaining tasks to Sprint 4
- Have a Review Meeting (show and tell) at 10am – 2 hours
- Have a Retrospective Meeting at 12 noon – 2 hours
- Have a Planning Meeting at 2pm
Please let us know if you have any questions or concerns.
Clients come to us because of our experience and expertise as software consultants. Many of the problems faced by our clients we have seen, and solved, before. This means that, sometimes, the software consultants know best. But this is a delicate subject. You must be very competent to pull this card from your sleeve. It is easy to not only cause offence but also be plainly wrong. So before you speak make sure you've got the two fundamental aspects of this rule clearly sorted:
- Knowing when you know best (and knowing when you don't)
- Knowing how to persuade the client that your way is the best way (and knowing when you have failed)
Knowing when you know best
The expertise of a software consultant is likely to be in the technology underlying your clients business, not in their business model. If they're willing to pay for external consultants its highly likely their business model has been successful to date and it's wise that you leave that to them.
However, on some issues you should speak out firmly when you think the client is suggesting the wrong course of action. The following areas are most common:
- Using old technology - e.g. .NET Framework instead of the latest .NET version
- Wanting a non-scalable solution - this should speak for itself - the client is likely coming to you because their current solution has max'd out
- Pushing for quick fixes when a better longer term fix is reasonable - e.g. hardcoding connection strings, using Boolean instead of Text when more options might arise down the track, fixing the size of text boxes instead of having them scale with the content.
- Not thinking that UX matters
- Trying to revert to a fixed price model when the agreement is time & materials
Knowing how to persuade the client that your way is the best way
If your client is not technically savvy you should be aware that an argument using technical language is unlikely to be persuasive. Argue your case using language that underscores your understanding of how your suggestion will improve their business, e.g. by future proofing the solution or allowing changes to be more easily implemented down the line.
As soon as you see the clients eyes glaze over, stop, it's likely you're bamboozling with techno-jargon. Rethink your argument and state it again.
If the point is arguable, once a client says no three times, don't push your luck too much. If you do concede don't forget to send an "as per our conversation" email to keep a record of the decision.
Over the course of work on a project, there will likely be many little disagreements, and most can be captured in "as per our conversation" emails. Sometimes the differences of opinion relate to architectural issues or things that will be hard to change later. A lot of developers are on the quiet, introverted side, but vocal developers make their stance clear. Even that can be hard with some clients who have super strong voices and some clients are not great listeners.
Video: Jeff Bezos on how to make decisions | Lex Fridman Podcast Clips (9 min)Too often developers say they disagree but months later, the client may say: "No I don’t recall you disagreed, I thought I gave counter arguments and then I assumed you had agreed with me."
Regardless it is important to document disagreements so the client is crystal clear and a stronger version of ‘as per our conversation’ is to include the words ‘for the record’.
Don't win by attrition
Disagreements should never be resolved merely by who gets tired of arguing first.
Disagree and commit
Enhance productivity by disagreeing and getting on with the job anyway. This is similar to 'for the record' except verbal rather than written.
One war story
"One day we had an incident where one of our clients had found out that a developer had hard-coded the CSS (the default Angular way). When the client discovered it, they were wild and wanted 24 days written off as a consequence. To be clear, the reaction and the request were disproportionate. However, clients have memories that are fallible and they can be entitled to be upset when they come to a company (like SSW) that prides themselves on following best-practices.
I spoke to the developer about it, and he knew 100% that he had agreed with the Product Owner to leave it that way because it was super quick and they had bigger fish to fry at the time. The developer recalled explaining to the Product Owner that he wasn't comfortable taking that shortcut. The step that the developer failed to do was to cover his ass with an "As per our conversation" email... or when the disagreement is related to architectural issues (or issues that will require a lot of rework later) I suggest a more clear "For the record" email.
Note: Even better the developer could have included a URL in the email with a link to a PBI to remove this technical debt later."
Adam Cogan SSW Chief Architect
When you have a disagreement with someone who has decision making power, and you are unable to convince them that your recommendation is correct (and they were unable to convince you that their decision is correct), you should send an email to the people involved including your thoughts, because:
- Later down the track it will provide a learning experience for someone (depending on who was right 😉)
Tip: Use follow up then to remind you to revisit your email (e.g. 6 months in the future), then take the opportunity to follow up on it with a retrospective analysing the decision that was made and what the outcome was (no matter who was right, it shows you were invested enough in the issue to keep track of it)
- After cooling down from the meeting, people might read it later and see it as useful input
Note: A "For the record" email should be reserved for a significant architectural decision, etc. That will be difficult or costly to change later. You should consider it a level above an "As per our conversation" email, which is better suited for more minor decisions.
(...on the day)
"OK, I will just go with the the Product Owner decision."
Figure: Bad example - Just go with the client decision reluctantly
(...on the day)
"Thanks for the chat today. As per our conversation, you'd like us to build this feature using a quick workaround. Just for the record, the best practice would have been to XXX, but since you are the Product Owner, and I understand we're under time pressure, I of course will go with your decision."
Figure: Good example - Documenting that client has asked you to do a shortcut
(...on the day)
"Thanks for the chat today. For the record, you have requested that we proceed with developing the Northwind Project in React, whereas we have recommended using Angular for the following reasons:
- {{ LIST OF REASONS }}
That said, you are the Product Owner and have final say in the matter, so we will proceed with React as per your decision."
Figure: Good example - You have politely pointed out they are making a poor technology choice and given empirical evidence.
Note: It's also a good email to have in your back pocket in case the client complains about slow progress in a few months time.
(...6 months later)
"I knew it, we should never have used React for the Northwind project."
Figure: Bad example - Being improductive and too late
(...6 months later - the curious retrospective)
"I just got reminded about this email from 6 months ago, in the spirit of doing retrospectives to learn, thanks for taking my call about it.
As per our conversation, we are both happy that the React solution has panned out and there has been some benefits that we didn't think of at the time such as hiring a couple of cool React developers. We agreed that we could have saved some money with Angular, but we don't regret the decision."
Figure: Good example – 6 month retrospective to analyse the pros and cons of a past decision.
Tread carefully with a follow up email - use your discretion to avoid souring a relationship by unnecessarily rubbing their face in it. Mention the words "For the record," so that you can find it more easily in the future with a search, but avoid starting with it because it can sound a bit harsh.
Make sure you Cc your account manager and any other relevant parties so that they can keep informed of the situation.
Make it clear that your advice is purely technical in nature and not business or legal advice. Consider putting the words "The above is not legal advice." at the end of your email.
This is also a good thing to do if you have an ethical problem with a task.
Sometimes a potential client contacts you and you are not the right person to deal with them. You need to hand them over to a sales person. There is usually no reason to call them. You can respond via email with:
- A clear instruction for the sales person to follow up
- One action item for the sales person to follow (more than one action item or asking the prospect to complete a task can cause confusion and delay)
If you interrupt someone when they are in the zone, it can take them 15 minutes to get back into the zone.
Instead of interrupting someone directly, you can:
- Send them an email to contact you when free (preferred option)
- Ping them on Microsoft Teams or Skype with the message “See me when you are free”
Check the rule Do you deal with distractions?
Being a good coder is not enough. There are multiple factors that can affect whether a project proceeds in a positive or a negative way. One factor that can have a significant impact on a project is the relationship between the developer and the client. This relationship is especially important if you want to be asked back to do more work.
A good practice is to set aside a little time each week to reconnect with a client, thats called giving 'client love' (aka Customer Love).
While the rule primarily focuses on clients, its principles are universally applicable to any type of contact. Whether they are past colleagues, university friends, suppliers, or other professional contacts, the same approach of showing interest and maintaining connections can be beneficial across all networks.
When reaching out to clients, it's crucial to foster genuine relationships rather than appearing transactional. We believe in building connections that feel natural and not driven by sales motives.
Showing "Client Love"
There are many ways to show "Client Love", the best way is to call them, a conversation (on Teams) or email is also ok, but this is different for every client.
Here are some things a developer can do and/or say:
- Give them a call if you've got a cool idea worth discussing
- Call the client and invite them to User Groups where the topic is related to their project
- Send an IM saying I was just thinking about your project and I think this might be a good idea? {{ IDEA }}
- Send an IM with a link to a web article that would interest them or thats relevant to their project
- Show interest in their industry (this will also help you to understand and fix their business problems) e.g.
I know we spoke about VSA, and as you know I am a fan. What do you think about this infographic? {{ LINK }} - Send them a "happy birthday" message along with something else (e.g. Happy Birthday, how are users finding that new order form?)
For existing clients only
- Buy the client their favorite coffee (remember without asking by writing it in their contact)
-
Talk and listen about non-work related things. Find out topics that they are interested in and why. Here are some examples:
- How was your weekend?
- What are you doing this weekend?
- General talking about their family (remember the names by writing it in their contact)
- General talking about their hobbies
The tasks don't have to cost anything. Free tasks are more thoughtful and show the client you are thinking about them.
Some of these are also relevant to previous clients. Great consultants try to maintain a friendly relationship with previous clients by touching base. This will keep you in the back of the clients mind, and they will think of you next time they need some work done.
Try not to upsell your products or services before you have gained your client's trust. The "Client Love" should focus on improving interpersonal relationship and should be non-work related.
Extra reading: For some, the above comes naturally. For everyone else, read the book How to Win Friends and Influence People written by Dale Carnegie. It is an easy read, the principles are easy to implement and will enhance all the relationships in your life.
Account managers need to make sure their developers are giving "Client Love" to customers and help them get better at it.
Documenting the conversation
Like any valuable conversation, its important you send an as per our conversation email. If you are calling the client its beneficial to draft this first (maybe get it checked by someone else) and use it as a guide for the conversation.
To: {{ CLIENT }} Cc: {{ ACCOUNT MANAGER }} Subject: {{ TOPIC }} Figure: Good example – Conversation is documented and the client is triggered to take action
Tip: Track the email so it appears in reports 📈
Imagine this... a client calls you in a panic when you are working at another client. You need to login to their DevOps portal to see the problem and so you sign out of your current clients DevOps portal ...wait... wait... get a 2-factor SMS... wait... and then finally get in! But then you notice it also knocked you out of the Azure Portal and your Office 365 email that you were previously signed into. Annoying!
Microsoft Edge & Google Chrome Profiles allow you to use different credentials
Tips:
- Never log out
- Never use Incognito (where you need to login)
- Install your cool extensions in each of your Edge or Chrome profiles
- Remove clutter from the new tab experience to increase focus
- Set a different image for your new tab page for each of your browser profiles
Consultants usually work on different client projects and use different client credentials eg. Azure DevOps, Azure Portal and sometimes an email account with the client’s branding. Password managers are great, but going from client to client you have to continually switch between accounts by logging out and logging in with different credentials.
Q: Is this only for developers? A: No, my PA uses this (in her case, her "client" is Adam 😉)
Many people have an Office 365 account, and a personal Office 365 account. If you want to avoid keeping logging in and out to switch between them, try setting up a separate "person profile" for each in Edge or Chrome.
Make use of Edge or Chrome Profiles to separate your bookmarks, history, passwords and other browser settings for different clients and that means that the frequent log out and log in overhead is eliminated. Simply switch to a client specific Edge or Chrome Profile and all the credentials are automatically restored.
Creating a new profile
- Open your Edge or Chrome browser
- Click on you profile button
- Select Manage People to create a new person/profile
- Click Add Person
- Fill in the person/client name and select an icon
Switching profiles
- Open your Edge or Chrome browser
- Click on you profile button
- Select the person/profile you want to switch to
How to add or remove a person profile?
Please have a look at Use Edge or Chrome with multiple profiles.
Firefox Multi-Account Containers
Firefox Multi-Account Containers is an innovative feature that lets you separate your browsing sessions into isolated containers. Each container can be logged into a different account simultaneously.
Tips:
- Separate Sessions: Keep your personal, work, shopping, and other activities separate without logging out.
- Enhanced Privacy: Each container functions independently, restricting tracking across containers.
Setting Up Containers
- Install the Firefox Multi-Account Containers extension.
- Click the Containers icon and choose 'Add Container'.
- Name the container (e.g., Client A, Personal, etc.) and select a color and icon.
- Open tabs in specific containers to maintain separate sessions.
CC the client from the beginning (unless it’s obvious internal communication). This allows the client to see progress towards speaking with the right person and also gives them an opportunity to correct any details we might have got wrong.
Often, when a manager is called in to help out with a conflict situation, they don’t have all the context or details, so backchannels can help to fill the gap.
- Prior backchannels - Have a "corridor conversation" with your manager or teammate before a client meeting. If your manager has no idea about an issue, when they’re put on the spot in a meeting, they then have to interrogate regarding processes followed, etc. It’s better to have them prepared before they go in. One way to do this is by asking good questions – see the video on how to ask good questions below.
- Live backchannels - Assist in real-time with relevant information in an alternative private channel (e.g. SMS or Teams). This can help the conversation flow and help to verify what is being said, and limits the need for phrases such as “William, is that true?”
- Post backchannels – Debrief your manager or teammate how the call or situation was handled, outcomes, where it is at now, next steps, etc.
In general, use Teams for private information, or SMS as a last resort. Treat sensitive information or scenarios with care to ensure a good outcome for all parties.
Using Teams chat to backchannel
When using a private Teams Chat to backchannel a Teams Meeting, it's a good idea to name the chat at prefix with "Backchannel - {{ MEETING NAME }}".
This makes it purpose of the chat obvious and reduces the risk of private messages being mistakenly sent through to the wider audience.
Let everyone know when something feels "off"
Often, you might feel that a decision made by a colleague or manager is not quite right. In such cases, backchanneling can help clarify and resolve these situations. Here’s how you should handle it:
In a meeting of 5 people, which includes the Product Owner, Solution Architect and 3 Software Engineers, the Software Engineers disagree with a decision made during the meeting. They start a backchannel to talk about it, without the Product Owner and Solution Architect involved, and reach a decision to not proceed.
Figure: Bad example - Not all team members are involved in the backchannel
3 Software Engineers disagree with a decision made in a meeting. They open a group chat with the Product Owner and Solution Architect soon after to discuss the decision.
Figure: Good example - All team members, including the Product Owner and Solution Architect, are involved in a group chat and are kept informed
Use "For the record" if disagreement persists
If the Software Engineers still disagree after the group chat, then they should make the matter official by sending a 'For the record' email.
Keep managers informed about important conversations with clients
Client: "I told them we’d need {{ SOLUTION }}" Manager: "Oh that does sound reasonable. Devs, why was that missed?"
Figure: Bad example - Manager looks uninformed and is always on the back foot, and needing to ask questions that everyone else in the call on both sides already knows
Client: "I told them we’d need {{ SOLUTION }}." Dev (on a private channel with Manager): "That’s true, but it only came up after the 1st Sprint was already done." Manager: "My understanding was that was only asked for after the 1st Sprint."
Figure: Good example - Manager is armed with relevant information as needed
Dev: "Heads up, they might be sensitive about this part as they have been very clear with us about it from the start and I missed it. This part was really my fault."
Figure: Good example - Let the manager know what parts are reasonable to push, and what battles are better surrendered
Video - Asking good questions
An important part of communication is to improve the Product Owner's understanding of ROI and help them make good decisions. When you are actioning a task, it's crucial to value your time and think about how much manual time it may consume over a longer period, say a year. You can then go the extra step and quantify this $ cost.
If you find out that another solution would be better, then you should clearly communicate that to the Product Owner.
In the software world to calculate ROI we take a PBI and do Business Value ÷ Effort
If the Product Owner still disagrees with you then it may be a good idea to send a 'For the record' email.
From: Piers To: Bob Northwind Subject: Email signature - not working Figure: Bad Example - ROI was not mentioned
From: Piers To: Bob Northwind Subject: Email signature - not working Hi Bob
Done - I have fixed the email signature by changing the file server's HTML and it took me 1 hour.
ROI Consideration - As per our conversation, I have to make these changes every month for 12 users. Therefore, for future changes to email signatures, let's wait until I implement the new 3rd party solution I am working on. This will give better ROI because I won't need to do any further wasted work.
Thanks!
Piers
Figure: OK Example - ROI is mentioned
From: Piers To: Bob Northwind Subject: Email signature - not working Hi Bob
Done - I have fixed the email signature by changing the file server's HTML and it took me 1 hour.
...but I will have to do it for each of our 12 users once a month.
The choices:
Option A - Continue manually adding each email signature, every month.
- Maintenance: SysAdmin x 12 hours x $200/hr = $2,400 per month
- Total cost = $28,800 per year
Option B (recommended) - Purchase and configure an email signature system.
- Configure: SysAdmin x 16 hours x $200/hr = $3,200 flat fee
- License: 1 License fee x $2,000 = $2,000 flat fee
- Total cost = $5,200 flat fee
Thanks!
Piers
Figure: Good Example - ROI is mentioned and quantified
Note: If fixing the email signatures had been a huge task then it would have been better for Piers to have a conversation with Bob before he implemented the fix.
The impulse to win an argument and prove that you are right can be a strong driving force, but it goes without saying that it should not take priority over keeping a good client.
Video: Do you know it's better to lose the battle but keep the client? (4 min)In the software world, a common point of difference is about the architecture of a proposed solution. The preferred approach is usually to implement an architecture that is "future proofed", so that future changes a client wants are easier to implement. It's the same as a builder saying "I should rough in some plumbing in this area now because it will make it cheaper to install an ensuite in the future." It will always cost a little more to plan for the future, but it will save money, and time, in the long run.
If you're unable to persuade a client to take your preferred approach, it's important to show empathy and demonstrate that you understand your client's point of view...or at are least trying to :)
If the situation escalates and the client is genuinely upset, make sure you start any reply with something like "I understand your frustration". At this point in time, you want to aim for a compromise, where each party meets the other, somewhere in the middle.
The operation was a complete success but the patient died...
Figure: Don't be righteous
How to understand and rationalize dissenting opinions
While not being able to persuade the client can be frustrating, understand there are 3 common reasons why 2 reasonable people don’t agree on a point:
- You haven’t explained your point well enough. e.g. you haven’t given them all the information
- You don’t understand the full context for their decision. e.g. they haven’t given you all the information
- One party is not able to process the extra information e.g. they may be emotionally invested
If it’s something you care a lot about then give the client some space and try again later, making sure you ask questions about their needs in the meantime. If the client feels like you are listening to their concerns sincerely you are more likely to be able to persuade them of your approach. For example, send a 1 week follow up to yourself to have another discussion to try and explain your point again, this time touching different points. During this 2nd conversation, you might be able to get more information from them to understand their point.
If after this, you still can’t agree, then go with what the client wants...if it's really important then send a gently worded email For the Record to document your opinion and make sure it is clear that you didn't agree with them.
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.
Tip: Ensure your client has a clear understanding of the difference before starting development. This will help manage expectations and avoid surprises.