Integrated Project Management for Software Product Development

ABSTRACT - Developing a software to be marketed as a “software product” involves more developmental aspects than an
application development for one specific customer. Concepts of Integrated Project Management (multiple sub-projects) are
useful in managing the higher complexity involved in product development. Integrated Project Management, as applicable to
a Software Product Development is discussed in this paper. Differences between application development and product
development are highlighted first. Areas that are specific to product development are discussed in brief. How the overall
product development can be organized into sub-projects, how are these sub-projects structured for effective coordination,
and how to manage the interfaces between the sub-projects are addressed in detail. The paper is based on the experience in
the development of SlimCIM XXX Cell Controller (SMCC) product at XXX Singapore Software Center. The author is the
SQE for the project.

KEY WORDS – Product Management, Integrated project Management

1. INTRODUCTION
Software Development has two business scenarios. First one is to develop a software, specific to one customer with a specific
set of requirements (application development). Second scenario is to develop a software which the organization intends to
market, after the product is in shape (product development)*. In the first one, the sole customer pays the entire cost of
development and he dictates the software requirements. Whereas in the second case, the pay back is coming from multiple
users (who will potentially buy the product). There is no specific customer to provide us the requirements. Typically the
products will be deployed in multiple sites and are produced with a general solution in mind.

*It is important
2. WHAT IS MORE to noteIN
thePRODUCT
difference between product development and application development within the context of
DEVELOPMENT
this paper
In contrast to the application development, there are more developmental aspects that need to be taken care in a product
development. From a management point of view, following are the major ones:

2.1. Ownership of the Software Requirements

There is no specific customer to tell you the specific requirements. Inputs for the product features will come from various
sources like customers, marketing, support team, technology trends etc. Beyond all these inputs, there should be a body to
finalize the requirements, which is a management task within the product development.

2.2. Marketing and Technical Support

When we want to sell the product once it is ready, the marketing activities need to be aggressive. So is the case with the pre
and post sales technical support.

2.3. Packaging and Distribution

Product packaging and preparation of the distribution media are tasks that product manager has to take care of. These are of
less concern in an application development as it is not meant for a mass distribution.

2.4. Licensing and Legal issues

As a consequence of multiple users, license management becomes an important task. Specific license control mechanisms
will have to be devised into the product for this purpose. Legal aspects such as product naming, patent filing, copyright etc.
also comes under product management.

2.5. Product Maintenance

1
Because of the multiplicity of users and sites, product maintenance is more complex than that of an application software.
Different sites may be running different versions of the product at the same time.

2.6. Multiple Threads of development

As the software evolves into a large product, scope of development also expands and it becomes no more viable to manage
the whole development in one thread. Rather it is more convenient to split them into multiple threads and manage them
separately. This will add to the complexity of the integration and Release Management.

The above developmental aspects are beyond the scope of our standard Software Development Process (SDP), which spans
from requirements gathering and planning upto the system test and release. Rather, SDP model cannot cater for the
additional needs of a software product development. A new Product Development Process Model is introduced here with an
objective of the overall management of the entire product development. This model, should ultimately help in organizing the
product development into a Master Project with multiple sub-projects, which is the basis of Integrated Project Management.

PRODUCT MANAGEMENT

C PROD FCL
U MARKETING STRATEGY &
S DECISIONS REL PLAN
T
O
M
E ARCHITECTURE
R SUPPORT
S

DEV1 DEV2 .. DEVn

…

INTEGRATION & CM

Fig. 1 Product Development Process Model

3. PRODUCT DEVELOPMENT PROCESS MODEL
Considering the specific nature of software product development and borrowing ideas from hardware industry, following
high level components are identified for the product development process model:

1. Marketing
2. Technical support
3. Product Strategy Description
4. Feature Candidate List and Release planning
5. Architecture development
6. Software development
7. Integration and Configuration Management

2
 Figure 1 explains the interfaces and logical flow of the process. While most of these activities are obvious and
straightforward, explanations are appropriate in certain cases. Following sub-sections (3.1-3.7) provide some brief
explanations for the above activities.

3.1 Marketing
These are the proactive steps initiated by the organization to facilitate sales and inform the customers. Marketing group has the
responsibility of identifying the customer requirements both technical and business point of view. These customer requirements
form the input for the Product Strategy Description. Other responsibilities are creation of product descriptions for customer use,
pricing sheets, brochures and other marketing materials.

