The Four Corners of Me – Provincial Edition

As I sit here looking out my window at the beautiful city Cagayaon de Oro, I am taking stock of what it means to be me.

CDO

It not even a beautiful picture as much as it is the fact that its not full of stuff.

When I am in Manila I try and balance what I call the Four Corners of Me, which are looking for new business opportunities, leading my current business ventures, creating analytics content and sharing my analytics expertise. At times it can be a lot to balance with the challenges that come with doing business in one of the most chaotic megalopolises on the planet.

At the intersection of the four corners are my mind, body, health and spirit. When those 4 corners effortlessly intersect, then then I can manage the four corners of my professional life. Given how the negative forces of Metro Manila like poverty, pollution, congestion, and corruption can sometimes sap my 4 inner corners, it can end up leaving my four outer corners out of whack.

Which makes this trip to CDO so well timed.

The conventional wisdom is that to set up a successful business in the Philippines you need to be in Manila. That’s where most of the players are, where the government is centralized and where most of the perceived best things are located. However, when you get out to the provinces, pretty much anywhere you will find expats who have bucked that trend and set up their own little business empires far away from the capital.

I have long thought I’d much more likely enjoy life if most of my time was spent in a provincial city close to the beach. I thought that in Iloilo, and in Bacolod. Now I can add CDO to that list of places I see myself in for a big part of the rest of my life. Business development can be done anywhere if you have your inner four corners lined up.

Managing my current businesses sure seems easier when my condo is two blocks from my office. But given I spent so much of my time outside Ortigas, and since I have a good management team in place, running things from the Visayans or Mindanao is not as farfetched as it used to be. We dabbled with having a team in Cebu and it worked well. So this is any easy one.

One of the beauties to what I do with most of my time, writing and blogging about analytics can be done from anywhere. Access to virtual resources and discussions about analytics in limitless. When I first set up shop in the Philippines in 2012, access to in person conversations about analytics pretty much required being in Manila. But not so much anymore. Having worked with schools in several provinces, the demand for good analytics contact is driving people to be much more open minded to where they find their solutions.

And finally, the training aspect. In many ways, the schools and businesses outside Metro Manila are more hungry for subject matter experts. The pressure to not only keep up, but show up things in the capital is quickening.

So, the dream of where the four corners of me is based in a province and not Manila is once again at the forefront. Thanks to the view outside my window for the inspiration to bring the dream back.

Flying at 30,000 Feet

I have spent a fair amount of time over the past 5 years travelling at 30,000 feet. The best part about my travels is the opportunity to experience cool things.

Since I first started laying the foundation for setting up a business in the Philippines, I have flown from San Francisco to Manila and back about 30 times. I am closing in on half a million miles with Philippine Airlines and have become quite comfortable taking the 11 to 13 hour flight. Flying never gets old for me. The excitement of takeoff and landing takes my back to my childhood every time. Flying a lot is cool.

With the explosive growth in Business Process Outsourcing industry over the past decade, I imagine there are quite a few businesspeople who have flown more often than me. Occasionally I bump into another call center owner or outsourcing professional and have had some memorable conversations about the state of the industry. Make me think I need to do more networking to meet more cool people.

I also use my travel time to read and write a lot. I make a point of every eastbound flight to pick up a business book, read it and then use my findings in future blogs or training presentations. Of all the things I do, standing in front of a room of people to talk about analytics is my favorite. I meet a lot of people who are looking for help into how to get more analytics in their business. It is way cool to be able to turn them on to a new idea or approach to achieve that.

On pretty much every westbound flight I write a blog post while at the airport waiting for my flight. I like to reflect on my most recent time spent and share something that seemed inspirational at the time.

Flying to the Philippines always fills with me with anticipation of new adventures and as of now unseen opportunities ahead. My adopted home is such an amazing country, with off the charts promise as history propels the county forward.

Flying back to the U.S. always fills me with pride as I look forward to being back in the land of the free and the home of the brave.

When I fly at 30,000 feet across the Pacific I take the time to reflect on just who I am and why I have such a blessed life. I look forward to the next 30 trips with as much excitement as I did my first trip.

This just never gets old.

And that is super cool.

Why Analytics Projects Fail – #13: Over Reliance on External Help

