Bill Litfin 04 Apr 06

Excellent post - I was just telling a friend about this part of the workshop (his comment was “…if the result is good - no one will beat you up for a missed process step”).

One thing that the brevity (in the case of a proposal) forces is that every word, sentence and paragraph has to communicate and inform. No room for fluff there.

Another point that Ryan made during the workshop which I think is valid… wireframes are less useful for specing or documenting web applications (esp. ones using Ajax) because the metaphor of a “page” is not as important anymore - because a “page” may be appear 20 different ways during a single user session.

ChrisH 04 Apr 06

I have to agree wholeheartedly with this.

As a freelancer, I cut out all those deliverables a long time ago. Big waste of time. Sure I make mental plans and notes and sketches, but I’ve built so many websites that I’ve learned where the pitfalls are and how to build the site to allow for change - because almost without fail, a client will change their mind at the last minute - so if your structure is too rigid, then yeah, you have a lot of work ahead of you to make the change. And all those deliverable documents only serve to TRY to cement in that structure. Even if you have those documents, they should be living documents and not absolute rules.

That said, the only deliverables I give a website client are:

1. a site map (constantly changing)
2. visual design comps (usually PDFs or JPGs saved out from my PSD or Fireworks file)
3. final product (the completed website, ready for testing, last minute changes, etc.)

Why shouldn’t it be that easy for your company? You’ll spend more time creating complex wireframes, functional specs, etc. than if you make their last minute changes (providing you allowed for such changes in the construction of the site by using CSS, includes, templates, or whatever other methods you choose).

Of course I’m talking about websites with some web app functionality, not necessarily full-blown web apps.

Alex Bunardzic 04 Apr 06

Absolutely correct. It’s not a rocket science, and Jason is right to point that out.

However, in my experience most of the teams that focus on all these documents and ‘illusions of agreements’ do that out of sheer incompetence. In other words, they don’t really know how to deliver a viable workable product, but feel safe and comfortable while living inside Word/Visio/Photoshop/MS Project/PowerPoint/Excel, etc.

That’s why such people will be kicking and screaming if you propose they abandon those phantom artifacts and start working on the real thing.

Is there a cure for that? Yes there is — it is called proper education. Learn how to build a real product, and you won’t be hanging on to the phantom mockups anymore.

Dan Brown 04 Apr 06

Less is more. Focus on what’s important. All good advice. I’ve never tried to “get real” myself, but I’m intensely curious about it.

I’m not sure the advice in this post is easy to follow. After reading it, you might still be asking yourself “Which documents should I drop?” or “If I drop wireframes, do I need to beef up my flow charts?” So I’ll offer another way to go about it.

At the end of the day, a document mitigates risk. It helps address potential miscommunication issues and establish accountability. Instead of listing out all the documents your process calls for, make a list of all the project risks. For each risk, think about how you’ll mitigate it. There’s more than one way to skin a cat, too, so think about two or three strategies. The challenge is to think of solutions that don’t require formal documentation. Perhaps you can use other mechanisms for enforcing accountability or perhaps you’re already capturing the information elsewhere and don’t need to translate it into something formal.

Reframing documentation as a means for mitigating risk, you’re free to identify other means for dealing with potential project pitfalls.

Jason, I’m a skeptic, but I’d love to see it work. Keep challenging us!

Mike Rundle 04 Apr 06

Totally true man. One thing that I *absolutely never* do is the “meta design”. The wireframes, the creative encounter document, the explorations, etc. etc. No, I ask some questions and then give them real stuff. Larger companies can charge more for client work because they douse the projects in 50 pages of non-design and then deliver one website. I deliver one website and no pages of non-design, cut out the hassle, and then get projects done quicker.

Ryan Ripley 04 Apr 06

@Dan: I can’t think of anything more “risk mitigating” than a working prototype. Ruby on Rails makes it very easy to get the clients initial concept straight from verbal form to web app very quickly.

From that point forward your conversations with the client changes from haggling over bulletpoints to discussing the features that are right in front of their faces…

Seems much safer that way to me…

Just my .02,

—Ryan

jonathan segal 04 Apr 06

Although I fully agree with the approach outlined here and in Getting Real, I find myself up against a local client base that expects 30 page, bound proposals for project tenders.

Fiji is old-school from that perspective…

That written, I do deliver proposals that are as streamlined and readable as possible and my success there has been more positive than negative.

I guess I just wanted to make the point that the developing world, in particular, generally isn’t thinking about business the way companies are in more mature Internet economies.

We continue to press on, though, frustrating at times…

Dan Brown 04 Apr 06

Ryan: I’m sure you’re right. To go cold turkey in environments which currently thrive on documentation, however, may appear too difficult for skeptics. On the surface of it, losing a little at a time, as the title of the post suggests, may even be more difficult.

For skeptics, they may walk away from Jason’s essay thinking, “Well, that didn’t help.” There are lots of unanswered questions. I was trying to make a suggestion (being someone who lives, eats, and breathes documentation) for those of us for whom documentation seems inescapable. There are ways to make even well-entrenched processes more streamlined and effective, but productive change management require more than “Just Do It.”

