
Why Doing Things Half Right Gives You the Best Results  - peter123
http://blogs.harvardbusiness.org/cs/2009/02/for_fullscale_returns_do_thing.html
======
mixmax
I've done a bit of management consulting and found that a good formula for
making a system that works is this:

1) Talk to management about what their goals are, and what kind of resources
they have to get there.

2) Talk to the people that will actually use this system, and make sure that
they all get to comment and put ideas into it - even if they are minor. These
are the people that will be using whatever system is being built, so they know
where it hurts.

3) Come up with a rudimentary plan of the system. I normally build a a simple
mock-up in HTML so that it will be understandable to everyone.

4) Talk to the people that will be using the system again, and show them what
you have come up with. Inevitably they will offer changes, because you didn't
understand them right the first time or because they didn't explicitly know
what they wanted, only the problem they have. Keep doing this for a few
iterations changing your HTML as you go. Make sure to get buy-in from
management along the way.

5) Use the HTML as a template for your spec.

6) Implement and test.

7) Deploy. This step is the easiest of them all, since all the employees (or
at least a good part of them) have eagerly been awaiting the fantastic new
system that will take away their itches with the old system. They know because
they all helped design it. And since they all helped design it they are all
eager to make it work.

I'm constantly amazed at how it seems that corporate systems are all designed
and agreed upon by management and consultants without asking the users first.
The author of the article seems to have fallen into this trap, and only just
discovered this simple insight.

------
swombat
"Doing things half right" is just one of the techniques to elicit
participation. I've used it before successfully - it definitely works.

However, jumping from that to saying that you should aim to do things half
right as a global objective is a little bit stupid. Or even very stupid.

Sounds like this guy needs more exposure to agile development practices. Hell,
forget about those - sounds like he needs more exposure to basic, good
requirements gathering practices. Who the hell designs something that's
"perfect for me" when 2000 other people need to use it?

A lot of fluff for not much in this article. Quite disappointed, usually HBR
articles are a bit more intelligent.

~~~
jcl
It sounds like the programming equivalent would be: _Release early and often._

------
dschoon
I think the article is brilliant for exactly one sentence, which in my
experience comes up all the time in organizations filled with smart people:

3\. The more perfect I think it is, the less willing I'll be to let anyone
change it.

I've seen so many pointlessly elegant projects cast aside for exactly this
reason. No collaboration is possible on art: your beautiful unique snowflake
is your own.

Sure, maybe the rest of the thing was a bit fluffy, but if every article had
even one hidden gem, writing on the internet would still be doing far better.
:)

~~~
10ren
I think it's also an instance of reducing rigidity by letting go of what you
are most attached to, as in "5. CUT WHAT YOU LOVE" from Joss Whedon on screen
writing: [http://dannystack.blogspot.com/2009/01/joss-whedons-
top-10-w...](http://dannystack.blogspot.com/2009/01/joss-whedons-
top-10-writing-tips.html)

There's also a similarity with "kill your darlings", in creative writing:
<http://everything2.com/index.pl?node_id=1282093>

_"Read over your compositions, and wherever you meet with a passage which you
think is particularly fine, strike it out."_

------
CalmQuiet
The title is clever, yes. The real insights of the post amount to appreciating
how important it is to elicit _participation_ from the end users. ...which is
the essence of the Web 2.0 world: that the community's wisdom is greater than
any expert's. Bergman also also provides some useful examples of _how_ to
respond to complaints or "issues" so as to maximize users' readiness to offer
feedback. Nice article!

------
zby
In a way this is very similar to the 'Start with NO'
[http://www.amazon.com/Start-NO-Negotiating-Tools-
that/dp/060...](http://www.amazon.com/Start-NO-Negotiating-Tools-
that/dp/0609608002) negotiating technique. The idea is that when people say no
they will feel obliged to give you the reasons why and then you can adjust
your proposal, if they answer 'maybe' then you'll not get any information from
them.

------
TrevorJ
Maybe it is semantics, but I think it is very possible to complete a
project/product/job to the very best of your own ability and STILL invite
outside involvement and allow others to make suggestions and add value to the
endeavor.

The underlying problem isn't only with the users of a system needing to buy in
though, the real problem is that if you don't half-ass something it's a lot
harder to be humble enough to take the criticism and suggestions of your
users. If anything I think the article highlights the character flaw many of
us have when we've built something we are proud of. I am willing to bet that
he could have rolled out the first "perfect" system in a way that invited the
very same user-directed suggestions and gotten great results. Doing so just
takes humility, a great work ethic and a lot more intestinal fortitude.

------
zurla
if an MBA speaks nonsense and there's no one there to hear it, is it still as
useless?

~~~
amirnathoo
I'd be interested in hearing what made you consider this article nonsense.

I've found when communicating with people, that the precise wording you use is
a really important factor in the response you get - kind of like programming
actually! Which is why I found the suggestion of particular phrases to try out
interesting: "Why won't this work for you?" "That's a good point. So how can
you change it to make it work?"

~~~
bpyne
"I'd be interested in hearing what made you consider this article nonsense."
And what would you do to change it?

(I couldn't resist.)

The article was a reminder that team building is the underlying success of
projects. Bringing people together and getting them to have a stake in the
project is at least 60% of the success of a project. (The 60% is derived from
a study written up in either CACM or IEEE's Computer that successful projects
had the common characteristic of weighting people at 60, process at 20, and
technology at 20. If anyone remembers which periodical and when it was
published I'd love to reread it.)

