Complexity. As a project manager at Brain Traffic, I hear clients use that word a lot. And, for good reason. When you think of everything involved in content strategy, it can get pretty overwhelming. In fact, Dictionary.com defines complex as:
- Composed of many interconnected parts; compound; composite: a complex highway system.
- Characterized by a very complicated or involved arrangement of parts, units, etc.: complex machinery.
- So complicated or intricate as to be hard to understand or deal with: a complex problem.
Content projects regularly fit each (and sometimes all three!) of these definitions. So, how do you tackle complex projects? Where do you start?
Step 1: Diagnose the problem
The first—and most critical—step is to take time to identify why exactly your project is unique, different, hard, or complex. It’s not as hard as you think. You’ve got help. Project managers have been thinking about what makes projects complex for decades.
In his paper, “Project Complexity: A Brief Exposure to Difficult Situations,” project management expert Dr. Lewis Ireland identifies two categories of project complexity factors:
Technical complexity factors
Management complexity factors
- Number of technologies involved
- Familiarity of team with technologies
- Brand new or well-established technologies
- Number of technical interfaces
- Project staffing and management
- Number of parties involved
- Change-related issues
- Stability and complexity of requirements
- Political issues
- Time/cost issues
Conveniently, Dr. Ireland’s categories line up with the two halves of “the quad” (a graphic we use at Brain Traffic to help our clients understand the interrelated areas of content strategy). The halves are:
- Content components—what the content is and how it gets prioritized and organized.
- People components—how content moves through the organization and how decisions are made.
When you compare Dr. Ireland’s categories, the quad, and your project particulars, it’s usually pretty easy to identify the factors. Some common complexity factors are:
Content complexity factors
People complexity factors
- New technology
- Complicated or unfamiliar subject matter
- Multiple and varying audiences
- Large amounts of content
- Multiple platforms, properties, and content types
- Stakeholders (large numbers, diverse roles)
- Multiple teams with different expectations
- Project participants who don't know each other well
- Different vendors with different priorities
- Recent reorganization, creating new or undefined roles
On your project, you may have one factor that makes the project out of the ordinary. Or, you may have a dozen. As we start adding more and more factors, our projects become more and more complicated.
Step 2: Break things down
Once you diagnose the factors that are entirely specific to your project, you can break things down and address each specific element.
- Multiple content properties: Choose one property as the parent or priority. Work on recommendations for that property, and then branch out. (Even if this means you might have to update your recommendations later.)
- Lots of diverse stakeholders: If you have several stakeholder groups, you might want to make a stakeholder matrix to create clarity and define roles. Distribute and share the matrix with the project team and stakeholders. If there has been a recent reorganization, highlight how things have changed.
- New technology: Budget time and resources for training and research. Bring in experts to help you understand the implications of the new system, if necessary.
Complex problems seem a lot less scary when you look at them in small chunks.
Step 3: Roll with it
And here’s one final bit of advice: Roll with it! Every project has its quirks, and that’s what makes our work challenging and fun.
Posted in Project Management
I am sort of a rarity at Brain Traffic, because I really don’t have much of a writing background. I probably wrote less than five papers in my entire college career, I get along better with Excel than Word (numbers and color coding!), and I like digging deep into the details of project management.
Although I have no immediate plans to transition into a web writer, learning about writing for the web has made me a better email communicator and project manager.
For example, here’s a first draft of an email I needed to send to a client:
I wanted to ask a few more questions about the newsletter project we spoke about today over the phone. I spoke with my supervisor and we need clarification on a few items. First, we are wondering about your timing and schedule. How many newsletters do you need? Have you decided how often these will be sent to subscribers? We also need more information about the requirements of each newsletter, such as number of content blocks, if advertisements appear, and if you are looking for us to create unique content.
It will also be helpful to understand your approval process, such as who will be approving the text and how long that usually takes.
Once I hear back from you I can draft the proposals. Thanks!
This email is a big ol’ mess.
It’s not easy for the client to pick out the action items and dissect what I need from him in order to complete a proposal. This email would be much more effective if the content was broken out in easy-to-understand sections with a clear guide for next steps at the end.
Also, itemizing the list of questions provides an easy way for the client to provide feedback to me. We cut down on the possibility of things getting missed this way.
Here’s a much more effective way of communicating this information:
I just had a quick connect with my supervisor about the newsletter proposal. I’m going to need a little more information than what I heard in our phone conversation last Thursday.
How often are the newsletters sent out?
How many newsletters do you need written?
Do advertisements appear?
How many content blocks are there?
Do you need unique content created (opposed to editing existing content)
I’m hoping to receive clarification from you by the end of Thursday. I can then send you revised proposal on Friday. Thanks!
Some of the simplest principles for writing for the web can and should be applied to email communication:
Don’t use ambiguous language.
Eliminate unnecessary words.
Keep your sentences and paragraphs short.
When making lists, use bullets.
When giving instruction or steps, use numbered lists.
Your last sentence should include a clear call to action.
Tags: email, Web Writing
Posted in Information Architecture, Web Writing
I think it's time we revisit an outdated practice—the dreaded splash page. You know, that Flash introduction page that displays before you can actually enter the site.
You probably remember these popping up on websites years ago by companies wanting to show off their design creds. Then people started talking about how annoying they were. Well, they've vanished from a lot of sites, and for good reason—they're a real killer for user experience. But they've been popping up here and there, lately, and they put a real damper on an experience with a site.
I recently clicked on a banner for a book I thought looked interesting. I was directed to this site. Before entering the site, a Flash introduction page played in a rotating loop.
This is a lengthy process just to get to a website’s home page.
- I navigate to website
- Splash page loads
- I acknowledge that I'm not looking for this content
- I look for “skip intro” button
- I click “skip intro” button
- I navigate to relevant content
But, by step six, I was no longer interested. Why would I want to watch some swirling graphics with no words that tell me nothing about:
- The product
- The company
- What kind of information I can expect
If the site gives the user the option to skip the intro, then he or she most certainly will take that option (if the button is obvious enough). What value does the splash page have site designers know ahead of time that they will most likely not be interested in seeing it? The user came to the website to find information, and the splash page acts as a barrier to that content.
It's instances like this when the following questions need to be asked:
- How is the site presenting the information to the user?
- Is the content valuable to the user?
With Flash splash pages, you can pretty much guarantee the answer to question #2 is a no. Still. After all this time.
Posted in Content Strategy, User Experience, Web Writing