Archive for ‘Technology’

June 2, 2015

Why Your Software Project Isn’t Like Buying a Car, It’s Like Seeing Your Doctor

For the past 15 years or so, I’ve worked in software, managing projects. I’m still surprised when the word “estimate” and “time and materials” means one thing to me, and something entirely else to customers. I’m not blaming the customer, per se – it’s not their milieu, so how should they know better?

For example:

Patrick Customer
Estimate An approximation of time and cost, based on what we know right now. Subject to change over time as we learn more. This is exactly how long it will take and exactly how much it will cost. Probably less.
Time and materials We’ll work on a time and materials basis – if it takes longer for any reason, we’ll let you know. This is a fixed fee project. If you make mistakes, that’s your fault and I’m not paying another dime.

I get it, though: I recently did a small bedroom update, and my contractor worked on a time and materials basis. But since I don’t build things for a living, it was easy for me to be shocked at the price and the timeline.

For example, after the demolition was done, I thought “how could this take 4 more weeks?”

It looked like it was much closer to completion than it was – looks can be deceiving. It was my lack of experience that made me feel that way, not that my contractor wasn’t doing a terrific job.

Not Like Buying a Car

When you buy a car, you are purchasing a product that is complete already. Sure, you can pay more or less when you pick tires, a stereo, a sun-roof. But you know before you sign how  much it will cost, and you also know when you’ll get to drive off of the lot. That’s terrific.

Software isn’t like that. Sure, we know a lot more than we did: there are scores of books about software development and best practice, and software tools are better than ever.

What those things don’t do though, is solve for all of the stuff that you (and we) don’t know.

Here are a few examples of areas where small unknown’s or seemingly simple choices can skew project costs:

1. You don’t know your data, and we don’t get to see it in advance. So we make a good faith effort to tell you how long it will take to migrate it to the new system. When we see the data we find out that you’ve blended all of the first names and last names into a single field, so we have to review and parse all of your data first.

2. You have an existing system and a previous developer purchased a calendar widget to make it work. That software is no longer available and doesn’t work with modern operating systems or browsers. So we have to replace your entire calendaring system.

3. You are certain that your case managers work always start with a screening so we build a screening widget. We find out at launch that you just wished they started with screening, but really they always do a full intake. So we have to tear out the screening features, and fix all of the processes to match what is really happening at your agency.

More Like Seeing Your Doctor

Say you have a cold, or think you do. You go and see your doctor, and she says “There’s a thing going around. Rest, drink a lot of liquid, and come back in 5 days if you aren’t feeling better”.

You come back in five days.

Your doctor says “This looks like it could be allergy related. Take one of these every day for the next 5 days, and come back if you aren’t feeling better”.

You come back in five days.

Your doctor does some additional testing and determines that you have an infection. She prescribes medicine and you get better.

Great. You just saw your doctor on a time and materials basis, and what you paid for was the fix and all of the steps along the way.

With software, you do the same thing: you pay for the process. But a lot of customers want to pay for just the solution. Imagine going back to your doctor and telling them that you aren’t paying for the first two visits. Wouldn’t that be nice for you?

But you know better: medicine is an enormous field, and experts work through a process to help you. The apparent thing isn’t always so; the path forward is sometimes murky; and its better to start with simplicity and move towards complexity than it is to go the other way around.

Software is like that, too.

What Can You Do, Then?

  1. Shop around. You can tell when the person at the car lot is blowing smoke, so you can learn to figure out which software vendors are reputable.
  2. Have a contingency fund.
  3. Be ruthless about features, and implement the crucial ones first. Don’t get bewitched by the cool, bright and shiny thing that increases your cost without providing commensurate value
  4. Make sure you actually participate in the project.
  5. Grow your technical expertise. You don’t have to become a software developer, but you should learn as much as you can about their proposed solution as possible.
March 7, 2015

First Week on the Rescue Project

It’s your first day on the project and although no one said out loud you need to rescue the project, you do. There’s a reason there’s been a switch, and most of the time people will be too polite to say out loud that your predecessor was failing. So here’s how to get started:

