Meshing marketing and IT for internet product development project

Consider this real-life example.

The phone call comes mid-afternoon on Friday, informing you the new release will not be installed over the weekend. Problems emerged during final testing and IT is postponing the release for a week to do repair. “Is that a problem,” the caller asks. Since letters were mailed to thousands of customers on Monday telling them about the new site and its debut, following a month of promotional effort by the sales force, yes it is a problem. After an hour's worth of frantic meetings the problem is resolved. But only by putting every internal sales rep and customer service agent to work well into the evening, calling customers to explain why the letter they just received is wrong.

The result? Internal confusion becomes public knowledge. Customer service suffers in the temporary re-deployment of staff. Sales lag as selling and relationship-building stop. The company's credibility takes another hit with its customers. All this essentially because IT, marketing, and sales have been working independently to develop and rollout the same product. How could this happen?

Exhibit 1

images

Internet-Based Products

Internet-based products are the websites an organization uses to deliver goods and services or to channel product flow. Developing Internet products is not an easy task. No longer will a collection of simple web pages suffice. As a product in its own right, the website is the public front-end for a series of internal human and computer systems. Successful product development requires significant effort and coordination between many functional units in an organization.

The advent of the Internet and World-Wide Web brought marketing and sales into a closer working liaison with IT than they previously “enjoyed.” Indeed, it has forced these groups into an uneasy alliance.

One frequent point of conflict is the different way these groups view project management. Formal project management is an emerging concept in marketing remaining, when it used at all, an informal practice. Sales forces, typically quota-driven, are even more informal in their project management approach. Meanwhile in-house IT groups and IT consulting firms adopted project management methodologies long ago.

Internet product development brings these approaches into conflict at the mythical “Internet speed.” The life cycle for Internet products are far shorter than for traditional products. So they require a faster-paced and more iterative spiral in a constant cycle of enhancement until the product's eventual replacement.

Internet products reflect complex business models, touching many parts of the business and, more important, the client or customer. Managing an Internet product development effort is more than project management, however carefully undertaken. Rather it requires a significant awareness of customer needs, the art of customer interaction, and a primary focus on the project integration, project risk management, and project communications processes of the PMBOK® Guide (1996,2000).

Or, to put it another way, Internet product development requires a marketing overlay on project management disciplines.

We need a way to combine the “lose coupling” flexibility of marketing and sales functions with the “tight fit” rigor of IT departments. Starting from the business needs of marketing, sales, and product development groups as well as the milestones of a typical IT project, this paper proposes an approach to guide project management in developing and implementing Internet-based products.

This paper offers “Five Essential Concepts” to guide thinking and planning for Internet-based product development, to assure that all requisite business units and functional departments are involved as early as possible. The Concepts help develop the internal organization for the product development effort, and are usable whether the work is kept in-house or is outsourced. Of these Five Essential Concepts the first, that of a “Framework,” is the most critical to success since it helps coordinate the differing approaches to project management of the functional departments.

Five Essential Concepts

Avoiding these situations can be come much easier once five concepts are grasped and applied. These five—Framework, Timelines, Roles and Responsibilities, Checkpoints, Stages— outline the essence of how IT, Marketing, Product Strategy, and other business functions can be aligned for Internet-based product development (IBPD).

The Concepts blend the activities necessary for both technical development and marketing campaign timelines, compelling all functional units to be aware of their mutual needs and dependencies. One key point: Each of the Five Essential Concepts is linked to other Concepts. That is why they are “Essential.”

Let's briefly examine each of these.

Framework

A framework serves as a guide to focus attention on what's important. A framework is not a project management methodology. Rather, a framework links together differing project management methodologies or even functional units without a project management methodology. Since project management approaches differ between functional units, such as IT or marketing or sales, a framework gives the project team a common reference for accomplishment.

Because of this, a framework is especially useful in properly setting expectations for the time frame or level of effort required in product development projects. It does this by identifying all of the essential phases and by identifying time relationships for them.

