This article is the next installment of the “10 weeks to Lean Integration” series.  If you are joining the discussion now, you may want to read previous postings starting with this one which includes links to related articles.

There is an old project dilemma that suggests you can’t have it fast, good and cheap – you can only pick two. That trade-off may be true for custom one-off solutions, but it’s not true for integration development if you approach it as a repeatable process. Some organizations have reduced their cost by a factor of 10 while also delivering integrations rapidly and with consistently high quality. The secret to achieving this amazing result is to focus on time.

A funny thing happens when you speed up the development of integrations – costs drop and quality improves. This may seem counter-intuitive since speed is often equated with throwing more people at a problem to get it done faster which drives up cost. Another common misperception is that speed means rushing and making mistakes which reduces quality and drives up cost due to errors and re-work. Time-based competition(1) – or using time to differentiate your capabilities – can fight the old paradigm.

The best way to speed up development of integrations is to eliminate wasted activities, reduce delays, and re-use common components, all of which have already been discussed in prior posts. Nonetheless, there are few additional techniques which can improve delivery times.

First, take integration development off the critical path for projects. Each project has a critical path or bottleneck that is the limiting factor for how quickly the end-to-end project can be completed. Integration activities often are on the critical path because of the complexities and uncertainties about how all the pieces work together. This doesn’t need to be the case if you clearly understand the root cause problems that tend to put integration activities on the critical path and tackle them head on. For example, data quality issues between disparate systems are a common cause of significant delays during integration testing. A solution for this problem is to include a mandatory pre-project data profiling assessment for all relevant projects. It is amazing how much time can be saved in development and testing when the data to be exchanged between systems is well understood at the beginning.

Second, implement a variable staffing model and develop processes to rapidly ramp up new staff. Supply and demand mismatch is another common root cause problem for delays. For example, if you have a fixed number of integration development staff that are supporting new project development, some of them may be idle at times when the demand is low while at other times demand may peak at well above the planned staffing level. If you have 10 staff and the demand jumps to 15 for a period of several months, there are only a few options available:

1. Get all the work done with 10 people by cutting some corners and reducing quality. This is not sustainable since reduced quality will come back to haunt you as increased maintenance costs or reduced future flexibility.
2. Make the 10 people work overtime and weekends. This is not sustainable since you could end up “burning out” the staff.
3. Delay some of the projects until demand drops. This is not sustainable since you are in fact chasing away your customers (telling someone that you can help them in two months when they need help now is the same as saying “no”).
4. Bring on additional staff. This is the only sustainable model, but only if you can ramp-up the staff quickly and then ramp them down when the volume of work subsides. The keys to making this happen include having well-defined standard processes, good documentation, and a long-term relationship with consulting firms.

Third, focus on driving down end-to-end project cycle time and not on optimizing each activity. This may seem counterintuitive, but optimizing the whole requires sub-optimizing the parts. For example, the task of creating user documentation is most efficient when all the software is developed. However, this can add a significant delay to the overall project if the documentation is prepared in a sequential manner. The overall project time-line can be reduced if the documentation effort is started early (even in the requirements phase) despite the fact that some of it will need to be re-written to reflect the changes that take place in the design and development phases. But if every functional group that supports a project is motivated to reduce the total cycle-time rather than focusing on the efficiency of their team, the overall improvements can be very significant.

Tune in next week for Part 6 in the series where I turn the attention to the people side of the equation and talk about empowering teams.

Note (1) George Stalk, Time – The Next Source of Competitive Advantage, Harvard Business Review, 1988