Successful project management for software product and information system development



Project management has been used extensively in the engineering, construction, and defense industry. Software product development companies are starting to rely on project management and sound Software Engineering practices to get their products out in today's competitive market place. This paper discusses Software Engineering practices, product management risks, and provide helpful strategies for managing software product development.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines project management as the application of knowledge, skills, tools and techniques in order to direct and coordinate human and material resources throughout the life of a project to meet established goals of scope, quality, time, cost, and stakeholder satisfaction. Software Engineering is a disciplined and quantitative process for the development, operation and maintenance of software-intensive system with focus on measurement, productivity, timelines, and quality. The paper briefly looks at the interaction between the project management process and the software development process. A summary of the processes and typical steps followed is given as well as a comparison between Software Product (SP) development and Information System (IS) development.

Exhibit 1. Information System Development Process

Information System Development Process

Comparison of IS and SP Development Processes

Project management deals with initiating, planning, monitoring, and controlling the activities required to fulfill the project commitments, and reporting their status to the project stakeholders. The software development process deals with the technical aspects required to complete a project or product. A sound development process needs to follow Software Engineering fundamentals and take into consideration requirements analysis, functional and technical specifications, data and object orientation models, documentation standards, software testing, software maintenance, software quality assurance, and configuration management.

In order to be successful in developing software systems or products the project management process and software development process must be integrated. To manage a project one must know some basic methodologies such as: Project Management Institute, Microsoft Solutions Framework, Software Engineering Institute Capability Maturity Model (CMM), IEEE, and Rational Rose Unified Process.

In this paper Information Systems (IS) development is defined as software development done by an organization for a single customer/client. This usually is customized work undertaken by the organization on request by a customer. In contrast, Software Product (SP) development is software development done by an organization for multiple customers. It could encompass periodic new releases and is often shrink wrapped. Exhibit 1 presents a process commonly used for IS development.

Exhibit 2. Product Development Process

Product Development Process

This is a waterfall approach with phase reviews held prior to the start of the next phase. The phases have predetermined criteria that have to be met before work on the next phase can begin. In contrast, the process for SP development has significant overlap between the phases and there are a larger number of phases. Each phase has one or more reviews not necessarily held at the end of the phase (see Exhibit 2).

IS development and SP development are similar but there are some essential differences. A comparison of the two is given below, based on the phases presented in the Exhibits.

Project Initiation Phase

In this phase for IS development, the customer objectives and needs are determined, senior management approval is obtained, and the statement of work is prepared and approved by the customer. A statement of work should include the customer's requirements, delivery schedule, and training requirements.

The biggest difference is that for IS development, there is a customer and the development organization can work with that customer to define the requirements. Therefore, the project can be started with a very good understanding of the customer needs and how to solve them. In contrast, for SP development there might be only a vision and high level marketing requirements.

Technical Assessment Phase

During this phase software rollout issues are determined, the software architecture, Human Machine Interface (HMI), design documents are completed and the project plan, work breakdown structure, and schedule are prepared. The project plan is a cooperative effort between the project manager and the team. The goal is to obtain a clear understanding of the work to be performed and to set a basis for monitoring and control. The project pan should include: development strategy, risk management strategy, constraints and assumptions, verification strategy, quality objectives, user documentation plan, performance measurement strategy, project contacts, configuration management, problem tracking, resource requirements, training needs, procurement, delivery, and training needs.

At this time the project manager would ensure that communications tools such as the project website, issues tracking tools, and mailing lists are set up. It is also important to plan for deployment activities during this phase and agree on an acceptance test criteria.

This phase in SP development consists of project definition, design, and user documentation phases. For IS development installation and deployment requirements can be obtained from the customer and the customer would be signing the acceptance test criteria.

For SP development the installation process has to be much more robust and flexible to allow customers to easily install the product under varied conditions. Decisions about the software delivery have to be made during this phase. Questions such as how is the software going to be shipped, does documentation need to be printed, how are the customers going to be trained need to be answered. In addition, does the customer need to upgrade third-party software/licenses for Operating System and databases? The product scalability and its cost effectiveness for small customers should be considered.

System Development and Test Phase

During this phase for IS development, the software is developed and unit tested, detailed test cases are completed, hardware requirements are determined and each feature is rolled out to the verification group. Once the code is completed, system test phase begins and typically, only one configuration needs to be tested.

This phase in SP development corresponds to implementation, verification planning, and testing phases. For SP development, many hardware/software configurations have to be tested. Installation and upgrade paths must also be tested. Installation documentation must be verified and the verification team has to follow the installation guidelines in the same manner as the customers. There has to be a lot tighter defect control with the Product Control Board making decision about which defects have to be fixed.

