Project management in marketing

the key to successful product launch

Madeline A.Veltri, PMP, Project Director, iXL Corporation

Marketing organizations are unique environments for project managers to work in. When I decided to join a Marketing organization and leave the Information Technology group, I was intending to conduct a large experiment. Could Marketing benefit from the structured and disciplined project management processes that have been driving successful software development programs for years?

The answer is emphatically yes! Marketing can absolutely benefit from sound project management practices. It has been a challenging endeavor, however, I have found that in the absence of effective project management, Marketing will be severely impaired from successfully launching quality products. They will not achieve speed to market. They will not deliver quality products at a reasonable cost. In short, they will fail to meet business targets and ultimately, customer satisfaction.

If you find that your marketing organization needs project management help, read on for some best practices and challenges.

Best Practice: Develop Your Strategy for Success

The first part of the journey that must be taken is to gain a good understanding of the business objectives of your organization. What is Marketing focused on? What is their vision and strategy? In my particular organization, the main objectives were to:

  1. Deliver repeatable solutions
  2. To the target market
  3. With Operational Excellence (this was a quality statement)
  4. And Speed to Market

Once the business objectives are laid out, then the current state of affairs should be investigated. This is essentially an assessment of the organization's project management capabilities. In my particular case, this was easy. There were no project management capabilities at all.

So where to start? Considering my organization's objectives and low level of project management maturity, almost any PM technique could provide some improvement. However, the initial efforts needed to pinpoint specific areas in order to gain some short-term payback that would fuel future efforts. The decision was to focus on the “pain points,” or those areas that were providing the biggest obstacles to achieving the stated business objectives.

Tips and Techniques

1. Whatever your organizations’ priorities are, it is critically important to be able to clearly articulate the value of what you are trying to accomplish. The organizational objectives and strategies must always be the driver for implementing project management processes. I found it very helpful to start with a presentation that illustrated what my vision was as to how project management would be absolutely necessary to achieve the firm's objectives. I call that my “sales pitch.” As we evolved and implemented the project management processes, I continually updated this presentation, including the progress made, and presented it periodically to senior management.

2. Provide quantifiable measures to determine progress. For example, on the speed to market objective, one could measure the cycle time of product launch prior to implementing the PM processes and then subsequently measure the improvements as a result of the PM processes. If results cannot be measured with hard data, then “soft” improvements will have to suffice. The key is to always be able to articulate your vision and your progress toward that vision.

Best Practice: Project Scheduling

Before implementing project scheduling, one must define what exactly a project is. In my marketing world, a project was a product development and launch effort for a specific service offered to a number of potential customers. A project included the following main components:

• Market research to determine the need for the product and customer requirements

• The design and build of the product

• The development of the financial business case for the product

• The design and implementation of all service delivery processes: for example, ordering, provisioning, administering, and billing for the product

• The design of the sales plan and sales processes, including identification of what amounts of revenue would be generated through which particular channels

• The training and rollout of the service delivery and sales processes

• Identification and development of all marketing communications materials and sales tools

• Coordination of the public relations strategy.

Project scheduling was initiated because the organization needed a method for forecasting the length of time a product would take to develop and launch. Since many different functional groups were typically involved in every product development and launch effort, a project schedule was absolutely necessary in order to facilitate the matrix-managed effort. Project schedules would identify:

• All tasks and deliverables needing to be accomplished

• Who was dependent upon whose deliverables (there were typically many dependencies between tasks in a product launch plan)

• When the sales channel(s) could be trained

• When the product could be made available to customers

• When the product could be announced to the press and industry analyst groups

• When the organization could expect to begin booking revenue for the product.

Having reliable project schedules would also enable the organization to know what products would launch at around the same time, in order to coordinate work efforts across product lines. For example, the sales channels could coordinate training of more than one product at a time, marketing/communications materials could be produced for more than one product, and the press announcements could announce more than one product at a time. In other words, knowing the product launch schedules enabled the organization to more effectively utilize resources and possibly gain economies of scale.

Project scheduling directly addressed the repeatable solutions and the speed to market business objectives of the organization. Having a detailed project schedule enabled the cross-functional teams to work in a more coordinated fashion, thereby reducing the overall cycle time. Additionally, the same project schedule could be utilized by other teams as a template, thereby beginning to build repeatability.

