So You Want To Be A Software Consultant?

So you want to be a software consultant, eh? I hear “how do I get into the business” questions a lot. I suppose I could save this for my next Monday Consulting Questions article, but I think I’d like to finish the month with a bang. So, let’s talk about it today.

There are several things I think you need in order to launch and have some assurance of success. Note that this list is by no means conclusive, it only represents the things that occurred to me in the shower this morning.

Experience. Ideally, you’ve been developing software professionally for at least 5 years, with steadily increasing responsibilities. You want 5 actual years of experience and growth, not 1 year of experience repeated 5 times over. But wait, there’s more. Hopefully you’ve also been able to spend about a year as a Team Lead or in some other position that lets you work at a slightly higher level, learning to manage people and allocate workloads. It would be super super ideal if you managed to get some project management experience too. In fact, I’ll go so far as to say that when launching a software consulting business, being a good project manager will be at least as important as being a good coder. If you don’t have any project management skills, be prepared to learn some.

Humility. Just because you’ve been a dev for 5+ years does NOT mean that you know it all. Preferably you’ve made some serious blunders, learned from them, and done better the next time a similar situation presented itself. If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.

Wisdom. Read these: Peopleware; The Mythical Man Month; Code Complete; Under Pressure and On Time Project Planning, Scheduling and Control; Slack; The Art of the Start; Book Yourself Solid; Million Dollar Consulting; Influence; The Time Trap; The E-Myth. Don’t argue, just read them. Read them all. Then read them all again. You don’t have to agree with them or even do what they tell you to do. But you do need to read them.

Contacts. When I say contacts, I’m talking not just about people you know, I’m talking about people you know who can be of help to you in launching your firm. People who can hire you for project work. People who can introduce you to other people who can hire you for project work. People who like you. People who want to see you succeed. People who will benefit if you succeed.

Clients. I can hear you already: “Well, DUH, Christopher.” But bear in mind that when I say you need clients, I’m saying that you need clients BEFORE you launch your firm. Don’t form a corporation, rent an office, buy computers with fancy 20" dual LCDs, hire a staff of 5, and then try to find clients. Oh no. Get yourself a few projects first, THEN launch. Deposits for several projects can make for decent start-up money. Work your network of contacts to find your first clients before launching your business.

Money. I’ve heard it said that professional services (like software consulting) are the easiest type of business to bootstrap. This may or may not be true. There’s another saying, though, one that I particularly like: always be prepared. Try to have as much of a financial cushion as possible before you launch.

A Team. Now, this is going to be controversial, since there are plenty of successful one-man operators. In fact, I used to be one, and even argued with Joel Spolsky about it. But the fact of the matter is, the sooner you are able to start delegating work, the sooner you can spend time working ON your business instead of working IN your business (kudos to The E-Myth for that saying). Working ON your business means you are building a system for doing business that will work even if you’re not actually billing. Basically, having a team means that you don’t have to do ALL the billable work. Starting out you will likely not be able to hire employees full time. Find some trustworthy subcontractors (former co-workers seem to work best) to begin with and make actual hires once you’ve fattened up.

Nerves of Steel. Launching a business of any kind is tough. When you’re just starting out, you can’t just code. You need to do your own books, you need to sell, you need to write the proposals, take out the garbage, negotiate the lease on your office, pay the bills, serve as technical support, beg your creditors for extra time to pay bills, and oh yeah, you might even write a little code from time to time. Clients will abuse you, they will slow-pay you, they will change their minds twice daily about what it is they really want you to be building. Cash flow will ebb and flow sharply sometimes. You may experience the rush of feeling like you hit the lottery one month, then the despair of feeling near bankruptcy the next. Of course, all of this can be managed, but you probably won’t know how at first. If uncertainty is emotionally difficult for you to deal with, re-think launching a firm.

I’m sure there is more to launching a software consulting firm than what I’ve laid out here. In fact, I know there is. However, I’m not going to be able to think of it all in one sitting; it’s a strange and varied universe we live in, and there are plenty of things that can make your consulting experience very unique.

If you would like to suggest additional requisites that belong on this list, go ahead and leave a comment.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

Monday Consulting Questions: Scope Creep and Getting Paid

Today I’m just going to tackle one Consulting Question.

Q. I need to negotiate payment on a project that went out of scope. How do I do this?

