This week in the pm-clinic discussion forum: Topic #53 - The fate of acquired teams.

Dear pm-clinic,

Your assignment, should you choose to accept it, is to assess a new project & team. Your job is to provide input on whether the team should be funded or should be killed, and it’s resources assigned elsewhere. What questions do you ask? What are your metrics? How much time would you need? How would you want to report your results? (As one specific example, imagine a project team that was acquired through acquisition).

- A tired man in an airport

Posted in Management, Software/Web development | No Comments »

This weekend was the first seattle mindcamp: a seattle version of the O’Reilly FOO camp and Bar camp. I’ve been to a few of these semi-self organizing events before, and here are my notes:

Highlights:

• The seattle tech sector lives. There are few open get-togethers in Seattle for tech sector folks, despite the size of the industry here. It was telling how easy it was to get 150 people to sign up for this event, and it’s embarassing that no one had done it before (Kudos to Andru). A few people mentioned idea day, which I haven’t been to yet. Thanks to all the organizers and volunteers.
• High quality sessions. There wasn’t enough time: I missed good sessions. The mix was good: less tech-centric than the last FOO. I threw myself in the middle of things, and got involved in 3 sessions, but that meant I didn’t go to many others. Ario, Joe and I did one on leading software teams (we met through the event wiki), I did a solo on why smart people defend bad ideas and ran a UI critique session with Mr. Richard Stoakley Thanks to windowssecrets.com , teachtown.com and others for letting us critique their sites in front of a crowd.
• Show and tell of ideas . Everyone had something to show or talk about, and the informal vibe made it easy to share. I spent a half hour chatting with Andy Edmonds about browser design and software instrumentation. Learned about the Firefox Attention trust effort from him as well. I saw live demos of gada.be, Ruby on Rails, a choose your own adventure DVD and two good sessions on information overload and web annotations by Ario. Given the number of sessions it was easy to bail on anything that bored me.
• Left with a mental buzz. I heard so many different ideas and passionate people that my head spun for the next 24 hrs. It’s easy to forget how stimulating it is to meet new people who are passionate about what they’re doing.

Lowlights:

• Wireless didn’t work. I felt bad for the folks who talked for 10 mintues at the start of the day for how they set up the wireless system (and how cool it was). After a few hours of everyone failing to get it to work, those guys were hard to find: it wasn’t their fault, as the building had less bandwith than they were told. It turned out ok: I was glad people had more reasons to close their laptops and talk to each other.
• Little incentive to stay overnight. The Sunday morning schedule was weak and there was a no alcohol rule: two strikes against staying. The building was huge which also hurt the stay overnight factor. Many folks I met left by 1am (myself included). I came prepared to stay over, but I couldn’t make a good argument for it.
• Some first time event mistakes . I used to run training events and I’m familiar with how hard it is to get it right. On the whole they did well. My notes: many had never been to a self-organizing event before and had no idea how to prepare or what to expect (Lots of “I would have brought X” or “I could have talked about Y”), the directions were confusing (even at the complex itself: there were no signs outside) , there was no phone number for people who got lost and the website didn’t help people hook up before the event (Something FOO did a good job of with photos of everyone up on the site and at the event itself).
• Post event value opportunities being missed. There was talk of capturing as many sessions as possible, but I have no way of knowing if that happened. The Seattlemind website and wiki hasn’t been updated since Friday. Everyone’s understandably exhausted come Sunday, but there’s time now to collect slides from all presenters, roll together lists of podcasts, etc. If nothing else it makes it easier for folks to prepare for Seattle Mindcamp 2.0 .

Suggestions to future Foo/Bar/Mind camp organizers:

