That concept is what Kissane calls "Day Two." It's shorthand for the time after the system (typically a company website) is launched, approved, and everyone settles back in to their "regular" jobs. In the case of any contractors or freelancers, it's the next gig (or looking for it). But in the case of employees--at least some--the definition of the "regular" job might have shifted.
Problem is, those shifts are not always recognised, much less budgeted/scheduled. (And if the consultants didn't hammer that point home during the planning phases, you probably don't want to hire them again.) Bottom line is that those extra hours of researching, writing, photographing, proofreading, vetting (by the Engineering/Marketing/Legal/Whatever functions of your organisation), etc. do not magically appear out of nowhere. (Nor, equally shockingly, does the time/money for training people when the launch crew moves on.)
Bigger problem is, no one is surprised to read about those realities. Yet too often the surprise comes when (through some evil influence or misalignment of the stars, no doubt):
- The company blog has been dormant for a year, plus some fool lost the Hootsuite account credentials, so the Twitter/LinkedIn/Facebook accounts are stale, too.
- News releases are being used as a political football between Legal and Marketing...and ultimately published (late) as convoluted fluff that no one with a shred of respect for the written word reads.
- Whitepapers cite the previous version of the product...and still have the old logo/branding--embarrassing!
- Calls to Customer Service (not to mention social media hissy-fits) creep up because the online help doesn't deal with new products and/or features.
- No one has any idea whether email campaigns are working or not, because who has time to set up A/B testing in MailChimp anyway?
- (My personal favourite) I/T receives cranky calls from Management because "No one's updating the website." (Don't laugh. It's soooooo not funny.)
Over in my more data-driven world, I'm usually, um, "lucky" enough to see somewhat less acute symptoms of the same disease. But it still means time devoted talking clients out of wasting their money.
Because the bottom line is that information that can't be captured as part of the normal course of doing business won't be backfilled later. It just won't. Anyone who thinks otherwise is delusional. That's the bad news. The good news is that you will--or should--be talked out of that by any halfway decent/competent application developer. (Why? Because we frankly don't want the fallout and bad karma that comes from letting you do that to yourself. For ourselves personally and for our industry in general.)
Case in point: I worked for a company that had to make a whack of outgoing long distance calls--to the point of bringing in part-time help (and the owner's kid) three times a week for eight hours a day. Before my time, the company had had to fire someone who abused the system by making long-distance personal calls. For an hour. Five days a week. I know for a fact that it bugged the heck out of the company Accountant, because he told me the story twice.
For all five hours of lost productivity plus the long-distance charges add up over 52 weeks, it would have been sheer profligacy to force each employee to log all calls--either on paper or even the most user-friendly app. any programmer could devise. Even requiring the Accountant scan through the month's dead-tree phone bill isn't a negligible cost (especially as the company grew from 20 to 40 people and acquired two other companies in the process).
But when the afore-mentioned Accountant bee-bops into my office to mention that, hey, did I know that our new phone service provider supplies us with a downloadable plain-text version of our phone bill and is that maybe something I could parse and dump into a database so he can generate reports from it...now, that's a different equation entirely.
Sure, there was the up-front cost of my time (setting up the database, creating a user interface to allow the Accountant to upload the e-bill, and of course setting up the reports). But after that point, the system could scale up to any number of employees with no extra incremental time required for the Accountant to segment and sort and total the data any old way he needed it. Including, if necessary, importing it straight into his own software.
That, friends and brethren, is pretty much the gold standard of business automation. By which I specifically mean that data that would have been prohibitively expensive to manually log was mechanically collected in an easily consumable format (by our vendor). Better yet, the only business process that had to change was the Accountant having to remember to download the .CSV file and then upload it to our system. Trust me, he did not complain.
And thus, "Day Two" of that application was just "Day One" of Happily Ever After. That's how you want your story to end. And it should end that way if you're realistic about how you're going to capture the data you need to make decisions. Yes, I realise that it's all too easy to be caught up in the fresh promise of hackathons and project kickoff meetings and wireframes and mockups loaded with Lorem Ipsum. Just remember that software comes with an invisible fine print that reads "Data not included."
