Rules to Successful Sales and Account Management

You can have the best developers in the world, but if you haven't got a good sales process, no-one will ever use them. It's up to the Sales Manager to get this right.

Once you've got the job, software projects are delicate activities and the client needs love. It's up to the Account Managers to keep everyone on the same page.
Here are SSW's rules for better Sales and Account Management.

Do you agree with them all? Are we missing some? Email us your tips, thoughts or arguments. Let us know what you think.

​
It's often quoted in marketing circles that it costs between 60% and 600% more to
sell to new clients as opposed to existing ones. It makes sense then to nurture
your existing client relationships.

There are two strategies that need to be employed here:

Keep your current clients happy​

Feedback has been received from larger clients in the past that they expect regular
check-ups​ and guidance from senior staff. A nice informal way to arrange this is
to buy your client lunch once a month. You can review the project for half an hour,
then grab a bite to eat. The review should cover the project as a whole, any niggling
problems, and discuss any upcoming projects. You should do this review free of charge.

As a Project Manager, one of the most important things you should focus on to keep
clients happy is communication. For active clients, a week must not pass
without a phone call or some other contact. A lot of the time this will be emails
from the developer. Almost all disputes arise when you don't speak to a client for
a period of time. This allows any annoyances to fester and any misunderstandings
can turn into real problems.

A "client relationship problem" is when you have said "no" to
a client and they let you know that they strongly disagree. In that case:

Tell them the reasons for your stand

Tell them that developers will sometimes do the wrong thing - clients have different
opinions of what that is

Tell them you are authorized to split a problem, offer them the solution and ask if they
are happy with that solution

If they're still not happy you may need to refer them up the chain of authority.

Stay in touch with past clients

Have a system in place that allows you to stay in touch with past clients,
even ones you may not have spoken to in a while: send a useful newsletter
to subscribers so your business keeps fresh in their mind. That way when they suddenly
realise that they need some work done, you're right at the top of the list. Secondly,
have a follow up system in place so that client get a call every 3 months
after a job is completed. Make it friendly, not pushy.
You should use a line like 'I'm just checking in to see if everything is still running
smoothly.' Setting up a system like this will result in more repeat business and
less need to spend money on marketing.

Always be interested in your clients' lives outside of work: find out about their hobbies, sports interests,
kids etc. If you come up with the perfect idea for a present for an important client, get it approved by
your manager and send it off.

​With the amount of money companies spend on marketing these days, it's vital that, when you receive a phone call enquiring about your services, you know how to handle it.

Be prepared for inbound calls. You should have a script that your phone operators keep close at hand to make sure you ask the necessary qua​lifying questio​ns. The aim is to determine if you are a good match with the prospect - that way you don't spend time on dead ends and can give more time to the most likely leads.

Once you have qualified the lead, your aim for the remainder of the call should be to arrange a face-to-face Initial Meeting with the client.

It’s important to have clear options for how a client can engage your services. ​You need to be clear on any differences between them in both billing and project management:

Time & Materials: Work to the client's specification, billing for the number of hours you accrue. The benefit of this type of development is flexibility – the client is able to add, remove and reprioritise development tasks during development.

Prepaid Time & Materials: Time and Materials clients have the option of a prepaid discount – buying blocks of 40 hours per resource in advance entitles them to a $15 per hour discount on the hourly rate of each developer. See the specific terms on our Terms & Conditions.

Fixed Price: Fixed price contracts necessitate having a specification signed off before work commences. This spec can't be altered, so additional items must wait until the fixed price contract is completed. The benefit of this type of development is that your expenditure is fixed. Fixed price projects are charged at a 20% premium to the project cost based on the standard hourly rates.

Recurring: The client commits to a minimum monthly spend in return for a substantial discount on the hourly rates. This work is managed the same as Time and Materials work.​

Unless you're the <1% of companies who competes based purely on price, you will need to be able to explain why your services are more expensive than 1 or more of your competitors.

In the bespoke software space, this is easy, as your clients are not buying something generic, and quality matters. Here's how we do it:

