File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Manage It!: help educate the client? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Manage It!: help educate the client?" Watch "Manage It!: help educate the client?" New topic
Author

Manage It!: help educate the client?

Katrina Owen
Sheriff

Joined: Nov 03, 2006
Posts: 1364
    
  17
I work in a tiny group, and we are trying to figure out "the processes" in order to work smarter - however one thing that keeps tripping us up is clients. We constantly find ourselves either trying to talk them out of something which we think is a pretty bad idea, or trying to figure out what they really want. Or trying to adapt when they say they want one thing, and then change their mind radically after three quarters of the development is done.

I suspect that the problem isn't really the clients (it just feels like it somedays. Today.).

Might "Manage It!" help us get things under control to the point where we could have a more efficient and fruitful conversation with the client?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Katrina Owen:
We constantly find ourselves either trying to talk them out of something which we think is a pretty bad idea,


That's probably not a so good idea. I assume that you see it as your job to provide value to the customer, so talking him out of something he sees value in sounds counterproductive.

or trying to figure out what they really want.


Yes, that sounds like the more productive strategy.

How is that troubling you?

Or trying to adapt when they say they want one thing, and then change their mind radically after three quarters of the development is done.


Yes. That's common, and a skill that needs to be learned.


I suspect that the problem isn't really the clients (it just feels like it somedays. Today.).


I think you are right here. The problem is "reality", as far as I can tell.

The problem is that you are doing something new - otherwise, you wouldn't be writing software, you would simply use existing one. And you are probably writing software that is supposed to be used in some process, and that is supposed to significantly *change* that process (if the process wouldn't, in some way, change by introducing the software, it would have no impact at all, and therefore wouldn't have value).

Now, changing a process in a way no one else had done before (at least not at this place in the world) is most often a chaotic process - you can't fully predict the consequences of the change. The only consequences that can rely upon is that after you *tried* the change, you will better understand what the consequences are, and new needs will arise from that understanding.

Another reason for change is that the environment changes, while you are developing the software. And the environment, too, changes in unpredictable ways.

So there really is no way around the fact that software that gets used, software that is successful, is software that needs to be changed - often rapidly. Software that cannot welcome change is software whichs value will decline rapidly.

That's what Agile software development to a big part is about: building software in a way - and learning the skills necessary - so that it is possible to effectively react to changing needs.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42585
    
  65
Katrina said:
We constantly find ourselves either trying to talk them out of something which we think is a pretty bad idea,


to which Ilja replied:
That's probably not a so good idea. I assume that you see it as your job to provide value to the customer, so talking him out of something he sees value in sounds counterproductive.


The problem is that it's not so rare that where a customer sees value, there is actually none to be had. I have seen it happen frequently that once it is explained what the consequences of a certain new or changed feature will be (esp. in terms of time/money/effort implementing it), then all of a sudden that feature becomes quite unimportant. Often that's because customers aren't very good at prioritizing things. They'll come up with a long list of nice-to-haves that have wildly different payoffs in value. Sometimes it's also because they're not technical enough to understand which of those features are easy/quick to implement, and which take a while. That's where the consulting company steps in and tries to bring some order into it.

One area where "bad ideas" are frequently floated is user interfaces, esp. the ones for public web sites. It'sa mazing what some people think is good usability in a web site. Here's it's crucial that the consulting firm brings in expertise.

Katrina:
or trying to figure out what they really want.


Ilja:
Yes, that sounds like the more productive strategy.


I find that that's often the same thing as talking a client out of a bad idea, or at least part of it. What a client wants, and what a client needs, are not necessarily the same thing.
[ November 14, 2007: Message edited by: Ulf Dittmer ]

Ping & DNS - my free Android networking tools app
Katrina Owen
Sheriff

Joined: Nov 03, 2006
Posts: 1364
    
  17
yes, "talking out of" is usually user interface elements.

