oh no not again with the done-done vs. demoable?

[Raoul Duke]

hi,

how have you managed the situation where the client apparently wants
everything done yesterday and on a fixed bid contract and oh can you
demo it along the way to assuage our fears and we have an alpha test
coming up so how about we just get it looking not entirely like crap
from the outside even if underlying it is not great

vs.

really following a done-done iterative approach?

nothing new, an age-old question, an age-old issue. :-)

[Ted M. Young [@jitterted]]

I find "just say no", works well.

;ted

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

[Raoul Duke]

On Tue, Feb 7, 2012 at 11:12 AM, Ted M. Young [@jitterted]
<tedy...@gmail.com> wrote:
> I find "just say no", works well.

yeah, except for those times when it doesn't.

[Michelle Smith]

It all comes down to setting expectations ahead of time. If you get to the
point where the client is demanding these things mid project, your mistake
was much earlier in the project.

All is not lost - there is still time to educate the client. That means
TALKING to the client, and doing so OFTEN. If you are building functional
software with frequent releases, that helps to engage them and to make them
feel like they are aware of what is being built. But you should also make
sure that your process is transparent, and that they are helping to drive
the direction of the project between releases.

They typically want the demos because they aren't confident in what you are
building or in the progress that you are making. Most often, these are
clients who are not technical, so they already feel uncertain about what you
are doing. More often than not, they've also been burned by a project that
went very badly in the past, despite assurances from the dev team that "all
is fine."

It's a frustration, but it can be overcome, and often the most challenging
clients become your biggest cheerleaders, if you handle the relationship
correctly.

Good luck.

Michelle

Dr. Michelle Smith
Managing Director
NimblePros LLC
msm...@nimblepros.com

--

[Steve Tooke]

Hi,

The question for me is how do you break down these asks. How do you slice things up so that the team can succeed?

On 7 Feb 2012, at 18:49, Raoul Duke <rao...@gmail.com> wrote:
> everything done yesterday and on a fixed bid contract

This one isn't going to work ;-). Can you discuss fixed price == fixed deadline. Sounds like there are some hard deadline in already. Can you base ongoing work on the success of getting the alpha out?

> can you demo it along the way to assuage our fears

I'm imagining this isn't the problem!

> we have an alpha test coming up so how about we just get it looking not entirely like crap
> from the outside even if underlying it is not great

So here you can get interesting. The alpha test sounds like a first upcoming hard deadline.

Build up the backlog that's needed for the alpha test, and negotiate scope based on what the client is looking to get out of the alpha test. Are they wanting to test the UI decisions? Can you build some of the features purely as prototype, with no real function? Or can you cut features elsewhere so that you can complete a smaller featured but well polished alpha?

> really following a done-done iterative approach?

The great thing about done-done is it never really is until it is - and what it is right now can be negotiated based on what's more important.

Steve

--
Sent from a device with a terrible keyboard

[Raoul Duke]

On Tue, Feb 7, 2012 at 12:12 PM, Steve Tooke <steve...@gmail.com> wrote:
> The great thing about done-done is it never really is until it is - and what it is right now can be negotiated based on what's more important.

ah, that's an interesting line of thought -- how do people manage the
asymptotic approach to done-done-ness? i think some folks are more
stressed out the further away from done-done things are, whereas other
people are like "eh put it in the bug base, and honestly prioritize
it, and then we'll just defer it out of existence." (although i think
the latter can get harder when you are in a contractor-client
situation vs. a totally in-house thing.)

sincerely.

[kelly french]

See page 141 of Tom DeMarco & Timothy Lister's "Waltzing with Bears" about risk management.

 

You'll find there a story that gives the best answer I've ever heard to those who keep shouting that the delivery date is to far away.

 

I've included the story below for your amusement and instruction.