From our research, our rates are in the top 1/3rd of our Australian competitors, and I understand that this can seem high, so let's try to highlight a few reasons why we more than justify these high rates:

Statistically, more than half of all IT projects fail

SSW has been around for over 25 years and has only ever had 2 failed projects

​
Be prepared for the initial meeting because first impressions are the most important.
Preparation cements your professionalism and underscores your ​eye for detail and
capacity to deliver.

Preparing for the meeting includes:

Ensuring the sales staff attending the meeting are familiar with the relevant technologies

Reviewing the clients' website or other available information, taking special note of the nature of the client's business. It's also useful to remember the office locations (e.g. one office, nationwide or international) and the year of commencement of business

Reviewing any specification documents the client may have prov​ided.

Having a wireless card to access the Internet if you cannot connect to the clients network. In fact, it is preferred you do not connect to the clients network due to time and security issues

Having the ​Standard Sales Presentation. Remember, while clients don't want to think this is you first job, they rarely like to listen to how many CommBanks, NRMAs or Pfizers you've done work for. Clients generally prefer the focus of the meeting to be their business. You will however consider any previous projects which bear similarities to the project on offer, you do need to prove our competency

The first meeting is on you. While you have 1 - 2 hours to provide the prospective
client with enough information to decide whether to pursue a Spec Review, the focus
of the initial meeting is the client, their problem, and how you might build
a solution.

The best way to action this is to ask questions, listen and take notes:
Clients appreciate someone genuinely considering their needs. A brainstorming session
is a fantastic way to give and receive feedback immediately. Even if the client
decides not to use you, you should leave them with useful information and a positive
impression.

The purpose of the initial meeting is to:

Listen - Understand the client's motivation for engaging software consultants. Clients 'want a software application built', but understanding the motivation
for getting that software built will assist you in making a successful bid for the
project. Three examples could be: 1. To replace an outdated, hard to maintain existing
system that's core to the business.2. Building new 'nice-to-have' functionality to allow
the client to offer a new service to the market. 3. Assisting a start-up company
with a speculative venture.

Listen - Understand the 'pain level' of the client

Listen - Determine whether scope, time, quality or cost has the highest priority for the
client and what level of project management they require. E.g. if a project must
be delivered by June 30, a high level of management will be required to ensure enough
resources are supplied to achieve this

Listen - Understand as much as you can about the processes/business rules the sy​stem has
to manage. Every level of detail you can correctly comprehend and confirm back builds
your credibility as a good communicator and supplier!

Listen - Assess the overall scope of the project, i.e. is this a ​'small', 'medium' or 'large'
project. The attending Architect should start guessing how many man months this project
might be. This information will help you assess how long the spec review should be.
These initial thoughts should not be shared with the client at this stage as they
are most likely incorrect.

Listen - Determine the client's budget and who controls that budget. E.g. Are you dealing
with the business owner or a line manager in a corporation? Do they have a fixed
amount to spend? Do they have a time period to spend it in?​

Listen - Find out if this is the sort of project you can do and want to do

Listen - Qualify the client to make sure they can afford what they want

Consider technology options

Introduce your team, explain how our involvement
can​ help them, and whether you have a 'good fit'

Explain your rates, including pre-paid

Explain the strengths and challenges of a Time and Mat​erials or Fixed Price approach

Explain our Scrum development method including the importance of a Specification Review

Ask for the sale: "This project is right up our alley and we'd love to be involved,
is there anything stopping you from scheduling a
Specification Review?" This will focus the mind of the client on the next step​

Schedule a Specification Review

For almost all projects, there is a need for additional requirements gathering. Some clients don't have any kind of specification, while the specifications you are given can sometimes be lacking in detail or incomplete. Accordingly, before you can provide an estimated price for completing the project, there is another step which requires an engagement of your resources - the Specification Review.

It is the responsibility of the Account Manager during the initial meeting to present the benefits of a Specification Review for the client. Following the initial meeting, the Account Manager will send a brief proposal in the form of a Post initial meeting email through to the prospective client for a Specification Review.

Note: Make sure everyone who was in the meeting from your company checks the email before it's sent.

It may be necessary to conduct a second initial meeting with a technical specialist attending as well.

