top of page

Technical article

Managing marketing projects
 

Defining the project

Project management can encompass everything from major infrastructure development to planning the company Christmas party and everything in between.  Even restricted to marketing, it covers a wide range of potential applications that can have profound effects on the entire organisation. Project management is never pure, and rarely simple  - or at least not as simple as many would like to believe and this is one of the main reasons why so many problems arise over timing, cost and failure to deliver desired outcomes.

 

It is strongly argued that the project concept must fit the overall organisational strategies, then culture, structure, expertise and resources must be matched quite specifically to the project at an appropriate level.  Otherwise, the outcomes are invariably less than ideal. Naturally, the more complex the project and the larger the number of stakeholders, the greater will be the risk.

Relationship to the business plan

For each significant project it should be standard practice for management to expect some kind of formal business plan containing an overview of how the proposed project outcomes fit the organisation’s goals, objectives, market characteristics and strategies. That document should not contain excessive detail about implementation techniques, but it should certainly set out the value propositions, causes, effects, resource requirements and payback scenarios with sufficient clarity that management may “sign off” on the plan, as a precondition to moving to the next stage.

Goals & objectives

 

A common belief that goals and objectives are interchangeable terms is wrong. The goals should be high-level statements defining the overall context, to be achieved through the application of one or more projects. .

The goals should define the benefits in terms of outcomes for stakeholders. If this cannot be done, the related project is probably not worth the investment..

The Scope of Work

  • A simple definition of what the project is intended to achieve
     

  • A short review of the business plan elements that directly affect outcomes
     

  • A statement of caveats defining any issues of company culture, management, resources, accountability etc that will cause the project to be conducted in any particular manner, likely to affect the outcomes.
     

  • Definitions of stakeholders in the context of the specific project. These must address the relative importance and relationship of each stakeholder to others and to the project, with anticipated reactions to its various attributes.

  • Resource issues, including production, outsourcing, funding, marketing, sales & distribution issues.
     

  • Timing expectations and an outline of phasing.

 

  •  Critical success factors
     

  • Project duration and milestones
     

  • Cost and payback budgets for successive stages of the project

This is the time to identify and resolve any vested interests, “sacred cows’ or other constraints imposed by funding, personnel, production capacity, segment          experience, supply-chain and so on. It will be far better to tackle these issues now than to accept responsibility for a project that may be fundamentally flawed from the start. However, this is fraught with political danger and may require considerable diplomacy and management skill to resolve. A plea of insanity or terminal illness may be the best option!
 

When all of the key issues have been resolved, the Scope of Work must be debated with management and formal agreement provided, along with budget approval and authority

The Scope of Work should not be allowed to become a project in its own right. If the groundwork was laid effectively at the initial evaluation and business planning stages, the process should be accomplished within a time frame ranging from a few days to a few weeks, but rarely longer. If management has “blessed” the business plan, there will be an expectation of prompt development of the actual scope of work

Goals & objectives

A common belief that goals and objectives are interchangeable terms is wrong. The goals should be high-level statements defining the overall context, to be achieved through the application of one or more projects. The goals should define the benefits in terms of outcomes for stakeholders. If this cannot be done, the related project is probably not worth the investment..

Conversely, objectives are specific statements of what the project will achieve. They must quantified,

The timeline

Gaining agreement on the project timing is critical.

Aggressive and/or unrealistic deadlines are fundamentally problematic. They place unrealistic pressures on the project and can lead to shortcuts, failures to assess the relevance of problems and opportunities, as well as forcing the pace of technical or production support.  On the other hand, there is little excuse for excessive delays or deferrals. Early indications of this will send negative signals to many stakeholders with potentially adverse effects on their cooperation, or on their perceptions of the efficiency of the project management team.

A significant element that will affect the timeline is the evaluation and marshalling of resources. Consulted at an appropriate time ahead of the required actions, explanation of the reasons and outcomes will go a long way to gaining the support and cooperation of colleagues, especially in production or technical areas where set-up or changes to other schedules are involved.

The planning process itself takes time, as does the communication and gaining of approvals, so it is essential to allow for this. A timeline should be clearly structured to balance the major decisions/milestones along with the details required to ensure the success of the former. Excessive detail is as inappropriate as  “broad-brush” assumptions.

Working tools

While there are no firm rules for the planning and recording of project stages, ultimately the requirement will be as follows:
 

  • Facility for recording and manipulating factual and timely information
     

  • Simple, preferably visual flags for the critical dates and/or processes
     

  • Extraction of sub-sets of information
     

  • Ease of reporting in a professional and concise manner to the various stakeholders.
     

Even quite large projects can be managed using Excel, a relational database or a project management tool like MS Project. More critical than investing in “whiz-bang” technology, the fundamental principles of information-management must be met.

“People” issues

