Category: Productivity

Monday, 2 May 2005

What is Failure?

by Garrick van Buren Comments Off on What is Failure?

The other day, I was talking with a software engineer about a potential project. During the conversation, he asked if I was ever on a project that failed.

“Failed?”

I’ve worked on thousands of projects and given that more than 50% of project fail. I asked for a definition.

“The project didn’t launch,” he responded.

Given the complexity of even the simplest project, software or otherwise, it still seems like an odd question. The gestation of any project requires a commitment of time and effort – at any point, some external force could (and frequently does) warrant an end to the project. An engineer at Edward’s Air Force base even declared this a phenomenon a law.

All this assumes the project was a good idea to begin with. I’ve been on projects where it became very clear the project was doomed. Bad idea from the outset. It just took a little while to figure out exactly why.

Is this failure? I don’t think so. Especially if “failure” was found quickly. In the long run, stopping a project mid-stream saves time, effort, and probably a reputation or two. The trouble comes in when, despite all the red flags, the project continues onward. Unstoppable, yet acutely aware of the impending demise.

Measuring a success by whether or not a project saw the light of day is like judging how good your day was based on the thermostat reading. It’s just one of many factors.

I think a more interesting question would be, “Have you ever been on a project that succeeded.”

ELSEWHERE 28 Dec 2007:

Testing leads to failure, and failure leads to understanding.” – Burt Rutan

Wednesday, 27 April 2005

Productivity Tip: Empty Your Dock

by Garrick van Buren 1 Comment on Productivity Tip: Empty Your Dock

Back in the pre-OS X days, I used DragThing religiously to keep applications, websites, and documents at my finger tips. That mentality migrated with me to OS X – put everything in the Dock, keep it handy.

Today, I shed it.

Inspired partially by my preparation for the Tiger upgrade and partially by my proficiency with QuickSilver, I’ve emptied everything out of the doc. Only the Finder and Trash are persistent. Everything else, in when in use, out when not.

Even in the half-a-day I’ve made the change, I feel less distracted and more focused. Fewer temptations by Mail (finally a way to turn it off), IM, and NetNewsWire. Plus, I’m more aware of which applications I’m using and what I’m using them for.

Here’s a special half-tip for you (this one, I’ve been using as long as I can remember). Set your desktop to a solid, neutral color – I’m partial to OS X’s ‘Solid Grey’. This way, colors will shift less when you’re trying to find the right hex value and there’s generally less visual noise.

Sunday, 17 April 2005

Greater Productivity By Turning Things Off

by Garrick van Buren 1 Comment on Greater Productivity By Turning Things Off

A couple weeks ago, I was having a tough time focusing. The culprit turned out to be a little red dot in my NetNewWire dock icon – the unread post count. I’ve unchecked that count in the preferences and my ability to focus has increased (Manton Reece did the same).

First, biologically, our peripheral vision is more sensitive than our direct vision. Second, our eyes are highly sensitive to the color red. Needless to say, tiny red dots arbitrarily showing up in the corner of computer screens are highly distracting.

Next step, find a way to turn off Apple Mail’s unread count.

Wednesday, 16 March 2005

An Unexpected Yak Shaving

by Garrick van Buren 2 Comments on An Unexpected Yak Shaving

One of the bathtub faucets has leaked for a couple weeks. Monday, I could no longer ignore it. That same day, Seth Godin introduced me to Yak Shaving.

yak shaving: Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on.

Tuesday, I headed to Home Depot for a replacement faucet stem seat.

According to the helpful Home Depot associate, great strides in faucet technology have been made in the 50 years since my bathroom’s was built (the faucet’s obsolete). He recommended I find a Plumbing Supply Specialty Store for the parts or pick up a new faucet. I opted for the new faucet.

Today, the Yak is clean shaven, er, the leak is gone.

Follow along if you will:

    Day 1:

  1. On Home Depot Trip #2 Jen and I pick up a new faucet.
  2. The old faucet framework wasn’t persuaded by the monkey wrench. It was however persuaded by Mr. Pipe Cutter. Unfortunately, Mr. Pipe Cutter left bare copper tubing rather than the more useful copper tubing + threading.
  3. Home Depot Trip #3 brought compression connectors adding threading to the bare copper tubes.
  4. With the faucet framework attached, it is obvious the old holes aren’t big enough for the new stems and the hole for the tub faucet is about an inch lower than the pipes will reach.
    Day 2:

  1. On Home Depot Trip #4 grab a 1 3/4″ hole cutter for the newer, bigger holes. (Where’d I put the power drill’s chuck wrench?) and a couple of pipes to reach the faucet hole.
  2. With the new holes drilled and faucet installed, I notice the faucet stem lengths don’t accommodate the wall between the plumbing and tub.
  3. Here I ponder tearing out and replacing entire the tub, surround, and wall. Instead…
  4. Mr. Hacksaw and I cut two copper tubing-size channels out of an offending 1×4, proving just enough space to connect the handles.
  5. Handles installed. Faucet installed. Leak ended. Mostly

