Yes, I Yelled at You—and I'm #sorrynotsorry

I wrote a while ago about being less of a jerk. And I think I’ve been making progress (although you’d have to ask my team). But this week, I lost it. I raised my voice. I yelled at the project lead of a consulting team I was working with.

It was only for a moment. It felt good. And it got the results I wanted. But that’s not how I like to operate.

But why then why am I #sorrynotsorry? To help you understand, here’s my (admittedly biased) take on the situation:

  • For several weeks, I’ve been pushing the PM’s team to get certain things to the client. It wasn’t going well. And this week, the team promised something and failed to deliver it. But that wasn’t the reason I yelled.
  • When I spoke to the PM, he used weasel words to try and explain his way out of it, instead of taking responsibility. As in “the consultant didn’t understand what was supposed to happen.” What I was waiting to hear was, “My team wasn’t communicating well. We’re sorry, and we’ll fix it.” But that’s not why I yelled.
  • At the end of the call, the PM said he could tell I was getting emotional. He could hear it in my voice. THAT’s when I yelled. (I wasn’t alone in this. The client was also livid with the PM’s performance.)

I can understand if you mess up in a BI project. And I can understand using weasel words to try and explain it (even though I don’t like it). I know I have a highly (some would say overly) developed sense of responsibility—that’s why I run my own business.

But if you’re not delivering week after week, and then you feel the need to point out that I’m sounding emotional about it, that’s not going to help.

Indeed, I had previously spoken to the PM’s boss about how the PM would describe things as tense when he was asked tough questions. He was told this wasn’t helpful. But obviously the message didn’t get through.

I will say that the anger here wasn’t just caused by the PM’s lack of tact. It comes from a feeling of responsibility. I had recommended the PM’s firm to the client because a long time business friend of mine was the sales rep. She’s a stand up person, and I could count on her to make things right in such situations. But she left. And while the client ultimately made the decision to hire the firm (and I was only a marginally involved in the selection process), I still feel responsible. I hate recommending anything that doesn’t turn out to be top notch.

In the future, I should have been more direct—both about the way the PM spoke in meetings and the fact he wasn’t meeting my expectations. Because then my repressed annoyance wouldn’t have come out in anger. But I’ll never lower my standard and accept anything less than top notch work.

What makes you yell? Or do you just keep calm and carry on?

 

What Does “Mid-Market” Mean for Our BI Projects?

The term “mid-market” is rather vague. We know GM isn’t mid-market. And we know the local corner pizza store isn’t either. But everything in between is a bit muddy.

At Red Three, we work primarily with mid-market companies. But what do we mean by that? While we often set a revenue range of between 50 and 500 million, other parameters provide a better indication of whether we’re a good fit for your company.

We’re a Good Fit for Your BI Project When…

1. You have multiple systems

We excel at working with back office data sets—even if multiple systems are involved. That’s what really sets us apart from competitors.

If your organization is entirely focused on one system, such as Dynamics GP, Lawson or Oracle EBS, you’ll do better choosing a consultant that focuses entirely on that system.

2. You have complex business or accounting requirements

If you’re an international organization, or have royalty, proforma or other complex accounting issues, then we’re probably a good fit. We shine most when we bring our knowledge of complex accounting to your complicated challenges.

We’re Too Small for You When…

1. You have huge databases

We’re used to dealing with data sets that range from around 200,000 to 30 million records. This covers a large swath of mid-range ERP, financial and payroll data. For example, we’ve handled:

  • Payroll reporting for up to 10,000 employees
  • Financial reporting for companies with 5,000,000 GL transactions per year
  • Supply chain interfaces with up to 10,000 transactions per day.

But if you’re tracking millions of transactions a day or week, we’re probably not the folks for you.

2. You have more than 50 users on one project

We work best when user communities number in the range of two to 50. This means we can handle most mid-sized projects as well as departmental projects for larger organizations. (We’ve even run projects internationally.)

But, if you need a consultant that can deal with hundreds of users across dozens of offices, we’re not the one for you.

We’re Too Big for You When…

1. You don’t have a test system

Test systems are critical to our process. Sorry, but we won’t touch your production system without running our changes in a test system first.

2. You’re happy with Access and Excel

There’s nothing wrong with Access and Excel if they’re working well for you. But that’s not an area where we can prove our worth.

Still wondering if we might be a good fit? Contact us to find out.

 

On Fixed Price and Not-to-Exceed Estimates for BI Projects