You may also find that some clients are unable to progress to a Spec Review until they have a vague ballpark. In these cases, the sales person is to make the decision whether an extra 4 hours will be spent investigating the solution before the ballpark is given. This should then be sent as part of that "Post initial meeting" email mentioned above, with Spec review info swapped out for ballpark estimate info as required.

A sales person has 16 hours per month of developer time they can invest into this pre-sales investigation, so this time has to be used wisely.

Never offer a fixed price at the conclusion of an Initial Meeting, and this engagement model must be chosen before the Specification Review is done.

Ad-Hoc work/Consulting

In the event the work is thought to be less than 3 developer days and the scope is well understood, it may be worthwhile for the developers to commence work straight away without a Specification Review. Normal standards for work should be followed, such as daily scrums. This type of work is called 'ad-hoc' work.

You may also immediately commence ad-hoc work if the client is a technical client and you are providing resources for an existing project under the sole direction of the client.

​
There is always something we can learn from our interactions with clients.
Initial meetings are a great opportunity to learn how we can fine tune our sales skills. Because there are always 2 SSW representatives in initial meetings with clients (usually an account manager and a developer) you should hold a debrief after the meeting on the way back to the office.

Questions that you should ask each other are:

Did I do or say anything wrong?

Was I listening to the client or was I talking too much?

Did I give the client my full attention?

Is there anything I could have done better?

Do you think I connected with the client?

How can we improve our sales process from what we learned in this meeting?

You should be as honest as possible with each other during the debrief but always use the sandwich rule.

Any good ideas or suggested changes should be emailed to the Product Owner.

​Generally speaking, the more time that passes after an initial meeting, the less likely the spec review is to be booked, as momentum falls and the client's enthusiasm for the project wanes.

For this reason, it's a good idea to try and get the spec review booked in straight off the back of the initial meeting, or as close to as possible.

​​

Figure:​ Chance of Spec Review sale decreases over time

​

This will often lead to a cycle of you calling and emailing your client to try to book it in, with the client getting less and less responsive as they gradually lose interest and as other things take up their attention.

The best way to ensure they strike while the iron is hot is to incentivise doing the spec review quickly. You should set a fixed timeframe, say 7 days, by which time they need to have made the booking, and that booking has to be within 30 days. If they adhere to this, they can have the spec review at half rates.

Giving fixed features and a fixed delivery date is very hard. Giving a fixed price is hard too... this is because of the 'Cone of Uncertainty'.

The basic reason is...

Over time, our ability to accurately predict a project's remaining time estimates gets better.​

As a team, our understanding of the amount of work remaining on a project becomes more accurate as the project moves along.

At the project’s initial conception, there is a lot to be learnt and consequently the estimates are likely to be inaccurate by a large margin. Half way through, however, the team has a much better idea of what will and will not be in scope, the technical issues are starting to get ironed out, and the estimates of the work now remaining become far more accurate.

Figure: The further away an event is (task, user story, job), the harder it is to know how big (effort, time) it is

Bad example: Waterfall project.

Estimating everything up front, when you know the least about what you will be doing (potentially 6 months of work).

​​Before you engage in any billable work, the two parties must enter into a binding
written contract. This ensures contractual obligations are clear on both sides,
mitigating the potential for disagreements down the line and protecting both you and the client in the event of a disagreement. Binding contracts can take the form
of Terms and Conditions, Emails and Instant Messenger or even verbal
agreements.

Terms and Conditions

A signed copy of standard Terms and Conditions are mandatory before billable work commences
as they explain the terms on which you work and the rates which will be billed.
Some clients may also have their own set of Terms and Conditions which you should consider signing if agreeable. It is also common for clients to ask you to
sign a Non-Disclosure Agreement (NDA) which you should always consider.

Long term clients should re-sign the Terms and Conditions every couple of years. Signed Terms
and Conditions should be given to the Accounts department for record keeping.

Proposals

At the conclusion of a Specification Review, you should provide a proposal to the client. This will include all of the relevant information
you have discovered during the Specification Review process. The proposal may take
the form of a PowerPoint presentation (preferred) or a Word doc.

