Not How Do You Do It… Should You Do It?

We spend a lot of energy in project management circles trying to determine how to do one thing or another. 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. However, I was less happy when I heard the reason why the customer felt 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 three 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 do 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 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 whiteboarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic whiteboard 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 it indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the whiteboard diagram. I headed to lunch with the CFO, the CIO, and the technology specialist who had called me originally with a good understanding of what they wanted and the kind of time it was going to take. 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.

However, 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 that and 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 and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

To his credit, the CFO described 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 currently handle the interface?” I asked.

“It’s an archaic manual intervention,” he described. Again, it sounded just like what I’d heard this morning.

“And how many transactions are managed through this archaic manual intervention?” I asked.

“Oh, about five a month,” he responded.

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 eight 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.

Don’t forget to leave your comments below.

---

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute.