Webinar: Panning for Gold by Data-mining your project tracking data

We’ve just published a new free webinar based on seminars that have been given many times in different venues around North America. Panning for Gold by Data Mining your Project Tracking data is approximately 60 minutes long and covers how to data mine enteprise project and enterprise timesheet data to improve efficiency. The webinar includes real life examples from some of our HMS Software clients in how they were able to data mine their project timesheet data.

Creeping Scope

No, I’m not talking about the new vine on your deck trellis. I’m talking about scope creep. It’s every project manager’s nightmare. The project starts off at a manageable modest size and in the blink of an eye, it’s a beheamouth of unmanageable porportions.

In one of HMS Software’s first ever mandates back when we were just getting started, we had a client who asked us to configure their project management system with multiple baselines. This was unheard of in project management software of the day so we had to do some modifications to accommodate the request.

“Why would you need more than one baseline?” we asked naively.

“Ah, you don’t know the ways of the project management world,” our client informed us. “There is the original-original baseline. That’s the one we make when we first create the project. Then there is the official engineering baseline. That one includes any changes we’ve made to the original-original baseline over the term of the project that the head office has approved. Then there’s the internal engineering baseline. That’s the baseline that engineering is actually working against because they know the official engineering baseline is a fantasy. Then there’s the expected baseline. That’s the baseline that will become the new official baseline when we can propose it to head office and get it accepted. That’s the baseline that the engineers project will actually happen.

Depending on who asks, we need baseline-vs-actual reports for any of those four baselines.”

