Working With "Big Idea" People
CF Webtools still does quite bit of work for small to medium size businesses. Unlike large companies where the point of contact is usually a CTO or a project manager, you often talk to the owner or main stakeholder in a small company. These owners are often visionary entrepreneurs with a knack for marketing. That seems to be what it takes to build a company - especially one that is based on a product for sale. Now let me say at the outset that I greatly admire these risk taking geniuses. Such men and women often go through 3 or 4 business failures before they succeed. I call them "Big Idea" people and their confidence and self-assurance are remarkable. They can see past the details and envision the final chapter in the long road to business success. Working with such folks can be frustrating however.
They often have an aversion to dealing with the minute details that are necessary to get an IT project done. They are so full of ideas that they tack on requirements without even knowing they are doing so. I often have meetings with such brightly burning souls. As I draw them to the specification we are currently working on, their eyes glaze over. But if I mention what our plans are for "Phase II" and they perk right up. They are far out into the future making millions - while I'm trying to figure out how to build a viable "no-frills" application that is within the budget for "phase I".
"Big Idea" people consistently lack interest in any form of documentation. We create carefully worded specifications that include all the features we think they have communicated to us. In many cases the stakeholder will skip to the bottom line and check out the billing or timeline estimates and gloss over the actual requirements. We often get signed and approved specifications for many thousands of dollars where I am convinced the user has not read it at all. We make the point over and over again - "If it is not in the specification then it will not be in the application". Yet we still get surprised looks when it comes time to test the application. "Where is feature A" or "Where is Item B?" At which point we take them back to the specification and ask, "Where is feature A?"
Why is it so hard for such folks to grapple with written requirements? I believe it is because they are used to telling their story and communicating their vision. Their job has often been in raising money and getting folks to "buy in" to their big idea. This communication is an infectious verbal siren-song that they have fine tuned with years of practice. Unfortunately, communicating the big picture doesn't do much to help the requirements building process. To translate the big picture into requirements requires painstaking, detailed and (some might say) tedious thought. You have to think about individual events within the application. You have to make lists of behaviors and use cases. You have to stop thinking about all the users you will have and all the money you will make and think about a single, individual user and his or her individual experience.
Some Tips on Working With a "Big Idea" Person
Here are some tips I have for getting through to the visionary:
- Do not accept requirements, change requests, or enhancements verbally - either over the phone or in a meeting. Even if the customer is a phone person ask them to write it down in an email or a document and then send it to you. "Big Idea" people are used to the power of their voice. They know how to "sell". But getting you to buy into their application has little to do with actually building it. If they call you with an idea make sure you insist that they send it to you in written form. The phone is perhaps the least attractive way to communicate requirements. It simply does not work. A requirement or a change request is not like ordering a magazine subscription. It's more like balancing your checkbook. It requires precise details. You can't balance your check book over the phone (not easily anyway), and you can't get accurate requirements over the phone either.
- Insist on a Feedback Process. When I write specifications I usually include numerous questions highlighted in bold, garish yellow. Getting answers to these questions are a prerequisite to finalizing the document. More than anything I am looking to engage the customer in a back and forth dialogue till we both know what he or she wants.
- Don't Pitch and Don't Sell. Instead, warn and qualify. I often tell customers, "I'm sure I got some of this wrong". It gives them a reason to read it (ha). I tell them that I only hear about 70 to 80 percent of what they intend. I write specs with caveats and addendums. I describe possible hidden costs or costs that may be lurking downstream after launch. In short, I see my job as a consultant trying to help them bring their idea to life, not as a salesman trying to extract fees from them. This makes the entrepreneur feel that they have found a collaborator and a partner. Remember, they know what a pitch sounds like.
- Include revision costs in your specification. We include a section called "debug and revision" that is at least 15% of the cost of any application. This amount is to account for the change requests that we know will come as we progress.
7 Comments
-
Mark -
I probably read your article wrong and I doubt you meant it this way, but your article makes it seem like working with a "Big Idea" person is either bad or a case of 24/7 C.Y.A. Good products need someone who is passionate and a visionary to drive the products.
I guess I see it a bit differently because I am currently on the flip side where the company I work for is too focused on the details/features. The tunnel vision of writing functionality bits and forgetting the vision can lead to a bunch of features that don't gel together to make a usable product.
Good projects need both people to succeed: The big idea person who is passionate about this new product, and the developer who understands the details and the consequences of those details. Both of them need to get out of their comfort zone for the product to be really successful. -
John, You definitely heard me with the wrong tone of voice :) As I said in paragraph 1 - "...I greatly admire these risk takers." I also said that "...their confidence and self-assurance are remarkable". I made these caveats precisely because I was going to follow up with a criticism. I wholeheartedly agree with you that it takes both groups of people. My point has to do with extracting requirements from them.
Being something of a big idea person in my own way - I know that passion is a prerequisite to building something lasting. But to complete an IT project requires that focus on the details - at least long enough to get them codified. Don't you think?
More to the point, I was not suggesting that we should avoid working with such people. The whole point of the tips was to help folks who may be frustrated with them. -
You might find Getting Real by 37 Signals useful. No, I haven't drinken (drunk?) their Ruby Rails Kool-Aid and I don't agree with many things they say. But there is merit to many of their ideas. The book discusses certain aspects of developing the interface first to use for communication, building requirements and getting agreement. It might not fit every situation but the concepts could be helpful in trying to get big idea types to pay attention.
http://gettingreal.37signals.com/ -
I am constantly on the fence about how to deal with Big-Picture-People. I've gone from the one extreme of hand-holding and building the UI first (as Ryan pointed out) to the other extreme of flatly telling a client "if you can't be bothered to communicate, then I can't be bothered to try to understand what you want". That last part sounds harsh, but I actually prefer it to the former path, as "how it looks" does not necessarily equal "how it works".
Lately, I've been striking a bit of a middle-road of heavily-flagged Visio wireframe mockups followed by bulleted lists. I make sure everything clickable has an arrow pointing to another diagram or a flag that explains its action. Any non-static data has at least one bullet point with a list of selection criteria. Every button or link is accounted for, and there's no wiggle room for "where's the widget that frobs the thingy?". It also has the benefit that truly wordless creative-types can just draw on the diagrams, while managerial big-picture-types can add bullet points.
In contrast to the "build the UI first" idea, I find I'm more likely to get paid if I don't write a single line of code, HTML, or SQL until I've got a sign-off on both the diagram and the bullet points. Coders with the word "agile" on their resume will tell you how horribly inefficient this is, and that may be true, but personal my experiments with such methodologies have not had positive results.
And really, if I'm working on a dozen or more projects at once, the thick dividing line between "time to think about it" and "not thinking about it yet" is nice, as it leads to fewer context switches. -
Rick - excellent comments. I'd be interested in seeing one of your visio wire fram mock-ups. What do they actually look like? They don't actually "mockup" the UI - do they? Just the behaviors - right?
It sounds like you indeed have found a middle of the road approach. -
If the client is willing to pay for a prototype of the UI, then that certainly helps refine what is needed. This is actually much easier to do now with Flex Builder, so a few of my projects have gone this path.
I have found the easiest way to make sure I get it right the first time is to make the client write the requirements. This sounds backwards, but by making the client do the work then collaborating with them on their requirements document things have gone a lot better. The client is far more aware of change orders when this is done, as they know what's included in the requirements document.
Otherwise Mark, I think your post was very good any has many excellent points. +1
Sites to Watch
Aggregators
RSS
