Processing the Process

Working with transformational technologies such as Workflow and Content Management, I often find myself warning clients not to transform too much, too fast. During our sessions, they’re eager to pronounce low-level, semi-detailed rules without giving much thought to administrative overhead or implementation costs. They’ll throw-out sentences such as, “Oh, and the system should stop the user if it’s an XYZ account and the ABC letter should be sent out to all the JKL clients.” The problem is that this seemingly reasonable request requires:

1. Integration to a new system,
2. A letter generation system plus integration to a database, and,
3. Implementation/administration of organizational support tables.

Then the user blithely adds, “Unless it’s quarter closing and we’re behind on processing, then just let it go through.”

 

Do the Big Stuff, then tweak…

The most effective way to implement systems that introduce radical change is to concentrate on getting the basics right. The most common objection I hear to this advice is, “If we’re going to do it, let’s do it right!” It’s typically said as if what’s “right” were obvious to all but the dullest fool. As I’ve pointed out before, however, new software is an invasive species, and it can breed unanticipated offspring.

I like to see software in it’s new habitat, and then evolve it, by design. After it’s introduction, we watch and analyze. We see how users are leveraging the new functions and data, what old habits are now redundant, and where former processing validations need not be enforced or can be obtained without user intervention. Only then do we tweak…

Don’t forget to tweak.

Tweaking is easy to forget, and yet, it’s where business can often reap the greatest reward. After implementing a disruptive system, and putting your users through so much change, you have to go back and listen to them all over again. You have to find out what works and what doesn’t. Yes, you may hear a lot of griping, and it may be on the heels of a difficult and stressful roll-out, but it’s crucial. No one likes to hear negative user feedback, but if you don’t clean up your own mess, someone else will, and you’ll be remembered not for what you got right, but for a vague smell of inefficiency and missed opportunity — it’s not a pleasant scent.

No Funding for the Tweak!?

This is one of the stupidest and most avoidable problems in all of software development — companies forcing project sponsors to procure funding once and never being able to ask again. This is a self-induced crippling of benefits. It forces sponsors/managers to spend more upfront, attempting to predict exactly how a system will be used, because going back for additional funding is difficult or impossible.

I understand it’s done for cost containment reasons, so that ROIs can be calculated and paybacks ensured — but it’s dumb. It’s the reason that rapid development and agile techniques are so often promoted, and it’s one of the reasons such techniques are ignored, because those approaches make building a compelling business case more difficult,

Ask Anyway

Numbers are hard to ignore. I find that when presented with real numbers (and the solid math behind them) folks will listen. Let’s say you have 30 Specialists each processing 6000 “applications” per month. If you can demonstrate how a $50,000 change to the system will save each user 30 seconds per application they process, the payback would be (in theory) 3 years (and there are many ways that theory can turn out to be wrong, but that’s the subject of another post).

If you add enough of those tweaks together — you’ll be talking about real money!

Effectiveness thru Annoyance

I am simply amazed at how effective ANNOYANCE can be. You don’t have to be smart or particularly driven to get something very unlikely accomplished — as long as you are willing to annoy hell out of people.

Maybe you request a daily meeting to update you on the status of some small, relatively meaningless problem — but one that for an unknowable / unfathomable reason you care about.

Or maybe you send an email every couple days asking, “Do you have any update on X” — where X is a point of benign minutia that no one would think to worry about, no one but you.

Or you could do it this way: Send out painstakingly polite messages over and over again asking to change the exact same pointless function. You can almost feel the recipient buckle under the pressure of having to find new ways of saying no to you. Spice up this last approach by copying other folks “above” your target who only have a superficial knowledge of the issue.

This works. It works so remarkably well that I’ve seen thousands of dollars spent to fix what isn’t broken or “problems” elevated above other, far more pressing, issues simply because a manager couldn’t bear to receive one more email from that user.

Honestly, it’s one of the most effective techniques I’ve seen. You have my respect, Mr. and/or Ms. Annoying — my respect and my loathing.

Mind-Bite-Size

Ahh… the freedom and pleasure of taking the first requirements on a brand new project…

…excitement is high, entire worlds of efficiency and productivity have yet to be discovered!

…the juice of creativity flows unrestrained — it runneth over!!

…swirls of systems integrations, the luscious fruit of big data, utopian visions of business-controlled process agility — all is possible!!!

And then we begin to talk about actual problems. Solutions to real-world processing dilemmas, and with an operational wave in the heady optimism of our fully-funded project, such obstacles are banished to the realm of mere “technical issues” — just problems for IT.