The other significant benefit of project scheduling is that it provides a basis for performance reporting on projects. Once the project schedule has been developed and baselined, it provides the basis for which the team can gauge and report detailed progress of the overall effort. The team will then have the early “heads up” when tasks are running late and potentially jeopardizing the committed dates. For progress reporting to be effective, however, it is necessary to keep the project schedule current and accurate with tasks marked as complete or with revised estimates-to-complete if necessary.

Of course, how effectively can we accomplish project scheduling without having a product development and launch methodology? How would one even know what to put in a project schedule unless there is some sort of road map, or template, to start with? The next Best Practice will address this area.

Tips and Techniques

1. Don't just make To Do lists. Good project scheduling considers all tasks, their durations, and their dependencies. Dependencies are particularly important in product launch because so much of the work of cross-functional teams is interdependent. Good project schedules are also resource-constrained (consider the availability of human resources and schedule accordingly).

2. Let the schedules determine key milestones, such as product announcement. Don't fall into the trap of having senior management set these dates without the detailed project schedule data to back them up. If you must meet “management set” milestones, seriously consider scope reduction techniques, such as elimination of product features.

3. Use the cross-functional team to develop the project schedule. They must be able to identify tasks, furnish estimates and also supply their available time to work on the project. If they build the schedule, they are more likely to live by it and it will be more realistic.

4. Make sure that you document all of the assumptions made and the risks identified with the project schedule. The assumptions should be validated (or not) during the course of the project and the schedule subsequently adjusted. The schedule risks should be monitored and managed on a continual basis with the whole team's participation.

5. Try to keep tasks to 80 hours or less. Tasks greater than 80 hours are difficult to status and manage. You may be 80 hours into the task before you find out it is behind schedule.

6. To learn more about project scheduling and some good techniques, refer to the Scheduling Discipline article referenced in the References section.

Best Practice: Adopt a Product Development and Launch Methodology

The challenge here is that typically Marketers view process as stifling their creativity (this is an acknowledged generalization). The positioning with Marketers, therefore, needs to be in convincing them to use their creativity on the product (or service) itself instead of reinventing the methodology each time. Using a standard development and launch methodology (or process) will also allow them to focus more on the customers’ requirements. Creativity applied to the methodology during the execution of every project will only serve to elongate the overall cycle time. The use of a standardized methodology will therefore address the business objectives of repeatability and speed to market.

We could have chosen to develop a full-blown process, instead of a methodology. The intention in developing a methodology was to allow the team members flexibility in choosing how to accomplish the work, instead of dictating the actual steps and procedures. The methodology definition focused on the establishment of templates, examples, checklists, and tools that should be used for all product development and launch projects.

It should be noted that there is no right or wrong methodology. There are many possibilities to choose from. What is important is to pick one and to stick with it. Make the methodology work for your organization. If it is not working for you or improvements can be made, then tweak the necessary components and continue using it. This is what is referred to as “continuous process improvement.”

There is one strong component that a good product development and launch methodology or process will have, however; that is a thread of “voice of the customer.” It is critical that the customers’ needs and expectations are known and addressed. Specific techniques and entry points into the methodology must be defined. Additionally, it is vitally important that the customers’ key purchase criteria and profile (what does a customer look like?) be known in order to be most successful in launching and selling the product.

A good product development and launch methodology will be the enabler that focuses each team member on:

1. What their responsibilities are

2. What information their deliverables should include and in what format

3. What the sequencing of their deliverables are

4. Who are they dependent on for their deliverables

5. Who is dependent upon their deliverables.

I know that in my particular organization, I definitely underestimated the effort it would take to successfully deploy a product development and launch methodology. When I first started out, I thought the challenge was in the definition of the methodology itself (we built ours from scratch). However, in retrospect, the real challenge was in the organizational change management. Getting buy-in and participation in the methodology from people with many diverse backgrounds and in many different functional areas proved to be overwhelming at times.

It is hard to overestimate the value that the product development and launch methodology brought to my marketing organization. It provided the common language that the organization could use to improve communications and team performance. Use of standard deliverables improved the ability of team members to “plug and play” with other product lines. Additionally, the use of standard deliverables and methodology significantly improved the organization's ability to orient new team members.

Tips and Techniques

1. The biggest challenge (for me) was in communicating the interdependencies of the work. It can be a very complex effort to get a product out the door! I believe that if all team members truly understand how much other team members are dependent upon them, then they will be more likely to turn in quality deliverables on time.

2. Gain senior management commitment to and involvement with the methodology. Senior management must be responsible to hold the teams accountable for adhering to the methodology. Establishing a senior management forum for this purpose is a good technique. In my organization, we set up a regular monthly meeting for senior management where the development and launch teams would either review their progress or present their cases to move through the various stage “gates.” The senior managers’ roles were to either approve or disapprove the teams’ movement to the next stage of development. Our methodology even included templates for the executive presentations.