Many of my client engagements start with a fixed price or not-to-exceed estimate. And often, as people come to trust us, we’ll work within a specified monthly budget without estimating each individual project or request.

That said, I’ve learned from experience that a few rules must be in place for fixed pricing and not-to-exceed estimates to work. (And, in fact, most of these rules apply whether you’re hiring an outside consultant or trying to get an in house project completed.)

1. Don’t Ask for Estimates for Every Little Thing

Estimation isn’t an art or science. It’s simply an exercise in statistics. As I’ve posted previously, an average report takes around two days to write. At the same time, any given report can take between one and five days. The more reports (or interfaces, or spreadsheets) included in one project, the more “reversion to the mean” will apply and the better the estimate will be. This is one major reason we don’t like estimating initial projects of less than $10 to $20K.

There’s a corollary to this: Once you have an estimate, don’t start asking about individual items within that estimate. Yes, you can look at tasks completed as a percentage of total tasks. You can also look at amount spent as a percentage of total budget. But breaking things down task by task doesn’t accomplish much.

2. Have a Solid Testing Environment

If you don’t have a test environment with up-to-date data, it’s almost impossible to get any kind of ERP or BI project done.

I’ve heard all kinds of excuses: We’ve grown. We’re waiting for new hardware. We have data security issues.

I get it. But if I don’t have access to real data, my team can’t possibly test adequately. As a result, we’ll waste your time when our work doesn’t make sense, and you’ll waste our time when we have to do it over again.

3. Give Your Users Time to Test and Approve

Sticking to a reasonable budget means we need to be efficient. So we want to do every task the minimum number of times. As work gets completed, it needs to be tested and approved in a timely manner. If we deliver a piece of work and it sits for two months, neither of us will have any idea what we talked about when we get back to it.

This point is so important that I’ve been thinking about ways I can put timelines into our statement of work. But ultimately, I’m not sure I’ll go that route. I hate complicating my SOWs, especially when things work just fine most of the time.

You’ll notice I haven’t included “requirements and specifications” in this list. In the world we work in, we generally find that what people say they want in a document and what they want in their software are NOT the exact same thing. But if we follow the other rules, we can adjust on the fly.

 

Why You Should Pay for Training and Conferences

A couple of my clients use Dynamics GP. So, I monitor related forums for tips and tricks. Recently, a user (a GP All Star and legend in the making) asked how he could convince his CFO (who was all about hard dollars) to send their accounting folks to the GPUG Summit.

The issue is important enough to merit another blog post. (In December, I touched on the topic of user training in my post, What to Get Your Finance Team for the Holidays.)

User Training = Higher Satisfaction

But before I get into monetary justifications for user training, let me provide you with anecdotal evidence. Generally, I’ve found that clients that send users for training (whether user group gatherings or other types of training) are far happier with their software than clients that don’t.

It’s not just a matter of getting answers to user questions. Rather, it about getting answers to questions users didn’t even know they had (e.g. how to track benefits more easily, which third party software rarely works, cool ways to use Excel with your ERP, etc.).

How to Quantify the Value of Training

But clearly, this GP All Star will need more than anecdotal evidence to convince his CEO. So here are few quantifiable rationales:

1. Save short-term hard dollars by cutting support costs.

If your firm spends a lot of time on the phone with third party consultants, you may be able to justify conference attendance with a reduction in expenses elsewhere. Perhaps a lower consultant invoice will offset the costs of the training.

But still, conferences don’t come cheap. You have to include not only registration but also travel and time out of the office. The $1,000 three-day conference registration fee can easily run to $3,000 when you take everything into consideration.

Of course, consultants aren’t cheap either. And it may help your case to identify areas where you can say, “We shouldn’t need outside support for these basic questions.”

2. Save longer-term hard dollars by solving a business problem.

With this rationale, you’re using conference attendance to accomplish a business goal, not cut outside costs. The goal could be something like implementing a faster close or finding a better way to present data.

The advantage of this rationale is that the payoff for solving a business problem is potentially much larger than the payoff for cutting support costs. For example, if you can shorten your close from two weeks to one, the positive implications can reach across an entire organization.

The caveat is that management has to buy into the business goal. They have to feel the pain of the problem. Many executives won’t pay for conference attendance/training when they think everything’s working just fine.

3. Put the cost of conference attendance in context.

ERP software is hugely expensive. A mid-size client can easily spend hundreds of thousands of dollars on software, consulting and support. Does it make sense to spend all that money and then leave your own people to just “figure it out”?