Yesterday the change request that someone gave me was so radical that we are talking breach of contract (it is as though the contract says "verify the electrical circuits", and the client is now saying "I saw this great building down in Santa Monica, could you make me one of those?".

I guess I'm just feeling out of control, and need to figure out how to work in a more structured, flexible manner.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I latched onto this What a client wants, and what a client needs, are not necessarily the same thing. and tried to reply earlier but the ranch was too busy to listen. Looking at a requirement in a document you can't tell if it's drop dead essential to the business or some casual choice the author made by flipping a coin.

Since then, I found Jeff Atwood said what I had in mind, but much better: Requirements Considered Harmful asserts: "Software development has been steered wrong by the word 'requirement,' defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence - inhibitors to embracing change. And, the word 'requirement' is just plain wrong." The whole article is well worth while.

My only advice for your tough customer situation is to ask "Why?" a lot. Soon you'll know enough to tell requirements from decisions and have a good conversation about alternatives.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ulf Dittmer:
The problem is that it's not so rare that where a customer sees value, there is actually none to be had. I have seen it happen frequently that once it is explained what the consequences of a certain new or changed feature will be (esp. in terms of time/money/effort implementing it), then all of a sudden that feature becomes quite unimportant.


Yes, I've seen that, too.

And I have been in situations where, if I hadn't taken the time and insisted on asking "well, ok, so this wasn't a good idea. Still, you did see some value in it - what value exactly was that?" - we would have missed an important opportunity to provide value in a way that actually made sense.

And I've found that it takes much less insisting on my side, and get more effective collaboration, when I don't start the conversation with "oh, no, this doesn't make sense, better forget about it", but with "ok, I see that you see value in this. Let's take a look a deeper look at what that value is, and whether perhaps we can provide it in a way that is even more valuable or less costly". Where getting an inconsistent system is a huge cost.


Often that's because customers aren't very good at prioritizing things. They'll come up with a long list of nice-to-haves that have wildly different payoffs in value. Sometimes it's also because they're not technical enough to understand which of those features are easy/quick to implement, and which take a while. That's where the consulting company steps in and tries to bring some order into it.


Yes. Helping them to prioritize, for example by helping them to clarify the value they get from a feature, and by providing them with a cost estimate, certainly is a good idea. I just don't think that "talking them out" of a feature idea is a good strategy. I think a better strategy is to find a way to *more* empower them, and to give them all the information they need to use that power wisely.

Another thing that helps is to make clear that they don't need to think of everything they might want to have later at the start of the project - that coming up with new needs and ideas later won't impose a huge cost penalty. They typically aren't used to that thinking. They are in fact trained to think of every possibility up front, by our profession.

I find that that's often the same thing as talking a client out of a bad idea, or at least part of it. What a client wants, and what a client needs, are not necessarily the same thing.


What a client needs, and what we "know" he needs, neither.

I really think that the best way to think about this is that we are in it together with the client. It's not about talking the client out of a bad idea, it's about working together, everyone providing his best expertize, on finding out what is needed.
Johanna Rothman
author
Ranch Hand

Joined: Feb 10, 2005
Posts: 72
    
    6
It sounds as if you're having some trouble with denoting value of each "requirement" to the customer. If so, have you tried the approach of saying, "Here's $1000. (or $10,000 or some other number) For each requirement, put a unique monetary value on it. If you have 20 requirements, and they're all close in value, they aren't all $500; one is $500, one is $499, one is $498, etc. Then you ask more questions to understand each requirement's value in relation to each other.

Have you asked context free questions at the beginning of the project, so you know what success means for the project? The context free questions (from Gause and Weinberg's Exploring Requirements: Quality Before Design are:
1. What does success look like?
2. Why are these results desirable?
3. What is the solution worth to you?
4. What problems does this system solve?
5. What problems could this system create?

Understanding what success means might help you navigate the yes/no we need this problem.

Johanna


See all my books
My blogs:Hiring Technical People blog - Managing Product Development blog
Katrina Owen
Sheriff

Joined: Nov 03, 2006
Posts: 1364
    
  17
Thanks, everyone, for your feedback, thoughts, suggestions, and ideas.

We haven't tried the monetary prioritizing approach - that sounds like it could bring in some pretty interesting answers!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Manage It!: help educate the client?