3. Educate, educate, educate. Consider this an investment, because it will definitely cost time and money. The cross-functional teams, functional managers, senior management, and any other stakeholders must be knowledgeable about your methodology.

4. Publish “best of breed” examples of deliverables. What does a good Sales Operations plan look like? Publish the best one you have for the rest of the organization to emulate.

5. Get a “poster child.” Use an exemplary team as the showcase for the methodology. Use their successes to sell the benefits of project and process management across the organization.

6. Develop champions in the organization that are influential and will be able to provide assistance. Within my specific organization, I was able to develop alliances with the CFO, Legal Counsel, and sales management. These folks provided significant amounts of support and commitment both to senior management as well as the “troops.” They coached and they held the teams accountable for producing quality deliverables.

7. Make sure you understand your sales channel(s)' requirements for launch. You may need to consider the sales channel as an internal customer of your product. If you get all the way to the end of your project (ready to launch product), and you have not met the channel's launch requirements, they could refuse to sell your product. I found it practical to understand sales channel requirements first, and then work backwards to ensure all of the requisite elements are defined in the methodology deliverables.

Challenge: Practice Risk Management

Risk management is a hot topic in the project management community. There are many publications, articles, and in general, a lot of material that deals with risk management. It is puzzling therefore, why many project teams (especially in a Marketing environment) are not practicing sound risk management practices, or even managing risk at any level.

In order to effectively manage project risk in a marketing and product development environment, the risks must be identified early in the project lifecycle, ideally in the concept phase. Early risk identification will enable the organization to make more effective decisions regarding the firm's investment in the product development. If the risks are expected to outweigh the ultimate benefits, then perhaps the investment in the development and launch of the product should be reconsidered. Better to know that information prior to sinking significant amounts of funding into product development efforts.

Subsequently, throughout the project lifecycle, the risk management plan should be updated: existing risk should be reevaluated and new risks should be identified. Generally, this should occur when the team moves from one phase of development into the next phase.

The most comprehensive risk management plans are developed with the participation of the cross-functional development team.

Risks can come from many different sources, and a brainstorming activity by the product development/launch team will be able to uncover many of the project risks. The project manager's role is to facilitate this brainstorming session and ensure that all facets of risk identification have been considered.

In terms of product development and launch projects, risk identification can be generally broken down into four categories as follows:

1. Technical risk. This is risk associated with the technical aspects of the product. Is the team using any new technologies that are considered on the bleeding edge? Is the team trained and technically competent? Has the product been designed well?

2. Market risk. This is risk associated with the potential market in which the product will be sold. Has the team validated that the product will be likely to be purchased by potential customers? Has the team identified the target market for the product? Is the product being developed with specific customer requirements in consideration?

3. Financial risk. This is primarily risk in the business case. Is the product cost effective to develop and launch? Will the firm benefit financially over the product lifecycle? Does the business case have a positive Net Present Value over a given time period?

4. Organizational risk. This category of risk is related to the organization itself. Does the cross-functional team have the right skills to succeed with the project? Is the sales force competent in the product's area in order to be successful selling the product? Can the cross-functional groups effectively work together to develop and launch the product?

After the risks have been identified, they must be also be quantified, so that the team can prepare effective action plans and programs to respond to the potential risk. Risks can then be ranked, which will enable the team to determine which risks warrant immediate response and in what order they should be dealt with.

An effective technique is to measure risk, not only in terms of cost to the project, but also measure the risk in terms of cost to the firm's business case (effect on NPV, profitability, revenue targets, and the like). For example, assume a risk is identified that will impact the project timeline (product launch) by one year, perhaps the availability of a key technology has been delayed for one year. The quantification of the risk should include the cost to the project (additional funding for project personnel), and also the cost to the business. In this example, the cost to the business is probably measured in terms of delaying revenues for an additional year. The firm can then consider whether the product still provides an attractive investment opportunity.

After the risks have been identified and quantified, then the team should brainstorm again to develop action plans for each high impact risk. If the risk is “unknown market/customer acceptance of the product”; for example, the project team can develop a risk mitigation strategy that would include market research activities, such as focus groups. The project manager's role is to ensure that all major risks have identified action plans (mitigation plans) and that those plans are subsequently factored into the project schedule.

Tips and Techniques

