Product Development is an Iterative Process
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