---

 

    Eary in 1996, one of my clients was the manager of a large embedded-system software project. Her job was to produce the control software for a new line of products that marketing was extremely eager to launch.  The major stakeholder was a marketing manager named Hans, who had proposed the project and gotten it funded.  Hans was angry when my client's team came up with a 4Q97 schedule.  He had been hoping for March 31, 1997.  He denounced her estimate at a public meeting as not aggressive enough, and he follwed up (unfortunately for him) with the statement: "I can prove to you that beyond March, every month that this product is not ready to ship will cost this company one-hundred-thousand dollars in lost profit."

    I queried him on his assertion.  "Hans, would that same figure apply to delivery before March thirty-first, as well? If we delivered by the end of February, for example, whould that give us an additional hundred-ten-thousand dollars of profit, beyoind the revenue stream that you have projected?"

    "Yes," he said. "Definitely."

    "If we could put the product in your hands today"--that was February 1996, when the project had just been funded--"would you be collecting that additional hundred-ten-thousand dollars per month for the rest of the year?"

    "Yes," he said, a bit less sure of himself now.

    "Well then, Hans, you obviously started this project much too late.  If you'd kicked it off eighteen months ago, we could be shipping now, and all those months of hundred-ten-thousand-dollars' extra profit . . ." I let him figure out the implications.

 

---

[Raoul Duke]

On Tue, Feb 7, 2012 at 12:27 PM, kelly french <kelly....@gmail.com> wrote:
> You'll find there a story that gives the best answer I've ever heard to
> those who keep shouting that the delivery date is to far away.

i see this subject matter as having (at least) two different gross levels:

(1) the level of "do the players grok reality, or are they really --
even if they profess to grok reality -- just going to be pushing to
hit deadlines deadlines deadlines"?

which leads to

(2) given players who are saying "just get it done", who has
successfully used nueuro linguisting programming, or nuanced
negotiation, or whatever else, to bring things around to a more sane
world?

breaking 2 down, there are (at least) two sides to it:

(A) the outside: the client's attitude.
(B) the inside: the builder's attitude -- are all their own ducks in a
row internally? are they willing to say no ever? are they capable of
understanding padding and that people get sick and that the bus number
is too low? etc.

so there's probably plenty of blame to go 'round.

of course, if *I* were running the world (B) wouldn't happen :-) :-) :-)

[Joel Helbling]

There's a fine argument to be made that fixed bid contracts are not
suitable for software projects. Unknowns abound at the outset of a
project, and, in many cases, the context/domain which the software
will address changes as the projects proceeds. We simply can't figure
out all these things to begin with. Anybody who says otherwise is
lying.

The question is, can you convert an upfront-fixed-bid oriented client
to one who is comfortable buying software an iteration at a time?
Maybe some clients would never go for this. But I believe most will,
if you can successfully explain why it is in their interests to do so.

Explain that the upfront promise is, nearly 100% of the time, either
1) an underestimation catastrophe which leads to unhappy everybody and
deadline overruns, or 2) gross overcharging in the form of a
overstuffed guess. Neither of those scenarios is desirable for the
client.

On the other hand, buying by the iteration puts the client back in
control. When will the project be over? It'll be over when the
client says it's over. At the end of each iteration, let the client
1) see what you've done and 2) take delivery of the code written so
far. If the client is happy with what's done so far, and still has
money, then the work continues.

I use the term "iteration" as a purposefully vague block of time which
should match what you're comfortable with. As a small outfit with
multiple concurrent projects, I have sold two week iterations
consisting of not less than 20 hours. However you structure it, make
sure the client is clear what "iteration" means.

The key is to make the right value proposition. All software projects
have risk. But instead of the huge risk of a shaky six-month promise,
offer a much smaller bit of risk: a single iteration, with the
opportunity to course correct or even terminate at the end.

[Andreas Leidig]

Hi,

this discussion here is interesting, because all of you focus on the content of the contract. However the major point to me is WHY do they want contracts like that? - I believe they want to delegate responsibility (especially in case of failure). Try to bring this point into the discussion. Maybe you can explain that this simply isn't possible. At least not if they do want working software. If they are only focussed on the money involved - and the risk of losing it - then the approach is reasonable.

A client who wants software working at a fixed date cannot delegate the responsibility to get that done. It's the client's project. And there usually are many more stakeholders involved than just the software contractor. If they are really in a hurry they also should try to start a.s.a.p. instead of working on contracts.

Cheers,
Andreas

[Matteo Vaccari]

Hi Raoul,

the "iterative done-done" can only work if the customer is available to really test and validate the features one by one.  If this is not the case, then your features can never be done-done-done.  They will have to change when the customer finally sees the product and finds that it is not exactly like they want it.  In this case you should have some strategy to minimize the damage.  