• Have a “First time at camp?” FAQ . Make it easy for folks to understand exactly how to prepare and how different it is from regular confererences. Don’t make up the FAQ: ask people who just went to their first one what they were confused about and what they wish they’d known before they’d arrived (Don’t codle them with detals but get them over the hump). I’d write it if someone would use it.
• Encourage pre-event connections. Name tags are not as good as faces. When people sign up, ask for a URL for a photo and include it. Also, many sessions listed on the wiki didn’t happen: why? not sure. There was plenty of room late Sat and Sun morning. There was just no supported way to tell those people before they event I was interested in their topic. The wiki/website made it hard to dig up e-mail or contact info for other people.
• Have a single primary pre-event news and update feed. In the days before the event it was hard to find details on updates and changes. There was the seattlemind website blog, personal blogs of organizers, the main wiki page, the session_ideas page, and various other child wiki pages. Instead, make it easy to track news, requests and updates in one place to fuel the self-organizing process. This same primary feed should be the way to get post event news (podcasts, slides, etc.) as well.

Posted in Teaching/Training | 7 Comments »

Slashdot linked to an article on History’s worst software bugs. It’s a short and darkly entertaining read that makes us feel better about all the bugs we’ve all shipped out to the world. We’d never make anything that bad, right?

Wrong. The difference between these stories and 90% of software developers is the context of the work. Few of us work on medical equipment, anti-lock brakes or nuclear weapon arming devices. We don’t work on things with the potential to kill or cost $100 of millions. For most of us, if we employed the same development practices we do on a daily basis on a mission critical project, we’d make this list in no time. The difference between us and them isn’t skill: it’s domain.

Another problem with articles like this one is that they offer little to learn from. It’s to easy to laugh at how stupid the mistakes seem and gleefully return to writing code. These lists tend to give us unfounded confidence that it’s our approaches to work that makes us immune from these kinds of mistakes, but that’s not true.

Worse, unlike other kinds of disasters, such as airplane crashes, medical errors, or building collapses, few of these worst bugs in history have publically available analysis of why they happened and how we can avoid similiar mistakes.

Learning from the past is not a strong part of the practioner software development culture, and it’s a shame, since we repeat the same mistakes again and again. Understanding landmark failures is an integral part of most engineering disciplines (See Petroski’s To engineer is human: the role of failure), is not yet part of the software development culture, but it needs to be.

It’d be great for every CS major to study one of these software disasters before they graduate and understand something about how failures really happen before they start building things as professionals. Back at CMU the only course I took on engineering failures was in the humanities school (and it may have been the best course I’ve ever taken).

Here’s some resources for learning from the mistakes of others:

• Risks list. A monthly catalog of reminders of how fragile technology is. People submit stories of potential mistakes and recent failures with emphasis on understanding and avoidance. Cuts across many technologies and businesses.
• Learning from software failure. Excellent magazine coverage of how to pull lessons out of historic failures. Three case studies on major software projects that went wrong and what can be learned from them.
• Why software fails. My favorite essay from the above magazine issue: distills lessons out of the previously mentioned case studies.
• Digital woes. A book of 13 stories of software disasters, written for a layperson audience. It frames each disaster in a social and engineering context and has recommendations for people that are starting new projects. Highly recommended: easy read.
• Fatal defect. Similiar to Digital woes but different examples. Also well written.
• Primer on software testing. I’ve come to hate the word “testing” as it implies you fix software after it’s written - but this summary of techniques is a great refresher for anyone that’s writing code. It’s a reminder of how much is known about making quality software that most shops never even think to put into practice.

Anyone have any references I should add? How do you learn from the failures of others? Your own?

Posted in Software/Web development | No Comments »

On Thursday 11/10 I’m down in Portland, OR speaking at the Rose City SPIN group at 7pm (details & directions).

If anyone in town wants to meet up for dinner ~5pm, let me know: leave a comment here.

Posted in On Tour | No Comments »

This week in the pm-clinic discussion forum: Topic #52 - The joy of team rivalry.

I’m a team leader on a project chartered with rethinking how rss/blog newsreaders work. It’s a good team (Team A), I love the problem space and things are good. My problem is that there is another team (Team B) that is trying to solve similar problems, but from a different direction. No one has said outright “you are competing with each other” but it’s pretty clear the designs each team has are on mutually exclusive paths.

How do I balance the conflicts of interest? Ho do I treat team B when I talk to them? Is it appropriate not to share all of our plans? What do I tell the members of my team when they encounter people from team B?