I’d love to see some real data on training and conference attendance. It’d be great to compare companies that invest in training vs. those who don’t, and whether certain types of conferences are better value than others.

If you’ve seen any good articles on these topics, let me know.

 

The Importance of Being Rational

Balance sheets and sub-ledgers get out of whack sometimes. And although I’ve written about how to keep your ERP system on track, alas and alack, not everyone in the world reads my blog.

And besides, sometimes the ERP system was coming off the rails well before you arrived on the scene. So what to do?

Certainly, this has happened to me multiple times in my career. Twenty years ago, I spent a whole day proving to a client’s controller that their GL problem started well before my AP system came into play. (We’re talking only $2M on a $10M number, but who’s counting.) When I finally proved my point, the controller shrugged, “Yeah, we’ve had a problem for a while, but I thought you might find something.” ARGH!

How Will You Know When a Number Makes Sense?

Even today, with pivot tables and million row Excel sheets, people still follow my 20-year old example and dive into the numbers to look for the proverbial needle in the haystack. And you may get lucky. But more often, you’ll waste a lot of time.

So today, I follow this basic rule: Before diving into a detailed analysis of where something has gone wrong, I ask myself how I can find an approximate number that will keep me in the ballpark and narrow my search.

A Case of Deferred Revenue

This happened again recently. In this case, it was a problem with deferred revenue. For reasons I don’t understand, no one in this company had reconciled deferred revenue against anything before. And the previous auditor was exclusively focused on the income statement (again, I don’t understand why, but that’s beside the point). And because the company’s main revenue generating activities were seasonal (a summer camp), deferred revenue was huge in the winter and spring months.

Unfortunately, given the state of the company’s systems, tracing every transaction on a global level was next to impossible. Fortunately, I didn’t need to. Instead, I asked, “How will we know when a number makes sense?”

And I found it: The system could give us a list of everyone enrolled in summer camp. And that enrollment number (less any outstanding camp receivables) represented deferred revenue before summer camp began. It also provided a list of things the auditor could test. We had solved the problem without having to trace the exact flow of every transaction.

So remember, when the system can’t provide you with the details you want (and even when it can), start by asking what’s reasonable. Then look for things that back up that reasonable assertion.

 

Six Things to Get Your Development Team for the Holidays

In a multi-generational, multi-cultural office, secret Santa gets awkward pretty quickly. And as for those guys with the drunken, “I love you man!” at the office holiday party, the less said the better. But still, it’s the holidays. So it’s important to foster a spirit of generosity as well as a resolve to do better in the coming year.

So to facilitate the crossing of the Finance department/IT department divide (a regular topic of ours as business intelligence consultants), here are suggestions for what Finance folks should get their developers this year. (And watch for our follow up post on what developers should get Finance.)

1. Software Training for Yourself

Why is software training for yourself the BEST gift you can get your IT department? Because other than the few, the proud and the (slightly) deranged at the help desk, no one wants to answer the same question over and over again. They’d really much prefer to work on developing new functionalities and hopefully getting through that backlog of work you keep whining about.

Where to start? Look at the software you use the most. If going for ERP training or attending a conference (to actually learn something) is too much to ask, how about signing up for an online Excel course? To paraphrase an old NY area commercial, an educated user is IT’s best partner.

2. Training for Them

Too often, training is one of the first things cut when budgets get tight or priorities shift. After all, the developers seem to be getting along with their current methods, so why should they learn anything new?

First, great developers like learning about technology. And if you want to keep great developers on your team, then keeping them interested is often MORE important than paying them the highest salary. Keeping them up to date on technology shows you care.

Second, it will pay off for you. Trust me. I spend a lot of my time reading blogs, books and attending conferences to keep up to date. And there’s still a lot I don’t know. But I DO know how often I find folks using technology in ways that weren’t current even 10 years ago. As business intelligence consultants, we’re heroes for showing folks how to do things in ways that were “out of the box” a long time ago. So keep your folks up to date and let them be the heroes.

3. A Straight Face

You want to encourage IT to understand the business. You really do. So, when IT folks try to use accounting terminology they don’t understand or say something silly about accounting rules, keep a straight face. Gently set them straight. (And in return, they can keep a straight face when you start throwing around IT terminology.)

4. Acceptance They Won’t Remember EVERYTHING About What You Do

An application developer’s job is NOT to remember everything you do in your daily job. Indeed, if he or she is intimately involved in every step of your process, something is wrong. Indeed, the better that application developers are at building and/or implementing solid applications, the less they’ll remember about what they did for you one, two or three years ago. Because it works so well.

