Everyone seems to think their projects are different, but actually, that’s not true.
A project is a project.
In training over 20 years and for thousands of project leaders, their top 10 problems are always the same—regardless of industry or sector.
Do any of these resonate with you?
The Scope Keeps Changing
Ah, the dreaded “scope creep.” It rears its ugly head for a number of reasons:
- Sometimes the marketing team thinks they know what the customer wants only to find out later that they weren’t mind readers.
- Or the customer just doesn’t know what they want in the first place (that’s the “they’ll know it when they see it” attitude).
- Another variation of this is that the customer thinks they know what they want but then changes their mind when you’re halfway through the execution of the project.
- Or, maybe the customer knows what they want, but then in the middle of the project, the customer leaves and a new person takes over that position and has a different vision for the solution.
- Or, there is a major shift in strategy within the organization that changes the scope of the project.
The Project Team Jumps Straight Into Action
Marketing people tend to be doers. They like action and so they don’t inherently feel that planning is a useful way to spend time.
We worked with a sports organization that even proclaimed that we couldn’t use the “P” word when working with their teams.
The P word was “planning.”
Planning was a dirty word? How on earth are you supposed to talk about running projects optimally without talking about planning?
They just wanted to get on with executing the project, which is the natural response for a lot of people that would rather not plan in the first place.
Everyone Works Independently, in Their Silos
Marketing is broken up into a whole array of vertical silos: Campaigns, Social Media, Product Marketing, Global Marketing, etc. and marketing projects often have each of the groups involved working independently, creating their own plans and then executing against them but without a master plan or common schedule that shows all the interdependencies.
Marketing is cross-functional by nature and most of its projects have stakeholders and subject matter experts in other departments, (most notably sales or customer service) who are often not included on the project team.
The idea that each group can work independently (or that you don’t need all the key stakeholders involved) means that the key voices are not being heard until it’s too late–when the project is over, and the stakeholders haven’t adopted the solution or are up in arms over what the marketing team came up with.
Let’s look at how you solve these three critical challenges the marketing projects face.
How to Minimize (And Even Eliminate) Scope Creep
If you’re facing any of the scope problems discussed above, then you’re probably experiencing something commonly called “scope creep”.
It can actually be much worse than creep–it can be all out “about face” where the customer suddenly decides they want something else entirely!
Constantly revising scope or having to change the whole direction of a project creates rampant rework and is a colossal waste of time.
There are a couple of solutions for the scope problem, depending on what is causing it in the first place:
- The customer doesn’t really know what they want. These are the “know it when they see it” type of customer.
The first thing you have to do is get really clear on what the customer is trying to achieve with the solution – what problem are they trying to solve?
All too often the customer comes to you with their idea of the solution and then the marketing team takes that and runs with it. They haven’t validated that the solution the customer asked for is really the solution that will help them solve their real problem.
So even if you deliver what they asked for, the customer isn’t satisfied, because they still have the problem.
Very few project teams do a good job of working with the customer to map out the solution in language (visual and text) that the customer can understand and relate to.
Conduct a “Solution Definition” session with the customer to get at their vision of the solution and their must-haves and nice-to-have features and functions.
By drilling down into what’s really important to the customer (the must-haves and then have them create a prioritized list of nice-to-have’s) you have a clear roadmap to work from.
As much as possible, create mock-ups for the customer to react to, so you can translate their verbal requests into pictures. Technical people tend to talk in their technical language and the customer just doesn’t really understand what you’re talking about, even if they are nodding their heads.
IT people do this all the time, and marketing people also have a technical language that may not resonate with the customer.
Also, most people are visual thinkers and if you’re just talking but now drawing pictures for them, creating mock-ups, diagrams, etc., then they’re probably lost. There is a disconnect between what they think you are doing and what you actually are doing.
- The customer knew what they wanted but then things changed.
This happens because things do change.
However, some of these things can be predicted and if you’re good at project planning, you can anticipate and build in contingency for them.
Other things are unpredictable and if the change is large enough, then there needs to be a change management process. That basically means that the project needs to be re-planned and started over by creating a new solution definition, a new schedule, a new plan and then execute against that.
- The customer defined the solution but then keeps adding things later.
You have to set expectations with the customer and create a Solution Definition cut-off point that is a line in the sand.
For example, “We will continue to brainstorm and work through what the solution looks like until this date” and then that becomes the cut-off. That’s version one of the project, and we will execute against that.
If you want new features or functions, they will have to wait until the next project, and that builds version two.
The alternative is to have a change management process by which the customer and other stakeholders can request changes to the plan (usually scope changes). The problem with this approach is that every time there is a change request, you have to go back and re-plan what you’ll be doing and that wastes a lot of time.
Another alternative is to start with an agile approach in which you don’t lock down the scope, but just keep iterating it with the customer until you get it “right.” Contrary to the popular obsession with agile, it’s not the best approach for every project.
- The Project Team Jumps into Action
Often, the reason for this is the team hasn’t been trained on how to do planning in a way that is collaborative and that really adds value to the project.
That’s not really your fault—these skills have not been taught, and all too often it’s the project manager that is doing the planning. The problem with that approach is that the team members won’t have a real connection to the overall project.
By switching to a collaborative project leadership approach however, the team engages in the planning process and through that engagement, develops ownership for the project.
Collaborative planning is a value-adding activity for marketing teams and when done properly, it makes the execution phase (the longest and most costly of the project phases) go more smoothly.
- Everyone Works Independently, in their Silos
There is a real lack of awareness of the need to involve stakeholders in projects that cross functions.
This is because leaders are traditionally isolated in their vertical silos and are driven by goals that are functionally driven.
However, because marketing projects are cross-functional by nature, they must be led differently.
In short, leaders really need to get trained on how to lead collaborative projects. That’s all of your leaders and not just project managers because it’s the basis of the leadership skills that leaders need in today’s organizations.
All of these problems can be solved by developing real capability in leading cross-functional projects. The approach that works is a collaborative project leadership approach.