The final reason I will articulate in this series of why analytics projects fail is an over reliance on external help. Historically the over reliance would happen when a team is “too busy” to learn the ins and outs of the analytics software they using.

An example would no one internally has the training to maintain or update the software themselves. Any fixes, patches or enhancements have to be done with the help of someone not on the company payroll. This has obvious limitations like not being top priority or made to wait longer the necessary, as well the potential slowdown caused be internal review and QA processes. Not having someone on the insides trained to handle external products is a major risk to an analytics project.

Another examples is when internal analyst don’t have the initiative to own the software. Meaning they just do the minimums, never really learn all the things the software can do and do not offer any new idea of solutions. Being totally dependent on a vendor to keep you up to date on all the new possibilities for use of the software is extremely short sighted. This often causes going the long way on a project instead of knowing about short cuts.

A third example is that your team is not empowered to work independently and their schedule is dictated by the availability of the vendor. Important deadlines might be missed or extended because the vendor resource is not available when you need them.

Regardless of the impact, relying too heavily on your analytics software vendor leaves open the risk of what if the external expert leaves. I have seen this happen a number of times, where analytics projects were halted or even cancelled because the expert was outside the company and left the project. The most common outcome of losing your expert is that things stop working and you have to either use workarounds or start over.

The key lesson here, if you are an analyst working with externally supported software, it behooves you to become the expert on it. This will mitigate any the risk of being over reliant on the vendor. It will also assure you of having more control of maintaining, fixing and upgrading your own analytics process yourself, which makes you more valuable to the organization you work for.

Analysts who know why things fail, are proactive, find solutions and become analytics champions are the ones you want to measured by. In the end, the best way to make sure your analytics projects don’t fail is to be awesome at what you do.

Analytics Culture – The key to using analytics in a business is like a secret sauce. It is a unique combination of analytics talent, technology and technique that are brought together to enrich and empower an organization. A successful analytics culture is not easy to create, but DMAIPH can show you how. Contact DMAIPH now at analytics@dmaiph.com or connect with me directly so we can build a strategic plan to turn your company into analytics driven success story.

Results Of My Quick Analytics Survey

As you may know, I have been working on a book about analytics and the data-driven cultures of companies who successfully use analytics. So, to help me in my research, I sent our a short survey to all 10,000 of my LinkedIn connections.

I asked just one question. “If the following business lines, which one is the business line in your organization that in your opinion best uses analytics when making key business decisions?”

Sales & Business Development
Marketing
Operations
Supply Chain/Inventory
Legal, Risk & Compliance
Customer Service
Human Resources/Recruitment
Strategic Planning
No one really uses analytics in decision-making effectively.

Thanks to all of you who replied.

Now, I’ll share my results.

7% of my 10,000 Connections
Sales & Business Development – 20%
Marketing – 17%
Operations – 15%
Strategic Planning – 14%
No One Uses Analytics Well – 10%
Customer Service – 9%
Human Resources/Recruitment – 7%
Supply Chain/Inventory – 4%
Legal, Risk & Compliance – 3%

To no surprise about a third of my connections indicated that Sales, Business Development and Marketing where the top users of analytics in their business. Using analytics to help track success in growing the business and making a profit is nothing new.

As expected, HR/Recruitment was not well represented. Given I will be conducting a training on Analytics Techniques for HR & Recruitment in a few weeks, this shows I’m spot on about the biggest need right now.

My U.S. Based LinkedIn Connections
Sales & Business Development – 18%
Marketing – 18%
Operations – 14%
No One Uses Analytics Well- 14%
Strategic Planning – 13%
Human Resources/Recruitment – 7%
Supply Chain/Inventory – 5%
Legal, Risk & Compliance – 5%
Customer Service – 5%

The most significant difference I saw when breaking our just U.S. based connections was that Customer Service was so low. Given how metrics rich most customer service environments are, I suspect the low ranking was mainly due to the fact that nothing cutting edge or amazing is going on in this area for the most part.

I was also surprised to see that 14% of American respondents listed No One Uses Analytics well as the top answer. Still a lot of opportunity here in the U.S. for analytics coaching and training.

My Philippines Based LinkedIn Connections
Strategic Planning – 22%
Sales & Business Development – 19%
Marketing – 14%
Operations – 14%
Customer Service – 11%
No One Uses Analytics Well – 11%
Supply Chain/Inventory – 3%
Legal, Risk & Compliance – 3%
Human Resources/Recruitment – 3%