However, the proposal is not a contract. It does not supersede the Terms and Conditions. In effect,
the proposal is a sales document which describes broadly the scope of the work to be done and our capacity to complete that work. In an Agile project, it is not a working document from which the project is managed.
The project will generally be managed using Scrum, with a backlog in TFS.

Ad Hoc Emails, Instant Messenger and Verbal Agreements

The most common form of mini-contract is a confirmation email.​Electronic communication such as email and Instant Messenger are extremely useful
in getting decisions confirmed quickly but it is important to follow strict standards
to ensure any agreements are clear to everyone. You should not generally rely upon
verbal agreements, always confirm anything agreed verbally in writing. The following
are important rules to follow:

​Often clients will see a multi-page T&C document with a box at the end that says sign here, and they will think that is the only important page and so sign it and send it back. However this can be a problem when you've got to provide evidence as to the content of the whole document they signed. To fix this issue, you can get them to re-send you through the entire document, but sometimes you don’t want to rock the boat. Here is another solution:

Print out the section of the contract/T&C's the client sent

Print off the balance of the pages from the relevant document (e.g. from the website) - of course it has to be the same document the client sent you a part of

Scan the documents together as one document

Email that entire document to the client

​Dear Client. Because you only sent me the last page I printed the other pages and scanned all the pages as one document for convenience. If there any problems, please let me know​

When a prospective client gets a quote for a huge price it's like giving them a slap in the face.
Break your proposals into a series of releases, where each is 1 or more sprints, and
clients can choose to proceed with a smaller financial commitment (such as just getting the mock-ups
done) than if they were committing to the whole project. Often, small financial commitments will
lead to bigger ones.

This approach also allows you to side-step common delaying tactics of prospective clients by making it easier to get the project moving.

Once you have completed the initial meeting and provided a quote, you have to be careful to keep moving towards your goal of making the sale.

In business, everyone is busy. The prospect you met with has a million things to do, and they may be relying on a decision from someone who also has a million things on their plate. It's easy to get stuck in a 'continuance cycle'. A continuance is basically a stalling tactic.​

A prospect will tell you that they're still interested, bu​t they haven't gotten around to making a decision for one reason or another. An advancement is a step that takes you closer to closing the sale. You should always aim for an advancement rather than a continuance. An advancement might be an agreement to complete mock-ups for the application. Often, small financial commitments will lead to bigger ones.

​​A great example of this practice is having a Specification Review being​ a stepping stone towards the full sale.

So you had a good initial meeting (like a 1st coffee with a new girl), and you have agreed to have a Specification Review (aka first date).​

For the majority of new clients, a Specification Review (also known as a Spec Review) will be your 1st paid engagement with them, and gives the client a smaller first commitment​. This is to work out the requirements and put together a broad time and cost estimate.

It is a simple 4 step process:

​Once you have decided that this is a project you want to work on, you have to convince the client to book in a Spec Review

This is a 1-5 day exercise for 1-2 people. The general rule is 1 man day per expected 2 week sprint.

This process is timeboxed, and so appears to the client as a fixed price.

The number you give to a client says a lot about how much room there is to move. Knowing the difference and when to use them can be a valuable tool in securing projects.

For a
fixed priceproject, exact figures should be used. This makes sure there is no ambiguity between what the client is thinking and what you are thinking.

A round figure gives the impression that it was just plucked out of thin air and you can go lower.

The project will take about 6 months to complete and cost $200,000+GSTBad Example - You've just made that number up, you can go lower​

An exact figure gives the impression that you've done your research and there isn't as much room to move.

The project will take 6 months to complete and cost $204,080+GSTGood Example - Everyone knows exactly what they're in for

For avariable priceproject, round figures should be used. This gives room for the project scope to be varied with additional items and lends itself more to an agile approach.

The project will take ​6 months to complete and cost $204,080+GSTBad Example - This makes it very hard to vary the project as the client will always have this figure in mind

A round figure gives the impression that this is a ball park estimate and that the price will likely change. The project will take about 6 months to complete and cost approximately $200,000+GSTGood Example - Give the client an indication of how much it will approximately cost without committing to the figure