A framework differs significantly from a project management methodology. A framework operates at a higher level of detail and covers the entire life cycle of a product—the time between product conception to complete replacement, including enhancements or upgrades short of a complete refit. While a framework can become a project management methodology, usually it serves to overlay the methodology. During the course of IBPD the effort may be translated into one or more projects.

A framework is especially critical for cross-functional projects, such as IBPD. Project and development processes tend to be specialized by functional unit. As a result, functional processes aren't easily transferred between functional groups. However, a framework identifies and links dependant processes so all involved functional groups can manage their level of effort accordingly. This compels all involved functional areas to be aware of their mutual needs and dependencies.

Timelines

Typically an IT project establishes its timeline in the project plan. While the plan is based on key dates established by the customer, that is no longer enough for product development. Each functional department has its own timeline for its own unique activities, which is typically not fully communicated or presented in a project plan.

Nonetheless, these timelines are important since each has a number of significant dates. The opening example illustrated this, when the dates for communicating with customers was not part of the IT unit's project plan or decision-making. As a result significant project risks were overlooked.

So, it is fundamental to this Concept that several separate but related timelines be linked throughout the product development effort. Some examples include:

•  A Product Strategy timeline traces the identification of new business opportunities, product or service development, and validation of the opportunity throughout development.

•  A Technology timeline illustrates the effort necessary to design, develop, test, and implement the technical work necessary for an Internet-based product.

•  A Marketing timeline outlines the effort needed to create, develop, communicate, and implement a new Internet-based product or service to customers or clients.

•  A Sales timeline details the process to train and motivate internal and external sales people to promote the new product or service.

When these or other timelines exist in isolation problems erupt, leading to delays and a poor fit between the business opportunity and product, resulting in client dissatisfaction and lost business. By integrating timelines we focus the attention of the technology staff on business and marketing issues, and of the business and marketing staffs on technical needs. Timeline integration should result in closer and smoother working relationships and communication.

By joining timelines all participants come to recognize their mutual dependence. While IBPD is a technology-based endeavor, it must occur in full recognition of the business environment and time-to-market demands on the product.

Roles and Responsibilities

It is important to distinguish between these two, as well as between roles and job descriptions. A person, who probably has only one job description, may fulfill one or many roles during product development. For example, if the product is an extranet a customer service representative might perform the Customer Service, User, and Quality Assurance roles during product development.

It is critical to understand that the project team must include all of the identified roles, which may or may not be identical to the following list. While a role may not be a full-time assignment for the full life cycle of the product, their use and involvement is critical to IBPD.

More to the point, all team roles must be represented at the project launch meeting. This way all units involved receive early warning of the product development, the degree of their involvement, and the delivery dates of product components or documentation they are dependent upon.

The following list identifies some typical Roles for IBPD, in the left-hand column, and briefly describes the responsibilities in the right-hand column. Following the description, in parenthesis, is a note of the likely functional unit to provide staff to fill the role.

Product Sponsor—Responsible for coordinating Internet product development efforts across all business unit products and functions (Sr.-level Business Unit)

Product Manager—Responsible for assuring that the finished product meets business requirements within the agreed budget and time constraints (Business Unit)

Project Manager—Responsible for assuring that the product is delivered meeting functional requirements within the agreed budget and time constraints (IT or Business Unit)

Steering Committee—Provide overall guidance and leadership to the product development efforts and relevant projects as the CEO (Business Unit), COO (Business Operations), and CIO (IT) for the product development (Sr.-level managers)

Relationship Manager—Responsible as the interface between the IT department and the Technical needs of the product development projects (IT)

IT Development—Responsible for designing and building an Internet-based product that meets the customer's expectations (IT)

Quality Assurance—Responsible for the testing and product review required to deliver a quality product (IT)

Business Operations—Responsible for assuring that existing business operations and the new Internet-based product operate together smoothly (Customer Service, Sales)