Don’t Read The Scope of Work

That’s right. Do NOT read the scope of work. There will be plenty time for that later. But the problem isn’t the scope of work, it’s that no one else really read it either. So here’s what you do instead:

Think of the project like a multi-layered cake. On the bottom, you have developers and QA folks – they’re doing the real work. Next layer up is the product or project manager. They think they’re doing the work. And the top layer? That’s the person writing the check. Sure – you can slice this into more layers, but 3 should get you started.

Meet with as many people on the bottom layer as you can, and ask them what they are doing. Don’t let them fetch the scope either, and make it conversational. Take notes.

Repeat with the middle layer. Take notes.

Finish up at the top. You can probably see where this is going already: the person writing the check thinks one thing, the product manager a second thing and the developers a third. There you go. That’s probably why your project is in crisis.

Figure Out How They Do Their Work

You have two broad categories here, Agile and Waterfall.

If it’s a waterfall process, find a whiskey barrel, get in it, and throw yourself off a cliff while holding a Gantt chart. You’ll have about as much success managing the project as surviving the fall.

If an agile process, your odds just went up. But you’ll want to know a lot more about what their version is really like. Do they say agile but mean waterfall? Are they actually delivering code to production at the end of each sprint? Those things matter, and they’ll help you understand how things are actually working. The tug of war between methodologies is strong, and even the most agile of shops can get pulled into waterfall processes and procedures. You won’t be able to change those, but if you understand, your odds go up.

Understand Their Technology

This can be challenging; your job isn’t to do the the actual work – but you should understand in broad terms how the project team is going about theirs.

  • If it’s a website project, you’ll want to know what tools they use to generate graphics, what technologies are in play on their live website (HTML, CSS, JavaScript and a lot more, probably), how they host their website (on premises, with a vendor, in the cloud), and how they publish changes.
  • If it’s a database project, you’ll want to get answers to the same questions about where (on premise, hosted, both) as well as to know the fundamental tools (SQL, MySQL, Salesforce, something else).
  • Mobile? Even more fun. What devices, what operating systems, what handsets, which app stores and so on.
  • Infrastructure? Swell. Domain names, routing, switching, fail over and redundancy and so on.

Again – you don’t need to be a domain expert, but you need to know the building blocks of the project you are managing.

Understand Their Culture

There are entire books written about this, and about how culture is perhaps the most important thing to know and understand at a place of business. You won’t be able to absorb it all right away, but you can ask yourself a few questions to get a sense:

  • Are their motivational posters on the wall?
  • Are people afraid to disagree with one another (or worse) their boss?
  • Is shoddy work tolerated?
  • Are people rewarded for following the rules?
  • Does your tech team sit far away from everyone else?
  • Does everyone come and go at the same time?

Here’s a shortcut: if you were looking for a full time job, and they offered it to you, would you really want to say yes? That’s a good sign. No? Not so much.

Now Read The Scope

You’re still in the first week – take a look at that scope. Make a copy for you, and mark it up. You may as well get the latest budget numbers and date estimates, too. Don’t get me wrong – those are all good things to know, and you’ll need to track those carefully to be successful. But merely tracking those things won’t make you successful – you need the other things on this list to do that.

There you go – a task for each day of your first week on the rescue project.

Looking for more tips? Try these on for size:

Patrick’s Top 21 Project Management Tips

What Makes Great Project Management Software?

Becoming a Technical Project Manager

Sent Your Iron Triangle to the Scrap Heap

Waterfall or Agile?

August 15, 2014

No, Virginia, Null is NOT An Answer

Okay – null sounds an awful lot like “dull” – but stick with me for a minute here: understanding null now will help you later when you really need to run that report!

If you haven’t run into the null problem yet, you probably will. It goes like this:

Chief Marketing Officer: “Can you get me a list of everyone that bought a widget last month and likes to drink beer?”

You: “Sure – we have all of that data in our database, because you had me add “do you like beer?” to our credit card checkout form!”