Update 19 Mar 2005
My dad came by today and looked at the repair. Looks like I got it mostly right. Just needed to be more liberal with the teflon tape. Thanks dad.

Walking into this, I had no intention of shaving a yak. Nor did I anticipate replacing a small bit of formed metal would take 2 days. On the outset, I expected 2 hours, max. That reminds me, here’s a special bonus thought of the day from David J. Anderson: Stop Estimating.

Something takes as long as it takes. ETA isn’t known until you’re deep into understanding the problem you’re solving (i.e. doing it). In physics, there’s the Heisenberg Uncertainty Principle principle: you can know a particle’s velocity or its precise location. Not both.
Let’s say ‘velocity’ is ‘doing’ and ‘location’ is ‘planning’. So, to rephrase; You can do or plan. Only doing will give you an ETA.

Tuesday, 8 March 2005

Making a Decision is Always Better than Not.

by Garrick van Buren 1 Comment on Making a Decision is Always Better than Not.

Yesterday, I grabbed a coffee with one of the smartest people I’ve ever met. We were talking about project teams wallowing in the unknown and stalling out. He proclaimed:

“Just put a stake in the ground and move on.”

His recommendation reinforces Charlie Lazor’s advice, “You really won’t know until you build it.”

Both of these thoughts require an acceptance of being wrong. An acceptance that the first solution, based on what is currently known, just might be faulty. The only way to find out is to build something and get more information – either from the customers, the technology team, or the prototype itself.

Every instance I’ve seen where a project team wasn’t able to easily define an interaction was due to lack of information. Similarly, every instance I’ve seen where defining an interaction has reached Heated Debate, the available information was faulty. A quick call to a customer or developer diffused the situation immediately.

Monday, 7 March 2005

Overtime Hurts the Everyone

by Garrick van Buren Comments Off on Overtime Hurts the Everyone

Late last week, a client and I were discussing a struggling project. The client mentioned his project team regularly works nights and weekends to meet the deadlines he had scheduled. I was stunned. This was months into a years longs project.

    There are 3 things fatally wrong with this management strategy:

  1. It devalues both the worker and the work.
    If the work doesn’t need alert, well-rested, and focused people – a machine should be doing it. Conversely, if the people don’t need to be alert, well-rested, and focused to accomplish the work – they’re on the wrong assignment.
  2. It hides the need for additional people and better tools.
    Regularly working overtime means there’s demand for more people and the company would rather exploit their existing staff than fill the demand. Productivity actually decreases throughout the day and after long enough, turns negative. This work-longer mentality keeps helpful people unemployed while others are overworked – both cases destroy health and families.
  3. It hides the need for realistic project scheduling.
    We all may be able to work faster, 9 women can’t have a baby in a month. Things take as long as they take, regularly working overtime hides this fact. Putting lower-quality time (overtime) into project introduces more defects, actually prolonging the project.

For other arguments against overtime, crunch time, and aggressive planning, I recommend:

Monday, 21 February 2005

You Really Won’t Know Until You Build It

by Garrick van Buren Comments Off on You Really Won’t Know Until You Build It

I caught Charlie Lazor, talking about building furniture and houses at the University of Minnesota this evening.

I found this quote on prototyping invaluable:

“We spent so much time arguing whether or not it work, and when we prototyped it, it worked remarkably well. We could have saved so much time, if we had just built it sooner.”

My full write-up on his talk can be found at: Your House as Furniture.

Thursday, 25 November 2004

More Slack Keeps Projects on Track

by Garrick van Buren Comments Off on More Slack Keeps Projects on Track

Plans are worthless, but planning is everything.
There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of ’emergency’ is that it is unexpected, therefore it is not going to happen the way you are planning. – Dwight D. Eisenhower

Swap in “project” for “emergency” and Eisenhower’s statement is equally as true. Yes, projects are as unexpected as emergencies. If all the variable of a project were known ahead of time – processes, timeframes, resources – the project would already be complete. Projects are in fact the process for answering these questions.

When I was working for a WiFi startup a couple years back, my product manager spent a good chunk of his days in Microsoft Project. Every day, he would tweak the Gantt charts to reflect the current state of the project, and print out the revised plan.