IT Operations—Responsible for assuring a smooth rollout and continuing operation of the new Internet-based product (IT)

Customer Service—Responsible for supporting clients in their use of the product (Customer Service)

Legal and Compliance—Responsible for compliance to the legal and regulatory environment in which the product is developed (Legal)

Users—Responsible for helping the project team develop a product that meets user needs (target audience)

Training—Responsible for helping the users understand and use the product (Business Unit or IT)

Any or all of these roles may be required in any stage of IBPD, but all roles should be identified and staffed for the initial project launch meeting. For each deliverable in each stage a role is designated as either “Responsible” or “Involved,” although only one role will be “Responsible” for the deliverables.

The “Responsible” role has the responsibility for completing that step in the process and is accomplishing the deliverable. They are responsible for obtaining signoff once the step is completed.

The “Involved” roles are necessary to accomplish the activities and deliverables for that step. The “Involved” role may be required for any step or deliverable to be accomplished. However, those who are “Involved” will be working with the person in the “Responsible” role and do not have direct responsibility for accomplishment themselves.

Checkpoints

The Timeline icon in Exhibit 1 illustrates this Concept. Checkpoints occur where timelines converge at the centerline. They are the times when a deliverable is made available for review by two or more functional units. For example, completion of a functional requirements document would indicate a checkpoint for IT and business units.

These checkpoints are vital for maintaining the communication flow between all effected and involved parties in product development. Internet products are developed to support or enable market initiatives and therefore involve multiple functional units. Accordingly, as each functional unit works on the product, several timelines operate concurrently and in parallel. A successful IBPD project mandates that timelines operate in conjunction and come to closure at the same time. Checkpoints assure that this happens.

Stages

The last Essential Concept in its entirety is frequently referred to a “life cycle.” Stages distinguish the transitions an IBPD project experiences as it moves from being a “bright idea” to being an operational Internet product. Breaking these transitions into stages makes it easier to schedule resources across functions. More important, it creates awareness of the pre- and post-development activities that tend to get lost in planning, even though they require resources and time.

To be comprehensive, nine stages are described in this section, although your actual number may vary. The stages can be divided into three processes. One process, consisting of the first three stages, will occur frequently probably without resulting in product development. This is akin to R&D and is equally as important. The second process, the “core process,” consists of stages four thru eight and must occur for every IBPD that makes it past stage two. This process is the actual product development. The last process is the implementation, or rollout, and will occur only once for each IBPD project.

Each stage results in one or more deliverables, typically a documents) summarizing the results of the work in that stage. For this paper however only the crucial deliverable is identified and briefly described. This is the deliverable that is used by each functional unit involved and marks a point where the separate Timelines converge, as illustrated in Exhibit 1.

The first three stages form a “Feasibility Process,” since their role is to define, and determine the feasibility of, any product or service idea. This process normally begins when an appropriate manager is persuaded to investigate a product idea, customer suggestion, etc. The first two stages can occur many times before a product idea moves into the third stage. Typically the third stage ends with he launch meeting for the IBPD project.

1. The Discovery Phase—Discovery defines the product idea, describes the intended results for the Internet product, and establishes the business case and objectives for the product. Key Deliverable: Description of the proposed product, including business justification.

2. The Definition Phase—Definition establishes the scope of the product, including the number of projects its overall development will be divided into, and a high-level project plan and budget. Risks involved in developing and implementing the product are identified and ways to mitigate the risks described. Based on this work, the business case and justification will be revised. Key Deliverable: A project plan, including schedule and risk mitigation strategy.

3. The Formalization Phase—Formalization initiates the actual IBPD. Charters for the new Internet product and the initial project are established, along with the budgetary authority. Project team candidates for each role and stage of the product development project are identified, evaluated, and selected. Key Deliverable: Document containing the product development charter and identifying the resources made available to the project.

The next five phases are referred to as “Core Processes” because they form of the core of the IBPD activity. These five phases also occur for each subsequent release of the product, which means they occur one or more times for every product.