Get Real seems like a great way to work, focusing on innovation and creativity instead of work for work’s sake. As Jason’s post admits, however, people are struggling to see it in the context of their own work situations. Not knowing 37Signals’ full complement of clients, I don’t know what sorts of situations they’ve dealt with. I’d love for Signals to deliver their Get Real workshop in Washington, DC where many of us deal with systems with complex business rules—requirements literally dictated by law.

It’s not that I think Get Real CAN’T apply to these situations, it’s that I haven’t seen anything that suggests how I adapt the thinking to these kinds of corporate cultures.

Anonymous Coward 04 Apr 06

@Dan: I’m not sure what “your skeptics” are expecting… A manual?

I find that people that cannot take an idea and internalize it are typically skeptical of everything and are immune to change…

Plus, these people are not champions (see Seth Godin), and probably would be unable to run with the idea of “Getting Real” even if the implementation were laid out for them…

Here’s a Getting Real tip for you: Figure out what your biggest problem is. Fix it by “getting real”. REPEAT until you are in a state of Fried… j/k

Example: We do too much paperwork… DO LESS PAPERWORK… REPEAT!!!

Have fun,

—Ryan

John Topley 04 Apr 06

“Trashcan deliverables”, “functional specs are a map to a place you’ve never been” - you guys are so quotable!

Ryan Ripley 04 Apr 06

@Dan: I’m not sure what “your skeptics” are expecting… A manual?

I find that people that cannot take an idea and internalize it are typically skeptical of everything and are immune to change…

Plus, these people are not champions (see Seth Godin), and probably would be unable to run with the idea of “Getting Real” even if the implementation were laid out for them…

Here’s a Getting Real tip for you: Figure out what your biggest problem is. Fix it by “getting real”. REPEAT until you are in a state of Fried… j/k

Example: We do too much paperwork… DO LESS PAPERWORK… REPEAT!!!

Have fun,

—Ryan

Rachel 04 Apr 06

I agree in theory with getting real, but our problem is that we work in a higher ed environment where our clients aren’t just people coming to us and hiring us to do something. Our clients are faculty/staff/students, and they are entitled to be demanding just because it’s how it is.

What this means is that if we don’t put our foot down and say “this is the scope of the project and that’s the end of the story,” we will never ever ever hear the end of the story. If we didn’t have agreements and approvals, we would get a bunch of people who have been trained that we are their resource, wanting to add a new “little thing” to a project every day. And not complying, or trying to reason, can often mean a trickle up to the dean. The only way we’ve found to combat this are finalized agreements that are approved before we start coding.

Another big problem we have (this is primarily in dealing with students, which doesn’t happen terribly often) is institutional memory. There was a project in place before I started in my position that had been floating around for years because it was started with a certain group of students on a committee, but then they graduated and the new people disagreed with how the app was to work. Then, being students, they procrastinated and were too busy and then the next group graduated. And so on and so on, and now it’s been batted around for years without any conclusions because it’s impossible to get them to agree on things across classes, or even be willing to commit to working on it So, since we have an involved group this year, we finally decided that we are writing up functional specs, and nailing down every little piece of information because we know that the odds are that the next group is going to whine about it and it will continue to not have an end in sight.

I’d love to not have to resort to boxing things in like this and allow a more organic flow, but it seems like it’s almost impossible in our situation. But I’d love to hear if someone else has managed to find a better alternative in their in-house situation where they are not your clients, you are their resource to use and abuse!

Anonymous Coward 04 Apr 06

Yes, just keep cutting out work because it’s all not relevant!

Matter of fact why do anything at all? Just sit at home and tell the clients to accept your way of working! What step of “getting real” is that?

You guys have some good points, but cutting out documentation like evaluation of current pages, sketched diagrams, lightweight personas and scenarios won’t be happening for me any time soon.

dc 04 Apr 06

I’d be thrilled to hear someone chime in with experience on how this affects the triangle of cost - time - scope. both how specifically you would fix scope with as little documentation as possible.

but also how eager clients are with letting one of those go. we could always just try it, but I know that most of our clients want to know all three pretty specifically.

dc 04 Apr 06

is anyone writing “getting real with clients” yet?

R. Marie Cox 04 Apr 06

Just about the only pre-development document I produce anymore is a process flow chart and that’s basically only created to make sure everyone is in agreement with the client’s business rules/policies — including the client. (It’s interesting how often two people who work together at the same company everyday can have wildly differing understandings of the same policy.)

Now, in terms of how a process flow chart relates back to the actual application, usually I try to keep it balanced so that it’s representative but not overly detailed/specific. This ensures that the document doesn’t overly exert influence onto the application’s interface but does keep it in check in terms of meeting and adhering to the client’s objectives overall as well as letting them know that I understand those goals.

Something to keep in mind is that there are always going to be things the client doesn’t remember (or realize) that they needed regardless of how copious your documentation is and often times they won’t know these things until there is something in front of them. Non-developer types will almost universally have issues visualizing interactivity and anything less than a working prototype will usually do little more than give a false sense of security and reinforce baseless assumptions.

What it boils down to is that there’s more risk in believing you can document every single detail of an application in one fell-swoop before you’ve written a single line of code than there is in understanding that issues will materialize, preparing yourself to handle them for when they do and getting started soon enough so you have more time dedicated to the actual development in order to correct them as early on in the project as possible.