Like, for instance, spend the first half of the schedule to deliver a prototype and set aside the other half to rework it.

Matteo

[Raoul Duke]

On Tue, Feb 7, 2012 at 10:32 PM, Joel Helbling <joel.h...@gmail.com> wrote:
> The question is, can you convert an upfront-fixed-bid oriented client
> to one who is comfortable buying software an iteration at a time?
> Maybe some clients would never go for this.  But I believe most will,
> if you can successfully explain why it is in their interests to do so.

another way of looking at this is:

how much self-respect do you (the contractor) have? how much are you
willing to put your money where your mouth is? or are you really doing
to just bend over when the time comes, because <insert list of
rationalizations here>?

of course, i do not run the show, and so i'm stuck with whatever the
powers that be decide, and they did decide that a fixed bid would be
ok. i do not know how much they consciously made an evaluation. i
don't know how much fixed vs. iterative weighs into any evaluation
they didn't make.

as another person said before in this thread, you have to be able to
say no. i suspect, since i haven't asked about it, and haven't heard
otherwise, that the powers that be didn't consider saying no wrt fixed
bid.

now the standard rejoiner is that, sure, it would be nice to be able
to say no, but on the other hand we have to actually have money coming
in. if "no" had been said in this case, what would have happened?
would we have been worse off over-all?

unfortunately, i think that particular "what if" becomes very
subjective. you cannot predict the future. so really one should
instead be standing on principle, on values, and do one's best from
there, and hope that things come together nevertheless.

(easy for me to say, since i'm just an employee, who probably could
find another job w/in a few months if need be.)

sincerely.

[J. B. Rainsberger]

On Wed, Feb 8, 2012 at 22:38, Raoul Duke <rao...@gmail.com> wrote:

> (easy for me to say, since i'm just an employee, who probably could
> find another job w/in a few months if need be.)

For me, this observation provides all the leverage necessary in these
kinds of situations.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
Find out what others have to say about me at http://nta.gs/jbrains

[Raoul Duke]

On Mon, Feb 27, 2012 at 4:16 AM, J. B. Rainsberger <m...@jbrains.ca> wrote:
> On Wed, Feb 8, 2012 at 22:38, Raoul Duke <rao...@gmail.com> wrote:
>> (easy for me to say, since i'm just an employee, who probably could
>> find another job w/in a few months if need be.)
> For me, this observation provides all the leverage necessary in these
> kinds of situations.

except that the other job might have similar problems. at least most
of my jobs have to date. :-( so i suck at picking finding getting
hired at the right places i guess :-} but the other point i was not
clearly making but had in my head is that: when you are running the
company, you have to really worry about the bottom line, it isn't just
an academic thing, and so i can have empathy and see how if i were in
the position to call the shots, i might also not want to do things
which feel like they could jeopardize an already working cash flowing
in situation.

sincerely.

[J. B. Rainsberger]

On Mon, Feb 27, 2012 at 21:29, Raoul Duke <rao...@gmail.com> wrote:

> except that the other job might have similar problems. at least most
> of my jobs have to date. :-( so i suck at picking finding getting
> hired at the right places i guess :-} but the other point i was not
> clearly making but had in my head is that: when you are running the
> company, you have to really worry about the bottom line, it isn't just
> an academic thing, and so i can have empathy and see how if i were in
> the position to call the shots, i might also not want to do things
> which feel like they could jeopardize an already working cash flowing
> in situation.

The others jobs will probably have similar problems. They might have
different problems. I think of it this way: I have to decide how long
I can handle /these/ problems, when I've had enough of them, and when
I'm ready for new problems.

I don't believe that there are enough "right places", so I don't look
for them. I hope for them, but I don't look for them.

I really respect your closing thought: I used to think that everyone
was crazy, but now after having run a few very small businesses, I
know that there are bigger and stranger tradeoffs than what IBM
exposed to me as a second-year staff programmer. This makes me
empathise much more with the odd decisions that I see some people
make. It might not excuse those decisions, but I understand them
better.

Even so, I always feel better when I feel free to leave. This helps me
work better. I imagine it creates better results, too, although I've
never tried to measure that.