“Um,” says some jerk in the back of the room. “I don’t understand how that’s going to work.” Heads swivel, eyeballs glare. “I don’t think it’s going to be that easy, or, actually, possible.” Clearly, he’s the wettest of blankets.

The voice of a VP rises above the din, hands wave as he explains, patiently, it’s simply a matter of “pushing” the data.

“Yeah”, think a lot of the people in the room, “what’s this guy’s problem? Can’t he see that pushing the data is so much better than the user pulling it? If the user had to pull the data that would slow down the process — and we have a blank slate here — we are improving processes — we are maximizing time, and time is money, and what’s this guy’s problem anyway?”

The guy is suffering from what I call, “The Unease of Gray”. It is the dull throb of stress and fear caused by vagueness of a business requirement. It comes from half “being burned in the past” and half “knowing a thing or two”.

Then the guys does a sobering something. He breaks down the problem, out-loud. Not so much for other folks to understand but simply so he can understand what it is they’re talking about.

He asks questions like:

“How will you know where to push the data this early in the process?

Will you push on a schedule or at predefined points in the process?

How do I get the data if I need it and you haven’t pushed it yet?

How do I know if the data has changed or if what I have is out of sync?”

It is by asking these small questions that the overall effort becomes clear.

And yet, there are those who persist, insisting, “We will save the users from having to click ‘Retrieve Data’. It’s so much easier!”

“But at what cost?” the cold wet depressing blanket responds. “How much bandwidth will the network calls consume? How much maintenance will the code require? What are the costs of implementation to save this ‘one-click?'”

And here’s the thing, I can’t answer that question. It depends, again, on bite-sizing the problem for your mind. How many times is this click performed in a day? What is the relative “value” of the individual performing the click? How many individuals in the organization would have to suffer this click? And could the user be doing something valuable for the business with their clickless time, should it be returned to them?

Answer those questions, compile your data, validate the results — then you will know.

And wouldn’t it be nice if problems in real life could be solved this way? If we could break down obstacles into little, answerable questions? If we could get away from the vague unease and fear of large and overwhelming existential questions and tackle them one by one, in tiny thought-morsels that we could get our minds around. Yeah, that would be nice.

The Shock of Misinformation

I remember the first time I met with crushing disappointment. It was a number of years ago, and I was working on a complex workflow project. Users needed, at a glance, the ability to assess the status/condition of their work and to have several techniques for annotating and setting alerts to help them track and keep informed of an item’s progress — all of this without having to exit the list of work currently assigned to them. I was proud of the final product and confident we’d met their needs.

As happens frequently in consulting, I was quickly assigned elsewhere — though I made an effort to keep in contact with managers on both the Business and IT side. I asked about user acceptance and adoption, I wanted to know if they were happy, and I was told they were, the software was a success, time was saved, dollars were retained.

Then all hell broke loose.

I received a call asking if I could come in, spend some time on the floor, talk with users and potentially identify areas of improvement. I was given a contact, arranged a date to meet, and arrived at the designated location. As I entered the office, I saw the bowed heads of engaged employees stretching far into the cubey distance. Honestly, I expected to be welcomed as a transformational hero — returned to further enrich the lives of appreciative users. Yeah, that was dumb.

Now remember, I’d been told how well everything was going. In fact, I’d been given numbers. Productivity was up and paper savings were through the roof — costs were down 30-35% overall. But these people before me, they were miserable. I saw folks working from printed spreadsheets, color-coding rows as they trudged along, keying in searches to find the next item they needed to work on. From a workflow perspective, it was horrible.

All the features we spent hours designing and vetting and prototyping seemed to have been abandoned, and the process before me was LESS efficient than the one we replaced. But I had numbers telling me otherwise!

Walking into the manager’s office, I was numb with shock.

Here is what I learned…

This particular group of users worked on items of “low-value” and low-profitability. They made quick decisions about which items to work on, and at any given time, they might juggle up to 100 pieces of work. This was in complete opposition to the requirements the system was designed to meet. The users previously interviewed were assigned 5-10 items and were expected to understand each one intimately. The underlying data and documents were complex, and each item they worked on was extremely valuable to the company. These were the vocal users of the system, and they were the ones that were happy.

This group was not. These high-volume workers needed advanced sorting and filtering functions. They needed certain data prominently displayed and the ability to pluck items from a volatile mass of time-sensitive and fluctuating assignments. And why were these folks’ needs not considered? Because they were not the “high-value” workers. They were far less visible, toiling away in  a kind of backwater business outpost. They were not the stars of the company, making enormous deals posted to achievement boards. And ironically, what I came to learn much later, was that the value of all these small deals and the customer-base / market-share it secured, was as valuable as the big deals that loomed so large in management’s imagination. But that will have to be the subject of another post.

