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.
"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.
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. :)
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!
In a way this is very similar to the 'Start with NO' http://www.amazon.com/Start-NO-Negotiating-Tools-that/dp/060... 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.
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.
As far as HBS articles go, I thought this one was pretty good.
If you've ever tried to push a new idea onto a group of disinterested people, you'll know that you'll generally get apathy or pushback, no matter how much you extol the virtues of the idea. Giving people ownership of an idea actually works (at least in my experience) in engaging them and getting them thinking about the idea. Though the caveat is that the final result may not necessarily resemble your original idea.
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?"
"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.)
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.