Left to their own devices, most developers will slowly make more and more unmaintainable code, that is only comprehendable by themselves.
This isn't a big problem for them as they are in it every day and know how it all fits together, but if they're not coding to a set of industry
standards, you'll find this code very hard for anyone else to maintain.

Figure: Bad Example - Would you want to maintain this code?

This can be fixed by having regular software audits with a Solution Architect to keep the developers accountable.

Each month, the Account Managers call all their current clients that have had a substantial amount of work done and offer
them a Software Review.

This makes more maintainable software with better architecture using industry standards.

More information: The process:

In the pre-sales, you should have already explained the concept of Software Reviews.

Look at a report to show your main current clients (best seen by who was invoiced in the past month)

Tip: This is also a good thing to have up on the wall as a reminder of who your main customers are at the moment.

Figure: A sample report to see your top clients

Choose your top clients based on who's had a substantial amount of work done (e.g. Say 10k in the last month)

Call them. Ask them how their project is going and if they have any concerns or anything they’d like changed

Offer them a Software Review with one of your top consultants.
This will ensure that best practices are being followed for all your major projects and help to ensure the quality of
the solutions developed

​When attempting to sell a solution to a potential client, you will invariably come
up against some objections. It is essential that you are prepared to handle these
objections so the client is confident in your skills and has no reservations about
choosing you over someone else. The main reason clients raise objections is because
they have concerns about your experience "fit" with their needs.

Probe - ask, "Can I ask you a few questions about the concerns that you have?""If I could resolve this issue for you, could we move forward?"You can't always solve objections on the spot - it's ok to say, "Is it alright if I speak to one of my developers about it and let you know about that later today?"

Answer - Pick the best response to their objection (see below)

Confirm that they are happy with your answer - "Do you now feel comfortable with
our approach towards your project?"

A typical objection we get is - "Why do you
put 2 developers on the project? This is going to be more expensive isn't it?".
This is basically how we handle this question:

Explain the benefits:

"We can complete the project sooner. Is that important to you?"

"You get more expertise - One guy is more focussed on UI, the other guy is stronger
with databases"

"You get better quality code because the guys are able to "put their heads together"
to solve a problem - this saves maintenance costs down the track"

"We can continue working if 1 guy gets sick"

If they are still unsure, you can offer a small discount off the hourly rate, or
offer some free support - it's all about managing risk.​

​You shouldn't charge a client for using your own product as part of the toolkit you take (e.g. we use Upsizing PRO when doing an upsizing job). This is because it's just like a plumber using his wrench. You take it away with you when you leave.

However, you should charge clients when you install or provide one of your products for the ongoing use of the client e.g. Code Auditor, Link Auditor, etc. which the client's staff will use after you leave. This is just like a plumber buying a particular piece of pipe to fix a sink.

Generally, you should avoid discounting product prices to clients since this would devalue the product.

An important source of comfort for any client is a feeling that they are in control and they know
the basics of what is going on. The fundamental part of this is who is working for them and how
much it is costing.

Therefore, if you change the developers on a project or if one or more of their rates change, it is
very important to inform the client, before sending them the next invoice, where they will find out
and could think that you're being shifty.

We have standard templates for these situations in our intranet shared documents​. You can see an example here:

Hi Marlon,

As per our conversation, I wanted to let you know that Eric was promoted to Solution Architect earlier this year. We held back his rate change until the end of this phase of the project, but we will be implementing his new rate as of 9/1/2019.

His new standard rate is $285/hour+GST. Don't forget SSW offers a competitive rate to those clients pre-paying time in blocks of 40 hours per Project Tea​m Member.

I trust you've been happy with Eric's contribution to your project so far. We look forward to working with you soon.

Let me know if you have any questions; always happy to talk.

Regards,
Ulysses Maclaren​
www.ssw.com.au

Figure: Good example of an email informing the client about a rate change

​It's important for Account Managers to stay involved with client projects past the
sales stage and into the implementation stage. The best way to do this is to call
them once every 2 months or so once the project gets going, just to guage their
overall satisfaction and happiness.