1. The project sponsor (and key stakeholders) should be made aware from the beginning of the project risk and must be given the opportunity to make project decisions based on the most current and accurate risk information. For example, at some point in the product development stage, the project could be cancelled due to the high risk of market acceptance (product anticipated not to meet the anticipated revenue targets).

2. The development and execution of risk action plans should be put into the project schedule so that they can be tracked. In this manner, the team is more likely to focus on risk action plans during the project cycle, in addition to other product development and launch activities. Also, do not forget that these activities will have a cost associated with them and therefore should be factored into the project budget. For example, to run a number of focus groups can cost significant funding.

3. It is a good idea to keep documentation of risks encountered along the way, along with the strategies for dealing with the risks (probably as part of lessons learned for the project), so that other projects can benefit from the knowledge.

Challenge: Effective Leadership of Cross-Functional Teams

Most of the lessons learned regarding team leadership were learned frequently through failure, plain and simple. What worked well in other environments completely fell apart in my Marketing world! As I reflect, I have noted the following reasons why the Marketing environment was so different and provided a unique opportunity to learn. See if any of these apply to your environment:

• Teams were comprised of many people in different functional groups within our firm. Teams were cross-functional; this was not a “projectized” environment. Some team members could also be from outside of our firm. For example, a business partner could be involved in product development, or a PR firm involved in launch, but there was strong participation from outside the firm.

• The product development and launch teams were not co-located.

• Many of the Marketing “types” did not like process, believing it impaired their creativity.

• There was a total lack of project management processes and also product development and launch processes. The environment was totally unstructured.

• Most team members were not experienced with using any kind of a process or methodology.

• Many team members would report that their deliverables were 90% complete and they never seemed to get totally complete. This seemed to be indicative of not knowing when “done was done.”

• The concept of a budget constraint was totally foreign in this Marketing organization.

With all that in mind, what can be done to improve the performance of these complicated team environments?

The use of a standard product development and launch methodology or process is the first step (discussed at length above). The methodology serves as the guide as to how the works get accomplished by the team and what deliverables are required. Additionally, the methodology should clearly articulate the roles and responsibilities of each team member. It is this understanding of roles that goes a long way in developing the base for an effective product launch team.

Effective team leadership is absolutely critical and necessary to guide the teams through the complicated business of product development projects and ensure that the right products launch successfully.

The role of the team leader (most likely the project manager) is to promote and encourage healthy working relationships within the teams. I will describe two unhealthy team situations below that I have unfortunately experienced too often in my marketing organization. The team leader must be careful to diagnose these situations and take corrective actions to resolve them as quickly as possible.

Situation #1: The Hero Syndrome. This is where one or several team members go through tremendous efforts to accomplish the work on behalf of the team within the most unrealistic timelines. The heroes do not take vacations or days off, they do not eat lunch, they go to work even when they are sick, and they always work long workweeks. This work ethic only burns out valuable contributors over time until eventually they are unable to contribute anything for a period of time. There is no sustainability of performance with this work ethic and is always a short-term focus.

Situation #2: The Dysfunctional Team. This is when the team members fail altogether to function as a unit or even individually. Team members fail to turn in quality deliverables and often the deliverables are late. This is the worse possible team situation because there is usually a total lack of respect between team members. This situation may actually be a lost cause, requiring that the team be disbanded before too much time or funding is lost.

The most effective method of resolving these team conflicts is through honest, open, and positive confrontation with the team. Confrontation should be used here in the most constructive sense and must not be perceived by the team to be negative or offensive. In Zenger-Miller's book, Leading Teams, a five-step process is discussed for resolving team conflict. The team leader is the facilitator of this process, and coaches the team into actually resolving the conflict for themselves. This approach will take practice and the team will likely make many attempts to perfect this technique.

Involving all team members in the decisions regarding their projects is the method that I recommend to significantly improve team performance. The team leader (project manager) role is to continually facilitate and lead team sessions that encourage this participative leadership. The team leader must also facilitate the individuals’ contributions to the overall project.

More specifically, some examples of the activities and decisions that should be accomplished with all team members’ input include:

• Development of the project charter

• Development of the project schedule and setting of milestone dates

• Identification of the project risks and contingency planning for those risks

• Interviewing and recommending new team members

• Review and approval of other team members’ deliverables for completeness and quality

• Decisions regarding the features to be included in the product, what the initial customer target segment will be, PR messaging, and so on.

