My friend Adrian Balfour who runs PCubed has just done a great article that people like Adrian (and I) have to deal with on a regular basis. How do you convince management to make the investment in proper project management. His article “How to Sell Project Management to Senior Executives Who Don’t Want It” is a great read. Go take a look on the PCubed site.
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.
I had the opportunity to be interviewed on my career and my views of the project management industry recently. Samir Penkar runs the Future of Project Management site at futureofprojectmanagement.com You’ll find the interview on the site just look for A few Key Decisions to take a look.
It’s great to talk to others in the industry about trends and where things have been, where they are and where they’re headed in the coming years.
I was working with a large Canadian company recently, helping with their enterprise project management processes. As part of my work, I got to watch while a project control officer prepared a report for the Chief Financial Officer.
It was a work of art.
First data was grouped together from multiple projects in the desktop version of a popular project management system. That data was copied and then pasted into a massive Excel spreadsheet as core data for what would become this report.
Now, this person grouped the Excel data and sub-totalled it. Next, a series of macros that were clearly cleverer than I am, created an entirely new Excel workbook with the data now grouped and sub-totalled in a completely different way. The project staffer now reviewed several thousand lines by eye, looking for discrepancies. When they found them, they returned to the first Excel cut-and-paste file and deleted lines, added lines and changed values so that the resulting final spreadsheet would be grouped in the manner they requested. When data really didn’t seem to make sense, it was removed for ‘later analysis’. The über-macro was run several times until finally the results were to this person’s satisfaction and then a second tab in the newly created Excel sheet displayed the data with lovely coloured headings and columns.
I was visibly impressed. But not in a good way.
During a report I made much later, one of the comments I made to the senior PM management was, “This report has a 100% chance of errors each month yet even though everyone knows how it is being produced, it is being interacted with as though it is financial quality data at the same level of quality as your payroll or your financial statements. You are making critical business decisions with this report that you know is flawed.”
The company took steps to improve their reporting process and created checks and balances to make sure the decisions they made were done based on information that they had a higher level of confidence in but the whole experience made me think about a deeper lesson that we can all take home. I wondered if there wasn’t incentive in the organization for this person to become the ‘indispensable project manager’; the person who is absolutely essential because they’re the only ones who can create the organization’s critical project reports.
We all have methods and processes in our project management environments that we’ve created ourselves and that can really only be accomplished by ourselves. If in this company, the person in question had to take a leave of absence, no one else on the planet would have been able to generate the report they did. That’s a risk factor for the PMO and it makes me wonder how many more such risk factors do we all have in our organizations.
The top level of virtually every Project Management Maturity (PMM) Model is to have the process be self-sustaining and self-correcting. Different models use different terms but the idea is the same. The original Capability Maturity Model developed by Carnegie Mellon University used the term “Sustained” for their top level 5 definition. This level of maturity indicates that the project management process can sustain itself and adapt or improve as changes occur. This would include, of course, changes in personnel which is always a risk factor to a process.
If the process was sustainable, then the steps to create a report, a method to test the report for accuracy and a schedule of when and how the report would be created would all be present. Hopefully this would be part of a much more extensive project management process guide that would include not just how to create a report but also the methods by which the data was collected so that we’d know the source information had quality as well. We often make important business decisions based on project data and there is often an assumption that the data is accurate because of how nicely it’s displayed yet it’s common to find project environments where data does not have verification for accuracy and where this is a poorly documented process.
I’ve been a big fan of a phased approach to things for a very long time so it’s a bit of a problem to me to find that the top level of the PMM process is often the last one tackled. I far prefer making an element of the project management process stable and then bringing that element all the way to the sustained level. Document the process, train the staff, repeat the steps required over and over, produce value from this one step and etch a groove for this one part of the process deep enough that it becomes ingrained in the corporate culture. Then build on the same method on the next element.
There’s a plus and minus to my thinking of course. On the plus side, the project elements I work on this way typically last a very long time. On the minus side, organizations rarely get to all the elements they originally envisaged. There comes a point where sufficient value is being produced by the elements of the project process that have been successfully adopted thus far that the incentive for additional investment is reduced.
From my perspective working on organizational project management, the pluses far outweigh the minuses. The bonus from the phased approach is that the process has power rather than an individual personality. There is no hidden, secret knowledge. The whole objective of a publicly known process is that everyone knows how the process works from start to finish. It’s all documented and all on the table.
Virtually anyone can make this kind of difference in their own project organization; small or large. Start by giving knowledge away by documenting how you get things done. If you’re in charge of a PMO, you can encourage team members to share their best practices and make them available to others but you don’t need to be in charge of the PMO in order to do this. It may seem counterintuitive to share your best techniques but don’t worry. Expertise isn’t a depleteable resource. You can generate new expertise tomorrow. Giving your expertise away and working to create your successful project management element as a sustainable part of your organization will have you leave a legacy; some difference that can last long after you’re not longer in that role.
After all, aren’t project managers about having others be more effective? That’s a real indispensable project manager.
HMS has announced some changes to their free TimeControl timesheet Trial site that will make trying the TimeControl timesheet system that much easier. First of all, the dashboard on the main page has been updated to show some readily accessible online learning resources such as the TimeControl Online Learning Center. Also, data in the free trial has been updated to make the flow of trying the system once new users log in more intuitive.
The biggest news though is the new Evaluation Guide that guides a user through basic functionality of the hosted trial from the registration right through adding a timesheet, adding a vacation request using TimeRequest and doing some reports click-by-click. Now anyone who wants to see just how easy TimeControl is to use can be guided through those steps screen by screen. The Evaluation Guide was based on the hosted trial site itself and describes what the user should see at every step and where to click or type next in order to put TimeControl through its paces.
The TimeControl trial site has its data refreshed nightly but users who register for the system will have access to it for 2 weeks. There are no restrictions on functionality though users are cautioned not to upload any information that is confidential or sensitive as the data is open-access. There is no cost to users to access the Free TimeControl timesheet trial.
To see the new Free Hosted TimeControl Trial Evaluation Guide, click here.
To access the updated Free Hosted TimeControl Trial, click here.
To visit the TimeControl Buyer’s Guide where there are numerous resources for evaluating timesheets, click here.
Over at my firm, HMS, there’s a great case study on the use of TimeControl at EXFO. EXFO has been a TimeControl client since 1999 and recently they were gracious enough to allow us to interview them and do a case study on their use of TimeControl. EXFO wasn’t a publicly traded company when we first sold them TimeControl but they sure are now. The company has expanded enormously since our first visit there years ago. The case study is on our website and available in both French and English. Our thanks to Andre Richard who took time out of his busy schedule to do the interviews for us and to review the final copy. We invite you to read how EXFO has been able to enjoy some of TimeControl’s key benefits and see how the timesheet links to multiple systems for multiple purposes within the EXFO environment.
To see the EXFO case study in English, click here.
To see the EXFO case study in French, click here.
It’s a common question that I’ve had to ask of many project management office managers. Because of my background in enterprise project management systems, this mostly happens in response to some request to review a problem with a project management system implementation. Over the years I’ve been called upon to try to fix, repair, re-establish or just replace a failed or problematic project management system and my approach is always the same:
1. Tell me what’s going on?
It’s a good start and it gets the problems and the client’s frustrations up on the table right away. The story typically comes out in a jumble. (Think Pulp Fiction where the story starts in the middle and then jumps to the beginning, back to the middle, to the end and then finishes back somewhere in the middle.)
2. Distinguish the parts
I’m never presented with a single problem. Inevitably before the problem has been fully described, it’s more than one problem and it’s critical to distinguish out each of the moving parts. I’ve had lots of experience debugging system’s problems and anyone who has ever been in that role will tell you that it’s important to try to isolate the problems and then isolate the causes.
3. “So, what are you trying to accomplish here?”
Now that I have a fuller understanding of what is upsetting the client, it’s essential to know what they want to accomplish and therein lies the expectations of the client.
4. Design the solution(s)
The solution is often not obvious and determining the expectations often changes where to look for satisfaction.
Let’s take a look at each of these 4 steps in a bit more detail:
What’s going on?
When people describe a project management problem from a systems perspective the most typical description sounds like this: “It’s just broken”, “It just doesn’t work”, “It’s got a bug” or “The data is corrupt”. None of these of course are helpful. So we start by asking for specifics. “What did you see that makes it look like it’s broken?” , “Can you re-create the steps that make it look like it’s broken again?” , “Can you show me a report or a screen-shot that made you think it was broken?”
This sometimes slows the process down. Remember that the ‘What’s going on?’ process often arrives in a jumble and we may be looking at multiple problems. When the client can finally show me the report, field, screen or result that they believe to be a problem, the next obvious step is to ask, “What do you believe the result should be?” During this part of the analysis I’m often fascinated as how people produce results. I’ve seen people take information from a project management system, extract it to Access or Excel, manipulate it with macros, formulas and then extract it again, merge it with data from other systems and then point me to the end result and say “See? It’s wrong!”
Think that’s unusual? It’s not. Excel remains the most popular project management tool by far and project managers often have more experience in it than in whatever project scheduling too they’re using.
Distinguish the parts
When we get the offending result identified and I can determine that it is, in fact, not the result the client was expecting, it’s key to ask “What other results are not appearing as you expect?” Often there is one part of the data or the process that is the most problematic for today but there are other results that are only a minor irritant yet may have bear a significant impact on the problem. For example, I had a client who was unhappy with the resource levelling results of a project management tool. “Is there annnnyyyyyttttthhhiinnnnngggggg else?” I asked. Well, there was. There had been a minor irritation with how individual resource calendars were updated when vacations were taken. That opened up the door to how resource availability was defined and before you know it, we’ve got a fundamental break in the resource definition process as the main culprit. We standardized that process and how an individual resource’s availability was defined and presto – the scheduling results were all perfect.
So, what are we trying to accomplish here?
The answers to this question often amaze me and you’d think I couldn’t be so surprised after almost 30 years in the industry. The most likely easy answer is “We just want enterprise project management”. Of course I then have to ask what they mean by that. On many occasions lately what I hear is “We just really needed a timesheet”. The client has purchased an entire resource management, schedule management, portfolio management analysis system and then finds that the timesheet aspect of what they purchased just doesn’t give the results they were expecting.
It’s also common to find that the education of working on an enterprise project management system deployment has changed the perspective of what they really need. Perhaps they were enthralled by the sales demonstration before they got started. Perhaps they didn’t really understand what questions they should be asking. Perhaps more knowledgeable people were hired only after the deployment started. Either way, the notion of what’s now required evolves and by the time the client calls me to help get their project management environment back on track, the expectations of the original system are quite different from what they were before we started.
It’s also very common for the client to have gotten so caught up in the minutiae of system issues that they’ve lost track of what the original goals were.
This often brings us to a challenging aspect of the repair project. What if the new goals of the enterprise project management environment would be better served by not continuing to deploy the system they’ve already got a lot of investment in? We’ve had a couple of cases where the client was trying to deploy an entire enterprise project management system but in the end just wanted a timesheet. Do we keep banging the square peg in the round hole? Or, can we put that enterprise system aside for now and just deploy a more appropriate timesheet? Now, that’s a situation of going from a more complex system to one that’s less complex but I’ve seen the reverse as well. Someone takes a simple internal timesheet system and then tries to modify it with every enterprise project management feature they’ve envisaged. At some point it makes sense to pause that work and rethink the whole tool selection.
Build the solution(s)
I’ve been talking a lot about tools but often a solution can be found in the process. It’s common to find that some process that evolved over time or that is engrained in the corporate culture is the root cause of data analysis that makes no sense. Once we know what the client needs are, we can go back to the source and start with a solid process for collecting and analyzing the data. What the client originally thought of as a tool “bug” or “corrupt data” is often resolved with a change in how data is collected, in how it’s interpreted, with training or just by saying “don’t do that anymore” (I can’t tell you how many times I’ve had to say that).
It’s also possible that we can produce a result in a manner that the client hadn’t thought of. Once we know what the client is trying to accomplish, there are often a number of ways to get there that the client simply hadn’t thought of. From time to time, for example, I’ve had to say, “Why bother automating that? We can do it manually in 10 minutes per month with a lot less stress.”
If you take a methodical approach to solving issues that are a challenge to your enterprise project management environment, you’ll find that most of them are solveable very quickly. When it turns out to be expanding into a more and more complex problem it’s often good to take a big step back and look from a higher perspective. Figure out what you’re trying to accomplish, what benefit that will bring you and then how you’ve been trying to get there. When you break the problem down to its component parts and you can see clearly where you need to get to, building a path there is easier.
As part of our new R&D Solution Portal, we’ve created a brand new white paper that you may find of use. The extensive paper covers an overview of how R&D tax claims work. We cover something we call the “Triangle Audit” which describes how most government tax agencies go about doing an audit of Research and Development tax claims. There is a section on how TimeControl timesheets work in an R&D setting and even instructions on how you can configure your own TimeControl to comply with auditing requirements. There are screen shots of individual TimeControl tables and example reports. The paper covers an overview of R&D claims in the regions we know best which includes: The US, Canada and within Canada, the province of Quebec where HMS Software’s headquarters are located. HMS has extensive experience with doing our own R&D claims.
For those who want to do more research, there are links to appropriate areas of websites at the Internal Revenue Service (IRS) in the US, Revenue Canada (for the SRED program), Revenue Quebec, HMRC in the UK and in the EU.
You can download the R&D white paper for free at HMS Software’s Research and Development Tax Credit Solution Center.