Given that a significant percentage of my LinkedIn connections work in HR and/or Recruitment in the Philippines, I was both surprised and intrigued by the fact that it scored lowest on the analytics survey.

So if you just happen to be in that 97%, then I have a great opportunity for you. I will be doing training in two weeks on this very topic

Let me throw out a little disclaimer, this survey is really just for directional purposed and is far from the scientifically sound type of survey I would recommend in most situations. But my goal was to validate my recent observation, that we still have a long way to go before analytics has taken deep roots in HR and Recruitment in the Philippines.

Why Analytics Projects Fail – #12: New Technology

Occasionally one of the problems that can doom an analytics project is a new technology that emerges and makes the project obsolete before it is even implemented. This happened to me once when we were using an older and heavily modified version of Business Objects and then we got access to Tableau.

At the time, the flexibility of Tableau made our Business Objects business dashboard obsolete before we even completed the design phase of the project. The data visualization and the ease of use of Tableau Desktop at that time was miles ahead of anything our IT team could build around Business Objects. As a result, countless hours and dollars were lost, but in the end at least the business requirements we had established could be done by end users in Tableau.

Another example of how a new technology might impact your project is when a new version of the database you are using comes out. One that requires some much QA and/or testing to meet internal guidelines, that when it is finally approved it is hardly useful any more. This can often be the case with big companies that have long vetting processes to use new version of software. You’d be surprised how many Fortune 500 companies are still running internal version of Windows XP because using 8 or 10 has not been approved yet.

Modifications done in house to off the shelf solutions can also make new versions incompatible. I have seen this happen with both Cisco and Teradata databases, where internal development of data flows and data structures to be so rigid, it was impossible to use updated versions of the same databases.

You can also come across situations where developers and IT teams are ordered to use something else because changes in a vendor relationships or a new strategy from the CTO. In the end you have to adapt and either sacrifice, lose, or give up on what you have put into the project so far.

As the number of data collection and storage options grow, the complexity of data models surge and the types of business intelligence solutions increase, the likelihood of a big analytics projects being impacted by new technology. A good analyst has to stay up to date on what’s hot and new, in order to not advocate the use of something that is on its way to being a dinosaur.

To help me stay current, I follow several blogs and belong to a dozen analytics themed LinkedIn groups. I also try and attend at least one big industry conference a year as an attendee as well. And finally I read a lot. I end up going through 3-4 analytics themed books a month. If you are facing a situation where you are worried your project might fall victim to a new technology, let’s talk about it. I can help you figure out a solution to keep you and your project on the cutting edge.

The key to using analytics in a business is like a secret sauce. It is a unique combination of analytics talent, technology and technique that are brought together to enrich and empower an organization. A successful analytics culture is not easy to create, but DMAIPH can show you how. Contact DMAIPH now at analytics@dmaiph.com or connect with me directly so we can build a strategic plan to turn your company into analytics driven success story.

Why Analytics Projects Fail – #11: No End User Participation

One the most overlooked and under appreciated parts of assuring a successful analytics implementation is getting the participation of end users. End users being defined as the consumers of either the data, the analysis and/or the reports that come out of the project.

I can tell you countless horror stories about stacks of reports that go unread, email summaries that are never opened and business dashboards that are rarely clicked on. In most cases, all because the end user was not involved in the project or its development process.

One example of this is when the ones who need the reports are not asked what they need in the report. This is more common than you might think. Requirements, no matter how well thought out, will always overlook something someone needs. Another reason is not finding out how the end users want it to look. They often are omitted from the design phase and just left to use it. Worse it’s possible that what is delivered in not even compatible with other things they do. This leads to failure by not being useful, a complete waste of time and resources, especially yours.

The best way to assure end user use is to have them involved at the earliest stages of the project. If you are selecting the project team or have influence on the team makeup, make sure you get an end user who can speak for that audience. It might be more than one person.

Another way is to keep the end-users informed and allow for feedback. Finding ways to work feedback into your project is another place you would be surprised by how often it is not done.

And finally make sure you build in a testing period before your project goes into production. In some cases this might include the feedback phase, but in big projects there is often a need for end user testing. If you don’t shepherd this effort, who will?