- Signed, The joy of rivalry

Posted in Management, Software/Web development | 1 Comment »

Feedshot.com

Summary: this isn’t a site as much as a dialog box for a service. Two buttons and four fields. Should be a piece of cake. But some layout issues and seperate of control creates a few stumbles. 6 of 10. (Would be a 7 but degree of difficultly here is low).

Core tasks:

• What is this for? There is a basic question of purpose here: what does this site do and why should I care? there is a link at the top that says “how is this different from pingomatic” but what if I don’t know what pingomatic is? The blog at the other end of that link says “FeedShot is a blog feed submission service, submitting your RSS or Atom feed to a large collection of search engines and news services with the click of a button.” A short version of this description should appear on the main page.
• The value proposition. Another mistake here is in approach. The value to me isn’t the technology: it’s traffic. The tagline shouldn’t be “56,000 submissions sent” but “56,000 feeds enhanced” or “56,000 feeds now with more traffic” or something that gets at the value, not the technology. The link should say “How feedspot advertises your blog for you. “

Basic layout:

• Layout needs cleaning up. A common mistake with form UI is to ignore how eyes work. We like scanning lines. The fewer lines you can group together, while keeping line length short, the better. So here’s a before and after:

  
  

• Confused control. The group boxes of the UI implies that functionality is seperate, which it isn’t. After filling out the form I have to click one of the submit buttons. It takes a few seconds to sort this out, since the two buttons, which do different things, are labeled the same. The decision buttons should be moved into the form, as shown here.
  
• Further cleanup. It’s possible to go further: Why have two buttons that say the same thing? You could put the meaning into the buttons themselves. The challenge is that black on grey doesn’t look so good for sentences: $3 for 25 may not be easy to read as a button, but If it were me I’d do some mock-ups and give it a try.

Posted in Design, ui review, usability | 6 Comments »

Sadly these critiques (in honor of world usability day) were delayed due to someone hacking the forums on my site. I’ll be getting to these queries over the next week as I recover some time.

Seattle Children’s Hospital

Summary: Nails the basics. It’s clear that most decisions made were done with care. The design has a clear audience in mind and carries through a consistent set of design concepts and elements, however there are some lapses and gaps here and there. Overall score: 7 out of 10 (just shy of an 8).

Core tasks:

• The good and the bad. It’s impossible to critique a design without some understanding of what it’s supposed to do, and who it’s for: especially a large site like this one. But this design does what good designs do: the front page tells me what the designer thinks the core tasks are. The right most column lists (what appear to be) some of the most frequent tasks people have. However, why are they on the right? The U.S. crowd reads left to right. Making this change breaks up the composition, so it doesn’t look great with my 5 second photoshop treatment, but that’s a direction I would go with (Among other things you’d have to change that arrow glyph to something else).
  
• Physician finder easy to use. I dug in here and poked around. Piece of cake. It was easy to pick a location and a specialization and get a list of docs. Search results pages were clean. My only gripe is that that no medical site in the universe has reviews from patients: referals being the most important thing for many parents in picking doctors.
• Donations and Gift shop. The interior leaf pages are nice and clean: easy to find my way and fill out the forms. The gift shop UI was good: I could pick gifts to send to guests. The only downside is that once inside the gift shop, the main navigation goes away. I have to hit the logo in the top left to return to the top: no other way to get back to the navigation (-5 points for that).
• What are the key needs? I spent some time in the health care advice and services sections, but if this were a critique for hire I’d be spend more time thinking about core/frequent behavior. There are clearly other core tasks worthy of exploration, but it’s time to move on.

Navigation:

