I spent the first 11 years of my professional life in Application Development (AD) at an IBM manufacturing facility. After that I moved on to software companies and worked in the Product Development (PD) area. More recently in my second life as a consultant I’ve been working with both types of organizations as a program manager and process analyst. Many of the other folks I work with have only had experience in PD (this being Silicon Valley and all) and I’m finding there are some key differences that are important to understand.
The most important difference is that PD is a profit center while AD is a cost center. That means that if PD ain’t happy, nobody’s happy; if AD isn’t happy they usually have to suck it up. In PD if there’s a product issue we do the equivalent of stopping the manufacturing line – find the issue, perform root cause analysis, look at best of breed solutions, and get things back up and running with the optimal solution. All normal business practice – the product that goes out the door is what makes the company viable. In AD the company manufacturing line is often a real, physical manufacturing line and the same thing happens there. If the software for anything other than running the manufacturing line has issues the company just wants to get it working again for the least possible cost. For AD organizations in a software company (the organization that handles business systems like the financial systems and marketing applications) there’s often some amount of spill-over in processes, but the willingness to spend money on solutions is typically significantly different than the spend position for PD. Customer-facing applications teams (like the external website or ordering system team) often have the toughest job since their applications typically don’t bring in revenue but could do the opposite and cause customers to look elsewhere. On the other hand, that kind of visibility sometimes makes it a little easier to get additional funding for improvements.
The political power that PD groups enjoy is usually not available to AD groups (based mostly on the whole cost center vs. profit center thing). This means that AD groups are sometimes unable to push through initiatives that are recognized best practices because of associated costs (staffing, opportunity cost, cost of tools) and sometimes have to implement functionality that the team knows is not optimal. When working with AD groups it’s really important to understand that even though the team understands the issues and wants to implement improvements it is not always possible. I know that I myself get decidedly cranky when pushed to do something that I simply cannot accomplish even though I believe it’s the right thing to do, so I try to understand the client situation thoroughly to know when to stop nagging for change. I/T management is often unwilling to deal with leading edge technologies in AD projects and applications. While often frustrating to the teams, this makes perfect business sense – leading edge technologies will not provide any competitive advantage to the company for non-products and could potentially cause disruption and expense if issues are encountered.
Finally, the processes and relationships in an AD environment can be logarithmically more complex than those in the world of PD. AD teams often do not have direct contact with the end users of their applications and the users and user representatives they do work with usually do not understand any of the technical issues. There’s a tightrope of information to walk – giving the internal customers the information they need to make critical decisions but not giving visibility into any of the technical processes.
It can be very rewarding to work in or with either type of organization; in order to do it effectively and with a minimum of frustration it’s important to understand the pressures and processes of the group you’re working with or in.