Archive for June, 2014

June 26, 2014

You Can Fix Your Dirty Data!

Dirty data isn’t a dirty word. In polite terms, what I mean is “dirt happens”, if you get what I mean.

See – even if you have a well-constructed database, and a savvy team – things change, and over time, you end up with funk in your system.

That funk doesn’t stand up and sing “That’s The Way I Like It” – au contraire – it irritates your team, your customers, keeps you from running effective reports, and prevents you from making sound, data driven decisions.

But you can fix it – here are a few role based tips:

Chief Information Officer:

Opt for a trusting security model. That means that when any one of your workers finds a mistake, they have authority and access to fix it. If you aren’t doing that now, go talk to your HR department. If you can’t trust your employees to make continuous improvements, you have a hiring problem.

Compliance Officer:

It isn’t 1996 anymore. HIPAA has been around for a long time, and the litigation that frightened you to death didn’t happen. Ditto for anyone with McKinney Act compliance needs. So dust off that policy book and figure out what you can relax so your team can maintain your data.

Data Architect:

You did hire a UX design expert, right? You know – they worked with you to design effective input screens, based on user roles in your agency?  If you didn’t – your dirty data probably comes from that messy screen where you recommended laying things out on a grid and cramming 200 fields on a single page.

Okay, you didn’t. So go and do that.

Corporate Attorney:

You and your compliance officer should have date night. Tip back a tasty drink, and talk about risks in terms of what might actually happen if one of your fears comes true. Don’t forget that likelihood and impact are far better indicators of what to mitigate than the risk itself. Now that you’ve lightened up a bit – go and tell your team about it.

Database Administrator/System Administrator:

You’ve implemented smart error handling, right? You know – limited the use of user checked boxes, people can enter a phone number and your code figures out how to render it, you calculate age based on a birthdate, and so on.

Oh. Alrighty then – you have some work to do. Make it easy for people to enter clean data – easier to fix it on the way in then after the fact.

Marketing Manager:

You aren’t asking for data that you aren’t going to use, are you? I get it – the more you know, the better you can market. But you have to give to get – and you shouldn’t put a barrier in the way of your end users or those doing data entry. Get the minimum required to start – and then entice your users to give you more.

System User:

You fix stuff as you see it, right? When you see “jOhn SMiTH” in the system, you just go ahead and fix it, right? Because if you don’t do it, no one will.

Oh – you don’t have access and permission? Go talk to your CIO. If they can’t help, go see your HR team and tell them that not being able to fix mistakes qualifies as a hostile work environment.

June 15, 2014

Maybe The Problem with Your Database Is You

I can say that, because I used to be the problem.

(Let’s assume your database is well constructed and well maintained.)

The first time I noticed was back in the day – I was ripping my CDs to my hard drive, and my buddy Joe called – we had a gig that night and we had to plan what gear were were going to bring. When I told him what I was doing, there was a pause:

“You *are* adding in the titles and all of that stuff, right?” he asked.

(Of course, now I know that he was talking about meta data. You know, the stuff that makes the NSA hot and sweaty. That’s okay – it should make *you* hot and sweaty, too).

I wasn’t doing that.

“Thing is”, Joe said – “if you don’t do it now, you never will. I have 1,000 songs, and the title for each of them is ‘track 1’ – just sayin’.”

The second time I noticed was when I was working as a bookkeeper. I had to get some checks entered so they could go off to the board for a signature. I entered the name, the amount, and thought I was done.

Bill looked at me. “You *are* going to enter the address, right?” he asked. “You know – so if we ever need to *mail* a check?”

I hadn’t planned on it – but both Joe and Bill were right: if I didn’t enter it now, the likelihood that I’d enter it at all was slim.

I realized that second time, that while it might be okay to be sloppy with data that was just for me – it was unfair to be sloppy with data that belonged to the company where I worked.

(Yes, I entered all of the addresses that second time).

So – what are you doing (or not doing) with your data?

Here are some common areas where scrimping now will make you suffer in the future:

  • Leaving stuff off because it’s a pain in the butt. You know – adding the address but not the zip code, or the phone number, but not the area code. You should stop that right now.
  • Putting it in notes or narrative. The moment you enter my birthdate in a text field, you’ve lost the ability to figure out my age next year, or my eligibility and a host of other things. Put the information where it belongs.
  • Skipping the stuff that takes a bit more time. You know – like making sure that you include where I work, or where I live, or who shares my house. You might have to click a few more times to enter that info – and you should.

How Do I Know What Data Is Important?

Terrific question. You won’t always know, because things change a lot. 20 years ago, no one cared if you had an email address. Today – that may be the cheapest and most effective way to communicate with someone.

So you’ll have to figure it out, as you go along. And you’ll want to work with the rest of your team – you might not care about something, but it might be valuable to someone else.

One more quick story:

I was fundraising for a living, for a theatre company. And I made an appointment to ask one of our top donors for a major gift. I went to their house, I had my pitch ready, I had a return envelope. I was ready.

When we sat down, I found out that one of our minor programs had been there the night before – and had secured a nice (but way too small) gift – precluding me from asking for the right amount.

See – I hadn’t flagged that donor in our database. And that minor program hadn’t noted that the donors kid was taking one of their classes.

So you need to work across your entire agency to determine what data you care about, and why. And how you’re going to store and maintain it.

You won’t ever be “finished” with this task – it’s ongoing. Your needs will change, the things you care about will change, and you’ll have to adapt.

One final tip: If you have to err on collecting too much or too little – take the too much. Easier to delete than to create from scratch!

June 5, 2014

Does Your Chief Electricity Officer Think an Ohm is a Yoga Routine?