A. Trying to get paid for out-of-scope work after it’s been done can often be like trying to un-ring a bell. Depending upon the circumstances, it may not even be possible to get that scope creep paid for. So, let’s look at the circumstances.

The first thing to think about is, how do we know this project went out of scope? Do we have a measurable way to determine what features comprise the project’s scope, like a functional spec? If not, you have a real problem, because without some record of what the project’s expectations were at the start, anyone can interpret anything however they want. To be honest with you, if you don’t have anything to prove that the project is out of scope, you’re sunk. Start negotiating and be happy to get whatever you can get.

Now, if you do have a scope document, you’re on more solid ground. However, you’re not out of the woods just yet. Did you set the client’s expectations correctly? That is, did you either:

a) notify the client at the outset that additional features would increase the cost, or
b) notify the client at the time of the change request that the change would increase the cost?

Yes, I know your client is staffed by adults and that adults have no excuse for thinking that more work costs nothing extra, but to be perfectly honest, nobody cares about you or whether or not you are treated fairly. It’s sad but true:

You get what you negotiate. Nobody will be fair with you; you have to defend yourself at all times.

So, if your client can throw up the “but you didn’t TELL me this would cost extra” defense, you’re in a tough position with regard to scope creep once you let it happen. At best, you can point to the scope doc and offer to remove the additional features if they don’t want to pay for more then the original scope. But in all honesty, the moment a client plays the “but you didn’t tell me” card, you’re sunk.

The third scenario — the one that puts you in the best position — is that you have both a scope document and you have communicated effectively with the client. The scope documentation proves what you were setting out to build, which means that anything not in that document doesn’t exist. So, changes are easy to identify and scope creep is easy to illustrate. The communication ensures that at the very start of the project OR at the moment a change request came in, the client was informed that yes, when you request more work, you have to actually PAY for it.

This is a one-two combo that even the most dishonest of clients will have a hard time applying twisted “you should work for free” logic to.

Here’s how I manage scope creep at Cogeian Systems:

  • Every project has a scoping phase, even if it is lightweight. We believe that figuring out what you are building is a normal part of any project. Any client that refuses this and tries to order you to “just get started” is a client we don’t want. Experience has taught me that ambiguity is frequently an ingredient in abusive client behavior.
  • Clients are informed before the project even begins that changes to the project plan WILL result in a revised estimate. Sometimes, the revision means that the estimate goes down. Sometimes, the revision means it goes up (obviously, in the case of scope creep, the estimate goes up). The determining factor is whether we are adding features (which is usually the case) or consolidating/eliminating features.
  • Clients are also informed that some degree of scope creep is normal, because nobody can know in perfect detail what a project will consist of. There are unknowns in everything, and software development is no exception.

I don’t necessarily think that scope creep must be avoided. It CAN be avoided, but I don’t think it MUST be in every case; sometimes scope creep is a good thing for a project — it can be a sign of opportunity for the client, and a chance to (ethically!) up-sell for you as a consultant. However, there is no question that scope creep must be managed. The client must have an opportunity to think about the consequences of change in terms of additional cost, longer delivery time, additional complexity, etc. And the developer must be paid for the work provided.

So, the short answer is, you get paid for out-of-scope projects by defining a change process before the work ever begins. Barring that, it’s up to you and your negotiation skills. Try to do better next time.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

Get More Freelance Clients By Using Face Time & Free Stuff

Business has been great for my little custom software company.  We’re not ready to take over the world or release a product, but things are doing OK.  I’m happy.  And I’ve been pondering the means by which I’ve managed to grow the business and get more freelance clients.  Sometimes I wonder if success in any endeavor just boils down to luck, a happy accident.  But after a talk with a good friend and colleague, I think I understand what has happened.

How does any business get customers?  By advertising?  Nobody pays attention to that anymore.  By clever PR?  Sure, there’s always the odd person who will hire you because he saw that newspaper article about how you donated 100 hours of your time to build a website that takes donations to help cure those poor kids in the oncology ward of the local hospital.  But as I talk to other solo and small businesspeople, an interesting trend reveals itself:  the #1 way small freelancing firms get get more freelance clients is by utilizing the “face time and free stuff” technique.

I can hear you already – “Wha-a-a-a-t?” Just bear with me for a moment.