Today’s lesson is this: Information is sensitive to source and focus.

When viewed from one angle, one might see a grand circle of success, but to others, the same initiative may be a square failure. A truly successful project requires an objective look at the whole — a careful examination of not just the “stars” on which a company’s success seems to rely, but of all involved — even those lacking the glamour and limelight.

Software is Soft

Having been tasked on more than one occasion to “position” enterprise level software (e.g. Content Management, Workflow, RDBMS) against its major competitors — and having poured myself over Gartner and Forrester reports, attempted to sort through the jargon and keywords-of-the-month to distinguish what I know to be true versus what the reports say — I’ve come to realize that software, really, is soft.

 

More importantly the aspects of software that push it higher in rankings may be meaningless or even detrimental to your use. Here’s a course example: Software ‘ABC’ get’s an uptick for “Multi-Platform Support” — it runs on Windows, Unix, iSeries, and z/OS. But you have a Linux server. The problem is obvious.

Now I’m not saying there aren’t differences between the big software vendors, or that 1st-gen product flops should be avoided (I’m looking at you Process Server). And one can certainly find hot-eyed defenders and baleful naysayers for any brand — but how those differences bear-out through a development cycle and the impact on future projects is almost impossible to determine at the time of purchase. Add to that mergers, acquisitions, strategic shifts in direction — and choosing software is like throwing darts… underwater.

The most important aspect of a software implementation is not the software, but the implementation. The strength / depth of your staff, or having a good relationship with a competent / trustworthy services vendor — those are better indicators of success than knowing in which “quadrant” an enterprise solutions appears.

And when you’re dealing with some shortcoming or ‘hidden feature’ of the software your company just spent a million dollars buying, and as you second guess your decision and gaze longingly at a write-up in some tech journal describing your competitors super-duper implementation on a competing platform — know that someone in that same company is beating his/her head on a desk fretting over some other limitation or trying to figure out how to tell management that the software they just spent 5 million on can’t do x or z natively.

It’s like a lot of other things in life, we’re not limited by our stuff but by our actions. It’s not about the furniture we’ve meticulously selected, or the specs on our car, or even the size and complexity of our paycheck — it’s what we do with our stuff that matters and how we live our lives that gives it value.

I still haven’t found the Gartner report to explain that to me.

Software: An Invasive Species

Companies are ecosystems. Cube walls, desks, swivel chairs, and cabinets — all this, the flora. We humans workers are it’s fauna, but so too are somewhat less intelligent species, such as multi-function peripherals, automatic pencil sharpeners, PCs, and the software that runs upon them. Toss in the occasional customer, a shifting climate dictated by business-type and the local conditions under which it’s performed — and you have a full-fledged ecosystem as difficult to quantify as winter in the amazon.

My job is to introduce new species, software that is, into what are invariably inefficient — yet functioning — business environments. Now in theory, the new software has been designed specifically and competently to meet the particular needs of each business. Visions were cast; opinions were aired; requirements were gathered; designs were vetted; procedures were documented; builds were promoted, and testing was exhaustively completed. Still, no one knows what the hell will happen when the software goes live.

Why is this? How is it that something so well planned — and so expensive in both cash and time — can lead to such unpredictable results? Because software is an invasive species. It feeds voraciously when first introduced, gobbling up person-days of productivity via formal training or the painful on-the-job, learn-by-fire technique adopted by many companies. And just as initial disturbances subside, the more sinister aspects of its presence become clear: minor tasks that were considered negligible during design turn out to require 5-10 clicks, multiple times per day. Edit checks that were introduced to protect the company and increase compliance, actually impede folks’ ability to deliver product to the customer. New dependencies in database design require peripheral systems to be updated more regularly — further leaching hours from the business day.

But there’s more — managers now request reports on data that had heretofore been unavailable. Executives push for customer self-service because, hey, why not!? Other units within the organization start using the system in unintended ways, though they were never in-scope and their requirements were never taken — then they complain the software doesn’t meet their needs.

And yet, time passes — tweaks are inserted, workarounds developed, knowledge gained. Folks discover shortcuts, and they whisper them across the landscape of cubes and around the watering  hole. The invader integrates, balance is regained. Promised efficiencies are realized but their source forgotten. Reports and data integration provide the business insight both internal and external. And the source of this too is forgotten. The new species melds into the background, and the benefits it has brought become just another part of the scenery.