The best way is to set yourself reminders to do this ​using FollowUpT​hen.

Sometimes the prospect is not ready at the end of the initial meeting to engage you for a spec review or ad-hoc work. Even if this is the case, it's really important you leave the meeting with a crystal clear future about the next stage and when that will be. Every prospect needs an intelligently scheduled follow-up activity.

So, at the end, ask the prospect:

"When would be a good time to meet next?"
Next Friday
"Cool, speak then"

Figure: Bad example: The client really won't remember this

"When would be a good time to meet next?"
Next Friday
"Do you have your calendar?"
Sure, hold on
"What time suits best?"
Let's say 3pm
"Cool, Do you want to send the appointment or should I?"

Figure: Good example: Asking them lots of questions and setting a specific time and date for the next meeting (or phone call)

This will ensure that the follow up meeting or phone call gets a much better chance of
happening... Basically the prospect sets this up and will feel a certain indirect obligation.

Small increments of work add a lot of administrative overhead to work, drastically reducing company profit from client work. As a general rule, make sure any billable client appointment has a 1 day minimum and should preferably be in day long increments.

Running training courses can be a great way to make sure your site always has new content and show that your company is active publicly. As well as being good for branding, it can also be a great source of lead generation for consulting work.

In order to capitalise on this, you should have a developer in any training course who is there to help out and get to know the attendees, whose job it will be to meet up with some of the attendees a couple of weeks after the course to catch up for a coffee and a chat. This could be the speaker or another personable developer if required. It’s important that this is not just a sales person, as it needs to be someone who can give further advice on the training topic at a later date if needed.

The last question is key as it could lead to substantially more work, but you should make sure the person you’re meeting with gets some good value out of the meeting itself, so this does not just seem like a sales exercise.

It's also a good idea to mention that this will happen at the end of the course so that the call doesn't come out of the blue. The speaker could say something like:

"Thanks for attending today. You can email either of us after this.
Also in the next few weeks 5 of you will be picked at random for a 'Retro Coffee'
It is about 20 mins. Bring your problems. We will chat about the course and what you still need to know."

While all staff pass strict recruitment procedures including technical and communication assessments, all staff
have different skill sets. For example, some have a broader level of knowledge and some are more proficient at project
management.

When determining which staff are appropriate for which projects you need to analyse​ the needs of the project.
Some may not require management skills, (for example if we are providing resources to another technical
organization), while some projects may require only a narrow field of knowledge, (e.g. creating Xamarin forms​).

For any major project, a broad spectrum of individuals may be required which will utilize each level of staff.

Working onsite has a number of benefits such as increased communication with the client and increased perception of value. However, if a developer is onsite for an extended period, they can start to feel disconnected from your company and their co-workers​.

​

​The solution is to bring them back to the office 1-2 days a week to reconnect with everyone and still feel like they're part of a larger organization.

This should be organized​ up front with the client when making the booking.​

Every now and then, a client will purchase training or event passes and be unable to attend. In this scenario, 2 things should occur in order:

They should be offered an alternative. This is important as if they needed the training, they may well appreciate being given the option. This requires a conversation with the client and the alternative options are:

A different date that the same course is being run.

A different course that interests them.

An equivalent dollar value of developer time to come onsite.

If they decline and ask for a refund instead, then this should be processed immediately. This is absolutely vital as delaying giving a client their money back rapidly decreases their opinion of the integrity of your company.

As an example, this means that the Accountant can always issue a refund for an event immediately, without any further approval needed from the boss, so long as at least 1 alternative has been verbally offered to the client (normally by the Account Manager)

Once a customised training engagement has been completed, it is important you follow up with your client for the following reasons:

Get feedback on how the trainer went

See if the client has any other consulting or training requirements

A few days after the training occurred, call the client and ask the following questions:

Are you happy with the training provided?

What did the trainer do well?

What could the trainer improve?

Did you learn what you expected to learn?

Would you recommend SSW?

Do you need help with anything else?

After you complete the interview send an “as per our conversation email” to the client and CC the trainer. The email should include the answers to the questions above and any recommendations for the trainer.​