Then as the plan came off the printer, some new information would arrive making the new plan obsolete.

Lately, I’ve been involved in a number of enterprise software projects all at the early planning stages. Project 1 is starting with a Gantt chart. Like all Gantt charts, it depicts a tiered, linear, hand-off process. This is inherently ineffective.

A more effective, collaborative, and true-to-life model is a weave [WorkingPathways_ProjectWeave.pdf]. The pdf illustrates the weave model I helped a design agency work towards.

Another effective planning model comes from Frank Patrick and has traction in the Agile Software development community: the Hurricane model for predicting uncertain futures. The crux – we know where the project is now and some notion of time it takes to get in any direction, but we don’t know exactly where the project will be at that time. That’s the classic quantum mechanics trade-off: you can measure velocity or precision. Not both.

The most effectively run projects I’ve observed are based 2 principles;

  • Slack:Project schedules should have 2 forms of slack built in – 1 day per week and 1 week per month. Only schedule work for 80% of the available time. That’ll keep the schedule flexible enough to adjust for all the unknowns you’ll discover along the way.
    Read more on slack in the excellent book Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  • Keep a loose association between work and resources:
    Define the pile of work and define the members of the team. Don’t define it in any more detail than that.

I think Steve Pavlina sums it up nicely:

“No plan survives contact with the real world.”

Monday, 18 October 2004

Success Comes in Small, Cheap Projects

by Garrick van Buren Comments Off on Success Comes in Small, Cheap Projects

Instead of spending milions of dollars on “The Superbowl Ad”, why not spend that money cranking out beermat campaigns, till you find one that really works? Using beermats in small, test markets, you could easily create 50, 100 (500? Who knows?) campaigns for the price of one decent Superbowl/TV commercial. It would be a simple, cheap and quick way of working out the necessary language to resonate with the beer-drinking public. – hugh @ gaping void

I met a art professor in college who believed everyone had 500 bad drawings in them. Only after getting the 500 bad drawings “out” would you start drawing well. Some professors asked their students to complete 1 or 2 drawings in a 3 hour studio. This professor – 50. Fifty drawings, each from 5 to 20 minutes a piece. Each one to find out what works and what doesn’t. No erasing. If you’re not happy with it, start a new one.

This quick and cheap way to success stuck with me and is one of the underlying principals of Working Pathways. We’re continually asking, “What’s the simplest, quickest, most effective way to reach the project’s goals?”

With this perspective, we’ve reduced turnaround times for some of our client’s research initiatives from weeks to hours. We solicit feedback continually. We provide long-term ‘teach a man to fish’ success.

We’ve all got 500 bad ideas in us, Working Pathways is here to help you get to the good ideas more quickly.

UPDATE: This notion of small, quick, projects paving the road to success is re-iterated by Robert Rodriguez,

“The more experience you give yourself the better prepared you are for the next project…”

This by way of Anita Sharpe’s Thought for the Day, Tuesday, October 19, 2004

Sunday, 3 October 2004

Once More, In Half the Time

by Garrick van Buren 2 Comments on Once More, In Half the Time

I apologize for the length of this letter, but I didn’t have time to make it shorter. – Mark Twain

Twain was referring to the fact that refining something down to it’s essence takes iteration. Each iteration abbreviates the time necessary to produce and consume the item. I offer the Van Buren Law of Iteration:

t^n = (t^(n-1)) / 2

Where; 

t = time for a given task

n = the iteration

I’ve written about the similarity between collaborative work and Improvisational Comedy before (Stop Asking Questions, Yes, and – not But, Want Better Collaboration Improvise). In this installment, I’d like to discuss the the Improv training game Scene Replay.

  1. Start a scene.
  2. Improvise for about 3 minutes.
  3. Replay entire the scene in half the previous time.

With each successive repetition, more of the uninteresting bits are automatically edited out and the scene becomes more engaging and entertaining. The first attempt takes the longest because those involved are discovering what needs to happen. After the third and fourth attempts, everyone knows what works, where the engaging parts are and the transitions between them. The same procedure works for any type of knowledge work.

Think of a small work-related disaster, an unsaved file getting corrupted – and becoming unsuable, for example. Revising the document again, will take far less time than originally because you know exactly which changes to make. You can cut out all the unsuccessful bits – getting to the good stuff, making it better, and getting done more quickly. The thinking parts are done – it’s all about execution now.

How do you implement the Van Buren Law of Iteration?
A quick way is the following exercise:

  1. Take 5 minutes to tell a good – patient – friend a story.
  2. After you’ve completed the story – tell it to them in 2.5 minutes.
  3. Repeat until you can tell the entire story in a single sentence.