Archive for category Client Relations
The Business Analytics Experience
Posted by Scott Andrews in Client Relations, Cognos, Ottawa Events on November 30, 2012
I recently had the opportunity to act as a facilitator in a Business Analytics Experience workshop. The Business Analytics Experience, or BAE, is a business simulation where executives and analysts from the real world get to try their hand at running a fictitious company for a few hours with a focus on business analytics. Through a Cognos 10 interface, they have access to the company financials, pricing and marketing strategy and various other parts of the enterprise. The simulation runs for 4 fiscal quarters, and in each the participants get to choose how they want to proceed with their corporate strategy. Each quarter the numbers are run and then they can review their decisions and see if they are meeting their targets or not.
It is a fun, interactive way to see business analytics in action. Even though the simulation itself is somewhat simplified compared to real life, it does offer surprising depth and complexity that can include additional modules as time permits. It shows how insights gleaned from business analytics tools can be applied to real decision making.
If anyone is interested in learning more about the Business Analytics Experience or would like to get information about booking their own BAE session, please contact me and I would be happy to see what we can do for you.
If It Ain’t Broke, Don’t Fix It
Posted by Scott Andrews in Client Relations, Data Quality on November 23, 2012
There are a few competing schools of thought when it comes to how to handle data quality in a data warehouse or data mart. There are those who suggest that all nulls and blanks and other variant data items should be converted automatically into a standard form, perhaps a uniform one, like “invalid”. There are others who suggest that data be left in its original form, unless there is a compelling reason to change it.
I fall into the later camp, for many reasons. First of all, most business users freak out at the thought their data is being manipulated in any way, unless they were the ones to request the change. Second, the Cognos environment (and most other reporting environments) have features and functions that allow you to easily handle variant data. And third, variant data in a database can mean many things beyond a simple grab bag of “invalid”.
Think of the many things that null could actually mean:
- This data item is not revelent to this record
- This data item was left null in error
- This data item was unknown at the time of data collection
- This data item represents a link to another table where there is no corresponding record
The only people who can tell you the true value of a null in a record are the business users themselves. Perhaps null should read “Not applicable”. Perhaps “Not available”. Perhaps “Error”. Who can tell you? The business users can.
Sometimes, as data modelers and ETL developers we are asked to create a “self-service” environment, usually with all data elements or as many data elements as possible. Therefore, we find it our duty to “clean up” the variant data we find in our data mart, sometimes with little or no direction from business users indicating whether or not such data items are a problem.
It goes without saying that you are going to want to eliminate outer joins in your data mart wherever possible, so there may be specific times you create a placeholder record in a dimension table to hold a surrogate key value in your fact table. Replacing nulls in a column regularly used for filtering with a specific code can improve query performance. But these are to specific purposes. To simply change all your data items in a dimension table to be “not null” and fill the nulls, zeros or other variants with something else will invite problems, especially if you do not know how or even if such data will be used.
At the end of the day, it will be your business requirements that decide how variant data should be handled, and your business users should have at least some say in that. If data is null in your source system, it may be null for a reason.
A Project in Crisis is like a Lost Kitten
Posted by Scott Andrews in Client Relations on July 23, 2012
Last Thursday we had an unexpected little visitor in our backyard. It was a small black kitten. Judging from its size we estimated it to be about 3 to 4 weeks old. Over the weekend I pondered the experience of finding and helping the lost kitten and how it related to a project in crisis.
1. Assess the situation – When you find a kitten in your yard, the first thing to do is to assess the situation. Where is the mother? Where is the rest of the litter? What are the risk factors? Finding no mother or litter, and with many raccoons and skunks in our neighbourhood (not to mention our swimming pool), we knew the kitten to be in danger. Likewise, assess the project in crisis. Who are the players? What are the goals? What are the risks? How did we get here?
2. Triage – Prioritize your next steps. What needs to be done now? Judging from how the kitten was licking and nipping at my hands, we knew it was hungry. Unable to drink from a bowl, we found that it was able to lick milk out of the palm of my hand. Identify your top most concern in your project as well. You may have to use unconventional methods to resolve your problem.
3. Get the right help – We knew that we were in no position to care for a kitten that needed round the clock nursing, so we called in the experts. We took it into the Humane Society. Make sure your project in crisis has the right people with the right skills. You may need supplementary help in the short term to meet any skill gap.
4. Your client will not be happy – The poor little kitten cried and yowled all the way to the Humane Society in the car. Likewise, your client in a project in crisis will not be happy either. You are attempting to minimize or mitigate damage at this point. Best to avoid losing your kitten in the first place.
But Do You Drive a Ford?
Posted by Scott Andrews in Client Relations, ETL on May 3, 2012
As an ETL developer, I cut my teeth on Microsoft Data Transformation Services (DTS) in 1999. This experience led to engagements in Cognos DecisionStream, and later Microsoft SQL Server Integration Services (SSIS), Cognos Data Manager and more recently IBM InfoSphere DataStage. I also have experience in Oracle SQL Loader and Unix scripting for data loading purposes. In all, I have been working in ETL for more than 12 years.
But never mind all that. When it comes to contract opportunities, tools rule.
If truck drivers were hired the way ETL developers are, they would have ads like this:
Wanted: Truck Driver – must have 5 years experience driving a Ford
Most ads read X number of years in Y tool, usually at least 2 to 5 years. When you are new to a tool, even with a decade of experience in others, you can be dropped from consideration. This approach is very limiting, both to me as a contractor and to clients who are hiring. Their pool of applicants is limited, and they eliminate an excellent resource like me!
Being a self-taught computer techie in Delphi, VB.Net, Crystal Reports, Gupta databases and to a certain extent SQL Server itself (I am formally trained in Cognos and Oracle), I am capable of ramping up on new products and technologies and delivering professional-grade, quality results in a short amount of time. But I often find myself pigeon-holed into a small group of tools, and recent experience in new products is often heavily discounted if not written off completely.
ETL development itself is very conceptual. It is more than the tool, the database, or even how the tool and database work together. I recently reduced the runtime of an ETL process by 80% by using database techniques that were completely unrelated to the ETL tool in question. This technique could have worked with almost any database or ETL tool. As such ETL solutions are not as tool driven as managers or procurement might have you believe.
This is not to say that ETL tools do not have differences, sometimes even major ones. But at the end of the day, like a truck, they get your data from point A to point B. And just like any quality, experienced truck driver, ETL developers should be able to change their vehicle of choice and drive it home.
Unblocking Your Blog
Posted by Scott Andrews in Client Relations, Tech Trends on March 31, 2012
In my line of work, I spend a lot of time googling Cognos error codes or investigating Cognos issues online. My online inquiries lead me to many different sources, including many other technical Cognos blogs. What I have discovered at my last two clients is interesting – as part of their “social media” policy, they block access to many blogs hosted on most blogging websites. Essentially, almost any free blogging site is deemed “inappropiate” as per their acceptable web use policy. Of course, they do suggest that you can apply for access to the desired website if you deem it “vital” to your work. But who has time for that? By then I have skipped ahead through the search results, looking for another answer.
I can’t say for sure how widespread this practice is, but if you want maximum exposure for your online material and corporate clients are a key part of your target audience, you may want to consider hosting your blog somewhere under your own registered domain. Otherwise, you may be missing wide swaths of users that work under such a social media policy. While we could argue against such a blanket ban that equates any time spent on a blog with that of time spent on Facebook’s Farmville, I suspect it will take the corporate world some time to buy into the value of professional blogs. In the meantime, make your blog look more professional by hosting under your own domain and then you should be able to get through to everyone.
Can’t anybody here play this game?
Posted by Peter Beck, CBIP in Business Intelligence, Client Relations, Cognos, Information Technology, Tech Trends on October 6, 2011
Can’t anybody here play this game? – Casey Stengel
IBM has a new paper out on that age-old question – why do BI projects fail, and what can be done about it? The paper is entitled “Bridge The Gap Between BI Best Practices and Successful Real World Solutions“. The first few pages are the usual marketing fluff, and they generally contradict the “meat” of the paper, which begins a little further in. That is, once again, we see a particular technical/product solution proposed to solve what is not a technical problem. This is accomplished by simply asserting that this particular technical solution maps neatly over the business problems Gartner has uncovered. If you are brave enough to hack your way through the paper to where the Gartner material actually begins, there are some interesting discoveries to be made. By “interesting” I mean “depressing”. Taken as a whole the paper can be thought of as a fine example of what the Gartner research itself reveals.
The paper begins with a set of now-common observations: that BI programs need a business sponsor, that IT ends up “selling” BI to the business (and doing it badly), that BI tends to get “stuck in reporting”, and that “Technology is rarely the culprit if the BI project is considered a failure”. All well and good. And then at page 2 we read, in bold, all-caps:
IBM COGNOS EXPRESS: THE KEY TO A WINNING BI STRATEGY
I see. IBM’s technology will be the “key”. That’s a relief. Gap closed! Close the document and move along.
But if I keep reading, I discover that the folks at Gartner have done some research on the practice of BI programs, most of which are not particularly related to technology (on the contrary.) The results aren’t good. That doesn’t mean they are surprising, of course.
The Gartner section of the paper is called “The BI(G) Discrepancy: Theory and Practice of Business Intelligence”. They break out 9 aspects of BI implementation, and discuss what should be done in each aspect, versus what their research indicates is actually taking place in the real world. The results are a confirmation of what most of us “in the trenches” feel intuitively: there seems to be little correspondence between what should be done, and what actually is done. And technology isn’t going to change that.
The whole thing is worth a read, but the most eye-popping section turns out to be the discussion of - BI strategy! That thing that the latest IBM product will provide a “key” for! Turns out only 2% of organizations informally surveyed in mature markets had anything called a BI strategy. That’s not a typo. 2%. And this is among Gartner clients. Let that sink in for a second, and then consider this quote from the paper:
“Nearly shocking results are obtained when reviewing the so-called BI strategy documents. Almost never would those qualify as strategy in Gartner’s opinion. Quite often a strategy is merely a statement like “We have a Microsoft BI strategy” or “Our BI strategy is SAP” indicating what products the organization is using or planning to implement. Other times the “strategy” is merely an architecture diagram… This is as if the Ferrari Formula 1 team described its racing strategy as “using Bridgestone tires, Shell fuel, a V8 engine and red paint.”
I like the use of “Nearly” to suggest seen-it-all unflappability on the part of the author.
The analyst goes on to describe the initial 2% number as “rather optimistic” (raw-ther, old sport!), blows some dust off the dictionary definition of “strategy”, and then (perhaps beginning to get a little exasperated, and reaching for the bottle) muses that:
“The question could be expanded to: Do executives even understand what constitutes a strategy?”
Yes! It does appears that the question could be expanded to that!
Everyone, and I mean everyone, I have ever encountered in this industry who works above the level of writing reports struggles with the problems outlined in the Gartner material every day. And yet here we are, decades now into the world of BI, and it doesn’t appear to be getting any better. BI still seems to be mired in confusion as to what it is – what is its identity within the organization. The default position seems to be: it’s a technology. IBM et. al. seems ok with this, and I can’t blame them. As long as the discussion can be returned to “BI is a product (and our product is the best!)” they seem to be happy, as they have a tangible thing to sell. My own feeling (obviously) is whenever the real answer to this question is found, it won’t be “Cognos” or “Microsoft Analysis Services” or any other piece of software, and I say this as someone who spends his days with these products in front of him.
If executives don’t have a grasp of the rudiments of BI strategy (or perhaps strategy in general), it seems that the best anyone can do is try to keep pushing technology. At least that seems to be what IBM’s “strategy” is with this document – provide a high-level summary, name the product and map it to what is “supposed” to happen in an organization, and hope for the best – and that no-one keeps reading. Or what the Gartner analyst, in the section on what goes on in the real world when it comes to the business case for BI, characterizes as a “leap of faith”. I’m not kidding, they actually use those words to describe what Gartner clients are doing to justify their BI investments.
Check the paper out, it’s worth a read.
The Three Degrees of Consultant / Client Relations
Posted by Scott Andrews in Client Relations on April 27, 2010
There are politics in every organization, but one thing I love about consulting is that you are always one step removed from them. As an expert outsider, you are often above the fray. When you give advice it is usually seen as neutral and professional – after all, that is what they are paying you for. But some clients are more difficult than others, and avoiding politics with them can be very difficult, if not impossible.
Over my many years of consulting, I have found that most consultant/client relationships fall into three broad categories. Whenever possible, it is best to position yourself in the top category:
Consultant as Guru
You are seen as a recognized expert and treated well. You are allowed to work autonomously. Your client appreciates and respects you, and good work is lauded. Personally I thrive in this kind of environment. I want to deliver success to these clients. I will go the extra mile for clients that respect me. It is a win-win relationship.
Consultant as JAE (Just Another Employee)
You are seen as one of the crowd. Depending on the managerial staff, you may be micromanaged. Other employees may resent you. Any “favouritism” shown to you will be a grievance to the others (larger workspace, better equipment, a window etc.). The only way out of this trap is to prove your worth by excelling beyond their expectations. If you can, you could graduate to Guru status.
Consultant as the Enemy
For any number of possible reasons, your client is not happy and is directing its collective wrath at you. Marketing may have over-promised and your client’s expectations may be sky-high. Negative past experience with other consultants may make them prejudice against you. Maybe the project is being shoved down their throats by upper management. Maybe they are unhappy that the software package they just purchased also requires tens of thousands of dollars in development time. In any case, they are quietly or openly hostile. You are resented as a “huge” expense. Sometimes your client even wants the project to fail for political reasons. Sometimes they want someone to blame. Pulling this one out of the fire will be very hard, if not impossible. This is the worst case scenario. These will be the hardest clients. They will demand the most and thank you the least. Avoid these situations whenever possible.
You may find that any one client may be a mix of these, depending on the circumstances. You may even find individuals within an organization scatter all over this scale. To position yourself well, you need to manage expectations as early as you can and strive to exceed them. Prove your worth as you are able. But while you do, bear in mind the adage “there is no pleasing some people.” Sometimes bad clients are not worth the trouble.
Is User Spelled with an L?
Posted by Scott Andrews in Client Relations on March 27, 2010
photo credit: Nick.Fisher
Early in my career, I took over as system administrator of a land inventory system for a woman who was going on maternity leave. There was an imaging component to this new system which was supposed to make paper files obsolete. However, there was much grumbling about this paperless feature, and many business users resisted using it by continuing to use the physical paper files. To prevent this, the week before she left the system administrator had all the paper files sent off site. So I walked into an unfolding disaster on my first week! The business users were furious and demanded their paper files back. What could I do?
I asked the business users why they didn’t like the imaging system. What was wrong with it? It turns out they had a lot to say. It didn’t allow searches. It didn’t allow book-marking. It was not user-friendly. The list went on and on. The reason they wanted the paper files was it was much easier to do their jobs with them. I took all of their complaints on record, and then ordered their paper files back. I did this because any information technology worth its salt should make business users’ jobs easier, not more difficult. Forcing users to use a suboptimal product when a better alternative is available (even if it is paper) is ill-advised at best and destructive at worst. It shows an attitude of arrogance and indifference to your users. Summing up this attitude, a fellow IT consultant once told me “Some people think that user is spelled with an L”.
This is not to say you shouldn’t ever introduce new technology to a resistant group of employees. But unless you can articulate the benefits, and they can understand what those benefits are, then no one is any further ahead. When evaluating a software product, be sure to seek the advice of those who will actually use it. Business users have a good idea what it is they need to do their jobs. Listen to them. Invite the input and creativity of your business user community and you will have an information technology system that is part of your business’ success, not its failure.
Big Value in the Little Things
Posted by Scott Andrews in Client Relations on March 20, 2010
A number of years ago, I had a client with an in-house developed application for sales and inventory. They were a small business and they had hired a programmer to develop this solution for them. However, after it was completed this programmer decided he had had enough supporting it, and left them. They approached my employer desperately searching for a Delphi programmer and so soon I was on assignment. I’ll never forget one of the first change requests they had for me. It was so simple. They needed a search feature in one of their list boxes. It took me maybe 20 minutes to complete the change. And once they saw what I could do, they were ecstatic. I was suddenly seen as a miracle worker! I understand that the change requests made to the previous developer were met with derision and resistance, a not uncommon occurrence in the world of IT.
My lessons from this experience were a) listen to your business users – sometimes what they want or need isn’t that big a deal, and b) don’t say no automatically to everything. Sometimes there are very good technical reasons why something can’t be done. If so, explain. But always saying no reminds me of a Dilbert joke translating techno-speak: “It is technically impossible” Translation: “I don’t feel like doing it”.
"Data Warehousing" is not Goobledygook!
Posted by Scott Andrews in Client Relations on March 13, 2010
“Gobbledygook may indicate a failure to think clearly, a contempt for one’s clients, or more probably a mixture of both.”– Michael Shanks, former chair of the National Consumer Council of the U.K.
I recently read an article in Wired magazine that looked back on the 10 year anniversary of the dot com craze. One of the things it notes from this period was some of the “business goobledygook” forged at the time – a list that includes “Data warehousing“, “ERP“, “ETL“, “OLAP“, “OLTP“. I was somewhat taken aback. I deal with these terms on a daily basis and they are not Greek to me – these are words and acronyms with very specific technical meaning. Dropping them from my vocabulary would mean not being able to communicate professionally.
I do exercise care when using these terms and ones like them (I always tell people I am a computer consultant, not that I am in “business intelligence” lest I be mistaken for a corporate spy). But it was a revelation to me that our lingo is incomprehensible even to other techies. Imagine! Yes, it is technical jargon. But it’s only gobbledygook in my opinion when used to deliberately bewilder or belittle others. So use with care!
-
You are currently browsing the archives for the Client Relations category.
