J. Rich Rogan - Interaction Design / Information Architecture

I have worked with teams small and large, using processes from Strict Waterfall to Agile with Scrum. I have found the best process is the one that matches the development environment, including schedule, budget, team, core competence and other factors. Having said this, I do believe there are certain initiatives which increase project success, and I have detailed these below.



The Strategy

The first thing with strategy is to keep it simple, then have it make common sense, improvise whenever necessary, and iterate, iterate, iterate. Optimally I like to be involved early on in projects, as close to the incarnation of "The Big Idea" as possible, through to rollout, postmortem and on to the next iteration. I like to break down Strategic Iterations in the following ways:

• Business Objectives
• Analysis
• Design
• Prototype
• Code
• Quality Assurance

These are the buckets, then there are initiatives which cross all buckets, such as involving users or surrogate users in the following ways:

• Business Objectives - Idenitfy Users, Influencers, Other Important Players
• Analysis - Get Depth on Users and Influencers, via Contextual Inquiry techniques
• Design - Identify actual Users or Surrogates, and involve them directly with design
• Prototype - Test and refine with Users or Surrogates
• Code - Test and refine with Users or Surrogates
• Quality Assurance - Test and refine with Users or Surrogates

Above is a way to define the detail of Strategy, then there is the heart of the strategy, which involves people and crystal clear communication in the form of dialog. A strategy cannot survive, (or at least be something you'd want to be associated with), unless the core is focused on people in the team and communication between these people and other stakeholders outside the team.



The Team

The most successful processes I have worked with involve empowering teams to make their own decisions, as much as is possible, from conception to release, and beyond if possible.

The most successful teams I've worked with were small, under 8 people, with less than 3 of them being project/product/resource managers of some sort. I'm always amazed how many teams I've worked on where the number of people measuring progress equals or exceeds the number of people doing the work.



The Day to Day work

I like working with small deliverables designed and developed in short time frames, very similar to Scrum. I especially like daily meetings of the entire team for 15 minute sessions, where each member identifies what they did, what they will do and what is getting in the way. This little bit of communication each day can help a team immensely.