One Problem That Hasn’t Changed in the Ever-Changing B2B Digital Landscape

I made the decision to go into software development in 2004, at which time I built my first website for NCR Corp. This came after dabbling in other IT areas: networking, databases, traditional C programming, etc. I loved being a part of creating something real and was drawn to the “new media” side. Websites, apps, touch-screen tools, virtual reality. You name it, I wanted to be a part of it.

There is one particular challenge I’ve encountered in pretty much every IT-related discipline, and marketing technology is no exception. It remains a persistent thorn in the side of all who have worked on any kind of development project. It’s kept me up at night. It distresses my father, who is a veteran large-scale IT project manager. Every technology professional cringes at the very thought of it.

I’m talking about the quoting process.

Geneca published a popular article citing that 75 percent of survey respondents felt their software projects were doomed to fail from the start. Yikes!

My guess is that 75 percent of those respondents attributed this to poor project definition. Uncertainty is scary, especially when you’re being asked to put your money where your mouth is.

In my role at TriComB2B, I am responsible for estimating marketing technology projects, ranging from websites and mobile apps to email campaigns and touch-screen kiosks. Usually, projects are initiated with a Request for Quote (RFQ) or some form of budgeting discussion. Often, this discussion takes place before the agency and client fully understand the project goals. Tight deadlines can exacerbate that lack of understanding, not allowing either party the bandwidth to definitively agree on a final direction. Marketing technology projects tend to be large and complex, so scoping and estimating are challenging. These complexities can compound quickly, so it’s only natural that everyone might be a little anxious from the outset.

Understanding a project takes time

In marketing technology, the sky is the limit. With time, money and resources, you can build just about anything. In addition, there are usually numerous paths to building desired functionality, each with its own time and cost estimate. That product finder you want? Probably five to 10 possible user experiences. A dealer locator app? Don’t get me started on the variables we could encounter when building this. Content for your site or tool? How much is your internal team really going to be able to produce? To understand the full depth, we’re going to need a few discussions.

And even if we think we have it nailed, we need to be honest about what actually happens in development. Things come up. Some of the details won’t reveal themselves until we’re farther into development. That’s okay, though. There are steps we can take to mitigate these risks.

Take smaller bites

The answer is often to break these projects into smaller, more manageable tasks.

1. Define and Confirm the Project Scope

• Discovery 
  It’s important to discuss initial expectations and the end goals of the project. From there, we can outline the desired functionality and what content will need to be collected or created.  We should also be able to define who is responsible for what.
• Architecture
  Next, we’ll take the information collected during discovery and architect a content road map that will dictate where content is placed, how it is related, and where functionality and interactivity will reside.
• Wireframes
  Then we’ll create strawman designs of key pages to allocate space for content, images and interactivity. This will help everyone begin envisioning the end product and later help the design team understand what is expected of them when the graphic design phase begins.
• Stakeholder Review
  For high-visibility projects, this is when you need ALL the stakeholders who have a say in the end product to weigh in. If something needs to change, it’s exponentially less expensive and disruptive to the development timeline to account for feedback now. If you can’t get input now, make sure reviewers know that changes after this point are more involved and could impact cost and timeline.

NOW STOP AND TAKE A BREAK, BECAUSE YOU NEED A NEW…

2. Statement of Work
If you follow the above steps, almost all of the doubt and uncertainly will have been removed. It’s now easier to create a formal statement of work that clearly outlines expectations for project functionality, content, platforms, responsibilities, deadlines and costs. What’s that? You thought you already had a statement of work? You’re right, you probably did have a preliminary version at the proposal stage. But for large projects, you’ll need a final version that reflects everyone’s collective understanding after the discovery phase is complete. Chances are, it’ll look quite a bit different than the RFQ.

3. Implementation
Build it, as defined and documented. This is where your detailed statement of work saves everyone time.

• Content creation
  Write content and create or collect images that will be used.
• Graphic design
  Visually design the website to ensure proper branding and the desired user experience.
• Development
  Program the tool to look and function as agreed upon.
• Testing
  Rigorously test the tool to make sure it looks and functions as prescribed (across all specified platforms, if applicable). This will involve at least the agency and your organization, and sometimes include key clients or reps.
• Launch
  Release the tool to the public.

Want to remove stress and save time? Work through that first project definition phase and commit to a second, more detailed statement of work. Anything less can lead to inaccuracies and incompleteness that leaves the end result open to interpretation. We’ve all been there, yet we often overlook the need for detailed discovery as an integral project step. More stress. More cost overruns. Longer timelines. Worst of all, dissatisfied stakeholders.

Won’t this make my project more expensive?

No.

In most cases, you’re going to pay your developers — whether they’re internal or external — for the time and materials that go into the project. Taking the time to get the scope clearly defined, with architectures and wireframes for support, removes risks, development iterations, cost addendums and schedule revisions. Ultimately, you’ll save time and money because:

• The cost of defining functionality is absorbed during project definition, not while designers and developers are involved.
• Any guesswork regarding which party is responsible for content, images and other tasks is completely removed.
• You can expect to pay less for project management time. Projects with well-defined scopes and timelines are much easier to run.  
• Review processes and testing will be streamlined, since reviews and testing are more structured.

And let’s not forget. Everyone is going to be a lot happier. Splitting up a project into consumable chunks minimizes uncomfortable discussions among various teams and stakeholders, eliminating conflict that makes complex marketing technologies that much more difficult.

As the saying goes, an ounce of prevention is worth a pound of cure. Doing the hard work up front is the logical solution, but sadly it’s not nearly common enough in practice. It’s time to approach your marketing technology projects differently. You’ll be glad you did.