Ah, but the initial turmoil and upheaval — those scars last forever.

Everybody Sucks at Imagination

Listening to and organizing people’s business needs can be tough…

— designing a system that cost-effectively meets those needs, a good deal tougher…

— but describing the system back to folks, asking them to imagine how their new software (at the moment mere words on a page or scribbles on a whiteboard) will fulfill “all” (about 80%) of their business requirements, saving them time in the overall process, and positioning them for future benefits (as yet undefined and unquantified), that’s the worst!

And I’m convinced that I’m fantastic at communicating the functionality and benefits of unwritten software. I’m patient. I’m enthusiastic. I’m detailed, but I’m not too detailed. I repeat myself over and over as the same question is asked again and again, and I almost never say things like, “Well, as I just mentioned 2 minutes ago, the answer is…”

It’s not me. The problem is Imagination. We suck at it. All of us. What we see in our heads is what we want to see (or sometimes don’t want to see), but it’s never what’s being described. Imaginations miss. They are filled with assumptions about how something is going or ought to work. The images in our minds are loaded with answers to questions that haven’t been asked.

Sure, there are tools and methodologies and utilities and standards, but each of these techniques requires effort and resources, they require a certain discipline I have rarely seen used consistently, and almost never have I seen them used effectively. Why? Because IT is a service with many masters that pull in opposing directions and because we don’t usually have the 2 luxuries the discipline demands: Time and Money.

Time and money are not luxuries, you reply, they are resources!

Nope. When you want something you don’t have enough of, and you still manage to get by without it — I call it a luxury. But I’m getting ahead of myself, let’s get back on topic and to the take-away of this post. When describing ideas, be they software interfaces, process models, systems integrations, or your favorite cocktail — remember your vision is not their vision. Details will be missed, gaps will be unaccountably filled with expectation and assumption. Be prepared to deal with those differences and divergences during the delivery cycle. And when they come to light don’t blame or resent. Realize that everyone’s imagination sucks — yours and mine.

If War Is Hell, What is Battlefront: IT?

This is a blog of observation.

For 20 years, I’ve worked at the interface of IT and Business. I’ve performed numerous and sundry roles at large financial institutions and government agencies. Mostly what I do is turn paper into bytes. Then I ensure the work that heretofore depended on paper can still be done without it — all the while designing more efficient business processes and integrating new technologies when and where they make sense. I don’t know if this is an intriguing or boring description of what I do, but I can assure you that in doing it, I’m repeatedly fascinated by the struggle between IT and Business — and the humans trapped between them.

Well, you might be saying, okay, but it can’t be that violent — why the combat metaphor?

You see, most folks will say that IT exists to serve. And I believe it serves more than the average number of masters. Not only does IT serve to make the life of “The User” better (by increasing efficiency, decreasing workload, providing access to information), it’s also expected to serve “The Boss” (by helping to manage said users and to a certain degree control and manipulate them). IT, however, must also serve itself. It must be engineered and  built with an eye toward change and future technologies, toward the overall performance of the system, toward disasters that may never come and ones that surely will. And all the while IT is itself a business, sharing the same pressures of profitability and success as the users, bosses, and other technologies it serves.

So, yeah, IT is a Service Industry. It’s a waiter — but one that after serving your food, reports your meal to your parents, warns you to finish your peas, keeps track of your calorie intake for future analysis, and long after you’ve left the restaurant, this waiter makes sure your meal is “migrated” properly and efficiently into it’s murky future. Which of course sounds a little disgusting, and which is why this blog is not called : “Hi, My Name Is IT, and I’ll Be your Server Today”.

All of this is to say, IT has myriad responsibilities and competing priorities that it’s expected to fulfill. Add to that, many in the field despise the masters — the disparate technologies we’re forced to consider and integrate with, the bosses we must constantly keep informed and empowered, and the users — those damn users! This is the source of conflict, this is the battlefront, the place where I live — where people ask for and expect as-yet-impossible functionality, where the needs of the business stress and strain the limits of human achievement, where smart folks who love to tinker and fiddle with the newest toys are forced to put them down, go back to work, and serve, serve, serve.

I’m writing this blog to share my experience–the view of a single IT Consultant ensconced deep in the machinery of corporate IT–and to provide advice on how the front-lines might be made a little less combative. I’ve seen what works on projects large and small, and I’ve seen what fails — miserably. I’ve been on IT death marches, and I’ve had some notable successes you’ll never hear about. I hope that by sharing what I’ve learned, and fostering discussion around it, I can help some folks who’re involved with how technology “get’s done,” get it done with less conflict — and more peace.