If you are no sure how to go about involving the end users and/or are not sure of who all the end users might be, then you should really answer those questions as early as possible. No one wants to see their hard earned work just end up in the trash bin because it does not fit the need it was designed for.

Analytics Culture – The key to using analytics in a business is like a secret sauce that fuels Data-Driven Decison-Making. It is a unique combination of analytics talent, technology and technique that are brought together to enrich and empower an organization.

A successful analytics culture is not easy to create, but DMAIPH can show you how. Contact DMAIPH now at analytics@dmaiph.com or connect with me directly so we can build a strategic plan to turn your company into analytics driven success story.

Why Analytics Projects Fail – #10: Key People Leave

One of the toughest analytics challenges to fix is when key people leave. This reason is another people problem, but with a technology bent. Depending on the importance of the person(s) who leaves, you can experience anything from a minor hiccup to a total meltdown of your project.

One example of this is when the one who built the database leaves. Often they take their unique knowledge of the data structure with them. Another example is when the systems architect who knows the ins and outs of where the data flows departs. This can make it difficult to track down errors and bugs. Lastly, the database admin who wrote the code might be the one who quits, taking with them all their coding work. I can even be worse if they leave on bad terms and take a key piece of your development work with them or even destroy it.

In general, the best outcome you can hope for is to is build workarounds that allow you to keep the project going, however sometimes you are better off just starting over or worst case you just live with what you have. So step one is seeing where you are in the process and then determining what it would take to replace that person.

If you are able to continue, then you need to start doing a better job of documenting and making sure information is shared so this won’t happen again. I learned this lesson early in my career. Learn all you can about all aspects of the data environment and document them. A lot of times a clear understanding and documentation will be required by management to assure funding and resources.

If you have to stop the project until you can find a replacement, then you should also learn, document and share everything so that the new person can pick things up as soon as possible.

In this case, the new person will likely be dependent on you to learn the ropes so use that opportunity to change your culture to be more open.

A final point to add, make sure you understand why the person left.

If there are things you can do to make sure the same thing does not happen again then it is on you to do just that. If it is a cultural thing, then you can be a catalyst for change. If its a compensation thing, then you can help define the expected scope of work and help in the compensation planning. If they left because of a personality conflict, then you can help find someone who will fit in better. Analysts have so much power to shape conversations. Use it.

Why Analytics Projects Fail – #9: Bad Data

In my experience, most of the time analytics projects fail its generally traceable back to a purely human problem. However, sometimes you see things fall apart because of technology, the misuse of technology and/or just bad technology. This is the case when projects fail because of bad data.

There are a lot of ways bad data can happen.

One common way you end up with bad data, is the data was not captured correctly. Perhaps the data was manually input with lots of error. Or maybe your data is not consistently collected so it has gaps. Knowing what exactly goes into capturing your data and being able to understand how it is collected is extremely important.

Another cause of bad data is that you are not getting all the data or you are getting data that has been altered. A lot of times when data passes from the collection point to you, it might be being truncated, or blended, filtered or converted. Lots of databases are structured for optimal data storage, not usage. A lot of database admins who don’t really know the data will add data flow shortcuts. Or maybe the fall under the datakeepers category and partition or cut out some of the data you need.

Bad data also comes in the form of old and out of date data. When you are making decision on data that just not recent enough, it can lead to a lot of problems. Keeping data fresh is something some companies just don’t value. If that’s the case, you will likely see your analytics initiatives come up with analysis that points you in the wrong direction.

In all three of these examples, one solution I suggest to mitigate the chance you have bad data is to build a data map. Learn about every point in a data flow that touches your data. Talk to the ones in charge of each touch point to make sure your data is not being impacted in any way that can result in bad data. Even if you cannot fix the problem, understanding it can help you set more realistic expectations of what your analytics project can achieve.

I have found using Visio to build data flow visuals is the best way to explore, document, and report how the data being used in my projects is being impacted by the environment it lives in. Knowing Visio is a valuable skill for an analyst. If you don’t use it, I promise you that once you do you’ll be sending me a thank you.

Why Analytics Projects Fail – #8: Lack of Resources