We were stunned. But we did what the client wanted. While we worked on the deployment of the project system, there was a particular project that came up for head-office review. It was a technology project that had been originally authorized 4 or 5 years previously. The original-original baseline had been $4,000. The actual was close to $4,000,000 (No, that’s not a typo. The original budget was four thousand dollars. The actual spent was close to four million dollars.

The project was cancelled.

Over the years we’ve encountered many companies with similar methods which attempt to control scope creep. Here are a few thoughts on how to keep yourself out of the creepier side of scope.

How did we get into this mess?

People almost always get into these problems with the best of intentions. In my own office, when this occurs it is usually because we are too responsive for our own good. We’re trying to satisfy the client before determining if just answering today’s request with changing something is healthy for either of us. Here are some of the most common ways people get scope changes creeping into their project:

Insufficient Scope

It’s obvious to say but some people just don’t look at everything involved when they scope the project. Did you think about training? Did you think about the links to other systems? Did you think about fixing inevitable problems after delivery? Did you think about risk? Did you think about all the existing systems that are affected? Did you think about the functionality in the system you are replacing that you don’t use but that someone else might need?

Taking your time to make sure you allow for all of the permutations of what you’d like to create is key. Working with your vendor to see what else they can see from their perspective is key also.

Not including all the relevant parties
It’s a classic project management error that can cause significant scope creep. A team starts working on the scope for a project but makes a wide range of assumptions for others who are not present and who are not consulted. Only as the project nears completion do those people get involved and suddenly they have a lot to say.

Not walking the business flow from beginning to end
Short-sightedness in creating scope is also a common issue. The project team identifies a function they desire but they don’t walk through all the implications of that function. As a vendor, we often have to do that type of walk-through and it is common to unconceal a plethora of issues that no one thought about. In some cases we find that the request actually contradicts other functions that were requested. In other cases we find the request doesn’t deliver the result intended because of what happens later in the workflow.

Not associating changing functionality to a business requirement
I’ve written about this before but it is a common challenge. Project team members make a series of requests but don’t pause for each one to determine how that request will affect the business. We’ve taken the position with many mandates that each request in the scope must relate to some business purpose else why would we do it at all?

Thinking more of “how” rather than “if”
This takes some culture change in many companies. I consistently ask our staff to justify a requested change from themselves or the client not just with how to do it but whether we should do it at all. For many years I would be faced with a request and the answer, “Because the client wants it” as the answer to, “Why should we do that?” Now my staff challenge clients themselves to ask what the purpose of the request is, to point out how that request might affect other elements of the project and determine if it should be done at all.

Being determined to do it all immediately
Some organizations have a challenge going through a project approval process and, as a result, they try their best to go to the money well a single time rather than making a phased approach. Our experience shows this often to be a mistake. Once a system is in use, new requests for changes from the client are almost guaranteed.

There are no doubt a hundred other causes of scope creep but you’re probably asking yourself if there is light at the end of the tunnel. Is scope creep inevitable?

It doesn’t have to be.

How do we avoid getting into trouble?

Here are a few ways that organizations can avoid or mitigate scope creep.

Start with a commitment to avoid scope changes
Sound obvious? It’s sadly not. Many organizations avoid talking about scope creep at all given how little it’s liked. As a result, those organizations have few tools and techniques in place to avoid the issue.

If you articulate your determination as an organization there are a few things you can put in place that have an almost immediate effect:

Include those affected
If you make a conscious effort to include those who may be affected by the project, you have a better chance of hearing what they need and managing both their objections and expectations long in advance. This can have a dramatic effect on how many changes get requested later.

Review scope before approval
A formal review of the statement of work by all those parties we just talked about is a good place to start to find any holes you didn’t expect when you wrote it in the first place. The review process must have a method for everyone to comment and for those comments to all be resolved before moving forward.

Make an allowance for what you don’t know
Making a contingency budget will allow you to deal with small scope changes without having to go back to a re-scoping exercise. How much contingency you set aside is highly dependent on the amount of uncertainty or risk that you’re confronting in your project.

Monitor scope changes
If you can’t measure something, you can’t manage it. So, set up baselines or other measurement mechanisms to determine if changes are occurring. Those baseline measures will allow you to determine the size of any proposed changes too. Whenever you do a change in your official scope, don’t erase the original, just make sure you reset a new baseline so you can start measuring against that.

Monitor and set reporting thresholds
Along with monitoring goes making a determination that it’s time to pause and relook at your scope. In our projects, we always know there is a small amount of contingency available and we set our own thresholds to take that contingency into account. It’s important to set the rules for what your thresholds are before the project starts so everyone is aware of how much scope change it’ll take to make the project pause and regroup.

Make sure change requests serve a business purpose
I’ve talked about this before from numerous perspectives. Often requests for changes will arrive in a project for purposes that are not associated to business value. Or, the changes may conflict with other functionality that is associated to business value.

Many requests are often about familiarity and comfort
One of the most common types of change requests usually has something to do with familiarity or comfort. The client looks at what has been delivered and says “That doesn’t look like what I’m used to.” This can be frustrating when the entire point of the project was to do something new. This typically means that whatever the legacy system or building or mechanism was is known to the client and what you are now showing is unfamiliar. You need to be able to categorize change requests and their value or purpose so the client can make an informed decision about what they are asking for.

Think in a more Agile fashion

Finally, it’s popular to talk about Agile in software circles these days but I’m really referring here to the Agile concept rather than its entire methodology. Agile at its core means doing things in phases. Whether you call your phase a “sprint” or a “wave” or a “phase” or our “next bit” is less important than the concept of working in small incremental parts. We have had our best success when we deploy not the most we can create but the least with full knowledge of both ourselves and the client that we won’t be done. The sooner the client is using the software in real-life, the quicker we are to get feedback that’s relevant to how they function. Our past experience indicates that no matter how much time we spend scoping the requirements, once the system goes live, we’ll get new requests for changes.

If change in scope is inevitable, the best way to avoid unexpected scope creep might be to plan for it from the very beginning.

Multi-Currency Project Management

Great news. You will be managing a large project that transcends international boundaries, multiple time zones and multiple sub-contractors. As a result you’re having to think about how to deal with multiple currencies. multi-currency This can be a project accounting nightmare if it is not thought out in advance.

Mulitple currencies can be a blind spot for project managers who have only worked in one country with one type of money and never had to deal with international contractors or clients. But the world is a lot smaller than it used to be and outsourcing outside your own country or finding a client in another country can bring in complex financial questions that have the potential to generate risk that you might not have given sufficient thought to. Let’s take a look at a few concepts you’ll need to think about:

Multi-Currency Challenges

Pick a base currency
This might not be as obvious as you think though it’s often a common starting point. “Just make everyone work in US dollars,” someone might say (even if they are not in the US. The key to picking a currency for your project accounting isn’t just what’s familiar. In what currency will most of the transactions occur? How stable is the currency you’re selecting? What risk are you absorbing by selecting the currency you favor?

How to determine conversion rates
Ever gone on vacation, convered your own money into the local currency and then converted it back when you left? Didn’t come out the same did it? There is always a gap between the selling price and the buying price. Moreover, you are very unlikely to get the same rate as the banks get. What should be a reasonable exchange rate for purchases? What should be the rate for sales? Will you have to bring money in from one currency then exchange it and then exchange it again sending it back? Sound confusing? Imagine you have a foreign client. They give you an amount of money in advance for services. You hire some workers in that country to do the work. You will sell the foreign currency to get it into your bank and lose some percentage on bringing it in. Then you’ll need to go buy that currency later to pay your workers and again lose some percentage sending the money out.

When do we convert the currency?
Imagine the foreign client sends you $100,000 worth of their currency as a deposit on your project. But, by the time you convert the money into your base currency, the exchange rates have changed and now it’s only worth $95,000 or, by the time the expenses arrive that this money was allocated for, their invoices add up to $105,000 when converted to your base currency.
You could convert when the foreign currency arrives.
You could convert it when you think the rates are favorable
You could convert when you use it for expenses

Which is the right answer? All of the above.

Have the Client or Subcontractor absorb the currency risk
You’ve avoided all these challenges by getting the client to agree that they pay you in your base currency and you’ve insisted to your subcontractors that you only ever be invoiced in your base currency. Problem solved, right? Sorry, no.

Now you’ve displaced the risk from you to your client for money you expected. The client lives in their own currency. There now exists the possibility that when the final invoice comes due, the client says they can’t afford it because the exchange is too great. Same problem can occur with the sub-contractors. In mid-project the subcontractor informs you they can no longer continue because their profits eroded due to currency fluctuations that they are absorbing all of the risk of and you are now stuck with a project half-done.

Solving the Multi-Currency Challenge

So, is the lesson here not to take on any contracts with either foreign clients or foreing sub-contractors? No, of course not. At my own firm, HMS we do almost 80% of our business outside of our headquarters and multi-currency management is a fact of life. Here are a few lessons we’ve learned over the years about managing the challenge of multi-currency project management

Pick a base currency
While our headquarters is based in Canada, we often use US Dollars everywhere else as a base currency. It is widely accepted in many countries as a currency where the fluctuations are known and dealt with in every day life. We also however, set some rates in Euroes and some in British Pound Sterling.

Identify costs in each base rate
While you might use a base currency for your accounting. Keep track of the invoices or receipts you’ve had in the currency they started in. That will always allow you to apply the conversion rules you’ve decided on to the original source amounts.

Pick a base rate
Start with a base exchange rate and speak about that rate with your clients and contractors. If the projects are very short term (as almost all of HMS’s are), the fluctuating exchange is rarely an issue. For longer term projects, articulate the multi-currency challenge with the parties involved.

Articulate this challenge into your contracts
Don’t forget to get your manage currency plan into your contract with your client and sub-contractors along with mitigation clauses for what happens if the currency fluctuates outside an acceptable threshold.

Monitor and set thresholds
Make sure you are monitoring the fluctuating rates and set thresholds before you start so you can raise a flag for you to re-assess and for you to renegotiate if requried with your clients and contractors.

I expect that managing multiple currencies within project accounting will become more and more common in the years as the world becomes an ever smaller place and communications makes it easier and easier to seek clients and contractors in other countries.

If you’d like to see how TimeControl handles multi-currency challenges, take a look at the blog post on blog.timecontrol.com at: blog.timecontrol.com/?p=162.

Do we still need training if we’re using SaaS?

At one time using a computer system required training. Not everyone will remember what older mainframe/terminal systems were like but user-hostile doesn’t completely convey the response.

Here’s an example of how to add a frequent flyer number to your itinerary, from the old character-based Sabre airline booking system from American Airlines (and others):

Using the abbreviated entry, add the FQTV (code for a frequent flyer number) number NW 759964796 to the PNR for the second name field:

Enter: 3SSRFQTVNWHK/NW759964796-2.1

Imagine having to learn hundreds or even thousands of these kinds of commands. Check-in agents would always keep a “cheat-sheet” card on their person for those hard to remember commands.

This type of interface was also true for early project management software systems such as the venerable Artemis. These kinds of long command lines would have to be entered to create a new project, new resource or new tasks. It’s no wonder that training was so critical to successful deployments of project systems.

The result of this kind of non-intuitive interface was that no deployment of project management software would be done without training. It was typical to allocate 20% or 25% of a deployment’s budget towards training.

But then the world changed.

As interfaces became more graphical, point-and-click interfaces meant that no one had to memorize long complex strings of commands to be typed in. So, not as much training would be required. Interestingly, at the same time, the cost of systems decreased. Where a deployment in 1980 of a project management tool would have easily been $250,000. The same deployment in 1990 was $50,000. By the year 2000, deploying the same functionality was closer to $5,000.

Where a training budget had once been $50-60,000, now, the same allocation of percentage of budget would be closer to $1,000. And, while it’s true that using complex software is much more intuitive than it ever was, it’s an interesting thing about training – a lot more knowledge transfer happens while you’re doing training than you’d ever get by just figuring out the functionality with online assistance. Basic underlying concepts and principles that the software publisher and long time users would understand just don’t always translate into instant function-based help.

At our firm we’ve noticed this gradual decrease in a commitment to training for our own TimeControl enterprise timesheet software over the years and in the last couple years the challenge that HMS and many other software publishers face in this training area has been compounded by a series of changes in the business world.

There is a movement in project management and in organizations generally to be less co-located. The improved ability of people to work remotely regardless of their geographic location has made using remote workers much more popular.
There is a movement in software development to focus on mobile interfaces and to have those be even more intuitive. SmartPhone popularity has driven all software developers to make software interfaces so obvious that they requires no training at all.
There is a movement in software development to focus much more on Software as a Service. The installation, configuration, management and integration of such tools is now delivered virtually instantly and the costs of such systems as a subscription are considered an operational rather than a capital expense, making investments like training seem even more unusual.

The result? Less and less training. There is some mitigation for this in the proliferation of more online training, more YouTube video training, and more free materials for self-training but when dealing with enterprise systems like an enterprise timesheet or an enterprise project management system, there seems to be no substitute for having someone who really knows the system teaching the underlying principles in how it works.

We’ve seen in recent years more and more of our clients returning to us with what appears at first glance to be a technical support request but eventually turns out to be insufficient training which, once delivered, makes for much happier clients.

It turns out there’s still room for the human touch in enterprise systems after all.

Archive: April 28, 2016