When electricity was not yet ubiquitous – companies has a Chief Electricity Officer. Their job was to ensure a steady supply of electricity and to integrate that supply into the rest of the business.

(Not an urban myth, but I must confess that I can only find blog posts about the electricity officer. No harm – I just needed a good title, anyway).  You’ll find those blog posts here, here, and here.)

So – stick with me. Imagine back in the day that you had a Chief Electricity Officer, and they thought an Ohm was a yoga routine.

Assuming that *you* knew better – wouldn’t you start shopping for a new chief?

Fast forward, and ask yourself if your Chief Marketing Officer knows that:

  • a CDN isn’t a financial instrument
  • SASS isn’t what you get from your kids
  • Metrics aren’t a newfangled way to measure the 100-yard dash
  • GitHub isn’t a meet up group for people with horses
  • A pixel doesn’t sprinkle fairy dust
  • Mobile first doesn’t mean you always keep your cell phone in your pocket

That was fun. I could go on. But I won’t.

You wouldn’t hire a CMO that didn’t know how to make a print buy. Or that didn’t understand Nielsen ratings. Or that didn’t understand the fundamentals of brand management.

So why are we letting them off the hook for all things digital?

If you are working a project and your CMO is under-educated about digital, it’s your job to close that gap.

You don’t need to send them back to school, but you do need to help them up their game. It will make your project go better, and it will strengthen your relationship with the marketing team. Here are a few tips:

1. Every interaction is a learning opportunity, but don’t force it.
No one enjoys having their ignorance exposed in public. If you spot a knowledge gap, address it in a way that doesn’t undermine your CMO

2. Use analogies.
Marketers are story tellers. You should be able to explain tech concepts in a way that your CMO can understand. For example – if it’s important that they understand what a CDN is, try this: Tell them that a CDN (content delivery network) lets your website assets get delivered more quickly – because they are closer to the person that wants them. It would be like making sure that there is a gas station next to every car owner – instead of making every car owner drive to Detroit (or Japan) to fill up.

3. Don’t tackle everything at once.
You can’t (and shouldn’t) expect your CMO to love getting in the weeds with tech. You don’t want them giving you tips on your CSS schema. So pick the right target when helping them learn: maybe it’s mobile this quarter, or social media, or responsive design theory.

4. Don’t make yourself the only expert.
There are terrific CMO’s out there, and very well written information all over the interweb. Help your CMO find and access those resources.

5. Focus more on the “why” and less on the “how”.
You shouldn’t expect your CMO to review your schema for minifying your code. (You *are* minifying your code, right?) But they should understand the importance of a speedy website and should work with you and your team to have a standard. Minify might be a way to get there, sure. But what you really want is a savvy CMO, not one that is going to review your JavaScript.

I don’t think the Chief Marketing Officer role will go the way of the Electricity officer. But I do think that over time, marketers will more fully embrace the why of digital. In the meantime – it’s your job to speed that shift along!

June 3, 2014

Becoming a Technical Project Manager

Making a leap into technical project management? Great! Here are some tips to get started!

Develop technology subject matter expertise.

You should be comfortable with technology basics. The geekier the better – but you should start by making sure you:

  1. Understand the fundamentals of data networking. This is the “how are things wired?” items – and while there is a *lot* to learn – at a minimum – you should understand how a local computer connects to the internet, and how computers connect to a network of other computers. And the basics of domain name systems – you know – the traffic cop of the internet.
  2. Learn about relational databases, and how (and why they work. Like data networking – there is a *lot* to learn. You might never become an expert regarding the difference between and inner and outer join. But you should be savvy about data normalization. So if you see a “database” that has a first name and a last name all in the same field – you’ll know that you won’t easily be able to sort by last name.
  3. Learn the fundamental building blocks regarding website creation. Again – this is a huge topic, but at a minimum, you should understand the basics of the “how” (HTML, CSS, JQuery, JavaScript), as well as the “why”. This second piece – the why – is also a big category – everything from responsive design to User Experience, and from Web Typography to Analytics.

(That’s just a start. You may need to learn a lot about any one of those items – but you get the idea – if you are managing a project – you’ll be better equipped if you understand the tools and theories that make everything work).


Learn About Software Development Methodologies.

This is both easier and harder than it sounds. There are really just two flavors these days, Waterfall and Agile, although each of those have a near endless variety applied to them in real life. I personally think Waterfall is of limited utility – but you should still learn about it.

(When taken to their extreme – both are silly. For a humorous take, see my article about using those methodologies to prepare for a 7 mile race.)


Develop Great Communication Skills.

Substantially ignore all of the mumbo jumbo about managing budget, time, risk. Your project will be successful if you have great communication skills, if you tell the truth, if you are curious to learn, and if you don’t treat your scope of work like a shield. Because it isn’t – the second you think you win because the scope says so, you’ve lost.

(You can do the same thing with the Iron Triangle – it belongs in your tool kit the way addition “belongs” in the calculus toolkit. Learn it, keep it around, but move on. Please.)

Sure – budget, time, risk – those are important. But when things get tough – you’ll need great relationships with your team. A great spreadsheet or project plan won’t help if everyone thinks you’re a jerk.


Earn Some Certifications.

Almost everyone will ask for either a Scrum Master Certification or a PMP certification. Both are good to have.

But don’t stop there: consider courses about communication skills, technology, software development, and more. Technology changes quickly – and you should seek to stay current, both with credentials and with self-learning.


Put it all to Work.

Managing a technology project is art, science, hard and soft skills. No two projects will be that much alike, but you can learn from every project. Figure out (even if just for you) what worked, what didn’t, where you made mistakes, and where you can improve. You can see my top 21 tips to get started.