When you sell a training engagement you should invoice the client as soon as the training is confirmed by email, as training is always fixed price and the cost will not vary like a time and materials engagement.

​​Sending an invoice before the training begins acts as a confirmation of the training and allows the invoice to be paid a little earlier than usual.

​Sometimes, a client will tell you that they’ve already thought of the easy solution, but that they want you to investigate the more expensive (but more optimal) option, so that they know much more it would be and can decide which option to go with. They may have already had the cheaper option scoped out by another company.

The trap here would be to the only scope out the expensive option, as it means there’s at least a 50/50 chance they won’t go with you. Instead, you should scope out and price up both options, so that if the client prefers your approach, but thinks your expensive option is not feasible, they can still use you for the cheaper option.

Here's how much the full rewrite of your solution would be: XXX

Figure: Bad example – no option to use your company if they don’t want a rewrite

The price to refactor your existing code base would be: XXXThe price to do a complete rewrite would be: YYY

Figure: Good Example – whatever option they choose, they can still use your company​

Ideally, all projects should be managed using Scrum, with sprint planning, reviews, and retros, daily scrums, sprint backlogs etc., but some client engagements are too short to justify this.

In these cases, as a minimum, there should be a backlog and a Kanban board, and the developer should still be doing daily Scrums with the client.

In order to ensure this, you should schedule a "Mini-Review" once a week for any client jobs that are too short or ad-hoc for a full scrum process. The client and the developer need to be in this meeting, and sometimes it might make sense to have it at the usual daily scrum time.

In this meeting, you should check the following:

Look at the board

Look at the backlog (if just using Kanban this might be the same as the board)

Ask what has been done since the last Mini-Review (or the start of the project)

Ask what will be worked on next

See if the current booking remaining is sufficient... i.e. book in more time as needed​

It’s important that your salespeople work together to help each other through blockages, and also that they keep each other accountable so that no one drops the ball for an extended period.

You should organize a weekly meeting for all Account Managers. The focus should shift each week between 2 topics:

Opportunities

Look at all current opportunities and make sure there is a plan for a continuance. Agree to close off any that are no longer viable

Current Projects​

Look at the way your current resources are being used and make any adjustments necessary. In the case of a consulting company, identify if all bookings are up to date, and potentially if under-used resources need retraining or re-allocation

Schedule a Specification Review

For almost all projects, there is a need for additional requirements gathering. Some clients don't have any kind of specification, while the specifications you are given can sometimes be lacking in detail or incomplete. Accordingly, before you can provide an estimated price for completing the project, there is another step which requires an engagement of your resources - the Specification Revi​ew.

It is the responsibility of the Account Manager during the initial meeting to present the benefits of a Specification Review for the client. Following the initial meeting, the Account Manager will send a brief proposal in the form of a Post initial meeting email through to the prospective client for a Specification Review.

Note: Make sure everyone who was in the meeting from your company checks the email before it's sent.

It may be necessary to conduct a second initial meeting with a technical specialist attending as well.

You may also find that some clients are unable to progress to a Spec Review until they have a vague ballpark. In these cases, the sales person is to make the decision whether an extra 4 hours will be spent investigating the solution before the ballpark is given. This should then be sent as part of that "Post initial meeting" email mentioned above, with Spec review info swapped out for ballpark estimate info as required.

A sales person has 16 hours per month of developer time they can invest into this pre-sales investigation, so this time has to be used wisely.

Never offer a fixed price at the conclusion of an Initial Meeting, and this engagement model must be chosen before the Specification Review is done.

Ad-Hoc work/Consulting

In the event the work is thought to be less than 3 developer days and the scope is well understood, it may be worthwhile for the developers to commence work straight away without a Specification Review. Normal standards for work should be followed, such as daily scrums. This type of work is called 'ad-hoc' work.

You may also immediately commence ad-hoc work if the client is a technical client and you are providing resources for an existing project under the sole direction of the client.

Help and improve these rules

Nothing great is easy. The SSW rules are a great resource for developers all around the world.
However it’s hard to keep rules current and correct. If you spot a rule that is out of date, please email or if you are cool tweet me.