Tom Greenhaw 04 Apr 06

I have worked your theory in the opposite direction. I started with as little up from documentation and have found the need to add more.

When you have ambiguity in your plan, the customer will always claim the assumption that “you didn’t give me what I asked for”. The will claim that features discussed but not planned for were in fact expected in the finished product. The right amount of “red-tape” can save you butt.

There is a delicate balance between too much (which is at best a waste of time and at worst a strightjacket), and too little which causes blown budgets and timelines.

Some publicly held companies have Sarbanes-Oxley requirements for IT governance that requires SDLC style project devepment controls and documentation. If you want the job, you must obey the rules.

For an initial proposal we do exactly what ChrisH listed above in addition to a proposal document that has a summary and brief narrative description of the functional specs. We also prepare a work breakdown in Excel that lists all the tasks with a granularity of 1 to 24 hours. This work breakdown is useful for estimating time (and therefore cost) and also is plugged into the ToDo list (in basecamp ;-) when the project gets accepted.

I have discovered a very interesting truth in analyzing many succesful projects and some learning experiences. There is a relationship to the size of a project to up front documentation:

16 hours of development = 1 page of documentation

gwg 04 Apr 06

@anon coward - As long as you deliver the product, take it as far as you can.

Dave 04 Apr 06

I should preface by saying I’m at a small company, but here is how I’ve managed to spark change in people’s beliefs. Basically, you trick them. When they ask you to get an ERD and a wireframe, you lie and tell them that you already have it, and invite them to your desk. And then you proceed in the span of ten minutes (when you would be discussing the diagrams) to prototype a portion of the model and a few controller pages in RoR. The first time, they will probably still ask for the ERD. The second time, they may want both. But by the third or fourth, they want to switch platforms.

Basically, you switch the process from “hey, this is what we want, think about it and we’ll meet in a week” to, “hey, can you try this out for a minute and see if something like this will work?”. Agile methods don’t have to sit between the developer and client, they can equally work in a manager-developer scenario. And when they can see instant gratification, dollar (or yen) signs fly.

It’s always a transition, but if you show them you can get more sooner with less paper and more actual work that can be used in the finished product, few people will say no. But telling them won’t alone solve it, you have to prove it a few times.

Tommy 04 Apr 06

Ok, this is going to sound bad no matter how I say it. I have to agree with Tom. I am the VP of marketing for a high-tech company (27 employees). I produce a lot of paperwork to get my boss, the owner to focus. Otherwise we move forward and then he changes his mind and we lose weeks of work. When a third party is involved it even worse.

The first web site I did for this firm I used less, not more documents. The inital concept was approved, then I got, hey add these 15 things to the page (and no I am not kidding). They didn’t “fit” or work, and I got, just throw them in. The next version of the site I didn’t make this mistake.

You’d think because I work at a virtual company we’d put stuff in writting. The exact opposite is the case. People think a phone call is enough. Time after time (and I am a note taker) when I don’t put something in writing I find we had far different opinons on what was said.

And finally, I have to agree and expand with Tom’s last comment. “There is a relationship to the size of a project to up front documentation.” I’ve always said the upfront planning and documentation, at least as a project manager, is key.

But that is just my opinion …

Anonymous Coward 04 Apr 06

And finally, I have to agree and expand with Tom�s last comment. �There is a relationship to the size of a project to up front documentation.� I�ve always said the upfront planning and documentation, at least as a project manager, is key.

Exactly. AS PROJECT MANAGER. Meaning you don’t do the work. Those who do the work don’t need the documentation because they are actually working things out in real time. You are busy cracking the whip.

Tommy 04 Apr 06

Fun “anonymous” since I both do the work and project manage the tech work that is way above my pay grade. My tech department (programmers) want more detail, not less from me. They demand it. Otherwise the problems I’ve had with site development happen on even a larger scale when we’re building out our product.

Tommy 04 Apr 06

I rarely give them long text docs (those go to management — and no they don’t deal with visuals well). Just like creatives on the agency side, that isn’t how their minds are wired. Any time I can say something w/ a visual, that is the option I choose.

I mean I send my tech department a number of your posts. I don’t disagree with much of what you preach. I just get a ton of push back.

Plus, I want my tech team thinking. I find many times they think I something I nor management has and it ends up improving the project.

Anonymous Coward 04 Apr 06

Plus, I want my tech team thinking.

It doesn’t sound like they are thinking if they keep asking for details from someone else. “Give us details so we can build based on exactly what you say.” That’s not thinking.

sixtoe 04 Apr 06

I worked for eight years in an environment that worked with very few steps in the process. Basically, we were briefed, disappeared for a few weeks, created the work we thought was best, and brought it to the client…and then sat through infinite rounds of revisions. We showed 17 site designs to a major golf manufacturer. I presented 35 TV scripts to the world’s largest sports network. The final products were always empty shells of the original presentation. It sucked.

I now work for an agency that beats the hell out of everything. Work Orders. Creative Breifs. Sitemaps. Wireframes. Pagetypes. etc., etc. The result? Better work, sold through the first time around. We sell more of our ideas to the client because they’re involved every step of the way and they’re not surprised or scared when we show up with a concept that’s a little different. Sell the big idea first in a few sentences, then build each step and show it to them. Yeah, you work harder, and longer, and deadlines get pushed. But ultimately, if the work is killer and brings in sales, the client will never remember if it was a week late.

