See full color web version at:
http://www.SeniorManagementServices.com/pvt-111-iteration.html
Have you seen these kinds of development problems?
If your company develops products, you've probably seen
schedule-changes in product development that had a huge
effect on pro'fit.
In high-tech industries, pro'fit often depends on
time-to-market. A two-month schedule advance might
double or quadruple your pro'fits, while a two-month
delay might make your company an "also ran."
Product development is an iterative process. For example,
early computers did not run at giga-cycle rates. Orville
and Wilber did not build a passenger airplane. Henry Ford
did not develop the Thunderbird.
Today's computers, passenger airplanes and fancy cars
resulted from the successes and failures (feedback) of
previous iterations of product development. Product
improvement is also an iterative process.
But, most companies burden their product development
departments with inevitable schedule delays. How? They
optimize their company around NON-iterative processes and
static business architectures, instead of optimizing around
iterative processes and time-to-market.
Here some examples of iterative vs. NON-iterative business
processes.
Iterative processes
Developing complex software systems
Developing a complex sa'les process
Developing an accounting system
Streamlining a manufacturing process
Developing an Internet marketing website
Building a company
Developing new product specifications
Non-iterative processes
Running a software program
Making a sa'les call
Entering data into an accounting system
Installing parts in an assembly-line
Fulfilling an Internet order
Doing the company's technical work
Delivering specifications to manufacturing
Companies try to minimize costs by using long iteration
cycles, such as, performing quality control (QC) checks at
the END of a long process.
These long iteration cycles inevitably cause delays.
Why? When QC discovers a problem at the end, they
must disassemble the item, fix the problem, assemble
the item again, repeat the QC process, find another
problem, disassemble, fix, reassemble...etc.
(It doesn't matter whether the product is an automobile,
a software product, or a custom restaurant meal.)
Take a look at PLAN A, an iteration model where feedback
"FB" is created only at Step 5 (QC) - or worse, in Step 7
by the customer.
http://www.SeniorManagementServices.com/Images/plan-a.gif
(NOTE: Boxes represent processes, and circles represent
data or things. Each process generates data or things
for another process.)
Notice that the model shows no schedule or time period.
Feedback from long iterations usually mask problems that
would be better fixed at the source instead of at the end.
Shorter iterations let you leverage new learning (feedback),
prevent problems at the end, and even shorten development
time.
Take a look at PLAN B, an iteration model where feedback is
created at every step. More feedback more learning and a
more dynamic process.
http://www.SeniorManagementServices.com/Images/plan-b.gif
Notice that PLAN B uses the same steps as PLAN A but
collects much more feedback. Many companies fail to gather
and use feedback, which is a source of delays and higher
costs. It is more effective to gather and use feedback ASAP
to:
Manage uncertainty by getting the information early,
Decrease risky situations,
Gain more certainty early in development
Avoid expensive delays that occur later on
Help you plan optimum iteration lengths
As you can see, this organizational structure is circular,
where results move clockwise and feedback moves
counterclockwise.
So, how should you organize your company
-functional hierarchy or project teams?
Let's look at the tradeoffs.
Functional hierarchies are an efficient structure for
reducing short-term costs because they tend to keep all
workers busy continuously.
While this is efficient, it can lead to delays because
people tend to get distracted from tasks that are
critical to the development project.
Then, along comes a manager who accelerates a slipping
schedule by saying, "Things WILL get done on this project."
So, the manager's pet project gets ur'gent attention
throughout the hierarchy. (But, nobody tallies the cost
for other projects that fall behind as a result.)
Project teams are an effective way to reduce elapsed time
from project startup to completion. Project teams tend to
keep their focus on tasks that advance their project goals,
even if workers are sometimes idle or not working in their
primary area.
The functional hierarchy is the company's permanent
management structure and is the lar'ger context for a
temporary project team to streamline production from an
iterative process.
There's definitely a tradeoff.
If you create a separate, although temporary,
organization for a project team, you will most likely
breach established accountabilities, Position Contracts,
and hierarchical staff/line relationships.
To review (from PVT 17):
A proper hierarchy has three important rules:
1. No manager may give a command or communicate
information to anyone except his or her immediate
subordinates.
2. Information and/or requests presented in violation
of the line relationship must be rejected
immediately.
3. No one can report to (be "line to") more than one
other person.
Line Relationships
In a LINE RELATIONSHIP, the boss is"line to" his or her
subordinates, specified by lines on the Org Chart. For
example, your boss is "line to" you and has authority
to give commands and substantive information to you as
his or her immediate subordinate.
Staff Relationships
In a STAFF RELATIONSHIP, neither person has authority
to give commands or substantive information to the
other. (If you are NOT "line to" or "subordinate to"
someone, you are automatically"staff to" that person.)
Thus, when you create a project team, you may create
management problems that you should carefully consider.
Still, you can use management tools, such as, Contractual
Commitments and Controlling Calendars to minimize possible
stumbling blocks.
It would probably be easier to create a separate project team
hierarchy for a long-term than to "loan" employees
intermittently.
How to save time developing specifications
You can waste a lot of resources creating formal, detailed
specifications at the start of a project.
Why? Because requirements inevitably change during
project development. A further risk is that the market
might change by the time you finish developing your
products.
So, in a dynamic market it is more effective to begin
development and let requirements evolve based on feedback
from new understandings and changing market conditions.
This way you can prioritize work on product features
according to their relative importance.
You decide.
What did you learn today that you found most
beneficial?
How will you apply what you have learned at work?
Best Regards,
Mike Hayden, Principal/Consultant
Your partner in streamlining business.
PS. If you're not on our P V T Roster, sign up (fr#e) at:
http://www.SeniorManagementServices.com
(c) 2005 Mike Hayden, All rights reserved. You may use
material from the Profitable Venture Tactics eZine in
whole or in part, as long as you include complete
attribution, including live website links and email link.
Did you like this ezine? To Signup: visit
http://www.SeniorManagementServices.com
How did you get on this roster? You or someone you know
Signed you up. We nev^er add names to our roster without
Voluntary signup.
Thanks!
(c) 2005 Mike Hayden
Senior Management Services
39270 Paseo Padre Pkwy 439
Fremont, California 94538
Silicon Valley: (408) 817-5684 or (510) 789-7578
Email: mailto:info@SeniorManagementServices.com
Website: http://www.SeniorManagementServices.com
Link: http://www.SeniorManagementServices.com/pvt-111-iteration.html
About the Author
Mike Hayden is Founder/CEO of Senior Management Services and the Documentation Express in Silicon Valley, California. Mr Hayden is the author of "7 Easy Steps to your Raise and Promotion in 30-60 Days! The book that smart bosses want their employees to read."
ISBN 0-9723725-1-2. More articles at http://www.SeniorManagementServices.com/pvt-information.html