Differences on Software Development between Product Development Department (R&D) and Global IT Department

Software development process differs depending on the project context. Firstly, organizational structure and culture matters. Different organizations may develop different development principles based on the leaders’ preferences and the organizational distribution structure. Secondly, software domain matters. For example, more safety-critical software domains (e.g. avionics, medical software) tend to require more rigorous development process. Thirdly and not obviously, what also matters lies on the different development environment within the same company, where here I want to talk about the differences between the product development department (R&D) and the global IT department.

It’s typical for an international large IT company that has one R&D responsible for producing commercial products for sale and one department usually called global IT responsible for selling those commercial products to distributors, partners, resellers, or direct customers. So, the R&D develops a set of software products while the global IT develops an ecology of systems combing enterprise information systems with customer relationship management and possibly supply chain management. In such a context, I identified some differences exhibited in the course of software development between the two departments. These differences are listed as following:

Firstly, R&D pays more attentions and efforts to architectural design activities whereas global IT often seems to neglect the solution architecture as long as the enterprise architecture remains good. One reason for this falls in the fact that global IT usually has tighter budget and time constraints, and in the meantime many projects run in parallel. Consequently, they tend to work directly toward the implementation to get one project delivered quickly so that they can start or work on the next project sooner. Besides, global IT projects mainly develops software systems that are consumed within the organization or with partners and thus face less pressure (the pressure to do the best) from the outside world – the market, the customers, the users etc. Conversely, products developed by R&D are mainly intended to gain better market share and make customers more satisfactory. Their products evolves quickly, and hence demand better architecture to support this evolution.

Secondly, the requirements process and design process in global IT are more closely intertwined than that in R&D. Requirements in R&D are mainly gathered by product managers from customer complains, competitors etc. And then the requirements document will be passed down to development teams where maybe more detailed requirements will be proposed and design begins. However, in global IT, many requirements are discovered from people within or closely associated with the organization; and most of these people are of technical background. Meanwhile, because of the tighter budget and time constraints, design occurs far before the requirements has been finished. Inevitably, a lot of design decisions will be made in the course of requirements discovering.

Thirdly, people in global IT have a more agile mind-set. They emphasize less on (the quality of) documentation and more on the quick delivery, while in R&D documentation still plays its role for communication and keeping product knowledge, especially architectural knowledge persistent.

Of course, some of these differences may stay true for some companies but not for some others. And there definitely exist more differences between the two departments. The point here is that we may improve our own course of software development from these differences by thinking on why such differences exist and what lessons one department can learn from the other.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>