What’s so bad about structure and process? I WANT to give this stuff to my clients, if it will save me endless rounds of headaches two months down the line.

Des Traynor 04 Apr 06

I like this approach and would use it where possible. Something that happens to me, as was mentioned by Rachael, is that when you give a prototype, people start making extra requests here and there. I see that your Express deal contained the disclaimer

“But, because of the low cost and short timeframe, we won’t be able to accept input once the design process starts, and what we deliver is final.”

When you’re doing one page, in one week, thats fair enough.

In short, how do you agree on the amount of work and payment that is going to be done on the app, and still permit changes once you’ve built a prototype?

Tommy 04 Apr 06

Let me try it again anonymous. Our CEO works 18+ hours a day. He is the money and idea guy. He also thinks technology can solve every problem.

He’ll have a vision for a product and we’ll start moving forward. Sometimes it takes weeks or months to build. Well his ideas by the time we deliver the product is a night and day different from the intial input.

Now I know this comes down to managing our boss, but we’ve tried. Therefore the documents we produce makes him think. It makes him focus (see Tom Peters book on this topic).

Although it takes longer for us to get started, we don’t end of building a product based on knee-jerk thinking.

I love 37 Signals, but at times I think they assume their “less is more” works for every firm. I don’t think that is the case.

Sandeep Sood 04 Apr 06

We recently adopted a one page proposal policy with our clients. These are clients who have been with us for a year or more and who are used to the level of service they get from us.

The rule is - any additional work on the proposal (that would take it beyond the one page) should be put into building, designing, or managing - doing the work, not telling them about it.

We include a basic summary, costs, a timeline, and a box for a signature.

Our finding? They love it. Suddenly, the time it takes them to review a proposal has gone down, they seem less afraid to ask for small projects, and it is becoming accepted that we will lock down the details as we go, not in the beginning.

Much love to the Getting Real approach for the inspiration to do things like this.

Alan 04 Apr 06

Like a lot of the Getting Real process, the more trust that exists between you, your clients, and your individual team members, the more success you’ll have in reducing the amount of process related debris that fill up your days.

If you have developers that are more interesting in following instructions than they are in building a product, Getting Real isn’t the primary solution to your problem.

If you have a client rep that’s more interested in playing gotcha or inflicting Random Idea of The Day on you and your budget, Getting Real isn’t the primary solution to your problem.

Dan 04 Apr 06

@Rachel, I’ve been in the higher ed. environment for a little while now, and although I haven’t had a chance to test this out, this would be my approach…(and this is what we are moving to hopefully!)

What this means is that if we don�t put our foot down and say �this is the scope of the project and that�s the end of the story,� we will never ever ever hear the end of the story.

Scope is a constant battle between the project manager and the client. On the one hand, the client want everything to be included, on the other, the project manager wants as little as possible to be included. IMO this is a silly argument to have, just like a functional spec… you’re both trying to predict the future to a degree — who knows if a particular feature will be required?

Wherever possible, use (agile like) feature driven development. Agree on a feature or set of features; develop and launch; move on to the next feature. Budgeting/resourcing/prioritising can then be done on a per feature basis, rather than on the entire project (impossible), or on an arbituary version number. If they ask for another feature, add it to your list of features, and let them decide which feature they want the most.

Using a waterfall type model, and trying to agree on a feature set at the start of a project will *not* work. I’ve seen projects waste two years on documentation this way… in the third year, the application was finally developed, but guess what? The client wasn’t happy with it anyway.

John 04 Apr 06

JFInstead of promising the recommendations document, the flow diagrams, the wireframes, that whatever-the-document-is-called, leave a few of them out of your next proposal. No one will miss them. Each time you write a proposal, leave a little more out of the proposal. No one will miss it.

In past postings you and your team have advocated for spending a few days creating one-page stories instead of complex functional specs, for adding annotations in-line with UI mock ups to explain to programmers how things should work, for making lists of what a product won’t do and for developing simple sketches of the interface prior to design. All of these things are forms of documentation that lead to better solutions. You haven’t “removed” documents per se, you’ve limited the scope and detail of these documents to allow you to get to a real solution faster. I think it’s disingenuous to tell people to remove specs, flow diagrams and wireframes from the process altogether because “no one will miss them” — after all, you continue to create these documents yourself, albeit in dramatically simplified form. Perhaps you’re taking an extreme position to make a point, but I suspect what you’re really driving at is that teams should restrict the amount of documentation to just what’s necessary to allow everyone to understand what’s being built, to flag up issues and to refine their thinking. On some projects, a one-page story and a handful of paper sketches may suffice; for other projects a simple flowchart and some low-definition wireframes with annotations may be needed. If the project involves re-architecting a large content site, maybe someone will need to quickly create a sitemap or spreadsheet that accounts for every page. It’s not about eliminating documents indiscriminately, it’s about being selective in the documents that you create and choosing the best tools for the job.

Mark 04 Apr 06