1. The Design Phase—The Design establishes, subject to acceptance by the business units involved, functional and technical requirements, as well as the look-and-feel of the product. The entire project team determines how the quality and reliability of the product will be developed. Once the design and requirements are complete, the project's budget and schedule are validated. Key Deliverable: Design document describing the business, functional, and technical requirements.

2. The Construction Phase—In this phase the Internet product is built and each component of the product is unit tested. This includes the Internet application, user interface, database(s), text or graphic content, and all required server hardware. Key Deliverable: The completed Internet product and all ancillary hardware or software.

3. The Testing Phase—This phase includes all of the quality assurance activities for the complete Internet-based product in a simulated production environment. These activities include testing the product as a whole, integration with existing Internet products and applications, performance under user load, acceptance by users, and usability. Key Deliverable: Completed test plans for each series of tests and signed acceptance by the Project Sponsor.

4. The Deployment Phase—Deployment includes the activities that support deploying the Internet-based product, technical infrastructure, and training to make the product generally available on the Internet. Key Deliverable: A fully functional Internet-based product with around-the-clock availability to its intended customer base with best available performance.

5. The Closure Phase—The Closure phase marks the end of the project with the attendant tasks of project closeout. This phase also focuses on reviewing the product development effort to establish a “Lessons Learned” document for future Internet product development efforts. Key Deliverable: Complete project files, including the “Lessons Learned” document.

The last stage is the “Operational Process” that covers all of the activity, planning, and resources required for the continued availability and maximum performance of the Internet-based product to its customers.

6. The Operation Phase—This phase encompasses all of the activities involved in the day-to-day operations of the product in the production Internet environment. It includes the review of site usage and performance metrics and periodic reevaluation of the product based on those metrics. The Operation Phase continues until the next version of the product is completed and deployed. Key Deliverable: System Administration manual, which explains how to operate and maintain the product in the production Internet environment.

Conclusion

Experience has shown that applying these concepts can smooth project integration, facilitate risk identification, and enhance cross-functional communication. Applying these concepts has enabled client companies to reduce the development cycle for Internet product releases to as few as 60–90 days.

Experience has shown that in the Internet world of e-commerce, product development is essentially project management taken to a higher level, organizationally and functionally, and front-ended by a customer-centric perspective. It is as important to the success of IBPD efforts as project management techniques are to the success of projects.

The PMI Marketing and Sales SIG was founded to bring the disciplines of project management into the fields of marketing and sales. An approach that embodies these “Five Essential Concepts” furthers this mission by easing marketing and sales professionals into project management using a perspective they can appreciate.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Identifying Challenges and a Research Agenda for Flow in Software Project Management member content locked

    By Dennehy, Denis | Conboy, Kieran Flow and its associated tools and metrics are increasingly being reported as an approach used to achieve continuous deployment of software and delivery of value in software development projects. Yet…

  • PM Network

    Escaping Pilot Purgatory member content locked

    By Waity, C. J. Pilot projects can bridge the gap between a brilliant idea and a valuable product—but only if the bridge is successfully completed and built to scale. And in the age of disruption, that doesn't…

  • PM Network

    Hands-On member content locked

    By Karunaratne, Charmaine Although the software development life cycle (SDLC) is an important part of any software project, IT project managers rarely seem to raise the topic. Instead, they leave it to the development teams…

  • PM Network

    Best of Both member content locked

    By Graetsch, Ulrike Maria When leaders at rapidly growing organizations establish a project management office (PMO), they're often seeking better control over which projects are started, more oversight of projects in…

  • Project Management Journal

    How to Buffer the Family Costs of Project Citizenship Behavior member content locked

    By Zhong, Rui | Xia, Nini | Hu, Xiaowen | Wang, Xueqing | Tiong, Robert Previous studies have mainly concentrated on the desirable aspects of project citizenship behavior (PCB) but largely ignored its dark sides. We seek to fill in this gap by exploring whether and when…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.