3.2 Technical Support

Support activities include installation of the product at customer sites, product deployment, consultancy and customer training.
Support group has also responsibility to identify new requirements for the customers, which will be inputs for the product
strategy decision as well as the feature lists.

3.3 Product Strategy Description

This is the process of coming out with a product strategy or product road map. A dedicated team may be formed for this with
proper representation from marketing, support and other engineering groups. The strategy decisions will be documented in the
product strategy document.

3.4 Feature Candidate List & Release Planning

Feature Candidate list (FCL) is a set of prioritized features to be considered for release. FCL provides a starting point from
which a smaller subset can be selected and committed to for a release. A Feature Control Board owns the FCL (requirements
for the product).

3.5 Architecture Development

Initial development of architecture and its continued evolution throughout the life cycle of the product are taken care in this
activity. An independent architecture team will help in ensuring design consistency and interpretation across all functional
areas. The architecture team has the responsibility and authority for
• Creation of the product line concepts and principles
• Identification of layers and their interfaces
• Identification of common mechanisms or services
• Definition, prototyping, and enforcement of common mechanisms such as error handling and inter process communication
protocols
• Communication to the project staff of the product line concepts and principles

Typically the architecture team will be a small group of full time senior engineers with extensive domain and engineering
expertise.

3.6 Software Development

Based on the release plan and business needs, product manager will assign specific project groups to develop the software.
More than one development team may exist for one product development. Each of these development projects can be
considered as an application development (as defined at the beginning) and will have its own project manager and project plans.
Maintenance of the existing products should also be treated as another development project with team members identified and
responsibilities assigned.

3.7 Integration and CM

The combined integration and Configuration Management (CM) team will have the responsibility for:
• Development of incremental build schedules (in conjunction with the architecture team)
• Integration and release of valid subsystems
• CM of customer release libraries
• Development of test strategies, plans and test cases beyond unit test
• Coordination of all test runs
• Identification and labeling of software components
• Creation of software delivery medium.

3
4.INTEGRATED PROJECT MANAGEMENT
The integrated project Management (IPM) is applicable whenever the project deliverables are produced by multiple,
interdependent groups. Many factors make IPM essential such as
• Functionally distributed teams
• Geographically dispersed teams
• Product size
• Multiple technologies
• Outsourcing

These factors fragment the project community and create the need for integration which directly applies to the software product
development. The greater the need for integration, the more vital it is to use systematic and disciplined project management
principles.

4.1 Frame work for IPM

The process model discussed in Section 3 forms the frame work for IPM. During the initial stages of the product development,
some of the functional groups are formed by the very nature of the work. But this is not true for all functions. For example,
marketing group may be formed different from the development group, but the development team may be overlapping with the
product support team. At some point of time, there should be a conscious effort to formally organize the team into a well
defined frame work. In the model discussed above, each component is a sub-project for the product development. Each sub-
project should have a defined boundary in terms of scope, schedule, resources and cost. The manager for each sub-project is
responsible and accountable for the allocated boundaries. A pictorial representation of the project architecture is shown in Fig
2.

Product development
Sub-Project Sub-Project
Team Team
Proj Product Management Proj
Mgr Mgr

Proj Proj
Mgr Prod Mgr
Proj Mgr Proj
Mgr Mgr
Sub-Project
Sub-Project
Team
Team
Proj
Proj
Mgr
Mgr

Fig 2. Architectural interface of sub-projects

Product Manager assisted by the sub-project managers is responsible for Product Management. For each sub-project, the
Sub-Project Manager (SPM) is responsible for the entire show with support from the respective team. This concept is not new,
but the point here is that, this framework has to be clearly defined and organized in order to have a successful product
management. There are many instances where such a structure is “assumed” to be there, but in reality ambiguities exist over
scope, resource and even cost among the teams.

4.2 High level WBS

Creating the high level WBS (Work Break down Structure) is the first step toward having a fully integrated program. The
structure selected may influence how the program is managed. Functional structure may increase the number and complexity of
interfaces. The level of the WBS can be selected in such a way that
• All activities in the product development are covered
• Specific group or groups can be assigned for each activity

4
• It reduces the overlaps and
• It leaves room for the individual SPMs to function within their boundaries.

It may be convenient to prepare a responsibility matrix as shown in Fig 3.

Marketing

Support

FCB

Architect