I posted previously that the aforementioned tech team wanted details to cover their asses, but apparently it didn’t get through.

They do. They’ve been trained to anticipate having to clean up the mess when they move forward on a project that hasn’t been fully thought through, or was presented to them poorly. So, detailed specs give them a document to point to and say, “wait, no. this is what we based our work on. this is what you got.” Absolution achieved.

I’ve learned well enough at this point to take the 37s mantra(s) and understand that it’s how they do things, and it works for them, and it isn’t necessarily suitable to every situation. Allow me to empathize with your tech team. I’m working in a big agency, with a Fortune 500 or less client, on a web site redesign project. I have to take updated comps from our Creative Department and provide them two (2) CSS files to update the previous delivery. Due date: 4/12. Progress today: 0. Creative’s still finalizing them until tomorrow. We’re talking TWO files that will be previewable when they’re done and which I will send over THE MOMENT I can declare them complete.

We’ve been asked for a daily 5:00 PM status meeting to check on my progress. What am I supposed to give them for the next 5 days at that meeting? A count of lines of code? In the first phase of the project, we were urged to provide dates for deliverables. We countered that AS SOON AS WE FINISHED A PAGE we’d put it in their hands. “Can we have dates?”

The reality for most of us is that there is precedent, there are clients who don’t get it, there are politics at play, there are big budgets and numerous stakeholders and a whole lot of people who want to own everything, but take responsibility for nothing. It’s amazing that any business actually gets done in this country, and that any money is actually made by such clients.

So, for the aforementioned tech team, it’s a lack of faith due to a poor track record, same as with my client. And for 37s, though I’m sure they get it and are aware of it already, my role is Senior Software Engineer. That’s the scope of what I can control. Our Account Director can’t tell the client to change their behavior, and we can’t turn away the relationship and budget. So these are the realities I deal with. Myself and many, many others. This is why posts serve more as inspiration than as action items we can take away and implement.

And why my plan is to soon be looking for a position elsewhere.

Marko 04 Apr 06

We�ve been doing Fixed Everything contracts for a few years now and with astonishing success. Our proposals have become our number one unique selling point. Clients adore our proposals and we often find them inquiring how we do it. And Jason is right; Happy clients all around.
We�ve developed a way to estimate functionality that is congruent throughout projects. That enables us to fix time, budget, scope and quality in the contract. (Well we have only one level of quality: The Highest. Well, there is another level of quality, but that�s only used when people�s lives depend on the software�)
We guarantee on-time, on-budget delivery of the project. If we�re one day late, the customer does not have to pay. If we go over budget, it is our problem. It won�t cost the customer one penny more. We guarantee the amount of scope we produce. Furthermore, the customer can stop the project at any time.
Flexibility or agility is retained because:
� If the project is finished and there is still value to be delivered, the customer can start a new project delivering that value.
� If during the project the customer finds his priorities have changed, the customer can exchange functionality. (ExChange Request) i.e. Take out the same estimated amount of functionality and replace it with something more valuable.
� Progress is measured in Delivered Working Software.
� Customer cannot exchange delivered functionality.

Amounts of documents for the customer to sign: 1 Contract
Happiness level of customers: 3E (Excited � Elated � Ecstatic)

Be sure of one thing: Keep your promises. If you do, your earn trust. Still you can only earn trust if you trust yourself and abolish fear. Having dozens of documents to sign or trashcan deliverables is a clear sign of lack of trust, either in yourself or in your relation with the customer. Customers need to learn inside a project too. We�ve never finished a project with the exact same functionality that was in the contract. Still all our customers are references. So it can be done and we have been doing it long since we ever heard of 37signals or Getting Real. We�re just glad to see others doing it as well. We hope you do it too.

@Rachel: Drop that project. If no one is willing to invest time to be a decent customer there is no value in your project. The only way to provide value is to drop it. Instant value;

� Less loss of resources on something nobody wants or believes in
� Less frustration for you and the team
� Less documents
� Less paper
� Less trees killed

Everybody profits!

Bill Tait 04 Apr 06

It’s getting hard out here for a PMP.

Has anyone else noticed the direct correlation between the PMP (Project Management Professional) credential and the need for massive amounts of useless documentation that needs to be updated at least weekly?

I don’t know what they’re teaching in project management school, but it sure feels like “push more paperwork.”

doug 04 Apr 06

I almost hate to ask this question. “How many agencies and design firms charge for the production all of those documents?” I think the root of the excess paper problem may be the fact that it gives the agency something tangible that will not be questioned as a billable line item on the invoice.

If this is true, the firms that get paid primarily for the end product will love “Getting Real”. Those who have revenue that is tied to producing these documents won’t leave them behind. I’m sure they will have a lot of very reasonable sounding excuses. But, bottom line - it comes down to their bottom line.

For the record, I am currently working on a personal project that could not be done the old way. I simply don’t have the resources available to generate all the paperwork plans. So far it’s going fine. So I�m biased. I still think the point is valid despite my personal bias.

RyanA 04 Apr 06

@Marko: That enables us to fix time, budget, scope and quality in the contract.

You fix all four? You must have an absolute killer team doing the same type of work, right? How is it possible to guarantee all four of these things? Trying to promise all four is often the biggest mistake people make.

