“Hey man, that’s old school,” said the person at the next table over from me at Starbucks.
I looked up to see who he was talking to. To my surprise, he was looking right at me. The young man looked like he was studying for college. There were text books and an iPad in front of him.
“Old school, man,” the young man, repeated pointing at my hand.
I was holding a fountain pen and making notes on a yellow lined pad. Now I knew what he was talking about. To be fair, there was also an iPad on my table held open with its Bluetooth keyboard but it was the pen that had caught my neighbor’s attention.
“Yes, I often like writing with a fountain pen,” I smiled.
“Why?” he asked.
“It makes me write slower,” I said.
This caused a look of confusion on the young man’s face that he hadn’t seen coming.
“Slower?” he parroted.
“Yes,” I replied. “I find that if I write with a fountain pen, I’m obliged to write just a little bit slower and when I write slower, my brain seems better able to articulate its thoughts before they end up on paper.”
This was clearly a concept that my Starbucks tablemate hadn’t ever considered and it was so foreign to him that I could see he was really thinking about it.
I went back to my work and I left him with the thought.
I bring the conversation up because in today’s instant gratification, real-time entertainment, miniscule soundbite world, we have a tendency to work faster than we sometimes should. This is mostly invisible to us because we live in it every day. It’s like water to a fish. We see it, they don’t. They just live in it. But, we are pressed every day for faster and faster and faster results. “Time to benefit”, “Time to market”, “Time to payback” are all popular concepts and prospective clients approach our firm all the time to find out how quickly they can deploy the enterprise timesheet or enterprise project system they’ve selected.
Going fast is not always the best plan.
Our staff try our best to have clients make a considered decision and to walk through the business processes that the prospective client is considering changing.
It’s not uncommon for me to have a conversation with a prospective client who says “We need to get this done” and when I ask for more details on “this” find that the organization hasn’t really considered the ramifications at all.
A few years ago, I was called into a large defense contractor by one of the largest publishers of project management software (I won’t mention the names to protect the guilty). I was to be the “subject matter expert” referred to by my acronym: SME . You know people think this is important when they say pronounce the acronym like it’s a title. “This is our “Smeee”. I was very proud of myself for not laughing.
So, there I am, the Smeee, and as I sit down, someone literally hands me the end of a projector cable, leaving me very confused.
“What is this for?” I asked.
“So you can demonstrate the software,” the head of the PMO replied.
I had no idea what they were expecting me to show them but they were sure in a hurry to see it. We hadn’t even gone around the table for introductions (except to point out that I was the Smeee).
“Um, maybe we can do it at first with the lights on,” I said.
This at least got people to laugh and then I insisted on someone describing what the actual problem was.
“We need your software installed and running right away,” was the answer of the IT specialist.
That made my hosts, the software publishers, very happy. They sat up even straighter in their chairs and looked at me expectantly.
“Sure, but that’s a solution to something,” I replied. “Before we talk about how long it will take, perhaps we can talk about what you are trying to accomplish.”
The head of the PMO took up the challenge and, speaking as though I was rather slow, started explaining what their problem was. It wasn’t so much of a problem statement as a description of how project data flowed through their system and I stood up, took control of the white board and started drawing it out.
The software publisher people looked unhappy. They thought they were about to get a purchase order and instead we were doing flowchart diagrams on a white board.
I paused at each new tendril in the flow to make sure we got all of it on the board. Most of the room participated in some way to make sure we got it right and once they were involved, the process moved quite quickly. As often happens in these kinds of exercises, some people including the head of the PMO learned things about their own process they’d never known before.
It took almost an hour before we’d diagrammed everything we needed and the problem was apparent. There was a bottleneck that had been created years ago to make sure that the Finance department and the Project Department both got data but the way it was delivered was in a complex movement of data through systems that were only used to massage the data for each party.
This bottleneck occurred in the section of the white board we’d identified as part of the Finance Department.
“Who speaks for them here?” I asked.
There wasn’t someone from Finance in the room which interestingly was where the heart of the problem was occurring but the head of the PMO had some inertia now and picked up the phone. Five minutes later we had a senior Finance manager in the room.
“Do you recognize this part of this flow diagram?” I asked.
To their credit, they did and they knew more than anyone else in the room had known about this particular area.
“Is there some reason we couldn’t feed the source timesheet data for this to you in the way that you’re getting it now and simultaneously to the Project group in its original format?” I asked.
“None at all,” the Finance person said with confidence.
“Ok,” I said, “so, it looks like if we were only able to get all your sub-contractors to use the same timesheet system you have internally, then you could get everything you’re asking for instantly from the same source. That would be a fraction of the cost and effort of anything else we’ve discussed.”
Now the software publisher representatives were decidedly unhappy.
“That would be impossible,” said one of the project people. “We can’t impose that kind of requirement on our sub-contractors.”
“That’s not exactly true,” said the Finance invitee. “I work in contracts and I can assure you that we have a clause in every single sub-contractor agreement that says they will use our internal systems if we request it.”
The meeting came to a close quite quickly. We’d been speaking for almost 4 hours in a meeting that they thought would be software demonstration lasting 90 minutes. Not one person left early.
One of my software publisher hosts was decidedly unhappy but his more senior partner told him that he shouldn’t be. Selling a huge package of software that wouldn’t have solved the problem would have been ultimately the wrong move, he explained. I appreciated the support.
The happiest person in the room was the woman who’d tried to hand me the projector cable at the beginning of the meeting. She was able to isolate the true cause of her difficulties and discovered that she already had the tools for fixing it.
It was a day when I didn’t make any money but trying to make money in that situation would have cost me more in grief and upset than I’d have made in profit so I was satisfied.
Sometimes, going just a little slower can produce the best results.