Warning Signs Your Marketing Project May Have Hidden Technical Risks

Early detection of technical risk can be the difference between a successful project outcome and potential disaster.

The Obvious Stuff

Let’s quickly cover some obvious signs of technical risk that require less discussion because you, your team or the client are probably already talking about them:

• Lack of clear requirements: Technical teams are usually quick to point this out.
• Aggressive timelines: Your seasoned leads will instantly flag timelines that are too compressed or unrealistic
• Insufficient budget: T-shirt sizing deals, based on past experience, or high-level estimates usually uncover budget deficiencies early on.
• Available Resources: The staffing plan has key resource gaps for technical skills or experience that you don’t have, or are not available, forcing you to hire or contract. This risk is exacerbated for roles in high demand.
• Big projects: Big for you or big for the client - also easy to spot with elements such as multi-channel enablement, enterprise platform deployments, complex system integrations etc.

Interestingly, most of these warning signs apply equally to non-technical work. Regardless, they are not generally hidden.

The Less Obvious Stuff

The projects that catch us off guard are often the ones where the risk level appears manageable. Then, you sign the Statement of Work, start the project, only to encounter unexpected trouble.

What are some less obvious signs that may indicate hidden technical risk?

6 Warning Signs of Hidden Technical Risk

I have personally encountered all of these, in some cases, more than once.

1. Lack of understanding about a client’s IT environment. It's essential to grasp the client's IT landscape before agreeing to adhere to any IT standards or restrictions. IT teams can enforce requirements that significantly impact your timeline and level of effort, including areas such as platform choices, security, data management, privacy, approval processes and more. Conduct a technical discovery to assess these details, and never promise compliance without fully understanding what you are committing to. This will usually take some amount of effort.
2. Integration with external systems. Integrations are always an area where I look for hidden risks. The following questions can help start to uncover them:
   1. Do the technical integration options reasonably match the needs of our project?
   2. Does the system have a proven track record of supporting other solution integrations?
   3. Can the system meet our performance and scalability needs?
   4. Does the client perceive the system as outdated or legacy?
3. Dependency on a third-party to provide part of a solution. The risk is often greater when the third-party is being imposed by the client as opposed to you selecting them yourself. Have some initial conversations with the client and the provider and talk through the following topics:
   1. Leadership in technical execution
   2. Appropriating and managing accountability
   3. Collaboration and communication methods
   4. Remedies for failure to deliver
4. Major new platform releases. Despite the lure of a shiny new platform update, it can come with serious risks, especially if you plan on using some of the new features or significant parts of the platform have been re-written. Avoid being an early adopter unless necessary, because most clients have a very low tolerance for platform issues. Using a prior stable version is often the better strategy if that is feasible.
5. Readiness for a significant increase in traffic. There is a tendency for technologists to consider scalability as a later phase task and instead focus on getting an initial solution built and deployed. Moreover, they might assume current traffic levels as their baseline goal for a phase one implementation. But this can prove fundamentally wrong if the marketing team is planning a dramatic increase in demand generation as part of their strategy. Technical leads must gain a full understanding of the program and be ready to support the right level of scalability on day one.
6. Mobile applications. Can carry significant risk unless you specialize in them. Creating reliable, performant apps that run across a range of devices and operating systems is challenging. Also be cautious of low-code mobile app development options that promise to make everything easy. They are typically a compromise solution that can impact areas such as user experience, UI responsiveness and reliability in poor connectivity cellular environments.

These warning signs offer a head start for uncovering hidden technical risks in your projects; of course, there are more out there. Also, watch out for combinations of these that can drive higher risk. For example, an external system integration, implemented by a third-party and which will be tested by a significant increase in traffic, is one that would certainly get my attention.

In future articles, we’ll dive deeper into some of these areas and discuss more about the mitigation strategies you can employ.

If you need help assessing the risk of your technical projects or mitigating risks you have identified, reach out and let me help.