I suspect you quote very large sums and have an incredible amount of buffer time in your schedule?

You said “If we�re one day late, the customer does not have to pay.”

Are you saying that they don’t have to pay for the project at all or they just don’t pay for the extra time you spend?

Further more I would like to see some case studies if you have any of succesful projects of yours.

Sorry to put you on the spot but, well, your claims kind of justify it :)

Jon 05 Apr 06

As a client, I find that over time we are asking for MORE from our web service providers. More detailed requirements, more documentation, more accounting for progress.

Partly this is because we have to meet Sarbanes-Oxley standards, partly its because we’ve been burned so badly by (big) developers who were more than happy to do things in an agile method, particularly because it rendered them basically unaccountable for anything that went wrong.

I do like all of the Getting Real hoopla, on a level, but it does make some pretty huge assumptions about the nature of the working relationship, client and developer behaviour, level of trust, level of risk, scale of project. A little more acknowledgement that this is aimed at a very specific sector with very specific requirements would help some sceptics understand why Getting Real seems to ignore the realities of their workplaces.

Andreas 05 Apr 06

10 page proposals??? This would took me 1-2 days. I’m a freelancer and that is time i don’t want to afford for boring docs. The longest I did was 2 pages. For a small project - and they wanted it. For large projects it’s usually less, mostly talking and making some notes and a short agreement. Never delivered documentation (besides the generated-from-source ones) - never promised to. Artists (painters, musicians, etc.) don’t do that either;) I am rejecting gigs that involve documentation or more than usual paper work for years now. Sometimes it’s hard, and it requires more faith in people. But it pays off later on: You’re not wasting your time anymore. It works that’s for sure. Though, the amount of clients is less, but I don’t need millions of them. I need one at a time.

I'm With Stupid 05 Apr 06

“I do like all of the Getting Real hoopla, on a level, but it does make some pretty huge assumptions about the nature of the working relationship, client and developer behaviour, level of trust, level of risk, scale of project. A little more acknowledgement that this is aimed at a very specific sector with very specific requirements would help some sceptics understand why Getting Real seems to ignore the realities of their workplaces.”

Oh, my! I would have thought that the fact that they have repeatedly said that this is what works for them and that you should take from it whatever helps you in your situation would have this covered.

I guess every post that 37s makes needs to have an the following disclaimer:

“All we are saying is that this is what works for us. We understand that your situation is special and unique (just like everyone else’s). We further acknowledge that there are approximately 180,543 reasons why what we are saying won’t work for you, isn’t valid in your situation, or just doesn’t jive with the Realities of the Known Universe.

In other words, your mileage may vary.

Also, please note, you shouldn’t swim for 30 minutes after eating, you should eat more fruits & vegatables, and, finally (but not exclusively), running with scissors is NOT advisable.”

Anonymous Coward 05 Apr 06

I like other people here find that if you don’t have a certain amount of documentation so that everyone is on the same page as to what need to be developed.

The client doesn’t want me to cut corners and shortchange them and I don’t want the client so see make a million tweaks and change requests.

I think not having a spec is great for a personal projects but big corporate projects are just too plain risky in my eyes without enought documentation.

Can anyone using Agile methodologies/Xtreme programming/”Getting Real” methods help?

Can

Roger Collins 05 Apr 06

Keep it real by admitting this process is more spin than innovation. I’ve been developing software since the Commodore 64, professionally since 1987. It is very natural for developers to develop and not write documentation. But complex projects live or die on effective communication and that usually means some documentation and meetings. If you do small projects you’re using the right method.

cj 05 Apr 06

@I’m With Stupid

Well said.

GHA 05 Apr 06

Jason —-

Can you should us a sample of a proposal 37signals would of prepared for clients in the past? I’d love to get a glimpse.

Thanks.

Chris Kay 05 Apr 06

We do agile development regardless of the size of project. Most people early on in agile suggested that it doesn’t scale well with larger teams. We have found that with a few tweaks it works really well. That’s a topic for another day. However on the topic of documentation….we do work with large banks, insurance companies and pharmacy companies. The fact is it works. Documentation does not equal communication, neither does having meetings. It equals less time being spent on real work. Natually though these types of clients have legal reasons for wanting some documentation…..so we adapt for each client. We take the approach Jason mentioned up top. We don’t do much documentation and then when the client come to us we let them know that our approach isn’t based on lots of documentation but it doesn’t mean we can’t do it. We do enough to keep the client happy and meet their personal legal needs.

I'm With Stupid 05 Apr 06

“Keep it real by admitting this process is more spin than innovation. I�ve been developing software since the Commodore 64, professionally since 1987. It is very natural for developers to develop and not write documentation. But complex projects live or die on effective communication and that usually means some documentation and meetings. If you do small projects you�re using the right method.”

If you try hard enough, you can miss any point. That happens when you don’t try at all, also.

Don’t Get ‘Real’? Maybe you can Get Agile.

Geof Harries 05 Apr 06

Exactly. AS PROJECT MANAGER. Meaning you don�t do the work. Those who do the work don�t need the documentation because they are actually working things out in real time. You are busy cracking the whip.

Give me a break.

Good project managers work as hard, dare I say even harder, than the people and teams they represent.

