Sanchmo at Technorati

Technorati Profile

The Belmont Club: The Consumer's Wizard War

Yesterday, Belmont Club's Wretchard bloged about the ongoing move and countermove between automation, privacy and criminal activity.

Applying Engaging Game Mechanics to Functional Software

ShuffleBrain's Amy Jo Kim blogs about social and game architecture. I don't remember how anymore, but I recently came across her presentation on applying game mechanics to functional software. It's an excelent read on using such game mechanics as Collecting, Points, Levels, Feedback, Exchanges and Customization to make functional applications more engaging.

iPhone: Revolution by Evolution

There are already enough blogs and articles out there about the pros and cons of Apple's new iPhone, lawsuits and trademarks aside. I'll point to some below. While the iPhone is revolutionary in a way, it's really more evolutionary. Just about every major feature has been around for a while. But to Apple's credit, they were the first to figure out how to put them together into a great solution.

• They finally replaced the hardwired keypad with more reasonable controls for a gidital device.


• They seemed to grasp how to use adaptive interfaces in a way Microsoft never figured out.


• They realized that a touch-screen is normally touched with the most powerful point-and-manipulate devices known to man.

Of course, since it is a revolution by evolution, that (hopefully) means it's better than what came before, but still not perfect. The most interesting discussion I think is Tog's view at The iPhone User Experience: A First Look. It is a very thorough review, with an interesting discussion of the amazing intuitability of the multi-touch screen and the history of the "pinch-spread" interface. (Shoulda patented, Tog). And Ryan Pearson's Everything's got a down side describes network compatibitily and storage expansion problems, and more importantly the longevity limits of touchscreen hardware.

The ECommerce Prenup

Tom Spring reviews his experience trying to cancel online services. It would seem that some etailers view their customer relationships as either "till death do us part" or as a hostage standoff. Either approach is pretty detrimental to trust or to good word of mouth.

Recommendation - if your business model includes subscriptions or regular reordering, give users an option of a one-time orders (you can always ask for another order later, say via email), very gently persuade them on the benefit of the subscription, and give them a "Prenup"that explicitly describes how to easily cancel. Sounds a little frightening to billboarders and dead-tree marketers, but if you do the conversion-rate math it will start to make sense.

Thanks to Mark Hurst at Good Experience for the original link to this article.

Mission Creep, or Second-System Syndrome, or Jumping the shark

The term Mission Creep originated in military and public service industries. In software development, it refers to the expansion of a system to a mission beyond its original objectives. Note that this is different from Scope Creep:

1. Scope Creep refers to adding new features or specifications to an previously defined project. For example, adding new bells and whistles - unanticipated by project management - to a shopping cart in an online storefront project, after the resources, schedule and budget have bet defined.

2. Mission Creep refers to changing the use of a system beyond that for which it was originally designed. For example, trying to transform a brochure-ware informational website into a transactional ecommerce website without revisiting system design, data and transactional security, performance requirements, etc. If you hear someone tell you "we already have a working website, we just need to add a shopping cart," you have a serious case of mission creep to contend with.

Credit again to Fred Brooks, who (IIRC) coined the term "second-system syndrome" and who wrote "Try to do everything and you will do nothing." Jumping the Shark is used in the entertainment industry to refer to the point when a successful TV series (or film concept or music group) runs out of good material and introduces "bigger and better" gimmicks instead. It specifically refers to the Happy Days episode when Fonzie jumps over a shark while water ski-ing in his trademark leather jacket. It is notorious in a film industry that so frequently relies sequels which are of poorer quality than the original. Unfortunately, there is not much literature that I've been able to find about effective control of mission creep in software programs. Maybe the entertainment industry can offer us some vauable lessons.

Brooks' Law

Fred Brooks' 1975 book, The Mythical Man-Month stated that "Adding manpower to a late software project makes it later." His famous analogy is that "The bearing of a child takes nine months, no matter how many women are assigned."

Brooks' Law is sometimes mistakenly taken to mean that more resources can't deliver a project faster. That was not what Brooks meant, although it is true - for each project there is an optimal staffing level that best meets cost and schedule targets. It is the job of a project manager to find that optimal level.

What Brooks meant was that it is critically important to find that optimal staffing level, and to start the project with that level, because once the project is underway it is prohibitively costly and time-consuming to add staff. Software development is a knowledge field, and bringing in new resources distracts existing resources from core project tasks. The more complex the project and the later in the project, the more of a negative schedule impact adding new resources. The lesson is that you should always start projects fully staffed (counter-intuitively, the strategy of adding folks as you learn more about your needs is less cost-effective than starting with more and streamlining mid-project), and also to be very careful if you do need to scale up.

A couple of good articles on this topic are Rick Brenner's The Cheapest Way to Run a Project Is with Enough Resources, and Scott Berkun's Exceptions to Brooks' Law.

Hofstadter's Law or The Planning Fallacy

Hofstadter's Law claims that "It always takes longer than you expect, even when you take into account Hofstadter's Law." Similarly, the Planning Fallacy refers to the tendency to underestimate completion times for complex and inter-related tasks. In my experience, the problem is not so much the underestimation of discrete tasks, but the underestimation of all other related tasks and events. For example, a project manager may accurately estimate the time required for a designer to complete 3 screen designs and the time required for a developer to implement those new screens; however, he will grossly underestimate the time and effort required for more "administrative" tasks like financial / justification analysis, project funding, time tracking, documentation, questioning of designs and assumptions by stakeholders, testing, user acceptance, rollout to production, sign-off and post-production project close-out activities.

In their paper "If you don't want to be late, enumerate," social psychologists Justin Kruger and Matt Evans concluded through various experiments that most underestimation occurs when individuals focus exclusively on core tasks and ignore related tasks. For example, in estimating time required to prepare a meal, cooking time is accurately estimated, but time to prepare ingredients, preheat the stove and set the table were not properly accounted for. They found much better results when study participants were asked to "unpack" multifaceted tasks - what we might call completing a thorough work breakdown structure.

I have an rule of thumb for creating initial, lightweight project SWAGs (Scientific Wild Ass Guesses) that has worked well for me over the past several years. I call it the "Work Times Three" approach:
1. Make an initial estimate of the core work and time involved in a project - requirements gathering, design, development, testing.
2. Multiply that by three.
3. The result is an close aproximation to actual time-to-completion, starting at project approval, that can be used for early decision-making.

I've used a factor of three successfully in the past, but anything from 2 to 4 can be good multipliers based on your organization and project. The multiplier you use should be based on the following risk factors:
a) More project complexity (number of discrete requirements and specs) = higher multiplier.
b) More uncertainty (requirements, specs, available resources) = higher multiplier.
c) More personnel means more communication and administrative overhead = higher multiplier.
d) More functional groups (IT, marketing, etc) = higher multiplier.
e) More organizations (contractors, vendors, partnerships, etc) = higher multiplier.
f) Less familiarity with project type, technology or processes = higher multiplier.

So, if I assume that the core labor required for a project is approximately 4 weeks, but that 3 internal functional groups and a new vendor with new software will be required, my initial SWAG may be 4x3 = 3 months from the initial "OK to proceed" to completion.

Of course, at some point you have to do a detailed bottom-up estimation or plan. The trick again is to sufficiently account for non-core tasks (documentation, approvals, testing, holidays and vacations, customer rollout, etc), and to sufficiently account for lag-time between tasks.