Therefore, you can’t just say: “You need to fix the month end process” or “The Walmart interface isn’t working” or (even worse) “The d**n report is a disaster. Again.”

Instead, start by making sure your developers know what you’re talking about. As in, which report? Which interface? How is it wrong? Where do you see errors? Because while YOU run the report every day, they haven’t seen it in years.

5. Time to Fix Old Stuff That (Kind of) Works But Isn’t Pretty

Quick and dirty projects are neither. And even projects that start well can get slammed at the last moment. And while those applications work, your technical folks know they’re accidents waiting to happen. If one or two key people leave, those applications will fall apart.

So, when planning for next year, give your technical folks the time to fix the old stuff. It may save you from receiving a lump of coal in your stocking later in the year.

6. Cool Sci-Fi Paraphernalia

Sorry, but clichés are generally true. Technical guys and gals love sci-fi. But if you decide to go this route, find out if your folks are into Star Trek, Star Wars or Dr. Who. Choosing wrong is like telling an AS400 guy that Windows is a better solution.

Happy holidays.

 

Numbers That Don’t Do Anything

As a business intelligence consultant, I spend most of time looking at other people’s information. But as a small business owner, I do occasionally get to look at my own information. And when I do, it reminds me of a basic rule: Information is worthless if you can’t do anything with it.

Case in point: We use HubSpot to run our website. And HubSpot provides lots of metrics. But many of the metrics don’t really help me. For example, HubSpot tells me where my traffic is coming from. (It’s easier to use than Google Analytics in this respect.) It can tell me whether traffic is coming from organic search or social media.

When I checked out those numbers recently, it showed me that of the 5500 views we got last month, 300 or so came from LinkedIn—which is way higher than we’ve ever had before. Sounds great! But here’s the rub:

  • After a spike in early October, we’ve returned to a more regular rate of about 10 views a week or 40-50 per month coming from LinkedIn. So, I wonder, is this just a technical glitch?
  • We publish links to our blog posts on LinkedIn. And I can see folks clicking on the links in the social media posts. But the number of views of those posts is nowhere near the number of clicks I got from HubSpot. So what’s that all about?
  • HubSpot can tell me where the views came from. And it can tell me which pages got lots of views. But I can’t see which pages were viewed from where. So, I have no idea where those LinkedIn members wound up. Which means I can’t figure out what I can do to reproduce that spike in views if indeed it was real.

I discussed this with my marketing consultant. She said most folks are just happy to see their numbers go up. But as a finance and BI guy, I’m only happy if numbers go up in two situations:

  • The numbers are in my bank account.
  • The numbers can tell me what to do (or not do) to get better results.

But if I don’t have more money, and I don’t what action to take, the number is meaningless.

 

Person + Hammer Carpenter:  Thoughts on Self Service BI

For years and years, software vendors have promised end-users they can have the data they want without talking to the IT department they don’t like. Things haven’t changed. I recently saw the following business intelligence stats (thanks to @TimoElliott and Logi Analytics).

As you can see, people still need IT. But why? Here are a few thoughts:

1. Person + Hammer <> Carpenter

If you’ve ever chased after a three year old who’s wielding a hammer, you know that a hammer is a simple tool. Even toddlers know how to use it. They bang away—at everything.

But just because you know how to use a hammer doesn’t mean you’re ready to build a house. Or even a porch.

So too with data. Sure, software, such as Power BI, is easier to use than earlier BI tools. But just as “Person + Hammer <> Carpenter,” so too “Super User + Power BI <> Data Expert.” Super users need to understand things like data cleansing and how to visualize data. They need to think not only, “Boy, that was easy” but also, “What mistakes did I make?”

2. Data Changes

If you have one system, with clean data, you can probably build a data mart, buy a tool, train your end users and then go on vacation.

But what if your data changes? And what if people want new combinations of that data? I’ve seen lots of end user tools that make reporting and visualization easier. But I haven’t seen many that can easily reconcile multiple systems or consolidate customer lists or interface across operating systems.

Before you consider “self-service” BI, ask how much your data changes. Because the more it changes, the more your users will have to rely on IT.

3. Time, Time, Time

Everything takes time. And sure, it’s easy to say to IT, “If you can’t do it, we’ll do it ourselves.” But when folks take on reporting and data analysis tasks, they often realize they don’t have the time to do it either. This is true even if you understand the basics of data cleansing, and you take the time to learn the tool. If you still have a day job, you may never get around to doing your own reporting and data analysis.