We’re running defense, keeping our team removed from corporate politics, sharing voices to the ears that need to listen and taking care of all of the annoying little details that detract you from getting your work done.

Simply because you can’t grasp the intricacies of what it takes to effectively manage a complex project doesn’t mean you should wash the profession with such negativity.

Jon 05 Apr 06

Says “I’m With Stupid”:

“I guess every post that 37s makes needs to have an the following disclaimer:

�All we are saying is that this is what works for us. We understand that your situation is special and unique (just like everyone else�s). We further acknowledge that there are approximately 180,543 reasons why what we are saying won�t work for you, isn�t valid in your situation, or just doesn�t jive with the Realities of the Known Universe.”“

From the second paragraph of Jason’s post (above):

“Besides the usual �but this won�t work in our company,� we had a good bit of people doubting if you can Get Real with clients. The answer is yes you can. We�ve done it plenty of times. It�s certainly not as easy as getting real on your own, but it is possible if you just give it a try.”

I’d like to point out that I really enjoy getting jumped on for making really moderate comments, so I’ll repeat my offence: 37s are providing a great counterbalance to overdocumentation with Getting Real (and for my vote, I’m about to buy the book), but in the general hype and hand-waving any reasonable spectator would come away from threads like this thinking Getting Real it’s the solution to every situation ever. What’s most interesting to me about this is the 37s assumptions about doing business. Like a certain level of trust between client and developer. Being assumptions, they don’t get talked about much, but I think they’re critical, so I’d love to see some coverage of these.

My mileage *does* vary. That doesn’t mean I don’t “get it”. To me, it means there’s still more to learn from this topic.

Aaron 05 Apr 06

Seems to me like you have never worked as a government contractor before that gauges your productivity by those deliverables.

Steph Mineart 05 Apr 06

When it comes to the “assumptions about a certain level of trust between client and developer” I think they cover that under the chapter “hire good clients.” Of course you have to get to a point where you can safely turn away business in order to pick and chose who you work for, but it’s possible to work your way into that position, just like these guys have done.

I'm With Stupid 05 Apr 06

“I�d like to point out that I really enjoy getting jumped on for making really moderate comments, so I�ll repeat my offence: 37s are providing a great counterbalance to overdocumentation with Getting Real (and for my vote, I�m about to buy the book), but in the general hype and hand-waving any reasonable spectator would come away from threads like this thinking Getting Real it�s the solution to every situation ever. What�s most interesting to me about this is the 37s assumptions about doing business. Like a certain level of trust between client and developer. Being assumptions, they don�t get talked about much, but I think they�re critical, so I�d love to see some coverage of these.

My mileage *does* vary. That doesn�t mean I don�t �get it�. To me, it means there�s still more to learn from this topic.”

I didn’t ‘jump on’ you. You stated, “A little more acknowledgement that this is aimed at a very specific sector with very specific requirements would help some sceptics understand why Getting Real seems to ignore the realities of their workplaces.” You seemed to be asking for something that at least 8.3 people ask for, each and every time 37s makes a ‘Getting Real’ kind of post and which 37s has repeatedly said, so I thought I’d provide the 37s guys some pro bono boilerplate to attach to each and every post they make. Ask and ye shall receive.

As for the other things, I guess that from your point of view (as a client), everything is about risk management. How much money do you stand to be on the hook for if Project X tanks? Will you still be able to get that next promotion if it does tank or will you be shuffled from Marketing over to, egads, Facilities Management?!? Will you get fired?!? Etc.

You’ve probably been burned by crappy developers before. So you put your trust in an iron-clad contract that specifies, to the exact pixel and hex color code, everything that will comprise a system (until, of course, your requirements change - and they almost always change).

How many times has that come off, without a hitch, without a change to the initial specification? How much time is wasted creating specifications for things that aren’t even used in the final system? How much more time is spent adding things that were missed 6 months ago when the spec was written?

As I understand them, the whole goal of ‘Getting Real’ and Agile Software Development is to cut out the cruft and get quality, working software into the client’s hands as quickly as possible. It is an iterative process and each iteration has as its goal the generation of quality, working software, not more flow charts, ER diagrams, and, as Jason called them, “trashcan deliverables.”

As for 37 Signals’ assumptions, it seems to me that they assume that they are going to treat their customers in a fair, honest, and open manner and they expect the same from their customers. It has been my experience that, people will generally rise to the level of your expectations of them and respond in kind to your treatment of them. My assumption is that their experience is the same.

Of course, everything I’ve said only applies to me, your mileage may vary.

Rachel 05 Apr 06

@Marko - see, the problem here is that we can’t dump them. They’re not “clients” persay. In theory we can say that we refuse to do something, but in practice, it makes cranky students complain to the student affairs director who gets cranky and in turn complains to the dean because they don’t want to listen to the students whine.

@Dan - Well, the issue is that we feel like we’ve tried the spec-less way with them and now we feel like the only way to get the project done is to nail them down. It’s no cost to them, and for whatever reason (students?) they are always okay with just saying “oh, well i guess it’s getting a little late for this to be done this year so maybe we’ll just put it off until next year’s group” and then the next group is either noncommital or completely disagrees with what we have so far or whatever. We’re at the point where we don’t feel like anyone will ever actually be 100% happy but that if we can just have an agreement, punch it out and be done with it, we won’t be relying on people to pick up where the previous people left off.