People like to do business with their friends.  Period.  Finito.  End of story.  Go out and ask 100 prospects if they’d rather do business with SuperMegaJumboCorp or with their poker buddy Bob.  Go ahead, ask them.  I guarantee you that if Bob is even remotely competent at doing what SuperMegaJumboCorp does, 100% of the time, the prospect will choose Bob.  Yes, he could get hit by a bus and take the project to the grave with him.  Yes, he’s only one guy and can only provide so much support.  Yes, he could get hired away.  But Bob will get the business in spite of all this, because he is the prospect’s pal. Being a friend and a known quantity is how Bob can get more freelance clients than you can.

I’ve actually had prospects tell me outright that yes, Bob has royally screwed up our database, and yes, it’s hard on our business sometimes, but we’re not going to fire him because well, we’ve known Bob a long time and he’s just a real good guy.  Competency didn’t even figure into the equation!  What can we learn from that?

When I first moved to the Central Valley, I didn’t know anybody.  Not a soul!  But here I was, with a new home to pay for and a family to feed, one of about a dozen people freshly laid off from a company that came thiiiiiiiiis close to going out of business (but later thrived and got acquired by PeopleFluent).  I had a handful of small clients, but in early 2003 nobody was hiring developers and nobody was taking on custom dev projects.  Obviously, I had to make something happen.  So what was my first move?  Did I take out a Yellow Pages ad?  Did I spend $75 to have a bunch of business cards printed up?  Did I paper the business district with flyers?  Did I go running to the Chamber of Commerce?

Nope.

I sat down with a copy of the Yellow Pages and hand-wrote – yes, hand-wrote, the same way your grandmomma hand-wrote letters to your grandpappy way back when he was serving in the Big Red One – a series of personal letters to the principal of every business in town that appeared to be even remotely technology-related.  But I wasn’t asking for work.  Oh, no.  That would have been sad and small and would have gotten my letter tossed in the trash immediately.  Instead, I introduced myself, briefly summarized my industry experience, and asked about the principal.  I offered to take the principal to lunch and talk shop.  I didn’t approach anyone as a supplicant looking for a favor – I approached them as a peer looking to get to know his fellow tech industry workers.  I forgot all about my predicament and focused on striking up a few new friendships with these interesting new people I was about to meet. In short, I embarked upon a friend-building campaign.

I paid for sushi.  I paid for Tex-Mex.  I paid for American Chain Cuisine.  I visited offices.  I talked, I joked, and I listened – oh, I listened.  People really, really like to talk about themselves.  And in the process of all this, I became friendly with some people.  Friendly enough that eventually a local business owner I’d introduced myself to confided in me that she was unhappy with one of her employees and wanted me to take over his position.  I politely declined that particular bit, but soon ended up doing some other work on contract for her.  Revenue at last!  Pleased, this business owner introduced me to some friends, one of whom I really hit it off with.  I ended up doing a little bit of work with him, too.

Around the same time, two other unrelated local principals took me up on my lunch invitation and I ended up hitting it off with them as well, the result being a little but more work.  Then a sweet lady from a local charity caught wind of my presence in town and invited me to bid on a project.  I took her to coffee, talked about her project and her charity’s mission, and eventually won the bid. This was the start of me beginning to get more freelance clients.

What’s the commonality?

I got face-to-face with these folks.  I got friendly with these folks.  I shared space and time and broke bread with these folks on my own dime before I ever asked anything of them.  In most cases, I never actually asked anything – eventually they just pulled me aside and gave me the “Hey, do you know how to do X?” routine.  But why me?  Why not the 72,566,985 other guys out there with similar qualifications?  Why did I end up getting the business and not them?

Because 72,566,984 of them didn’t bother to reach out, get face-to-face, and hand over a free lunch, that’s why.

When I bid, I’m usually the most expensive bid.  My rates are reportedly higher than most for the local area.  I’m neither handsome nor charming enough to leave people starry-eyed long enough for me to conk them over the head and lift their wallet.  But by golly, I seem to do an alright job of making a new friend over a good meal.  And that appears to be enough to put me in the running for most projects I want to be involved with.  Everyone likes face time – a real conversation with a  real human being.  Everyone also likes free stuff – a real, honest-to-goodness, no-obligation freebie, like lunch at your choice of restaurant or your favorite flavored latte delivered to your office, just to say hello.  And the best part is, everyone can do this to get more freelance clients.

