• Home
• News
• Resources
• Books
• Glossary
• Archives
• Blog
• About
• Contact

Thinking About Lean

December 27, 2007 @ Herding Cats from Glen Alleman

(No Ratings Yet)

 Loading ...

"Thinking about lean" requires a starting point. Without such a starting point the conversations get off track real fast - as I've experienced in the Lean Forum. My training and experience in this area (Six Sigma and Lean) is limited to petrochemical, electric utilities, and discrete manufacturing and the software system that run these business.
    One starting point that provides a broad basis of discussion is...

Life Cycle Costing

Life Cycle Cost is the total of direct, indirect, recurring, nonrecurring, and related expense incurred, or estimated to be incurred in the design, development, verification, production, operation, maintenance, support, and retirement of a system over its planned life.
    So when we start talking about something like "is testing a waste?" in the absence of a context and domain, then there is not much to talk about. It's just "one man's opinion," based on his experience in the absence of a framework for the assessing the topic.
    Another framework is the concept of Mission Success. These are the activities performed in line or under the control of the program or project that are necessary to provide assurance that the program or project will achieve is objectives. The Mission Success activities will typically include risk assessment, system engineering (integration and operational assurance), reliability analysis, quality assurance, configuration control, software validation, and failure analysis.
Lean Processes in the Context of Life Cycle Costing
    Now when we look at the Lean Process areas in light of Life Cycle Costing we can ask and answer questions like:

Is the proposed process or "not-process" (as is testing is a waste) going to positively impact the Life Cycle Cost? That is does doing or not doing something impact the TOTAL Life Cycle Cost of the project, product or service?

Here's the key to a successful conversation about this. Look beyond the narrow self interest of the speaker. A agile developer is that an agile software developer. A unit testing engineer is just that a unit test engineer. A database administrator, a A SIC design, etc. etc. etc. Look at the "System View," the total system from birth to death and then ask the Lean questions in the previous post.

Microeconomics Framework for Life Cycle in Lean
    One approach to analytical solutions - rather than anecdotal solutions - is the microeconomics assessment of tradeoff analysis. This is a common approach in the Systems Engineering worlds of complex system acquisition strategies. Complex systems are common in the ERP domain, with the integration of legacy and COTS products while running the business at the same time on both systems. Such system involves:

• Changing external environments
• Negative and positive feedback - damping and amplification of the changes on the outcome of the system
• Emergence of requirements, technology, processes, and productivity tools.

In the Systems Engineering domain these are usually manifested in "Systems of Systems" architectures. Which is defined as a collection of task oriented or dedicated systems that pool their resources and capabilities together to obtain a new, more complex, 'system' which offers increased functionality and performance than simply the sum of the constituent systems.
    An integrated ERP and Legacy architecture is such a SoS. The application of Lean with the Trade Space of Life Cycle Costs is a useful starting point for the discussion of any proposed process addition or removal - such a "testing" and its bookable value.
Nothing is New Under the Sun
    Any discussion of applicability of one process or another needs to have some "unit of measure" as an anchor. The unit of measure must also be meaningful to someone who has a stake in the outcome. Usually the unit is money and the stakeholder is a consumer of the products. But in the end the Life Cycle costs must be the boundaries - not the narrow bounds of a role in the process - developers, tester, designer.

Comments

Copyright © 2007 PMToolbox :: Tools and Resources for Project Management