So you run the report and hand it over and your CMO wants to know why no one likes beer! And it turns out that you have a NULL problem! It’s about blanks. And we know how blanks turn out:

  • “He had a blank stare”
  • “My screen suddenly went blank”
  • “The signature on my check was blank, so I was charged a late fee”

You’ll most often see a null value when you haven’t required someone to give you an answer. In the case above, you probably didn’t make the “do you like to drink beer?” question required – so some people said yes, some said no, and most left it blank.

It’s worse when there really *ought* to be an answer. Try this one – gender. Everyone has a gender identity – so if you ask that question and don’t make it mandatory – you’ll get blanks. Which leads to your CMO looking at you like you are crazy: “What do you MEAN we don’t know what Patrick’s gender is?!”

When we store data that is supposed to be binary (like a yes or a no question), we really have three states:

  1. Yes
  2. No
  3. We don’t know

It’s that last one that turns out null – and what it really means is that you didn’t ask the right question, or you didn’t ask it in the right way.

Here are some tips for avoiding getting to null:

Don’t add optional questions to any of your online forms or interactions. Besides being a poor user experience (what does my salary have to do with signing up for your newsletter?) it practically ensures that you’ll have null or blank values.

Don’t ask for information that you don’t need right now. Sure – your fundraising efforts get better when you know a lot about me. But don’t forget that we’re trading – you give me something I want, and I give you something you want. If we just started dating – you shouldn’t be asking for my salary.

Make sure your internal data entry practice is sound. That means looking at all of the spots where you are storing data, and figuring out a default value. So if you have a spot to track my gender identity – one of the options should be “not provided” – so you can tell your CMO that Patrick DOES have a gender – but doesn’t want us to know.

Regularly look for null or other confusing data points, and fix them. It happens – you import some data, switch tools, or otherwise end up with data that isn’t clear. That’s okay – just don’t let it clog things up. At regular intervals – run a report and look for null or blank values, and make a plan to clean them up.

July 1, 2014

The Oldest Trick in the Book and the Most Common Lie

Ah – you think this will be a post about prostitution, but it’s not. But I am going to talk about stripping.

Pretty exciting stuff.

Here’s the deal: the most common lie we tell ourselves is that technology has advanced far enough that you can have a What You See is What You Get tool for editing all of your web content. It’s called a WYSIWYG for short, pronounced whizzee-wig.

But it isn’t true.

Sure – it’s WAY better than it used to be. But if you’ve ever wondered why your Times New Roman started to look a lot like Comic Sans – this post is for you.

See – almost every widget you have at your disposal adds formatting information to your copy. And then when you cut or paste, or move things around, say, from Microsoft Word into your WordPress driven website, formatting Armageddon happens.

So here’s the stripping trick: Copy all of of that font hellishness over to a plain text editor. On a PC, it’s likely a tool called Notepad, and on a Mac, it’s likely a tool called TextEdit.

Both of those tools are exactly what they say they are: a plain text editor. Plain as in “no formatting” –so if it is

bold, 18 point and italic  in

WordPress, when you paste it into Notepad or TextEdit, all of that formatting goes away. Like this:


So – fine – now you know how to strip. Here are a few tips that just might help you avoid having to do that in public:

Write First, Format Second

Don’t get me wrong – what you write and how it looks are both very important. But resist the urge to format as you go – get the words in order and then go after the formatting.

Always use the same tool

Always start and finish with the same tool. If you are using WordPress – make ALL of your copy edits there – resist the temptation to create in one tool and format in the other.

Learn HTML

Almost all of the tools have a button you can press that will show you the HTML it is creating on your behalf. A little knowledge goes a long way – and after about 30 minutes, you’ll be able to spot that line break that is getting in the way.

When in Doubt, Start Over

Set a timer and stick to it – once you land in formatting hell, you should know when it is time to quit fiddling around with your text editor and just start over. Do the stripping trick, get all of your copy in place and THEN format it.

Use a Style Guide

