Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

XS✔ ◾ Fixed links /do-you-manage-clients-expectations #7536

Merged
merged 2 commits into from
Dec 13, 2023
Merged

XS✔ ◾ Fixed links /do-you-manage-clients-expectations #7536

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
af9271d
Fixed links /do-you-manage-clients-expectations
tiagov8 Dec 13, 2023
ec7b566
Auto-fix Markdown files
github-actions[bot] Dec 13, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions rules/do-you-manage-clients-expectations/rule.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,13 @@ created: 2009-02-26T03:03:57.000Z
archivedreason: null
guid: 63337ba8-d206-41dc-920d-f89f5ff3b998
---
"Software development can be painful and costly." Hang on, that should say: "Software development **is** painful and costly."

_"Software development can be painful and costly."_ Hang on, that should say: _"Software development **is** painful and costly."_

There's no doubt custom software development is a challenging industry. According to [Critical Success Factors In Software Projects by John S. Reel](https://cmapspublic.ihmc.us/rid=1240967873742_627444575_5503/Critical%20Success%20Factors%20In%20Software%20Projects.pdf):

<!--endintro-->

> Nearly 75% of all development projects missed their target release date or never ship at all.

But what is so interesting is that at least **7 of the 10 most common signs of product development failure** are present **before the design is created or a single line of code is written**.
Expand All @@ -23,40 +26,38 @@ Projects often fail because clients think suppliers under-deliver and over-charg

![](fail-image.png)

<!--endintro-->

### Tip #1: Don't give ranges

Let's say a prospect asks me "How much to do this Release?" I could say "Somewhere between $15k - $20k"... then I hear "20k", the prospect hears "15k". I'm pleased we got it done for "25k" with a whole bunch of changes, the client is annoyed we didn't get it done for "12k". So, never give a range to a client. Tell them something like "The first Release, along with its spec, is likely to take $35k. That's two guys working full time for two weeks."
Let's say a prospect asks me _"How much to do this Release?"_ I could say _"Somewhere between $15k - $20k..."_ then I hear "20k", the prospect hears "15k". I'm pleased we got it done for "25k" with a whole bunch of changes, the client is annoyed we didn't get it done for "12k". So, never give a range to a client. Tell them something like _"The first Release, along with its spec, is likely to take $35k. That's two guys working full time for two weeks"_.

### Tip #2: Be upfront about bugs

There is no such thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See [what is covered in fixed price contracts](http://www.ssw.com.au/ssw/Standards/Forms/ConsultingOrderTermsConditions.aspx) for more information in relation to what is and what is not a bug.
There is no such thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See [what is covered in fixed price contracts](https://www.ssw.com.au/terms-and-conditions) for more information in relation to what is and what is not a bug.

### Tip #3: Don't give fixed prices

A big fixed-price contract can also be dangerous in managing expectations because it removes flexibility. If you deliver exactly what the spec says, the client can quite easily be unhappy, because the hundred and one things they thought of during development weren't included.

If you need to go with fixed prices, we recommend to do it in Releases of no more than 2 weeks (1 - 2 releases), which helps alleviate this problem.

It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. You should generate another release plan for all the extra items once the fixed price contract has been *signed off*. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off **before** starting extra work.
It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. You should generate another release plan for all the extra items once the fixed price contract has been _signed off_. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off **before** starting extra work.

### Tip #4: Talk dollars ASAP

Talking dollars with the client is often something consultants don't like doing after the initial meeting. I've heard of consultants refraining from sending invoices when a project is suffering a few delays, or the client is unhappy with the application state.

If the client is unhappy to receive an invoice now, they will **not** be happy to receive it in two months!
If the client is unhappy to receive an invoice now, they will **not** be happy to receive it in 2 months!

Send invoices for time and material projects every week. This way the client is informed of costs every week, and if a hassle arises, it's trapped straight away.

### Tip #5: Be transparent about rates and resourcing

Defining the hourly rates and resources that will be available to clients ensures they are not surprised later. Additionally, explaining the differences between resources makes it clear why specific resources are grouped together and what kind of services they provide. You should have [clear definitions for all of your roles](https://github.com/SSWConsulting/SSW.Roles) so that clients understand the part their resources play.

## Related Rules

**A.** You've already committed to work for this Sprint, so don't take on more than you can do: <[https://www.ssw.com.au/rules/triaging-do-you-correctly-triage-additional-item-requests>](/triaging-do-you-correctly-triage-additional-item-requests>)
---

**B.** Update the client before you hit the deadline: [https://ssw.com.au/rules/inform-clients-about-estimates-overrun/](https://ssw.com.au/rules/inform-clients-about-estimates-overrun/)
#### Extra

**C.** Never make people chase you for a deliverable: <[https://www.ssw.com.au/rules/professional-integrity>](/professional-integrity>)
* You've already committed to work for this Sprint, so [don't take on more than you can do](/triaging-do-you-correctly-triage-additional-item-requests)
* [Update the client before you hit the deadline](/inform-clients-about-estimates-overrun)
* [Never make people chase you for a deliverable](/professional-integrity)