Dev team

Int & CM

Prod web Market Rel 2

page brochur patch

feature dev Prepare Error

CD handling

Responsible Contributor

Fig. 3 Example of Responsibility Matrix

4.3 Managing the interfaces

High level WBS in one way define the boundary of the scope for each sub-project. From there on, sub-project manager owns
the responsibility of performing the WBS tasks. Each sub-project will have dependencies (interfaces) with other sub-projects.
An output from a task in one sub-project, which forms the input for a task in another sub-project is a project interface (Fig.4).
For example, Error-message numbering scheme, which is an output from the architecture team forms the input for the
development team to generate the low level design.

Project Interface
Input
supplier output
receiver

Fig 4. Interface between sub-projects

Interface management is a systematic approach for managing these inter dependencies. Fig. 5 shows the steps involved in
defining and managing the interfaces in a multiple project system

5
 Identify the input requirements

Identify the outputs

Match the inputs with outputs

Consensus among team No

Yes
Resolve & track

Integrate the schedule

Fig. 5 Interface Management

The steps are self explanatory. The schedule integration (last step in Fig 5) is the process of combining all sub-project plans into
an overall product plan. Here, all the sub-projects are linked through their respective interfaces. It may be noted that because of
the complexity of the interfaces, the critical path of the whole schedule may flow through many sub-projects. The Product
Manager is responsible for this schedule integration and subsequent monitoring of the progress in terms of the interfaces.

There are various tools available for this type of schedule integration. Manual approach is to define the interfaces as milestones
– both inputs and outputs. For the supplier (sub-project), the interface-output is defined as a deliverable milestone. And for the
receiver (sub-project) this input will be represented as an external dependency milestone. This representation helps the product
manager to track the projects at milestones level ensuring that all interfaces are taken care..

5. SMCC EXPERIENCE
SlimCIM XXX Cell Controller (SMCC) is a software product to monitor the manufacturing process and equipment utilization
via the General Equipment Model (GEM) compliant machine in surface mount technology (SMT) industry. SMCC today is the
standard factory process and equipment monitoring software system for XXX Communication Enterprise factories.

SMCC product started development 3 years back. For the first 2 years, it was run like any application development at
Singapore Software Centre (SSC). By that time the product grew large, there were more customers, there had to be multiple
threads of development, maintenance issues piled up and was further complicated by the uncertainty of the future direction of
the product. It was then the need for a specific approach for product development, different from that of an application
development was realized and a process model as discussed in Section 3 was identified. Looking at the model above, there are
four specific components which adds value to it:

1. The Product Strategy Decision (PSD) which decides the future roadmap of the product
2. The Feature Control Board to finalize the requirements for the software product
3. Independent architecture, common to all development teams, to ensure the integrity of the designs
4. Independent integration and CM team which takes care of integration, configuration management, testing and packaging

Once the multifunctional frame work is in place, the question of interfaces between the groups becomes a problem. There is no
other means to monitor the progress without integrating the schedule and looking closely at the interfaces. That is when the
concept of integrated project management was brought in. We feel that the idea should have been implemented quite earlier.
More specifically, to organize the whole product development into distinct sub-projects and manage the whole development
with an integrated project management approach should be targeted very early in the product development cycle. Otherwise the
rigidity in the functional groups become more harder, resulting in difficulty to form a frame work for smooth product
management.

6
Benefit of this approach is nothing but a systematic means for managing the entire product development. Better predictability of
deliverables in terms of delivery date and cost are obvious results. Implementation difficulties, based on our experience are:
• Proper buy-in from various groups involved
• Lack of proper training for all concerned. Common language or project vocabulary is important in interfacing multiple
projects
• Organizational capability in terms of predictability of deliverables. Uncertainty in one sub-project will affect the other
dependent sub-projects as well

Based on this learning experience, a product development process is being defined at SSC so that future product development
initiatives will follow a systematic approach from the very beginning.

6. CONCLUSION
Integrated Project Management for product development is well accepted in hardware industry. The concept when applied for
software products, has subtle differences in terms of organization of the sub-projects. By careful consideration to those special
nature of software development through a suitable process model, the principles of IPM can be used beneficially for software
product development.

7. REFERENCES
1. XXX Digital Systems Division (CIG) Product Management Process
2. XXX Singapore Software Centre Software Development Process
3. CE-Q Gate System Life Cycle document – Draft-C