Customer Field Testing and Acceptance Phase

This phase is held at the customer's site in lab or controlled environment with the help of the deployment team. The development team provides fixes as needed.

This phase for SP development corresponds to engineering release. For IS development this is the customer final acceptance of the system, while for SP development this is a beta version, and beta testing starts with key customers. The product is reworked based on the beta test results and the user documentation is finalized. At the end of this phase, the software is mastered; part numbers and bill of material are assigned; the CDs, user documentation, installation instructions, and release notes are completed; and the support staff is trained. The product is ready for general availability.

Project Completion Phase

The project manager holds a project retrospective review in order to document what went well, what did not work, and lessons learned. At this time the project manager also ensures that the project is archived including all the source code, documentation, test tools, development environment, meeting minutes, and schedule. This phase is the same for both IS and SP development.

Project Monitoring and Control

For both IS development and SP development the project manager has to follow good project management practices. He or she has to create and maintain the project plan, hold regular reviews of progress against plan, update the schedule on a regular basis, hold phase reviews, hold regular team meetings, and update issues and risks. In addition, the project manager must report progress to senior management and other stakeholders.

General Comparison

Other differences between IS and SP development are that for SP development there are the schedule pressures caused by market drivers. With SP development, collateral material and trade shows demos are needed well in advance of product completion. Since there is a tendency by sales and marketing to sell “vapourware,” the project manager should advocate reviews by the development team, prior to publishing, to avoid any misrepresentation of the product.

With SP development one must consider product launch. The product manager is responsible for the product launch. He or she needs to do internal presentations to ensure that the team is on the same page. Another difference between IS and SP development is the customer release management. To achieve smooth product roll out, for SP development, the organization has to keep up-to-date inventory such as: number of customers and their site data as well as a list of hot customer issues. The project manager should ensure that the following are addressed:

•   The upgrade process

•   Communication of any changes to software or hardware required for the new release

•   Updates to the external product website.


The key to success in managing software products is that of managing risk. Here are some common risks in SP development and some mitigation strategies.


The biggest risk is the inability of many product managers to define the requirements clearly. In many cases the product manager is unable to convey to Engineering the product requirement because he or she is unsure of the market need and in general, product managers are not details oriented. In order to clarify the requirements, use cases, operational scenarios, and Graphical User Interface (GUI) mockups should be used. Engineering needs to do prototyping and deliver early iterations to Product Management. This will ensure that there is no misunderstanding between the two. It also allows the product manager to validate the marketing requirements with the user community. It is essential to have several key customers since this will enable the product manager to abstract the customer needs in order to develop a product suitable for a large user community.

Extra care must also be taken if there are third-party developers involved. In this case, the requirements have to be specified in detail, with frequent progress reviews.


One technological risk is the use of unfamiliar or unproven technology by the development team. The project manager needs to ensure that the development team is focused on the customer's problems and not solving technical issues just for the sake of it. One way to deal with technological risk is to break up the development into iterations with deliverables very early in the product development. This forces decisions about the technology early, when not much has been invested in development. Other technological risks are scalability, which encompasses the number of simultaneous users, reports, records and data sizing, network topology and scaling. It is very common to forget these requirements until the product is in beta test at the customer's site. The project manager needs to ensure that there is a resource committed up front in order to test scalability as the product evolves. The scalability requirements should be identified up front and should be part of the requirements document in order to ensure that there will be test cases developed to address these issues. The architecture of the product needs to consider future expansions, which also is another technological risk. Although it may not be feasible to have this in the first release, developers need to think and plan for it.


During the development of the product, product managers, driven by changing markets will request additional features. In these situations, the Engineering team is often eager to please and this leads to scope creep. The project manager needs to have a change control system in place and must ensure that all parties understand the full impact of a change. This is not just the impact to development, but also the impacts to verification, documentation and technical support. Since in most organizations there are limited resources, any change to the requirements will result in reprioritization of tasks. It is the project manager's responsibility to facilitate the decision-making process relating to scope change.

Time to market

Time-to-market forces exert intense pressure to skimp on quality. Time-to-market products need to focus on meeting the delivery date. The value of a product with a schedule constraint decreases exponentially. Some examples of products that fall in this category are:

•   Gaming industry, where the games must completed in time for Christmas sales

•   Educational software, where the product must be released prior to the beginning of the school year

•   Companies with limited financial resources that need the product revenue to survive.