Our biggest problem, I think, is that our clients don’t pay for our services. Sure, someone is paying for our time, but it’s not the person we’re doing the project for. We really only have a time/quality leverage to work with, and it seems like once you get started with them, unless it’s really urgent they eventually forget that they originally wanted it done in a month and are asking for other things right and left. So, I can say that I can do it but it will take more time, but at that point they’re like “well, it’s already been a month so I guess I don’t mind another week.” I think people are typically very motivated by budgets and whatnot, and we don’t have that aspect breathing down on our clients.

And to the arguments - I don’t think that 37 needs to make a disclaimer, and i don’t think that it’s unreasonable for people to read their theories and say “wait, but…” because it’s unusual in our world…I think there’s a difference though between saying “wait, but here’s my situation and i don’t know if/how/where i can do that” or bringing up the pitfalls of the theory, versus just saying “that won’t work” or “i’m not allowed to do that.” Asking questions and presenting alternatives and questioning theories is how we learn from each other. Not to get all Brady Bunch, but as much as people say it’s tiresome hearing “I don’t know how to make that work” it’s also tiresome hearing the retort “just because you can’t make it work doesn’t mean it doesn’t.” I personally think it’s interesting hearing where everyone is coming from and how this is working or not working. Just my 2 cents.

I'm With Stupid 05 Apr 06

“Our biggest problem, I think, is that our clients don�t pay for our services.”

You hit the nail on the head. My main gig is similar, if not exactly the same, as your situation. The projects for which there is internal charge-back have clients who are much more focused on results and GTD than the others.

On the ‘arguments’:
There is a difference between asking ‘how does this apply to my situation’ and saying ‘this is wrong, it doesn’t work, my situation is special’.

The former seems to be seeking knowledge and communication. The latter seems to crave validation that whatever it is they are currently doing is the one and only right thing they could be doing and any suggestion to the contrary is just wrong.

Lately, there seems to have been a steady increase in the latter.

Uzi Shmilovici 05 Apr 06

I really appreciate the getting real approach but unfortunatley not all of our prospects and clients do. And it is a big problem, especially when our competitors offer all of those documents and deliverables.

Why do our competitors do it?
It is just another way of milking the client’s budget. More steps in the process > more deliverables > bigger budget and unfortunately corporate culture and politics are causing the corporate project managers to spend more money (so they will get a bigger budget next time and thus be more “important” in the corporate).

So it really depends who your customer is, and dealing with corporates ain’t easy as they expect those deliverables and event want them (for them it is a proof of work being done…)

We do take the getting real path, while developing a new exciting web app, but it is always much easier when you are your own client.

Roger Collins 07 Apr 06

Sorry to rustle feathers; it caused some to miss my point. I’m not saying don’t do “Get Real.” I’m saying from my experience, it is what developers already do naturally. We need to read a whole book (that’s a kind of documentation, you know) about a process that says “look at what’s there then do something,” and “don’t meet or document about it.” You need training sessions (that’s a kind of meeting, you know)?

Use documentation and meetings when it helps you be more effective; don’t use them when they don’t. Someone want to help me define a whole process around that? What shall we call it? Common Sense?

John 11 Apr 06

I really wish the resident interactive design professor at my college would be teaching this proposal method. Knowing that half of the 10-page proposal my group slaved over for our class & client was pointless isn’t very reassuring when I’m trying to convince myself that my money is being well spent on college.

Matt 13 Apr 06

I can imagine a world without “trash-can deliverables.” When I imagine this world, I get a big smile on my face. No arguments, it’s a beautiful idea.

I can also imagine how this works in a team of people, all working on a product which they define and which they will benefit from.

Where my imagination breaks down is in a client-driven environment. More specifically, the money. I’ve been designing for the web for years now, and I know that the majority of my clients, if presented with a product which was never defined, which was never discussed, which was never documented, would want to change things. They’d react as if their wishes hadn’t been fulfilled, they’d think of 100 things at the last minute which aren’t included but are absolutely essential. I know this phase occurs in every project, but at least with a clear definition the studio and the client both agree on how much is too much and how much extra too much costs.

The question for me then is how do you price a project which has “gotten real”? If we imagine the standard process in the studio where I work (lots of paper work at the beginning, workshops, discussions, then design and programming), would a “real” project cost the same due to less deliverables up front, but much more tweaking, changing, adding and so forth at the end of the process? Or is part of the idea of “getting real” to not online streamline process, but also reduce cost to the client? If so little is defined from the beginning, how does a “real” studio know when to shout “stop!” when the project’s at the end?

Lawrence Krubner 14 Apr 06

At this point, I’m confused. I thought that “Start with the Interface” meant that essentially the whole product is, in some sense, documented, you’re just starting with what it looks like, rather than a list of specs written out as text. The idea, I thought, was to avoid “appeasement documents” and get to something real as soon as possible. That makes sense to me. But designing a product or site without first agreeing with a client on any deliverable that’s been shared or discussed, not even a mock-up of the interface, makes no sense to me and seems to go against some of the better advice that 37 Signals gives.