Putting together an internal team of internal personnel may seem the most cost-efficient method. After all, this is likely to encompass a range of stakeholders who know the market, the resource capabilities and expectations of management. However, while this approach is inherently sound, there will inevitably be a hierarchy where the opinions of some are (if not by intentionally) more likely to prevail than ideas from those lower on the “pecking order.” 

 

Usually, a committee is appointed under a “qualified” chairperson who is, unfortunately, not always the one with the skill or the “clout” to overcome vested interests, or mere intransigence. Conversely, if the CEO is the chairperson, will the other members be prepared to adopt an openly contrary view, however valid the logic?

The answer lies, of course, in establishing the parameters against which the concept must be measured, the outcome being a “pass,” “fail” or “amend & resubmit.”

 

Project management credentials are even more critical. Being the boss’s niece or the ability to run project management software are not substitutes for fundamental competence, skill and experience.

Communication
 

A “proof of concept” pilot is often essential before various stakeholders colleagues are “sold” or management is prepared to sign off on significant resource allocation.  Sometimes, this may require physical models or prototypes, especially if new manufacturing processes are involved.  

 

The tools at the disposal of today’s project manager are formidable and there is little excuse for not applying them in an appropriate manner. Computer modelling, VRML in the hands of experts will bring a concept to life and allow even the most recalcitrant stakeholder to visualise the results. However, a word of warning – the “expert” at the computer keyboard will need highly specific guidance regarding what to present, in what sequence and to what level of sophistication.  This stage is a project in its own right!  

 

A n a recent example where international management was to receive presentations from the local team, we had immense trouble persuading the local CEO to depart from the former practice of overhead projector foils.  Happily, we prevailed and the team made reasonably professional and valid presentations, even though they were scaled down to absolute essentials (no fades, pop-ups or other effects).

In another example, we were forced to use material from another industry to demonstrate a range of information management techniques. (Extracting data from the company server, creating object libraries, publishing templates and user-defined information formats). These techniques are now fairly simple processes and it should have been easy to see how sets of information from different industries were essentially similar. While the demonstration achieved local project approval, it failed to secure support from the (overseas) head office personnel, who could or would not see how the demonstration applied to their particular category.  The conclusions are obvious – demonstrate, but be sure the context is entirely appropriate. As in most things, judgment is needed to decide what is “appropriate.” The cost and use of resources needs to be weighed against the value of the project outcomes, the level of risk and the probable reactions of the stakeholders. 

 

More about Stakeholders

As implied above, we challenge any view that stakeholders are solely from within the organisation. Certainly, management, employees, administrators, purchasing, logistics, customer-service, IT and accounting personnel must be consulted if they will be affected by some aspects of a new project . If they are not consulted, the project manager has only himself to blame if (or rather when) some important function fails to meet expectations.

There are few projects that do not also have external stakeholders. They can be the greatest challenge, but also the most useful alliances if treated with professional courtesy. For example, a supplier can provide innovative solutions that will enhance a key value proposition, reduce costs, shorten delivery time or maybe just make life easier due to their professional service.

No consideration of Stakeholders can be valid unless it includes the end users. Regardless of marketing and distribution methods, there is usually an end-customer. Understanding the aspirations and motivations of these users can make or break the outcomes. A classic example of this occurs when “innovators” develop (often literally) fantastic solutions to problems that largely do not exist. Sure, some innovations will succeed.  Others may have convinced investors but unfortunately, not the users who are supposed to take up the solution in vast numbers. 

 

Detailed planning

All of the above essentially covers background or general issues without which serious problems are likely to arise at some stage of the project. These must, however, be supported by the specific activities related to every detailed stage of the process.

The need for ability to manage a number of simultaneous project elements increases with the complexity of the overall project. An unresolved problem at one point may have potentially serious consequences.  In many cases, these issues need to be worked in parallel, relating the effect of one decision to the inputs of another. This is often easier than it first sounds, using the time-honoured practice of breaking large problems into component parts. Care should be taken to adjust for conditions that may change over time. Good stakeholder relationships will help to overcome this,

Another form of “future-proofing” a project is to be entirely open about unknown factors. We sometimes create surprise with clients by stating that at the outset of a project, we “don’t know what we don’t know.”  However, we explain that the process will identify such issues early in the project, so they can be dealt with in an appropriate manner. Unless perceived to be mission-critical, this approach is reasonable.  If they are critical, then the objectives were probably unrealistic, or the value propositions undeliverable.

As long as intangibles are recognised and reasonable assumptions shared with management, the potential for unpleasant surprises will be minimised. The worst any project manager can do is to assume that some vaguely anticipated problem will either not occur, or will resolve itself. Better to identify the potential roadblock, explain its context and level of importance, canvas input and guidance early.

Click HERE to return to the home page
bottom of page