Posts Tagged ‘people’
Photo from http://www.care2.com.
About three years ago, I walked into an absolute train wreck of a project. I’ve seen my fair share of disasters, but this one was in a league of its own. Call it RRC here. Consider that RRC had:
- major data quality and integrity problems
- nothing close to a master record on its employees
- significant M&A activity within the past four years, exacerbating the first problem
- poor or nonexistent documentation on past data conversion efforts and existing and past policies
- a great deal of employee turnover
Because of these restrictions, conducting an analysis based upon a change in overtime policy was a Sisyphean effort. (To boot, RRC hired another consulting firm for the same project whose newbie consultants did little but ask basic questions and honestly just get in my way.)
Upon taking the project, I asked, “How did things here spiral out of control as much as they did?” I also wondered out loud, “Weren’t their key opportunities for RRC to identify problems–and solve them?”
In fact, there always are such opportunities. However, organizations often miss out on these windows to take hard looks at things. A partial list includes:
- the implementation or upgrade of a new system
- changes in leadership
- M&A activity
- audits–and shocking results
- government regulations
However, it’s downright wrong to claim that organizations can only make major changes when confronted with these inflection points. I would soon learn that no one at RRC had what I call a healthy disrespect for the organization’s current data management practices–or lack thereof. The result of years of neglect and ignorance: data chaos.
Particularly at more senior levels, newly hired employees should bring with them a sense of skepticism and curiosity when they see something that doesn’t make sense. While I don’t condone rudeness and premature judgment, you can go too far in the other direction. Obsequiousness isn’t helping anyone. There may be reasons that an organization set up its systems, IT infrastructure, and applications in a certain way. However, that doesn’t mean that that way continues to make sense.
Of course, often employees with a sense of skepticism and curiosity can irritate the powers that be. Sometimes, as I know from personal experience, the most politely phrased question about why things are they way the are is bound to evoke a critical, even scathing, response. More than a few VPs and CXOs have things set up they way that they like them. Since many of them are close to retirement, rocking the boat is the last thing that they want to do.
With rare exception, data management practices tend not suddenly break bad. More often than not, a gradual erosion in governance (if it ever existed) takes place over a pronounced period of time. Encourage current and prospective employees to question things that don’t make sense. You’ll find that problems are found and fixed sooner.
What say you?
In Why We Make Mistakes: How We Look Without Seeing, Forget Things in Seconds, and Are All Pretty Sure We Are Way Above Average, Joseph T. Hallinan writes about the quiet-eye period. He defines it as:
the amount of time needed to accurately program motor responses. It occurs between the last glimpse of our target and the first twitch of our nervous system. Researchers have documented expert-novice differences in quiet-eye periods in a number of sports, ranging from shooting free throws in basketball to shooting rifles in Olympic-style competition. The consistent finding is that experts maintain a longer quiet-eye period. (emphasis added)
I thought about this quote in the context of a recent consulting engagement on which I was bidding. Call the potential client Company X here. To make a long story short, Company X is a very large organization with more than 10,000 active employees that needs to upgrade its time and attendance system by the end of the this year. On a conference call discussing the project, we eventually got to arguably the key question: How long is this going to take?
It’s the point at which many consulting firms throw out a low number because it’s safer–and the firm is more likely to get the deal. Less scrupulous firms do this and then hit up their clients for change requests after the project has begun in earnest. Before long, chairs are being tossed in conference rooms.
More scrupulous consultants (and I firmly put myself in this category) maintain longer quiet eye periods. We know that the answer to “How long?” hinges to a great extent on client data and related subquestions:
- How much information needs to be converted or migrated?
- How much information needs to be cleaned?
- How accurate is the information?
- How comprehensive is the information?
- In how many different places is that information?
Only after these questions can be answered can good consultants realistically estimate the amount of time, effort, and money involved in an information management (IM) project.
To its credit, Company X didn’t balk when I said that, after a one hour call, I couldn’t possibly estimate the project’s length and, by extension, cost–at least in an accurate manner. I would know more when I know more. (Yes, this is reflexive but completely on-point.)
Company X liked that answer and I’ll be starting the gig soon.
Organizations should be wary when consultants’ quiet eye periods on IM projects seem short. If it seems to good to be true, then it probably is.
Moreover, how do we know what we don’t know? To be sure, taking months to provide a quote or estimate is probably excessive, especially when the organization is facing critical deadlines. By the same token, however, anyone who can answer big and unwieldy questions in a few seconds really isn’t an expert at all. As such, the organization should go in a different direction.
What say you?
Thirteen years ago, before I worked for myself, I worked at a large Fortune 50 company in a hybrid capacity. About 60 percent of the time, I worked in and with IT. The other 40 percent of my time was spent in corporate HR. It took me a little while to understand the vast differences between the groups and, in years since, I have witnessed first hand many other IT-business chasms.
I can remember one project on which I worked with the recruiting department. A director (call him Alex here) wanted an analysis performed on the schools at which the company currently recruited. He wanted to know whether targeting Ivy League schools made sense. You see, Alex had to justify expensive recruiting trips to Cornell, Harvard, and other elite institutions.
Disclaimer: I have a master’s in labor relations from Cornell University.
One of Alex’s direct reports (call her Lauren here) was much more functional than technical. That is, she understood the business needs of her department but wasn’t great at extracting and manipulating data. Added to the mix, our employer’s internal systems and data were, to put it bluntly, a mess. Perhaps I could help her try to make heads and tails of things.
Not a problem. Eager to lend a hand, I dug in to the data. I started with high level questions, such as:
- Do hires from Ivy League schools perform better than those from other institutions?
- Do hires from Ivy League schools remain with the company longer than those from other institutions?
- Do hires from Ivy League schools justify their higher salaries–relative to those from other institutions?
- Do the recruiting expenses required to hire these candidates justify their costs?
- Ultimately, should our company be focusing on candidates from Ivy League schools?
Note that I did not have accurate information on many things, including internal recruiting costs, making definitively answering questions like number four impossible.
But not having completely accurate and comprehensive information should never stop you. I’ve always been able to use proxies when I lacked such information. For example, while I couldn’t tell you precisely how much Alex had spent on his plane ticket to Harvard, it wasn’t hard to approximate that expense–and others. Things like offer acceptance rate are also easy to estimate when you talk to others.
Among my findings, at our company, Ivy League employees (relative to non-Ivy League ones):
- were not appreciably better performers
- did not stay with the company for a longer period of time
- did not justify their expense
Even with significant limitations of our company’s data, the statistics were overwhelmingly clear. Brass tacks: the costs of recruiting at Ivy League schools did not remotely justify their benefits, even if my assumptions were off considerably.
Don’t Tell, Don’t Ask
Lauren was amazed at what I could do with a tool as simple (yet powerful) as Microsoft Excel. (Again, she wasn’t very technical.) However, she wasn’t an idiot: she saw the same trends that I did. She presented her findings to Alex, her boss. And here’s where the story gets interesting.
Alex would have none of it. He didn’t want the real answers to the questions: Should he be recruiting at Ivy League schools? Was the Ivy League strategy the best use of his department’s–and the company’s–money? Or would it be better to focus on state schools? He only wanted confirmation that he was already doing the right thing. He liked going to Harvard and Yale. He liked telling others (internally and externally) that he “bagged” a new MBA from Columbia. He dismissed the results of my analysis immediately upon learning the results.
And you wonder why HR doesn’t exactly have the best reputation in many organizations?
The bottom line of this little yarn: you shouldn’t ask the question if you don’t want the real answer.
What say you?
There’s an old English saying: A fish rots from the head down. This maxim can be applied to many different situations. In a nutshell, it means that when an organization or state fails, the leadership shoulders most of the blame. From a senior executive’s perspective, is this platitude inherently fair? Probably not. I’ve worked on many large-scale IT projects in my day. While I’ve seen my share of terrible and ill-equipped leaders, it’s facile and simply inaccurate to just blame the folks in the corner office. Consider the MIKE2.0 Managed Data Governance Organisation with C-level executives ensconced firmly at the top: As you can see, there are myriad areas for potential problems in large organizations–even if everyone has the best of intentions. Of course, this is rarely if ever the case. While the above diagram is simply a framework, I have found these types of visual representations manifest potential problems on information management projects. On a personal level, I’ve witnessed many recalcitrant employees who have found creative ways to subvert management because they didn’t agree with any number of things. (Even entry-level employees can cause major problems by doing–or not doing–key things in a timely manner.) While often not outright defiance, employees usually have more than a little room for interpretation on a daily basis. Long story short: what a leader wants and what a leader ultimately gets can be two entirely different things.
But CXOs shouldn’t expect fairness–not when they make so much money and have so much responsibility. Collectively, CXOs’ level of compensation and responsibility mean that they have to–or at least, should have to–solve bigger problems than the everyday employee and deal with more issues. That’s why they make the big bucks, isn’t it? This isn’t entirely dissimilar to quarterbacks in the National Football League (NFL). They make much, much more than the league average because of a number of reasons:
- It’s the most visible position in the sport.
- It’s the most complex position to perform (well).
- They’re just aren’t that many good ones around.
Like a bad leader, a bad quarterback CIO or VP can destroy an organization. Because they represents the sum total of the people working for them, they can easily point to individuals, groups and departments not doing their jobs. The best leaders don’t do this. They make do with what they have. They make tough decisions relative to resources (both human and financial), strategy, implementation, and execution. They hold people accountable when things veer off course. They realize that actions have consequences. They manage risk and a cauldron of other issues.
The workplace isn’t a democracy and employees are expected to fall in line. Foolish is the leader, however, who expects things to work out entirely as planned. While it’s probably an exaggeration to expect complete dysfunction, it’s wise to remember Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
What say you?
My friend Robert Hilliard on this site recently wrote about the oft-discussed issue of information management. He writes:
I argue that although the creation of new data in absolute terms (as opposed to the retention of existing data) means the innovation is genuinely new, it does not become disruptive to existing business unless it actually enhances the connections to current data. Creating new data on its own doesn’t add much value to an existing business, but creating more links definitely does.
Creating new data–or cuts of existing data–is often of questionable value. I always ask myself: Is this truly needed given what the organization already has? Of course, therein lies the problem.
Consider the following questions for many large organizations:
- How many reports merely reflect essentially the same data as other, existing but unknown ones?
- How many people or departments inside a big organization insist upon their own BI tools because they don’t play well with other people or departments?
- Do any organizations have accurate and comprehensive lists of all of the tools throughout?
Color me pessimistic, but at large companies I’d argue that the answers to these questions is typically “We don’t know.” What’s more, at these organizations, there’s rarely a great deal of data governance. As a result, a state of anarchy causes myriad problems–typically leading to requests for new “stuff” when old stuff will suffice..
The Sort-Of Simple Solution
Is there a simple solution to this problem? Not really, but let me tell you about a radical method that several CIOs have used to determine exactly which reports, BI tools, and data sources are needed: Turning everything off.
Let me explain.
A CIO sends an email to all managers explaining that there are too many applications, reports, data sources, etc. Perhaps this email goes out in February and states that, unless s/he hears otherwise, all “stuff” will be turned off at the end of the year. Perhaps several other reminders are sent as well and the topic is posted internally and referenced at meetings
No one is messing with payroll applications. Major ERP and CRM applications need to remain active, but everything else is fair game. Also note that silence equals consent: non-responses are tacit approvals. Finally, even in sacred cows such as ERP and CRM, there typically are reports that are simply never used anymore.
After the Email
Diligent managers will respond immediately. They will list their reports, applications, and data sources cannot be deactivated. As is often the case, however, many of the emails and announcements will be ignored. At the end of the year, all “stuff” previously ignored are turned off. End of story. Systems are retired. Reports no longer need to be generated because obviously no one was using them.
This is obviously a way to remove superflous reports. Think Office Space and TPS Reports.
When CIOs have boldly taken this step, many have been silent. Then, several months or years post-deactivation, a few stragglers have come back with requests to resurrect those now dormant legacy items.
Is this risky? Sure. Is it arguably a good move? Yes. Everyone tends to overestimate what they need for fear of budget and headcount cuts, especially at large organizations.
What say you?
At its core, the MIKE2.0 Methodology is fundamentally about people. So is any development or deployment methodology, really. Systems don’t implement themselves and, despite what Watson recently accomplished on Jeopardy!, that’s not about to happen anytime soon.
Yes, it’s still all about people and people-related issues. I’m talking about things like:
- project, change, and performance management
- managing group and individual workloads
- putting the right people in the right roles
- managing expectations
- staffing appropriately
Much of this sticky stuff hinges upon the organization. In this post, however, I want to remind people about the choices they have when choosing employment.
Matching People and Organizations
About seven years ago, I was happily employed as a full-time consultant for a large company. The company liked me and vice-versa. Other than the near-constant travel, I really couldn’t complain.
One day, I received a call from a big company based in my home state of New Jersey about a full-time job. Because the job would enable me to sleep in my own bed at night, I took the interview.
The company was trying to take its IT department to the next level and, at the risk of being immodest, I had the precise skills for which the company was looking. I had asked about the company’s current use of technology. As I suspected, it was a mess.
But here’s the rub: key people within the company wanted to do things better. What’s more, my would-be manager and her boss (a VP) knew that I could help do jus tthat. I was flattered but still a bit skeptical.
- Would the company be willing to let go of long-held processes and antiquated reports?
- Would key people, the culture, and the organization let me make things better?
That VP called me personally to tell me that I was the company’s top choice and that I would be able to “take things to the next level.”
How wrong I was.
Over the next three months, I was in a constant state of push-and-pull not only with my manager, but with influential end-users who just wanted things to be done the way they always had. It didn’t matter I knew better ways of extracting and inputting information into the company’s systems. I was proposing something different, and that was a problem. For example, key reports that took days to manually cobble together could have been rewritten and published via the web for scheduled delivery.
“We don’t do it that way here”, I was constantly told.
After three months, my manager and an HR person sat me down in an office and told me that that day was going to be my last. Angered, I had asked why they just didn’t tell me when I interviewed there that they were stuck in their ways. We could have all saved us the hassle of a failed hire.
I used to blame my manager and VP for lying to me during the interview process. I don’t anymore. I should have realized that I was signing up for madness and a fundamental aversion to change, no matter what they said.
Big, bureaucratic organizations are often stuck in a perpetual state of dysfunction and, if key people admit it, they’ll never staff positions with skilled folks.
Learn from my mistake. If you like constantly improvement and fixing problems, don’t take an information management role in a clunky organization, no matter what you are told and by whom. Powerful technologies and reporting tools mean nothing if the organization is hell-bent on utilizing the same old manual (read: broken) processes.
What say you?
In last week’s post, I wrote about organizations that fail to secure the requisite resources while undertaking major information management (IM) initiatives. In today’s post, I’ll extend the discussion to another source of resource-based problems on these projects: money.
Penny-Wise, Pound Foolish
When it comes finding the right resource for an IM initiative, many organizations are cautious with small amounts of money but careless with larger amounts. While attempting to procure independent contractors or full-time consultants/vendors, many focus exclusively on hourly rates. (This is particularly true if third parties such as recruiters or consulting firms are involved. These companies often attempt to pressure the consultant or subcontractor into taking the lowest possible rates.)
Focusing on hourly rates alone is one of the cardinal sins made by organizations during IM and IT initiatives. Such myopia misses the big picture and ignores the very important concept of Total Cost of Ownership (TCO).
Now, this is hardly rocket science. A consultant or subcontractor with superior skills might–and probably does–charge a premium rate. However, highly skilled individuals can often accomplish their work in far fewer hours than their lesser-skilled counterparts.
Consider the following fictitious example. Griffin, Inc. is a major manufacturer of toys. Over the years, the company’s data and systems have become increasingly segregated. Orders are often incorrect, delayed, or shipped to the wrong location due to inaccurate customer information in its cauldron of systems. Management is starting to realize that this problem isn’t going away; it’s getting worse.
Griffin has decided that enough is enough. It will begin a major IM project with the ultimate intent of consolidating and purifying its data. For this, it needs help. The hiring manager, Peter, has the resumes of two candidates:
- Brian charges $125/hour for his services. He has extensive programming, data analysis, and general business experience. He can interpret requirements that are anything but iron-clad.
- Stewie charges $90/hr his services. While no newbie, he just doesn’t bring the same skills to the table as Brian.
Pressed for money, Peter tries to get Brian to come down to Stewie’s rate. Brian has some flexibility but ultimately won’t come close to $90/hr. Peter goes with Stewie, thinking that he’s ultimately saving money.
But is he?
Stewie is no fool, but he’s simply not in Brian’s class. He struggles trying to make logical inferences. He doesn’t have the same tools in his bag as Brian. Stewie is unaware of existing frameworks that mitigate project risk and allow for smoother transitions, such as MIKE20.
Against this backdrop, it ultimately takes Stewie about six months to complete the project. He bills Griffin for 1,000 hours of his time. Brian could have performed the work in half that time. Consider the following TCOs of each:
- Brian’s TCO is $62,500 (500 hours * $125/hr)
- Stewie’s TCO is $90,000 (1,00 hours * $90/hr)
Also consider potential travel expenses and the fact that Stewie needed to engage Griffin employees for three extra months, taking them away from their day jobs. Also, what about the issues that Brian would have found?
Look, money matters in any economy, much less this one. There’s always a temptation for organizations to make do with “adequate” resources. Sometimes paying more on an hourly basis results in a lower TCO; highly-skilled resources often more than justify their premiums. Don’t dismiss resources simply because they initially appear to be too expensive in the near-term. Ask yourself if actually they’re cheaper in the long-term.
As I continue to familiarize myself with the The MIKE2.0 Framework, one thing has become entirely apparent to me: it’s based in large part on having the right resources at the right time. In this very important sense, the MIKE2.0 Framework is the same as any other methodology for implementing new systems. In a new series of post, I’ll discuss some of the biggest mistakes that organizations make during information management projects (IM). In this post, I’ll cover timing as it relates to allocating resources.
Hurry Up and Wait
When I’m not writing, speaking, or chasing down tennis or golf balls, I’m typically on a consulting project. Like many people, I’m a hired gun available on a first-come, first-served basis. While there are certainly exceptions, most large organizations tend to struggle locking people like me down.
Consider the following example. Back in early June of this year, a firm for which I regularly subcontract (call it BU2B here) recently submitted me for a one year project for a large new system implementation. I didn’t hear anything for two months and assumed that either the project never started or that I wasn’t chosen. C’est la vie, right?
Fast forward to August 17th. I get a call from a recruiter at BU2B that its client needs to talk to me–today. Forget the fact that I am on site, billing my current client. BU2B tells me that this call has to happen today. I explain that that’s just not possible but that I’ll be free on the 18th for pretty much the entire day. Long story short: it has to be the 17th, even at night. Unable to make a firm commitment with a “burning plank” deadline, I have to pass.
Of course, this begs the questions:
- Why wait two months to find key resources for such an important project?
- What was going to be decided at 8:30 pm on Tuesday that couldn’t be decided at 8:30 am on Wednesday?
- Why would an organization wait two months and then give a candidate two hours? Does this seem reasonable?
- Does an organization really think that it’s getting the right or best resource with such a tight time line?
- If this is the way that this company operates, would I really want to get on a plane every week and go there?
Trust me. This isn’t sour grapes talking. I’m very comfortable with rejection, especially since I went to a 70 percent male college. But does this story sound familiar?
Don’t wait until the last minute to find consultants and contractors, particularly as your project approaches key dates. Follow these guidelines and you can maximize the chance of a smooth transition and minimize the chance of scurrying at the last moment:
- Let everyone know well ahead of time when projects are supposed to begin
- Lock down resources well before those key dates
- Identify backups just in case stuff happens
- If an extension is necessary for an existing resource, attempt to arrange this as early as possible. Don’t wait until Friday morning to see if a key person is available on Monday.
- By all means, don’t complain when that resource has found another gig
TODAY: Mon, April 24, 2017April2017