The idea is that a team that feels more in control of its destiny is more likely to put forth the effort required to succeed together. Each team member must feel that his or her input is listened to by others and is a useful contribution to the overall product. The ultimate goal is that at the end of the project and at key milestones throughout the project, all team members feel the sense of pride and ownership in the work they have accomplished together.

Participative leadership in the cross-functional team environment will certainly require an enormous amount of commitment both by the team leader and the team itself. It will also require the firm's investment in education, skills training, coaching of the teams, and just overall patience as the product development and launch teams work through team-based activities and decisions.

Many corporate training departments offer leadership skills training classes in-house. Take advantage of these classes whenever you have the opportunity. If they are not offered through your company, consider attending classes and seminars offered by professional organizations. Some examples of professional organizations offering excellent training, include:

• Vanderbilt University, Owen Graduate School of Management (www.mba.vanderbilt.edu)

• American Management Association (www.amanet.org)

• Franklin Covey Institute (www.franklincovey.com)

Tips and Techniques

1. Senior Management should provide a role model for the marketing/product development teams. When the top management team is functioning effectively in a cross-functional fashion, then the teams below them have a wholesome example to follow. This is a top-down sort of approach. If the top management team is dysfunctional, then the lower levels have very little chance of succeeding together.

2. Use team-building exercises. There are many books and papers that will provide ideas. If budget permits, bring in a third party to facilitate team building. Develop your own file of games and techniques that can be used for various team-building strategies.

3. Charter all projects. This is the document that can be dusted off periodically and can be very useful in focusing team efforts on the overall business objectives. If developed with the team's participation, the project charter can be a powerful tool.

4. Develop project closure processes, such as Lessons Learned. This type of process can ensure that each team member can be heard. It is therapeutic in a way, for each team member to debrief on what went well and what did not go well after the “heat of the battle.” In this manner, Lessons Learned can be a very good team-building technique if facilitated effectively. Lessons Learned also provide a way to leverage experiences across the organization.

5. Use a RACI chart (also known as a Responsibility Matrix) to clearly note who is responsible, accountable, consulted, and informed for process work products (deliverables).

6. Team members should be encouraged, and strongly urged to review and approve others’ deliverables. This message has been stated previously, but definitely bears repeating. The team members should hold each other accountable for completing the work in a quality manner, because they are the ones who are dependent on the deliverables. The project manager can be useful by scheduling this review time into the overall project schedule and by acting as the team facilitator during these review sessions.

Conclusion

In conclusion, this paper has presented several best practices and challenges that I faced during my tenure in the marketing world. There were many other project management processes that had to be defined and worked out. Certainly, we were faced with many more challenges along the way. This paper describes the beginning of that journey. As we moved along that journey, we added key components along the way.

The journey is still not at the end. Although I have left that marketing organization and moved on to other opportunities, I am heartened that the organization is still carrying on with many of the project management processes that we defined together. The Project Management Organization (PMO) still lives and so does the product development process. Hopefully, that journey will never end.

References

Githens, Greg. (1999). Building Scheduling Discipline—Part 1: A Capability Framework and Initial Levels. Visions (July).

Zenger, John H., Musselwhite, Ed, Hurson, Kathleen, & Perrin, Craig. (1994). Leading Teams—Mastering the New Role. New York: Irwin.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston,Texas,USA

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Navigating Tensions to Create Value member content locked

    By Farid, Parinaz | Waldorff, Susanne Boche This article employs institutional logics to explore the change program–organizational context interface, and investigates how program management actors navigate the interface to create value.

  • Project Management Journal

    Getting Past the Editor's Desk member content locked

    By Klein, Gary | Müller, Ralf To reach acceptance, every research paper submitted to Project Management Journal® (PMJ) must pass several hurdles. This editorial aims to declare the editorial process and reveal major reasons for…

  • Project Management Journal

    Investigating the Dynamics of Engineering Design Rework for a Complex Aircraft Development Project member content locked

    By Souza de Melo, Érika | Vieira, Darli | Bredillet, Christophe The purpose of this research is to evaluate the dynamics of EDR that negatively impacts the performance of complex PDPs and to suggest actions to overcome those problems.

  • Project Management Journal

    Coordinating Lifesaving Product Development Projects with no Preestablished Organizational Governance Structure member content locked

    By Leme Barbosa, Ana Paula Paes | Figueiredo Facin, Ana Lucia | Sergio Salerno, Mario | Simões Freitas, Jonathan | Carelli Reis, Marina | Paz Lasmar, Tiago We employed a longitudinal, grounded theory approach to investigate the management of an innovative product developed in the context of a life-or-death global emergency.

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

Advertisement