• Mostly consistent hot track. Most navigation items, such as links and buttons hot track (mouseover) to white. But some don’t. The primary navigation at the top doesn’t have any mouseover behavior at all. This should be consistent. The impact is minor though: so many sites jumble up mouseover & link behavior that most people can figure it out.
• Tabs + breadcrumbs? I wasn’t sure the breadcrumbs were needed, given how clean and simple the tab navigation is. It seemed redundant, especially when pages had a graphic underneath the tabs.
• Section colors don’t unify the site. It’s clear that the colors for each sub-section of the site were chosen with care: they’re equally saturated tones. But the change between each subsite is strong enough that for a moment it feels like you’re gone to a different site altogether. Those colors should come through into the main navigation on the home page: either those are the colors for those sections or they’re not.

  
  

• Here’s a quick mock up of the main nav with consistent colors:
  

Aesthetics / Layout:

Linespacing and links can be cleaner. Although the color and style choices are good, there was some room for cleanup. First move was to make better use of the title space by moving Calendar and News to the top. Then, a rule: all headlines fit on one line. This always makes things easier to read. You can see in my tweaked version B it’s easier to skim. You could go further and experiment with moving the date into the link itself.

Other comments and nitpicks:

• Title is not the place for marketing. The site title is “World class pediatric health care from…”. Not good. This title string is what will appear in user’s bookmarks. It should be like a phone listing: terse. “Seattle Children’s hospital” is perfect.
• Title lengths. The titles grow on sub pages: even one level down they grow to more than 80 characters long. Who is going to read this? There’s no need to track the site hierarchy in the titles. All you need are two things: A short tile for the page and a short slug for the the site itself (and in that order).

Posted in Design | 1 Comment »

In honor of world usability day, here’s an essay that examines the causes of bad designs, and offers advice on avoiding them.

Why ease of use doesn’t happen

Posted in Design | No Comments »

Still seeing some reviews come in which I’m grateful for, 5 months after the book has been out. Most folks don’t know it but the window for books is small: if it’s not picked up in reviews soon after publication, odds are slim anyone will ever even hear about it.

My own interests aside, any time you write a blog post or amazon review for a book, it makes a huge difference to us authors. Even if sales don’t follow, it’s super validating to any author to hear the book meant something to someone. I hope to write more book reviews myself here.

MSDN Magazine had a short review of artofpm:

Scott gives you project management concepts in simple steps, using lots of examples of successes and failures from his own experiences, and he is always considering the “people” factor. With all the emphasis on tools and process that we have today, it’s refreshing to see a book on project management that spends as much time on human factors as it does on technical tools and metrics.

This book is a candid and honest piece of work written by someone who has really been there, done that, and is willing to share.

Boxes and arrows, a webzine about information architecture and UX, had this review:

This is a comprehensive, how-to book devoid of jargon and theory. The author gives direct advice from his own experience. The real value of this book, though, is that it is not about a single methodology for project management, nor is it just for project managers. Instead, Berkun is able to speak about project management at its highest-level without filtering it through a given approach. It is deep enough to keep seasoned project managers reading, but also appealing to non-project managers. I’d recommend this book to anyone looking to improve general project skills.

Posted in The Art of PM book, artofpm reviews | 1 Comment »

Tommorow is the first annual world usability day. Free events all over the world are taking place to promote ease of use and good design in everything.

I’m surprised not to see more events in the SF Bay area or Seattle (Nothing at Microsoft, Amazon.com, Zaaz, Blink, Real, Saltmine, Adobe ?) so I’ll do my part:

I’ll do 100% free expert reviews of the first 3 websites people submit in comments (I will likely do many more but I can only promise 3). It can be your website, your company’s, a site you use or something you think would be interesting (or entertaining) to have me critique.

Update: About ten in already but do keep them coming. I will do as many of these as I can tommorow and more over the next week. It’s not too late.

Posted in Design | 27 Comments »

Whenever data is misused as the only means for making decisions, a death spiral begins. The lust for data overwhelms all sensibilities. Cowardly decision makers howl in glee at reams of unnecessary data, while bright people sit handcuffed to ugly slidedecks and mediocre ideas. Decision makers forget their brains and wait for numbers, fueling an organizational addiction to unnecessary and distracting data.

Data is good: it dispels ignorance and raises questions, but it has its place. Data doesn’t make decisions or come up with good ideas: people do. As soon as you discount people in the name of data, the downward spiral begins.

