Wednesday, 28 March 2012 10:21

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

Written by 
Rate this item
(0 votes)

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

Read 2763 times Last modified on Monday, 16 April 2012 11:19

Comments  

 
0 # Bob 2012-03-28 06:20
Great post Chris, and kudos for taking the path you did. Thanks for sharing.
Reply | Reply with quote | Quote
 
 
0 # Gary Bellamy 2012-03-28 09:07
Chris, The epiphany you experienced with your clients during that lunch is a perfect example of the very first task in the Enterprise Analysis knowledge area of the Business Analysis Body of Knowledge (BABOK), as defined by the International Institute for Business Analysis (IIBA). Defining the business need means identifying why a change to organizational systems or capabilities is required and a key technique used in this task is root cause analysis. Your story illustrates why someone playing the business analysis role should be involved in decision making before a project is launched. Too often, we BAs are only involved once the decision to start a project has already been made, even if the objective of the project is to implement a solution to the wrong problem or a problem that doesn't justify the project investment.
Reply | Reply with quote | Quote
 
 
0 # Chris Vandersluis 2012-03-29 07:17
Bob and Gary, Thanks so much for your kind comments. It's great to see the article resonated with you. Chris
Reply | Reply with quote | Quote
 
 
0 # Suvojit De 2012-04-02 05:05
Thanks for the great post, Chris. Someone very knowledgeable told me very early on in my career, that sound business decisions and good project management are almost always based on Common Sense. This post could not be a better reflection of that.
Reply | Reply with quote | Quote
 
 
0 # Ravi Madhavan 2012-04-03 02:46
The article is bang on. The case study drives home the point on the needs to define the problem statement clearly and then embark on a charter for the same. That is the explicit point to be derived from the story, but I am actually inclined to point out an implicit point as well which points towards the value add for the customers. What I am trying to say may be a bit outside the original context of the discussions. B y solving a problem for the customer without actually coding or developing anything augurs well for a customer relationship and trust building exercise which is beneficial in the longer run. We can also take this story
Reply | Reply with quote | Quote
 

Add comment