Just take yourself back to the schoolyard for a moment, when you were young and open and not conditioned to fear rejection.  What did you do back then to make a new friend? “Hi, you wanna play with me?” or “Here, want half of my sandwich?” were both perfectly acceptable ways of introducing yourself as a kid – unless the sandwich you were offering contained baloney.  Thankfully, the adult world isn’t THAT different.  Baloney still doesn’t fly, but a simple hello and a lunch invitation can work wonders for making new friends.  And if you take care of getting out into the community and making friends with people, the business will be more likely to come.  Sure, it’s not going to come from every person you meet, nor is every new person you meet going to become a friend.

Even so, you’ll certainly become friendly with many people, have a lot of interesting conversations, and pump a lot of “you” presence into the collective mind of the local marketplace.  Eventually, when there’s enough “you” in the mindspace of the market, the pressure will cause something to pop, just like a closed system that’s been pushed beyond capacity.  And that pop can end up putting dollars in your pocket once you start to get more freelance clients.

Face time.  Free stuff.  Get out in front of people.  Open up.  Make some friends.  Don’t ask for business, just get out there and befriend people – become a known part of the local business community.  Give somebody lunch, or a t-shirt, or a free hour of your time to fix a problem, or shut your yap and listen to someone tell you about himself.

It takes time for this to work.  But for truly small businesses – especially those who are not located in prospect-rich environments – face time and free stuff is a great way to operate. If you’re not having conversations with new people regularly, you may be missing out on a lot of otherwise-hidden opportunities. This alone won’t build a business for you, but it pays to make this habit a part of your overall strategy to get more freelance clients.

The Thrill and Agony of Working From Home

I’ve been running my consulting practice from my home office for about 2.5 years now.  Primarily, I interact with my remote team members via email and IM. After spending the previous 10 years in actual office space, it’s been quite a change. Along the way I’ve learned a few things about myself and my work style in my few years of working from home. Perhaps these things will apply to you too.

These points should apply to both entrepreneurs or freelancers working from home and people who telecommute to work.  Just pick out the items that apply to you and ignore the rest.

If your family is unwilling or unable to respect your work time, you are in deep dip.

For about the first 4 months of my working from home, my wife would pop in to my office for a visit once an hour. She’d pop in to tell me about some interesting fact she just heard on Oprah. She’d pop in to tell me about some cute thing our son did. She’d pop in to tell me who she just talked to on the phone or to tell me about something cool she just read. She didn’t understand why I got so upset about the interruptions. I broke out a copy of Peopleware and explained what it takes to go into a productive zone.  I explained how much time and ground I lost every time I was interrupted.  That didn’t really have the effect I wanted.

Then I showed her my billable reports for the days when I was interrupted and the days when I was left alone.  She understood that.

Now she’s a champ about respecting my office time when I’m working from home. She does a better job of playing defense against my 5-year old son coming to visit me too. In return, I make it a point to take a break in the middle of the day every day to hang out with them for a little while. But those first few months…I was working WAY too hard for my billables.

If you are unable to respect your own work time, you are in deep dip.

Family aside, when working from home everything is a potential distraction. The fridge is ten paces away. So is the cookie jar. And the beer. And the TV. And the PlayStation. And so on. There’s always something that you could be doing instead of working. And some days, that’s a tough obstacle to leap. When you have a regular office, you’re surrounded by work stuff, so at a certain point you just give up and do some work. When working from home, it’s orders of magnitude easier to say “forget this” and go for a swim in the backyard.

Laser-like focus is a must. As for how to get laser-like focus, well…all I can say is you better be doing work you really care about, or at least be doing work that has a payoff you feel passionate about.

Dressing the part is a big help.

I have absolutely noticed a difference in both my demeanor and my productivity when I dress like I’m going to work in a real office. When I roll out of bed and pull on the nearest sweats and T-shirt, it’s not quite the same. Sure, it’s nice to be able to work in sweats and a T-shirt in the privacy of my own home.  But without fail, if I get dressed like I have a real office to go to, I am more professional and more productive.

It might sound silly, the idea of getting dressed “for real” just to work in your third bedroom, but it really does help. There’s an old saying:

“Dress for a dance, and you dance. Dress for playing football, and a game breaks out.”

I believe in that saying completely. In my case, it’s more like “Dress for work, and you’ll work. Dress for lazing about, and you’ll end up lazing about.” Besides, the process of showering, shaving, and dressing is a nice ritual for helping me get into my game-state.  I don’t have a problem with comfortable or even casual dress – I’ve billed plenty of hours wearing jeans and a T-shirt (clean and ironed, of course).  I do have a problem with people being slobs when working from home, which is what “casual dress” usually devolves into.  Dress sharp, feel sharp.

I’m not advocating wearing a suit & tie just to work in your spare bedroom.  This post is being brought to you by Levis and a plaid shirt.  My company isn’t not a formal operation by any means.

Getting OUT of the home office with regularity is a must.

It is easy to shut yourself away and go overboard on the billables. It is also easy to slip into a state of deep depression and apathy while doing so. Some of my highest-grossing weeks while working from home have also been the most agonizing.

I make it a point to go to lunch with colleagues a couple times per week.  I visit clients a couple times per week (even when I technically could deal with them via Skype or some such).  I take a break to play with my son daily. I’m a relatively social guy, and I found that being away from the interplay of an office environment was difficult for me.  Getting out regularly was a non-negotiable “must have” for my work schedule. Even the most introverted of the introverted will stagnate and grind to an intellectual and emotional halt, being shut up in a home office all day every day.  As distracting as it sounds, even a few hours working from your local coffee shop can go a long way toward combatting feelings of isolation.

Even if you’re not a people person, regular changes of venue and human contact will keep your engine at a higher idle than pulling a Kaczynski will. And for the love of all that’s holy, open the damn window and breathe some fresh air!

Getting IN to the regular office with regularity is a must, too (if you have a regular office).

This one is for you remote workers who have an office you could go visit – not only can you begin to feel detached when working from home, but your co-workers can begin to feel detached from you.  This is not good and can result in people forgetting to tell you about meetings, it can leave you out of promotions due to lack of visibility, and in the worst case scenario it can create resentment amongst your co-workers who work in the office full time.  So pop into the office once a week, even if it’s only for an hour.  The social aspects of the workplace are very important to your career and your mental health.

At my last job, I was one of the people who ended up working at the satellite office because it was closer to where I lived than the corporate HQ was.  What a mistake that was!  It didn’t take very long for poor communications to render everyone in the satellite office out of the loop.  The additional overhead of fighting to make sure people remembered to include the satellite folks in things that pertained to them added an un-needed burden to our daily workloads.  Now, this was 2 professional offices having such difficulty.  Can you imagine how the issue can be compounded when working from home?

Don’t skimp on tools!

Just because you are working from home does not mean that you can get by with an old laptop on a folding card table, sitting in a chair you stole from the dining room.  Crawl off the dime and make sure you have dedicated space – or, at the very least, comfortable, quiet space that you can have reasonable control of during work hours.  Make sure you have a development-class machine (if you are a developer), and a printer – hey, sometimes you really can’t avoid printing some things out.  Get any non-work-related stuff out of the room if you can; it will only serve to distract.  When I first began my consulting career, I was working from a $99 computer hutch from Target, stuffed in the corner of the dining area of our 700-square foot apartment.  If that’s all you have to work with, that’s one thing.  But you need to be looking to set up a real workspace as soon as possible.

Please don’t take this as an excuse to go splurge on an Aeron chair and the highest-end machine you can find.  Your gear must be appropriate, not splashy – splashy will drive you into the poorhouse.

Set expectations for yourself.

Have regular work hours.  Take regular lunch breaks.  Set performance benchmarks for yourself, and stick to them.  If you need to, publicly commit to some goals in order to motivate yourself.  And when you’ve hit your goals for the day or the week, stop and re-evaluate.  Can you knock off for the day?  Are you ahead or behind?  Working from home means working from home, not “hanging out in front of the home computer,” so treat it like you would treat office-based work, and adhere to good performance standards.

Be thankful for working from home.

You don’t “have” to work from home, you get to work from home – never forget that.

On Functional Specs and Project Pitfalls

Revised on 13 May, 2015