To start with a lack of resources should probably be called lack of time. Lack of time to design an effective strategy. Lack of time to find the right talent. Lack of time to get everyone on the same page. We are all just too busy and have too much to do. We say lack of resources, but mostly we mean our team doesn’t have time.

A lot of times you hear about failures with analytics projects is because of lack of resources. When I hear about this, I always ask for a better definition of what is meant by lack of resources. Is it lack of leadership support, lack of funding, lack of strategy, lack of focus and vision, lack of talent? They are all often disguised as lack of resources.

In each of the previous seven blogs in this series I talked about a reason why analytics projects fail and since they can all fall under the boarder lack of resources, let’s do a quick recap.

Lack of Focus – People are not on the same page
Lack of Vision – People don’t know where this is going
Lack of Management Support – People don’t know who to follow
Lack of a Champion – People have no one to cheer lead
Lack of Organizational Support – People don’t really care
Lack of Funding – People don’t want to waste money on this
Lack of Talent – People can’t do the job

There are all people driven reasons for why your project may be in danger of failing. They are all fixable using people skills. This is why I often argue a good analyst who can communicate is worth more than a great analyst who cannot. The reasons why analytics projects most often fail is human, not technological.

In the end, for whatever of the reasons above, your project is in jeopardy, it will be up to you to show people why they should invest the time needed to get things back on track.

You have to push for focus, share the vision, educated your managers, become a champion, gain organizational support, secure funding and align the right talent to make things work.

I have been in this situation numerous times. In every situation the one constant variable that changed possible failure into a success was me. Bring a truly great analyst means showing people how your project will be a solution to their problems and is well worth their investment of time.

When you do this, they you won’t be in a place where lack of resources dooms your analytics project.

#IamDMAI

Why Analytics Projects Fail – #7: Lack of Talent

When analytics projects fail due to lack of talent, this is generally symptomatic of a bigger cause. Lack of talent is something that can be much harder to fix then just hiring someone.

One of the reasons behind the lack of talent may be a misunderstanding of the project by senior leadership or just an overall lack of management support. As I mentioned in a previous blog, the best thing you can do is work with a senior leader to help them understand what level of talent is needed. When you do this you can enhance your analytics solutions and have them advocate for you to get the right talent.

Lack of vision and/or focus by your organization can also result in not having the right talent available for the job. It might not even be the analyst, but the it might be something missing within the development team or the project implantation team. This generally ends up with analytics solutions being full of patchwork shortcuts that limit their impact.

Lack of funding can also be an issue, where your organization just can’t offer a competitive package to the available talent. This is becoming even more of an issue lately as good analytics talent is in high demand and the supply can’t come close to keeping up.

Having the right analyst, with the right skills sets, the right training and the right tools aligned to give your business a good analytics solution misfires a lot. There are hundreds of business intelligence tools, thousands of types of databases, all generating very unique reports. When one of these elements does not match up it can easily cause a failure due to lack of talent.

My suggestion if you think you have a lack of talent problem is draw some kind of process flow. Who are all the players in each part of the process? What applications are used to collect, store, analyze and report your data? What programming or language skills are required? When you lay all this out then you have an idea of what skills and experience your analyst needs. Combine this with the people side of the job, what communication skills, what data visualization skills, what project skills does your analyst need? If you don’t have anyone in the organization with this list of skills, you need to either hire one or create one.

When you look at job postings right not for analysts, its easy to see that requirements vary greatly across positions. No two companies have the exact same analytics needs not employee analysts the exact same way. So if you are going out to hire one, make sure you have a clear idea of what you need and not get caught up in looking for an analytics rock star.

It is often easier to actually look inside and find someone who can be trained to take on the role. Having internal business knowledge and knowing the organizational culture are huge plusses. A lot of time because that person doesn’t have the skills on their resume yet, they get excluded. However, I have always favored promoting from within and upskilling then going out and hiring an unknown variable.

So if you think lack of talent is killing you analytics project and are not sure what to do next. Connect with me. Let’s build a job description that tailor fits your needs and see where the best place is to find them. It’s probably someone sitting in a cube next to you.

	DMAIPH on You Don’t Build A Busine…
	Ioliveiraserpa on You Don’t Build A Busine…
	DMAIPH on The Current Analytics Talent L…
	John on The Current Analytics Talent L…
	Dominic on Outsourcing Tip > Size the…