Process - or a tool set?

27 Jan 2007 - 1:52pm
7 years ago
1 reply
448 reads
Mark Schraad
2006

There is a lot of conversation about process and tools on this forum.
Most of which is very enlightening and helpful. It is especially nice
to get insight prior to a purchase, not have to do the same research
someone else has already gathered, and have the benefit of industry
leader's experience. But I sense the very natural desire to find the
"perfect" application or process. I think it is important to not get
too intrenched and approach this as more modular.

In the mid eighties Michael Gerber wrote a great book called "The E-
myth Revisited". One of the stronger take aways from that book is to
refine your process and institutionalize it across the organization.
He attributes much of McDonald's success to the refinement of process
and the consistency with which they implemented it.

There are, however, two common misinterpretations of Mr Gerber's
writings. The first is that the process is static. To
institutionalize process is dangerous, to not regularly question a
process is irresponsible. Constant challenge and refinement of the
process is an integral part of McDonald's formula. Second, designers
are problem solvers not widget makers (at least I hope most of us
are). A rote design process will become problematic.

I might suggest, as many already practice, that not only in design
but also in design research, having a set of tools that can be mixed
and matched with a diverse staff, is a better arrangement. Though
many projects may seem to have the same or similar criteria, it is
worth the time to evaluate methods, tools and process for each
project, just as we do with design constraints, goals and objectives.

Your thoughts?

Mark

Comments

29 Jan 2007 - 4:31am
maglez@btintern...
2006

Hi Mark.

I agree on the dangerous of a static processes.

If a company decides to put a process in place and follow it, they also have to have a Process
Team to control the good implementation and quality of that process, it must be a Process Manager
able to control the process and adapt it if necessary, all this mean dynamic against static.

It may be that the person that described the process may have done that from a dynamic point of
view, the problem many times is that the company that adopt the process has not the resources to
maintain a process team nor the knowledge of a Process Manager and then the initial capable
dynamic process become static.

And then the worst happen, when a company runs a process by people that don't understand it, they
just follow it believing that what they are doing is correct, they deposit their trust on that
process and run the project with a level of confident that should ensure success, then everything
fail, too late to be fixable, they don't understand the reasons for that failure and just blame
the process.

I also agree with you that even working on similar projects, some time should be spent on
analysing processes, methods and tools, unfortunately competitors force you to deliver faster and
so you have to shorten all that analysis, here is where experience and knowledge wins, those with
the ability to identify those small differences between similar project have the advantage to
modify processes and methods in a short time and so ensure the success of the project. I find all
this really exciting and necessary.

Miguel Gonzalez.

--- Mark Schraad <mschraad at mac.com> wrote:

> There is a lot of conversation about process and tools on this forum.
> Most of which is very enlightening and helpful. It is especially nice
> to get insight prior to a purchase, not have to do the same research
> someone else has already gathered, and have the benefit of industry
> leader's experience. But I sense the very natural desire to find the
> "perfect" application or process. I think it is important to not get
> too intrenched and approach this as more modular.
>
> In the mid eighties Michael Gerber wrote a great book called "The E-
> myth Revisited". One of the stronger take aways from that book is to
> refine your process and institutionalize it across the organization.
> He attributes much of McDonald's success to the refinement of process
> and the consistency with which they implemented it.
>
> There are, however, two common misinterpretations of Mr Gerber's
> writings. The first is that the process is static. To
> institutionalize process is dangerous, to not regularly question a
> process is irresponsible. Constant challenge and refinement of the
> process is an integral part of McDonald's formula. Second, designers
> are problem solvers not widget makers (at least I hope most of us
> are). A rote design process will become problematic.
>
> I might suggest, as many already practice, that not only in design
> but also in design research, having a set of tools that can be mixed
> and matched with a diverse staff, is a better arrangement. Though
> many projects may seem to have the same or similar criteria, it is
> worth the time to evaluate methods, tools and process for each
> project, just as we do with design constraints, goals and objectives.
>
> Your thoughts?
>
> Mark
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

Syndicate content Get the feed