You shouldn’t have to make it up every time. A headline should always be the same font, size, weight. Ditto for bulleted lists, numbered lists, pull-quotes, and the rest. Create or get a style guide that tells you what formatting to use, and follow it.

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.

May 30, 2014

Send Your Iron Triangle To The Scrap Heap

Or maybe to a ranch somewhere, where it can be used to call folks in for supper. Or dinner. Whichever one happens at lunch time.

So – here’s the deal: We keep talking about the iron triangle, or triple constraints as a bedrock of project management – and it’s not true.

Sure – understanding your timeline, and your budget (which these days also includes resources because you can buy just about any expertise you may want) and your feature set is important.




But those three things aren’t useful in the way they once were, not especially for software projects.

In the old model, it was super expensive to set up a server. To pay someone that understood routing. To find someone that understood the difference between an inner and outer join. And so on.

And in the old model, either it all worked, or you didn’t have anything.

Because of those two things – the iron triangle made a ton of sense – if you bent any part of the triangle, something else had to give. Since creating software was super expensive and super time consuming – this was a handy way to frame a project.

My, how times have changed! You can have a server setup in a few minutes, at the hosting location of your choosing, and it costs pennies on the hour.

Shouldn’t we change our mind about the usefulness of the triangle? I think we should.

I suggest that we relegate the triangle to the basement – you might want to drag it out and use it once in a while – but you don’t want it cluttering up your work.

And then replace it with a much simpler diagram – it’s about decision making, releasing to the public, and adoption.

You have 2  axes:

  • Rapid, informed, and devolved decision making
  • Rapid and iterative release to customers

If you achieve both of these – your outcome is adoption (you ARE releasing what customers want, right?)


But if either of those axes tilts (slow decision making/slow release) – you don’t get adoption. Someone else gets there first:

It’s not the big that eat the small, but the fast that eat the slow.

A bit more about decision making. Your business owner shouldn’t be involved in the how. And they should be involved in the what only to the extent that they can describe it out loud. Asking them to weigh in on your CSS schema is silly. So you want to devolve decision making as much as you can – get your execs to tell you why, and what in general, and then let them get back to running the business while you and your team get to work.

And that work should be fast and iterative. Show, don’t tell. Let your team build something that works, and show it early and often – and you can course correct quickly. Even better – show it to your actual customers and find out what they think.

What do you think?

May 28, 2014

Make Your Next Project Manager Hire an English Lit Major

I’ll disclaim right away: I am an English Lit major and also a project manager.

(That also means that when this post descends into broad generalizations, I’ll know that I’m intentionally using hyperbole.


When a lit major says “I don’t know” what they really mean is:

“I don’t know yet, but I learned how to know in school.”

When a lit major says “That seems familiar” even though nothing looks familiar, what they really mean is:

“I learned how to recognize patterns that cross boundaries – so this looks familiar, so I can help solve this problem.”

When a lit major says “I’ll send a status report”, what they really mean is:

“I might send it as an haiku, but everyone will read it and know what it means.”

When a lit major says, “I can explain that”, what they really mean is:

“I’ll find a way (allegory, storytelling, comparison) to help you grasp a technical concept in a way that allows you to make a great decision.”

When a lit major says “It’s okay if we disagree”, what they mean is:

I learned in school that there are oft more than once answer to a question – so I don’t need to be right, so long as we are moving forward together.”

When a lit major says that success is finishing the project, what they mean is:

Following a method is easy but doesn’t guarantee success. Success is defined by finishing, not starting.”

I could go on, but I won’t. Not imitating James Joyce or Charles Dickens here.

Here’s the deal though: People with a lit degree make better project managers, because their eduction was about learning, not about doing. Project management isn’t about following a software development cycle, keeping a schedule, managing a budget. Those are the least important parts of project management (needed, don’t get me wrong). But merely keeping track means you can be successful at . . . keeping track. So what? You want a fast learner, someone with endless curiosity, someone with great communication skills, someone that can get through a ream of reading material and know what is important, someone who grasps and uses context.

What you need, then, is a Lit major!