If the product must be shipped by a certain date, the project manager must ensure that the requirements are prioritized and that the drop-dead dates are identified. The team has to know which features are important and concentrate on developing them. In addition they need to know what can be dropped and when. The project manager has to ensure that product quality requirements are identified, up front, in the project plan and enforce them. Skimming on quality may get the product out on time, but there are high costs associated with supporting a poor product such as loss of customers and draining development resources resulting in an inability to complete future releases.


It is the project manager's duty to ensure that there is good communications between development and product management as well as other support groups. The key to a successful product development is good understanding of the product, what it is going to do, who will use it, and what differentiates this product from the competition. It is the project manager's responsibility to keep senior management informed of what is in the product and what is not going to make it. The project manager also has to facilitate communication between the product manager and the development team to ensure that every one understands the road map. In addition, the project manager must arrange frequent presentations to senior management in the form of demos, mockups, and prereleases. This will ensure that management sees progress and that the development team is meeting the product manager's requirements.


In order to mitigate schedule risks the project manager needs to follow good rational practices and enforce the work breakdown structure. Some schedule risks are:

•   Overly optimistic schedule relating to unfamiliar areas that may require longer time than planned—The way to mitigate these pitfalls is to identify them up front and validate the estimates through the use of prototypes.

•   Omission of necessary tasks—To avoid task omissions the project manager needs to have the schedule prepared by the whole team: product management, development, verification, user documentation, customer support, and deployment.

•   Schedule is based on certain resource availability—The project manager must obtain senior management buy-in and obtain a sponsor for the project.

Ultimately, as in the time to market risk mitigation, the project manager must know what can be dropped and when.


As discussed in the time to market section there may be a tendency to short change quality. To meet the deadlines, the team may want to bypass design and code reviews. This will not only result in rework, but it will also leave the organization vulnerable if key personnel leave. Design and code reviews are a good way to train staff.

In some situations, the verification team ends up testing the wrong features. It is very important that the project manager ensures that the test scenarios are reviewed by all the stakeholders and that the verification team understands how the product is going to be used. They need to be involved up front in reviewing requirements, HMI documents and functional specifications. It is essential that everyone understand that low defect rates and short delivery time go together. The project manager must also ensure that all defects are triaged and prioritized.


The risks associated with the software process are that it may be too cumbersome, may require too much paperwork and put a burden on the development team. The project manager has to make sure that everyone understand that a process is just a means to an end. Everyone should be encouraged to question the process. However the project manager must emphasize that too many shortcuts in the process will result in rework.

Delivery Strategy

A common strategy is staged delivery, where the project is broken down into several iterations. Each iteration is planed as a mini-project and some iterations may be delivered to the customer. There are a few advantages to this form of delivery: critical functionality could be delivered first, requirements and technical risks are reduced, the customer can start training and using the software early. Iterative development also makes it easier to track and report progress, but it does introduce some additional overhead such as retesting, version control, and installation.

Product Rollout

Very often when the product roll out and logistical issues are ignored at the start of development, it may lead to major delays during installation at the customer site. The project manager needs to ensure that these issues are addressed at the beginning of the product development. In some cases, this may require a separate resource. For example, the Microsoft Solutions Framework has the role of a logistics manager who takes care of these issues. Some of the questions that need to be answered are:

•   Third-party software—What third-party or “share-ware” software is used, what are the licensing requirements?

•   Product installation tools—Is the customer able to install this product or does it require a field engineer?

•   Is this a new customer or an existing customer? What upgrade tools are required and does the customer need to upgrade third-party software or even hardware?


Project management for SP development, in comparison to IS development, has more dimensions in terms of customer management, unclear requirements, rollout and time-to-market pressures. There are also similarities; in order for the product or project to be a success, the key issues must be identified up front.

Good rational Project Management and Software Engineering practices are the cornerstone for successful software product. The project manager has to be flexible, has to understand the risks, has to deal with various methodologies, and has to quickly recognize the differences and similarities when dealing with projects involving software.


Charette, Robert N. 1986. Software Engineering Environments—Concepts and Technology. Intertext Publications Inc.

McConnell, Steve. 1996. Rapid Development—Taming Wild Software Schedules. Microsoft Press.

McConnell, Steve. 1998. Software Project Survival Guide. Microsoft Press.

Toth, Kal. The Software Engineering Process: Principles and Applications, lecture notes, Intellitech Consulting Inc.

Project Management Institute. 1996. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Upper Darby, PA: Project Management Institute Standards Committee.

Wideman, Max R. 1996, Project Management Framework, PMP Exam Preparation Coarse Notes, Simon Fraser University

Microsoft Solutions Framework,

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA



Related Content