We spend a lot of energy in project management circles trying to determine how to do a thing. In my travels to various parts of the planet something that’s sadly lacking in many places is good judgement on whether we should do that thing.
I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. Yet, I was less happy when I heard the reason why the customer felt that their existing system was no longer able to meet their requirements.
“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. Because they need 3 rate values and our existing timesheet can send only two we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you that with your TimeControl?”
TimeControl was certainly capable of sending multiple rate values, I assured the specialist but I was at a loss to understand why they needed such an interface in the first place. In the end, after some discussion, the client agreed to pay for a day of system design and I scheduled some time in the offices.
Our meeting together started off just great. They had the CIO in the room and I was suitably impressed that the head of the IT department was sufficiently interested in the problem to attend himself. He and the technology specialist took turns white boarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic white board marker colors all over the board.
I took copious notes.
By the break though I had my first intelligent question. “What was the volume of transactions,” I asked, “that was being handled through this manual process?”
No one knew the answer.
“Can we ask the CFO?” I asked.
A quick call was made. Yes, the CFO was keen to talk to me but could only do so over lunch. I was delighted. Senior management intervention at such a rapid pace isn’t that common and indicated to me that management was committed to get this problem handled. Things were looking good.
We worked for another hour on the white board diagram. I headed to lunch with the CFO, the CIO, and the technology specialist that had called me originally with a good understanding of what they wanted and the kind of time it was going to take to create. The CIO and I agreed that changing the timesheet was fundamental to the new solution and that 6-8 weeks of developer time to automate this “archaic manual transfer process” sounded quite reasonable. I was upbeat. Sounded like some business on the way.
Yet, there was something niggling at the back of my mind. The whole premise of the problem came back to a lack of a single field in the old system and its inability to move that column of data to the Finance system. I’d already determined that this data was critical to the corporate effort “Why not just give up on that extra data,” I’d asked. “What would happen if you just didn’t transfer the data?” The CIO had told me he’d already considered just that and that management had made a good case for this data being essential to their ability to bill accurately.
Time for lunch. We went across the street for chicken. (Business lunches always seem to be feather, leather or fish!)
I sat across from the CIO with the CFO to my left. The technology specialist was across from him. We exchanged pleasantries and then ordered and while we waited for our meal, I turned to business.
“I’m here to work on this timesheet system to finance system interface,” I explained. “The CIO here and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”
The CFO to his credit describes exactly what we’d been talking about all morning. This was a good sign. Often when you go back to the client or end user of a system, the understanding of the requested change isn’t at all what IT understands.
“Now could you describe how you handle the interface now,” I ask.
“It’s an archaic manual intervention,” he describes. Again, sounds just like what I’d heard this morning.
“And how many transactions are managed through this archaic manual intervention?” I ask.
“Oh about 5 a month,” he says.
There’s silence at the table.
“Five,” I repeat. I see the CIO’s jaw drop out of the corner of my eye.
“Yes,” says the CFO.
“And how long does it take to do these transactions manually each month?” I ask.
“Oh, it takes one of my staff about 20 minutes,” he says.
“Excellent,” I say, my heart sinking as I changed the subject.
The CIO couldn’t meet my eyes. We finished our meal and headed back to the office as we did so, he walked next to me. “I’m so sorry for wasting your time,” he apologized.
“No need to apologize,” I said. “I’m just happy we figured this out before spending 8 weeks on writing the interface.”
The time to recoup a return on investment from the effort we’d described would have been many years. At 20 minutes a month there was no point in doing the work. In fact, the company had already spent way too much time working on how to do it already.
Could we do the work? Sure. But we shouldn’t.
And sometimes that is the most effective project of all.
