Inventory at the beginning of a development process includes business or customer requirements data that have not been scheduled for development yet. It’s hard to do much about this until you’ve done something about inventory in the middle of the process, but once you have, then there are some tools to apply to streamlining requirements analysis. These will be some of your QFD tools and such, and we’ll get into those later.

Inventory in the middle of the process takes the form of Work-In-Process for the feature set that is under development. This would be any functional specifications, design models, source code that is less than fully tested and integrated, or any other artifacts that you produce in the process of delivering working features to the customer. Applying Lean practices to this part of the business is about improving operational efficiency, regardless of how your customer relationships are structured. If you haven’t done anything yet, start here.

Inventory at the end of the process is largely about customer relationships. Your relationship with your customers may evolve into a multi-year deployment cycle partly because your own business isn’t capable of delivering on anything less than a multi-year cycle. Developing the ability to deliver on a shorter cycle is good for your own business independently of the current expectations of your customers. On the other hand, if you start to demonstrate that you have desirable features just waiting to go for the next deployment, then your customers might start to rethink how they want to fit you into their business plans. The literature about Toyota or Dell is full of stories about how their supplier relationships realigned as Lean principles propagated through the supply chain. Sometimes Lean thinking is about training the customer to have higher expectations. But until they are ready, there’s no reason not to queue those features up for bundling into the expected package size.

I’d love to hear your thinking on how to fold lean software engineering practices into that kind of business environment, the opposite of the software as a service model.