- Background: HP FutureSmart Firmware Case Study
- Cost and Cycle-Time Drivers Prior to HP FutureSmart Firmware
- Value Proposition of Re-Architecting the HP FutureSmart Firmware and Processes
- Establish Development Objectives from the Business Analysis
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Value Proposition of Re-Architecting the HP FutureSmart Firmware and Processes
After establishing where you are spending your resources, it is important to clearly understand the value proposition of your product. Is your primary goal to reduce cost for a given functionality? Is it to release the largest number of products at a given cost? Or is the real opportunity to provide clear differentiation to the customer? Each of these is valid, and there are many more, but the decisions around the trade-offs to make in transitioning your development processes will be dramatically different depending on your specific business value proposition and cost drivers.
To start our agile change, we stepped back and asked what we really wanted to accomplish. What if we could change that “95% turn the crank” reality into something very different with innovation at our core? Following are the real business drivers that we established as our vision and value proposition:
- Our firmware had been on critical path for nearly every product delivered for more than 20 years. We sorely needed to get it off that critical path. How could we deliver firmware early and often with even higher quality?
- Because such a large percentage of our resources was spent on the “turn the crank” activities mentioned previously, a significant pent-up market demand existed for more features and innovation. For four years, we tried to spend our way out of the problem, increasing firmware R&D investment dollars by two and a half times across multiple versions of the code base that had split off in an attempt to let each business unit control its own destiny. But it didn’t seem to help. We needed to significantly improve developer productivity and organization agility to truly lead the market in all desired product attributes and features. We needed to engineer a solution.
- Our business drivers were also changing. Customers had been moving from a previous focus on “buying up to the latest product for faster printing” to needing an advanced and consistent set of Multi-Function Printer (MFP) features for workflows/solutions that have the MFP as an integral part. Previously, it had been okay for different products to have different capabilities. But after MFPs became an integral part of their workflows, customers started demanding consistency in the feature set. The technology curve with printers was to the point where the hardware engine speeds and print quality were satisfying customers, and we didn’t need to keep ramping up the curve of higher speed or print resolution. More and more product differentiation began originating in firmware. Our firmware had transitioned from a “thin layer of code to help control the print engine” to being more software-like as the critical enabler for supported workflows and solutions. Customers also began to manage their fleet of printing devices, raising the importance of managing devices in a consistent manner.
With these clear cost drivers and opportunities as our backdrop, we were prepared to put agile to work for us (not us for it) and tackle these difficult but critical disconnects in our investment versus value-add picture.