You know you’re in a data death spiral if:

1. Confusion over what the hard part is. If you are working on anything challenging, data will only define the landscape. It won’t dictate a particular strategy: good data has different interpretations. If you present data to justify a decision you are emphasizing some data over others: which is an act of creativity and opinion, not fact and figure. Opinion is everywhere and is most dangerous when it’s hiding behind spreadsheets.
2. No opinions are considered without data. Opinions are good if they come from smart thoughtful experts. If you are in a world where you, as an expert, can’t make obvious improvements without 10 pages of supporting material, guess what happens? Nothing happens. People spend all their time defending the obvious and the scale of work, and the energy to improve, drops dramatically.
3. Creatives are hiding in the corner. (Good) Designers and other creative people know how to make things. Lots of things. They experiment and explore. When used properly they are a piston of progress. But if the landscape is data and analysis obsessed, creative types are relegated to refinement work, the least leveraged use of their talents. The team gets a fraction of their possible value.
4. No one questions data. Not all data is the same. To collapse data down into “70% of our customers prefer green” requires several layers of simplification of the truth. Which customers? What alternatives were they shown (were there just 5 kinds of green)? How many customers were there? If no one every questions the data and understands its nuances the gates are open for people to throw more misinterpreted data at each other. You need data quality not just data volume.

How death spirals start

The spiral begins with ignorance. Leaders confuse the collection of research with thought. People who throw more data (not better) at problems are rewarded and others follow. Soon no idea can be suggested without a data armory. Meetings are data battlegrounds. Or worse, data massacres. When someone says “Morale is low. People are crying in the halls. We must do something.” another says “but where is your data?” and the conversation ends.

As the spiral bottoms out, people are proud of numbers and slide decks: not the results.

Steps to preventing death spirals

1. Separate good data from bad. Good data self describes its biases. A smart person uses data with consideration for what things the data can’t tell you, and they include this understanding in their story. Encourage people to play devil’s advocate on their data and make data inquiry part of the discussion any time data is presented. Diffuse data obsession.
2. Data and ideas are partners. Make sure developments happen both ways: ideas that are pulled out from data, and ideas that come from minds, with supporting data found later. At its best it’s an itterative process: you have ideas, you research data, you refine ideas, you research more, etc.
3. Instincts matter. The Gladwell book Blink explores how our instincts serve us: are the instincts of your group serving you? Layers of process and data bury our hearts. Some people have better instincts about certain decisions and you want to harness that talent, not dilute it. It can be fine to say “Fred has the best perspective on this. It’s his decision.” And allow Fred to define how much or how little research is needed.
4. Let go of the fear. Many people collect data to defend their choices should things go wrong. When bad things happen they point to the data and say “See! We did the right thing!” despite the results. This kind of paranoid, self-protective thinking weighs on a team: instead of ensuring success, people are protecting their asses. Most of us can smell it when a leader is in this mode and it puts the entire project on its heels. Insurance is for the birds: A good manager earns the trust of his team and lets them know that even in failure, he’ll take responsibility for what was done.
5. Kill contrived group think meetings. Data obsession and consensus-driven teams go hand in hand. It’s on big, cowardly teams with leaders who demand everyone agree before decisions are made that people show up armed to the teeth with handouts and marathon presentations. Not everyone needs to agree to everything. Define who is in the best position to decide and give them the power. If necessary, pick a handful of people who disagree to go off and fight it out in private, reporting back when a decision has been made.
6. People are better than data. Much of a person’s talent is difficult to capture in numbers. Their experiences, instincts and passions all factor into what makes them good at what they do. As a manager, I want to make sure I have channels open to these assets, channels that don’t require the same kind of data in order for me to listen. If I shut these things out, I’m denying myself the benefits of true expertise. If I’m working on something hard, and with tight deadlines, the more good decisions I can have my team make without days of research, the better off our team will be.

(See also How to lie with statistics and Chapter 8, how to make good decisions, from the Art of project management)

Posted in Management, Software/Web development | 2 Comments »