I found a good post about functional specs when I was reading Ian landsman’s blog this morning.  Ian notes the different opinions on whether or not writing functional spec is a good idea – one camp claiming that spec is purely a political appeasement move, and the other claiming that  spec is vital to a well-written app – and ends up coming down on the side of those of us who write functional specs.  Good show, Ian!  He also wisely notes that functional spec is best done in small bits.  I agree – the bigger a single iteration of spec is, the more likely it is you missed something.

There is a reason that I included inadequate/unclear requirements amongst The 5 Pitfalls of Estimating a Software project – this problem is HUGE in the industry and it cannot be solved by saying “specs don’t work – don’t write specs.”  It’s true that ultimately you need people to agree on the functional spec, just as it is true that they eventually need to agree on a user story or an interface mock-up.  This doesn’t not make the functional spec an appeasement document, though.  If anything, the process of developing a functional spec should get people talking about – even fighting about – what task experience the app needs to provide.  The biggest fear a developer has is to deliver an app only to be told “that’s what I asked for, but it’s not what I want,” and the process of developing a functional spec – done correctly – will avoid this. That’s why I’ve always advocated that every project needs at least – dare I say it – a small spec.

Having said that, I’m going to leave this here:

SmallSpec - painless functional specs

SmallSpec – painless functional specs

Ahem.  Moving on…

Why did I qualify my previous statement with “done correctly?”  Simple – too many developers have an “order taker” mentality when it comes to developing a functional spec.  A client or project manager will rattle off a list of wishes – “Yeah, this program needs to cure cancer, gnarfle the garthok, walk my dog, do my taxes, and make me a sandwich.  It’s pretty simple, you should be able to do it in about 2 hours.”  Now, at this point the developer can go one of two ways:

  1. Say “yes, sir” and shuffle off to make a half-hearted attempt at doing what he knows is impossible, only to be driven to drink and beat his children when hopelessness finally sets in, or
  2. Push back on the client or project manager, challenging their demands; “no, that doesn’t fit in-scope (unless we make adjustments elsewhere in the project)

I’ll give you three guesses what a good developer will do.  😉

When developing a functional spec, it is your obligation to act in a consultative fashion and challenge your clients assumptions and requests.  This is not McDevelopers – you don’t simply serve up whatever the client in the drive-thru orders through the speakerbox.  It is your job to protect the client from himself.  If you find that even after developing a functional spec, the delivered app is met with “that’s what I asked for, but it’s not what I wanted,” then odds are you have failed your client in some way.  Note that I did not say the spec has failed – you have failed.  Perhaps you didn’t probe deep enough.  Perhaps you let some assumptions slide.  Perhaps you didn’t lay out the different scenarios your client’s requests could lead to clearly enough.  I’ve been there, and it is painful to not only let your client down but fall flat on your face with your release.

Controlling scope creep is also part of doing functional specs correctly.  One can claim that functional specs inherently lead to scope creep because it is easy to add something to a Word document, but I disagree.  I think weak developers lead to scope creep.  Again I say – a good developer will not allow this to happen.  A good developer will push back.  “This change conflicts with xyz” or “This change will double the cost of abc” or “This change is not technically feasible,” etc.  When it is obvious that the scope of the project is in jeopardy of changing, a good developer will speak up and offer suggestions.  In some cases, the developer must be willing to stand firm and say NO.

Functional specs don’t fail.  Developers do.

To be fair, the “don’t write functional spec” guys were primarily designers at the time, although over the years they’ve built one hell of a software empire, and presumably still don’t believe in functional spec.  Even so, a designer is dealing with a different set of concerns than a developer is.   I get the impression that some people have a mental image of a functional spec that is just a massive, Steve McConnell-style Word doc with endless bullet points and no interface examples.

This is not how I do my specs here at Cogeian Systems.  Rough wireframe UIs are always liberally sprinkled throughout my functional specs to illustrate what the text is describing.  However, I don’t go into tremendous detail in the spec, nor do I go off building a real, functioning UI until it has been decided what that UI should do, and how it should do it.

A good functional spec should get you on the right side of the 80/20 rule.  Given that, it’s natural to allow for some discovery-as-you-go. And as you make these discoveries, your spec should become enlightened as you do.

I will stick with the approach that has made my projects successful – committing the application experience from a user POV down on paper in an appropriate level of detail in the form of a functional spec – and vetting it with the users – before writing a line of code or building a working interface.