What’s your experience? In your company, do users build their own reports? Has new BI software changed anything?

 

(Almost) Never Blame Your System

It’s been a fun few weeks. I’m not sure if it had anything to do with Halloween, but in the last 10 days I’ve fixed more business intelligence “systems” problems than in the last six months. But in almost every case, it wasn’t a systems problem at all. It was a people problem.

Blaming the system is easy but usually not correct. If you have problems with your technology, you probably have issues in your process, training and communication. When (and only when) you have these other pieces in place (and working well) should you look to your system as the source of your problems.

A few examples of “system” problems we’ve worked on over the last two weeks:

1. Interface doesn’t process three out of several hundred files sent.

Looks like a system problem, right? Not quite. A little investigation showed the interface was programmed to look for the field “carrier.” In the three unprocessed files, the field wasn’t called “carrier” but “vendor.”

This isn’t a system problem. It’s a lack of documentation problem (which is the bane of our existence). It’s crazy how many ISVs can’t provide documentation for their own systems.
Looking at the file we received, it wasn’t corrupt. It was just different. We had to figure out HOW it was different before we could fix it. And we needed the vendor to tell us what to do.

2. General Ledger doesn’t agree with billing system.

For years, this organization blamed its disparate systems for its problems. When a new auditor was hired, he wouldn’t accept “it’s the system” as an explanation. With a bit of digging, the organization discovered that they posted many adjustments directly to the General Ledger, without first hitting the billing system. Other revenue came in via wire transfer and had nothing to do with the system. This wasn’t a system problem. This was a lack-of-proper-procedure problem.

3. Order transfer to Invoicing fails.

At this organization, once an order is filled, the user pushes a button to turn the order into an invoice. On this day, it failed with a very strange error message.

We eventually figured out that a developer has created a trigger on the database—which is a bad idea with almost any kind of packaged software. But beyond being the wrong thing to do, it also wasn’t moving from development to production correctly. A bad strategy executed poorly. Not a winning combination.

Again, this isn’t a system problem. It’s a training and process problem. The developer needs better training, and the company needs better processes to move things from development to testing and from testing to production.

4. Interface program overrides accounts to a default string of all 999999s.

Finally! A system problem! And a truly weird one. At this client, accounting information was sporadically overridden to all 99999s during an interface process. We couldn’t reproduce the problem when we retested the same file. This DOES appear to be a system problem because the program produces different results with the same information. Everything else (training, processes, communication, etc.) looks solid. Now, we need to clean up the test system to reproduce the results and figure out exactly what’s happening.

We’re in the business of fixing system issues. And they do exist: -interfaces are missing, tools don’t scale, numbers don’t match, etc. But most of the time, the problem isn’t the system—it’s everything around it.

How about you? In your company, is it the technology or the training, processes and/or communication, which cause the most headaches?

 

Power BI and the Value of a Little IT Support

Power BI, a new part of Microsoft Excel, is being touted as the greatest thing since sliced bread. And it does do a lot of cool stuff. With my dedication to Microsoft BI solutions, you’d think I’d be a huge fan. But I’m not.

I will acknowledge, however, that Power BI can be a valuable tool in certain conditions. Let me explain.

The promise of Power BI is that end users can create dashboards, visualizations and other cool BI stuff without IT intervention. There’s only one problem: Power BI only works well if your data is organized and your users pay attention to data cleansing. And for most folks, this isn’t the case.

But then I ran into Belinda Allen at the GPUG summit in Reno, NV. Belinda is a Microsoft MVP. We’d met almost a year ago when I spoke at a local user group. We talked, and she mentioned that she’d given a full day pre-conference class on Power BI. She picked up on my facial expression (I don’t hide my opinions very well) and realized I wasn’t a fan.

She responded with two key points:

  1. She dedicated an entire half her daylong training to the importance of data cleansing.
  2. She strongly advises end-users to seek out proper DBA help to set up views over their data. They shouldn’t try to figure out table relationships for themselves. (For more on this, see our post, Room for Some Views—Understanding the Value of Database Views for Reporting.)

Now, whether her audience will follow through, I don’t know. Indeed, Microsoft’s Power BI marketing doesn’t claim you can be independent of IT (except for initial DBA help). They just claim you can be independent.

So, hey, if you follow Belinda’s instructions, then great. And if you need some of that behind-the-scenes data cleansing and DBA help, we’re here to help you out.

 

Get tips and insights delivered to your inbox

Start a conversation with us

Call: 917-848-7284
Email: inquiries@redthree.com

Request a Consult