On Software Imagineering

Traditional software lifecycles required long phases for product definition, design, development / implementation and release / rollout (e.g. Microsoft Vista, mySAP ERP). These assumptions have been challenged by hosted software providers, perpetual BETA services like Google, and the guiding principles of Web 2.0. That doesn't mean software lifecycles are history, as you find people in this "new world" responsible for the "old jobs" but in new ways how to make this work faster, with better ROI and desirability by the users served.

Software imagineering is not a new discipline or methodology, but evolution of software imagining / definition and engineering / architecture in an era when time-to-market is as important as the quality / robustness of the service offered. The term imagineering has been coined since 1957, after Walt Disney Imagineering was founded. Taking the basic principles of Disney and applying them in the software lifecycle phases, following user-centric design with Web 2.0 principles in mind, is what Software Imagineering can be about.

Why Software Imagineering is different or better? The best example of what it takes to be an Imagineer I have found is in the IDEO method of delivering innovation that simultaneously examines product desirability, viability and feasibility.

Imagineers are the ones who can collaboratively (dis)cover the:

• Human needs (desirability) by asking questions like is it useful, is this the simplest solution to get the job done, does the solution show empathy for end-users?
• Business needs (viability) by asking questions like what is the ROI, does it make us profitable, what is the business case?
• Technical needs (feasibility) by asking questions like do we have the right resources and skill set to implement this, does this fit into the current architecture, how can the solution be configured / supported / maintained?

SAP is placing tremendous focus on this way of thinking regarding innovation and design, also evident externally with Hasso Plattner's Institute of Design at Stanford University (see press coverage). Teams and imagineers are now tackling the design and engineering phases while constantly iterating, (re)designing, staying in touch with users and understanding the way they use the software. I can speak from a personal experience, making a career shift from an Engineering role within Development into Strategy role within Product Definition has also made a world of difference in how I "imagineer" the new solutions at SAP.

In closing, interesting takeaways from a Vice President of Products at a flagship Web 2.0 company -- Sixapart -- that resonates well with everything said above on imagineeering:

• Nothing's better than seeing a user in context (My GOD, that's how they use our product?)
• End-users aren't the only ones that matter (Can't ignore the other actors in the value chain)
• Prove it with a prototype (Especially when you're breaking new ground)
• It's the same old "product definition / management / development" story (Except things are faster and cheaper)
  

Link to Michael Sippey's presentation, a courtesy of the Silicon Valley Product Management Association.

technorati tags:imagineering, engineering, design, prototyping, Web2.0, user-centric