Previous posts in the Factories 201 series:
What are they (concretely)? (Edward)
When would you build one? (Jezz)
To continue the factory 201 series let's discuss a next question: What do I tell my manager? Or maybe, how do we explain the benefits of software factories to the management to justify moving to a software factories approach.
Before we ask the management to move to a software factories approach we have to explain what the value proposition of a software factory is, and what is to be gained from a software factory approach. As we all know, most managers are not interested in technical details so we have to focus on the topics that are important for them! However, the value that we can get from this approach requires a change in the way we develop software today, and this requires a firm commitment from management to achieve success with this approach. Let’s have a look.
Please note that in this post I am using my own experiences from working for a System Integrator. These types of companies are building and using software factories in-house to deliver products for customers. Some of the topics I describe might be (slightly) different for other type of companies, for example for companies that build factories and sell them to their customers without using them in-house.
The first step might be to tell them what a factory is, we can use the “What are they (concretely)?” post for that. The next step to get them really interested is to explain the benefits of software factories.
Probably the easiest benefit to explain is increase of productivity, decrease in cost. Factories automate parts of our development and design work and as a result of that the development team will be more productive during the development phase of the product, and that reduces development costs. But there is more!
Factories will also standardize the product that is developed and therefore we need less time for design and proof of concepts. Another benefit is the improved and consistent quality of the product that is built by the factory. After all, the assets for the factory are built by domain experts and remove the dependency on the very few highly skilled resources (sometimes referred to as ‘local heroes’) or over-resourced projects, to deliver the same high quality work. A lot of companies are working on improving their software delivery process, reaching a certain CMMI levels and software factories can definitely help with that.
Factories use abstractions to simplify the development of solutions. They encapsulate domain specialist experiences and knowledge into the assets behind these abstractions. As a result of that we don’t need to constantly staff each project with very best domain experts, since the assets themselves contain the required experience to solve the problem for us in the best way. Basically, the factory provides a collection of domain skills and experience we can use on each project. These assets represent the actual captured value of our skilled resources.
Furthermore, it’s possible we can re-sell these assets to other companies who may also find getting skilled resources a challenge.
All of the above mentioned benefits are somewhat related to the product that is delivered from the factory, the resources we need for that and are mostly focused on the internal organization. Let’s have a look at some benefits that are recognized externally by investing in factories.
Software factories are hot and will probably become even hotter when they reach the larger community. This is obvious because the value proposition is so strong! Therefore companies can use the presence of software factories in marketing campaigns, and use them as a means to communicate their effectiveness and professionalism to their customers. They can display their innovation in this space and can use that in their recruitment activities to attract senior and skilled professionals.
Of course, in the end, our company can also leverage the factory approach to help solving its own resource issues. We can use the best resources to do the most challenging work and actually built the software factories. In this way we continuously challenge these resources, instead of making them participate in ‘boring’ project work and ordinary tools, to make it more likely they will stick with the company. The less experienced resources can become the factory users and be way more productive as they were before.
Of course, after telling all of the above described benefits to our management they can't wait to adopt the software factories approach, but wait! There is more we have to tell them to make sure the adoption of software factories within our company has a fair chance to succeed.
We already discussed the requirement for dedicated resources in a previous post (“When would you build one?”) but we cannot stress enough that you have to use the very best experienced, skilled architects and developers to build your factory. They have to be domain experts for the product the factory outputs but also have experience in software (tool) development in general.
However, we all know that the very best resources are the first resources to be pulled off a project and put on another. Since the value of factory assets (and therefore the factory as a whole) directly depend on these resources, it is critical they must not be removed from the factory development project. We all know, and so do the managers, that it’s our customers, market, and organizational culture who decide the allocation of our resources internally. To mitigate this we have to change these conditions to free ourselves from this powerful force to be able to keep these resources focused. The factory development project needs to be separated from the core business development projects, shipping ‘ordinary’ products, and requires a new organizational structure, cost structure, goals, culture and market to succeed. Management needs to support this.
Return on investment is about profit and growth and thus more important than anything in the world for our management. We have seen the benefits that factories can bring us but before the management is willing to invest in software factories they probably want to know how fast they get their return on investment. After all, why would they want to invest in something that never pays back?
As we have already seen in our "When would you build one?" post, we probably need to build more than ~5 products with a software factory before it pays back so we better make sure we invest in a factory that is likely to be used more than once. We will discuss how and when this investment is returned in one of our future posts “How long will it take?”
Of course, the expectations on the ROI will be different than the established expectations for existing ordinary product development. So, there again, this calls for a separate organizational structure with its own values on what to expect from the product the factory delivers.
We have to make sure we keep the initial investment costs as low as possible. Therefore, trying to build a huge, fully featured factory from scratch in one attempt doesn't make sense, not only from a technical perspective but also from an investment perspective. We need to see a return on each iteration of the factory development.
To be successful, a progressive, iterative approach is preferred. The best thing you can do here is to start with small increments in automation of the product your factory creates. With each increment we identify the variable parts of the product and design those into the next iteration. This way, management can see an incremental return on every cycle.
To ensure your factory is applicable to more scenarios in its market, make sure management promote its use in many projects, even if the factory covers only a (relative) small part of the solution that is built. This way your factory can quickly identify many valuable scenarios of use, and support those in its evolving design.
Another option we have to minimize the initial investment costs is to re-use and customize an existing factory. For example, Microsoft patterns & practices released some (early examples of) software factories that are totally free and ready for use. It only takes us a few days to get familiar with these factories. After that we are ready to start using them in real life projects. Our project will benefit from the factory that we are using and in the meantime we will build experience with using software factories in our software development process. All of this with minimal investments but the experience we will gain from that will be invaluable for our future factory development activities.
One of the first questions we will have to answer when asking for an investment in factories is: "how do we measure the success of the factory?” In other words, we know the factory is supposed to increase our productivity, improve the quality and degree of standardization, but how do we notice and when will we see our first results? We have to make sure the management knows what to expect and therefore we have to specify this upfront.
For example, we can state the factory delivers a 5 % productivity increase during the development phase for projects larger than 2000 man hours, we can maybe save 80 hours during the design phase because we can use a standardized architecture documents and need less time for building a proof of concept. Further we have to specify when we can expect these results. For example, do we benefit from the factory in our first project or is it more likely this will happen in the second or even third project because the factory needs some improvements, people have to get familiar with it, etc. Of course, all of this depends on the state of the factory itself, the project, etc. but it is crucial that we use this kind of data to validate the effectiveness of the factory and the investment we are making in software factories.
Factory development isn't something we do as a "stand alone" activity. After all, the factory is supposed to be re-used by a lot of projects and different project teams within our company. To make sure we don't suffer from the "not invented here" syndrome we have to make sure the factory authoring team, but also the management communicates openly about these initiatives. We have to tell our colleagues about our initiative, demo an early drop or even better, let them play with it and ask them to provide feedback, tips hints, etc.
Another thing we can do to increase the adoption of our factory is to help people use the factory on their project. Tell them a member of the factory authoring team is available at the start of their project to support them in using the factory. This will give them a head start, not only from the productivity and guidance they get from the factory itself but also from a domain expert that demonstrates them how to best use the factory in their situation. From experience we can tell this is something that is really appreciated by most projects. We can also ask projects that we supported to provide feedback to the management and tell them how the factory helped them in their project. This will definitely help us in marketing our factory approach within the company.
Remember Me
Page rendered at 3/12/2010 12:27:31 PM UTC
patterns & practices Developer Centre
Web Service Software Factory
Service Factory Contrib
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.