cazh1: on Business, Information, and Technology

This post started off as an excuse to experiment with Google Docs, and this really neat feature I discovered - embedding a spreadsheet in a web page as a sharing method. However, it struck me as a potential way to cost justify the time, effort, and expense of implementing collaboration systems with the Most Cynical Among Us.

We've all been in large meetings, with tens of people from the project team, along with the expensive consultants, sitting around a table listening to the project manager read their slides to us. The meetings always get scheduled for a full hour (it's the default in our calendaring system!), and everyone feels the need to speak, if only to make sure their voice has joined the chorus of agreement.

However, many of the Most Cynical Among Us have observed the large number of people in the room, and asked the question "How much is this meeting costing me?" It's a worthy exercise to go through ... so I whipped up a little spreadsheet model to quantify the hard and soft costs ...

It doesn't take long to play with the model and see the dollars add up; even if you don't believe in tracking "soft costs", the amount of time spent in meetings can get really big, really fast.

Are status update meetings inherently a waste of time? Absolutely not - communication is critical, and most organizations typically don't do enough of it. An exercise like this just puts the potential cost, in time and money, in real terms - and reminds us to focus on maximizing that investment.

Can this meeting be avoided? Collaboration platforms (blogs, intranets, etc.) let us update the team virtually; people can get the information when it's most convenient for them.

Are we communicating effectively? Sometimes, face to face communication is required and preferred - especially when you need to monitor how the message is being received in real time. Hence the broad focus on effective presentations and impactful communications ...

Look at the cost of your last meeting - did you get your money's worth?

PS: I welcome any suggestions for improvements to the model -  to request edit access or to get a copy, send email to jpmacl_docs@cazh1.com.

Previously ...

• Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
• Hidden Gold in Automating Recurring Processes (May 28, 2007)
• Communication is the responsibility of ... (August 19, 2007)
• Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
• RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: business value of IT, collaboration, hands on, people management, presentations, productivity, project management, Web 2.0,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

I've received input from ten companies so far - large and small, with all sorts of ERP systems. If you care to add some information, I'll thank you in advance, and add it (sufficiently anonymized) to the summary results document (download from here).

Here are some of the findings / observations from the summary ...

Master Data Domains

The types of Master Data called out included the usual suspects - Customers, Vendors, Finished Goods, Employees. Others mentioned include Metadata, Packaging / Tooling (components), and Indirect customers (like Payors in managed care, or Buying Groups in B2B). The primary systems in scope included SAP, Oracle, JDEdwards, and QAD, joined by an eclectic mix of legacy systems and point solutions. Secondary systems called out included Siebel, JDA/Manugistics, and ADP (payroll) - plus more legacy / home grown / departmental apps.

Master Data initiatives varied, based on where the "current pain" is - R&D / engineering, CRM / Customers / Contracts / Pricing, and Finished Goods / Logistics were named by different companies as their particular focus areas. Other important considerations were things like geography (North America vs. ROW), and business structure (Enterprise vs. business unit vs. local plant).

A significant determinant of how folks thought about this problem was how their ERP is implemented - in a fully integrated "enterprise" (Finance, Order Management, Supply Chain, etc.) - and/or how the instances are divided (all enterprise, by location (geography) or by business unit).

Note, however, that relatively few respondents are concerned with synchronizing data across multiple instances - a popular callout / feature of some MDM solutions. they will speak of "integration", but a focus of the conversations were all around quality and process, not synchronization.

An interesting frustration from some of the respondees; the ERP system(s) do not capture all of the required attributes for an item, so these additional details are kept in a separate, siloed system. Easy examples would be specific attributes (like shipping material specifications), but there were multiple instances where [so-called] Master Data is calculated with complex formulas / rationale, so an Excel component is required (typically in the area of pricing / quoting details).


Size & Scope of Master Data

Predictably, there was a great variation in the responses - 100s to 1000s of customer, vendors, finished goods. However, the interesting trend was the notation that 10s of people (relatively large numbers, based on size of the company), were "responsible" (i.e. "did some of the data entry"). Could this be why there is interest in MDM and an MDM organization? Apparently, Master Data is often managed like a wiki - everybody is an editor.

Most organizations have no metrics in place; a few can speak to "data police", folks that actively monitor the data looking for issues. Best examples cited included "Health Check measures" (does data fit set of established guidelines / tolerances); vendor audits, and [results of] scrubbing (ex. Name And Address data against external sources).

When asked about the business benefits of a Master Data Management effort, most companies left this blank or said "none". I generally got the sense that hard benefits are difficult to quantify; notable exceptions seem to come from past pain. Some organizations spoke to inventory reductions and transportation savings - both derived from more accurate supply chain data, which is facilitated by clean, consistent, complete Master Data.

Master Data in the Organization

Many companies keep control / accountability at the functional area. However, companies with "enterprise ERP" implementations (full integration of Finance, Order Management, Supply Chain) typically call out ownership at the Enterprise level. It's not about the size of the company or the recency of their implementation - it's the degree of integration within the primary ERP.

Organizational specifics were tougher to get at - depending on how the company managed their master data. Generally speaking, companies that manage Master Data at a functional level (Customer Service, Purchasing, Finance) have organizational clarity. However, folks that say they manage at the Enterprise level had the wispier definitions for Title and Accountability

Of note: centralized MDM teams rarely manage the bigger projects (implementations, acquisitions, or special projects with large MD components) - but they will (out of necessity) participate. None of the respondents look to these organizations / people for project management skills. However, there were some good callouts for the communication / change management skills required for the role, especially where the group has to review implications of adds / updates [of Master Data items] with multiple groups that will/may be impacted.

Scope of Responsibilities

An interesting, consistent set of answers in this area; "Yes, we take ownership and accountability - but no, we can't measure it". To be fair, not all companies had that clarity of ownership, but the lack of sharp, clear quality metrics is noticeable. Content, Quality, and Governance are consistent in all of these companies … consistently not-well defined, not well measured.

Positives & Challenges

Funny how best practices in one company are challenges in another. There are two recurring themes throughout the responses; Quality and Complexity. The latter is interesting; this was the first point in the survey where the difficulties of Finished Goods Master Data were raised. Many companies call it out as a large challenge; all of them cite the complexity, the multiple facets (manufacturing, packaging, warehousing, transportation, pricing, costing) and the cross-functional nature

Full Results

The summary results document is available for download from here; I will add a version date on the page and keep it up to date as additional surveys come in.

Questions? Comments? Suggestions? Let me know ...

Previously ...

• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• Five More Realities for Driving Business Value from Technology (January 30, 2008)
• Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• Who owns Master Data in your company? (May 30, 2009)
• Bootstrap Market Research: Master Data Management (What, Who, How) (November 30, 2009)

Technorati Tags: best practice, collaboration, CRM, documentation, ERP, hands on, Knowledge Management, SAP, supply chain, tech management, wiki

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

As the new year approaches, debates over the "value" of IT and business projects intensify; it's not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I'm hearing more about the struggle to quantify business value, especially when selecting those few projects that will "make the cut". We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don't scoff  - it is possible - more in a later post ...)

However, I think there's an interesting vision in some people's minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately -  as long as they all have business values assigned.

I don't think assigning a value to every proposal is realistic, and certainly not something to aspire to - well, not directly anyway. There are a number of significant hurdles to deal with - the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn't think it up on their own (ie. close the patent office, we're done).

Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas - how could anyone to claim the ability (or the time!) to rank such a list from "best" to "worst" (or, since I don't propose projects are bad to begin with - "most best" to "least best")? Truth is, they don't - most of the business leaders I've worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?

Rules of Thumb

Most people have a favorite way of eating their elephants. Yes, one bite at a time - but where to start? How to carve?

Deliver Small, Iterate, and Evolve: The agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.

Focus on the Big Rocks:  The biggest and toughest problems - or the projects with the most benefit - are sometimes so daunting that they intimidate us into dealing with "the easy stuff". Clear your calendar and tackle these larger opportunities first, else you'll never get to them.

Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people - in key positions, with monopoly knowledge. Simplify things by prioritizing their projects first - but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.

Practical Problem Solving

As I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It's important to understand the fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are juggling) is roughly the same. The sooner you can put yourself in the other person's shoes, and speak to them at the level of detail they (not you) need - the more effective your conversations will be.

Besides, they're paying you to solve problems, not define them.

Previously ...

• Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
• Innovation That Matters - Substance Over Style (January 12, 2008)
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• The Innovation Generation - Communication Styles (April 1, 2008)
• IT and the Business are Closer Than You Think (June 28, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• A Plea for Empathetic Communication (November 16, 2008)

Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

I think this is one of those fundamental concepts that, once it is pointed out to me, become self-evident and obvious (ie. why didn't I think of that). I'm curious if other people agree ...

I've seen these principles illustrated in different areas of business and technology; understanding this relationship can relieve frustration and provide hints on where to focus your efforts when working on a project.

Simple is Difficult

Simple Idea: My favorite example is the phenomenon of "smart part numbers", where organizations find it convenient to encode attributes about a product in the item / SKU number. This makes it easy for people to read labels and reports, find parts in the warehouse, and work with line items on an order. Unfortunately, implementing systems & processes that rely on "smart part numbers" can be problematic; reports and queries rely on multiple pieces of information embedded in a single field / column; SQL queries are tough to write, and reports & other programs become notoriously difficult to maintain.

"Lean" Process: Somewhat related is the phenomenon where business processes are rarely documented. Everyone in the group knows how to start with the Order, through Make-to-Ship, and back to the Cash. The problem usually hits when we experience turnover or some other staff change; our well-oiled machine starts to slip up, and performance gaps appear as the new team member doesn't fully understand know or understand everything that is required / assumed of them.

User Friendly: I've written before about documentation that insists on screen prints for every step of a process. I can empathize with the end-user on this; this level of hand-holding is extremely helpful, because it makes it easier to learn a new system or technique. Unfortunately, documentation at this depth is expensive and time-consuming to create & maintain - and is typically done best by folks whose primary job is documentation / communication (ie. not the folks who are asked to create this stuff).

Simple to Use; "Elegant": There is a related demand for software and websites that are easy to use, truly user-friendly and possessing intuitively obvious interfaces that everyone can just run with. These don't require complicated manuals, but they do require an awful lot of skillful programming to deliver such use and simplicity. I am working on a simple, small Web application (more on that later ...), where I'm trying to develop something that will elegantly solve a specific problem, yet be truly intuitive and obvious (dare I say fun?) to use. The challenge, however, is cross-browser compatibility; in the past few evenings, I've discovered some amazingly intricate problems with how CSS and PNG works with the Microsoft browsers - and have had to go to extraordinary lengths to make the website look the same on Firefox, Safari and Internet Explorer.

Difficult is Simple

The reverse argument can be behavioral and cynical; "time is money" drives some to oversimplify. However, "agile" design and development can be a practical tool when trying to maximize sustainable output.

Difficult Idea: I think the time-and attention-starved workday contributes to an unfortunate amount of oversimplification. If there is a complex project or difficult issue to deal with, get ready for the unending stream of peers, partners, subordinates, and "higher-ups" asking about status and root cause. Unfortunately, these people have limited time available to waste on active listening and understanding; typically, they will demand a short summary. They just want to know that the problem is in hand and getting handled.

Rapid Development: McConnell notwithstanding, some teams use "rapid development" as a convenient shorthand for "quick-and-dirty programming that relies on hard coding, flimsy structure, and a lack of testing".

• With some extra work, reusable logic can be modularized, interfaces can be abstracted, and simplistic, utility programs can be replaced with flexible, fault tolerant modules that can be reused and extended. This particular brand of good cooking takes time, and a bit of design foresight.

Hard to Use; Hard to Understand:  Of course, if you focus on Time to Completion, driving to get stuff done, focusing on deadlines over quality, it's not surprising that systems and processes are hard to use, and communication pieces are difficult to understand. As an old Army officer once told me, "if you want it bad, you get it bad".

IT's Challenge - Fighting the Good Fight

Of course, the "good cooking takes time" argument typically doesn't go over well with most businesses. The pressure on IT, really any business area, is to learn the local tools and techniques, and leverage work that has been already done. In addition, there has to be some points awarded for systems that don't require help desk support, processes that don't require handholding, and follow-up training in the weeks after go live.

Communication with management and the business is just as critical, just as difficult and just as rewarding when you get it right. Your counterparts in the business aren't dense - they just need things explained glibly yet completely. Master this, and Le monde est votre huître.

Previously ...

• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Best Practices for Process Documentation: Iterations (2 of 3) (September 17, 2008)
• Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• The Delicate Art of Pushing Back (July 5, 2009)

Technorati Tags: best practice, business value of IT, documentation, presentations

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

The topic was training users for an upcoming project rollout, and the debate (as always) roamed back and forth between "traditional" (classroom training, scripts & workbooks) versus "experiential", pairing existing users with their counterparts (who are new to the system), walking through the basics (screen navigation, terminology, and step-by-step instructions for the most common required tasks). Training methods are a common area of debate and discussion with system implementation folks, and I can make a great case for any and all sides.

Task Oriented

(This is where I adopt my Pat Buttram voice) I remember back in the day ... we had "green screens", text-based terminals running applications that flowed like the languages they were written in; procedural, top-down, ordered and neat. There was only one path through each process ("This is the way you set up a vendor and cut them a check ... This is the way you set up a lease and charge the rents ... "). The training material was also very orderly - each step of the process was lovingly detailed, keystroke for keystroke. For more aggressively user-friendly documentation / training material, authors included a screen print for every step of the way.

Documentation Lament Part 1 - I typically take issue with folks who insist on a large number of screen prints. Yes, it appears user-friendly, but it's brutally difficult to keep a document like this up-to date and relevant. Even in the green screen days, we saw basic changes to the application that altered the screen's appearance. Since we're providing these images to provide users comfortable reassurance that what they see is what they are supposed to get, each change means a complete reshoot of all the affected screens. More trees die as page inserts and updates are distributed - and electronic distribution is not much simpler, as the document files are quite large, with chunky .BMP inserts that presented a challenge to all of those floppy-enabled sneakernets (back in the day).

High Concept

I remember when my kids were in their early grade school years; I was impressed to learn that some of the first math classes that they took were all about pattern recognition. Brilliant, I thought - that's the best way to learn how to work with the gooey (graphical user interface, or GUI) applications that were supplanting the chewy (character-based user interface, or CHUI) apps from the old days.

As computers became more powerful, programmers built apps to take on event-driven, flexible format tasks that matched the environments they were implemented on. Sure, there were wizards to take you through some basic operations, but when you're typing a document, manipulating artwork, or laying out your spreadsheet, there's no start-to-finish process - you are "creating". Training for this software is not about step-by-step processes, but complex operations built with common component tasks. The Microsoft Office suite taught us all that there are certain patterns to modern software (ribbon notwithstanding) - all menu bars were populated with the same basic component tasks. Top left always had File Open / Close, Edit Cut / Paste - and Help can always be found at the rightmost position of your menu bar.

The challenge, of course, is that not all people excel (so to speak) at conceptual learning. Us old folks grew up memorizing multiplication tables, and we've built our careers on a certain facility (based on familiarity) with the step-by-step.

Documentation Lament Part 2 -  The practical document author should see to flexibility and fluidity of GUI applications as a valid reason to forgo the screen prints. There is so much variability to what is presented on the screen - especially when the latest stuff allows you to customize the appearance of menu bars and other options. Alas, the well-meaning training teams still insist on copious screen prints that are even more likely to differ from what the user sees on their screen. Why can't everybody just adopt Microsoft's online help style? The vast majority of it is text based - no screen prints, menu options described with subtly layered in-line constructs like File, Open. Elegant simplicity, and much easier to maintain.

Follow That Guy Around

Of course, the most common training method of all is the modern apprenticeship - follow someone around that knows what they are doing. For companies of all sizes, it still amazes me how many important processes are not documented. Some might claim they are forced into this modus operandi by expedience and/or a slimmed down the workforce; I think it's just human nature. It's hard to get people to effectively document how they do what they do.

Don't get me wrong - I freely admit my preference for this approach, especially when it comes to new programming languages. I can read a technical manual with the best of them, but I do like to have at least one sitdown with an experienced programmer, watching over the shoulder as they take me through the development cycle (edit, compile, debug, run). Just show me on the screen how it works; once I can do my first practical [hello world()], I can grab the book, refine my skills, and catch up on the theory.

Good, Bad ... I'm the guy with the gun

Truly, there is no right or wrong answer here. Different people learn things differently; some react better to the spoken word, other prefer the printed, and some folks need to have step-by-step instructions laid out for them. Note that I purposely do not suggest that procedural versus object-oriented learning is a generational thing; I know plenty of old folks that do just fine with the object-oriented, creative, free-form, self-directed style of learning.

The key is that trainer / communicators must be facile in many different methods, and quick to understand which method will work best for your target audience.

Previously ...

• Sometimes analogies work amazingly well ... (July 14, 2005)
• Of course we can pay for that ... if it makes business sense (November 7, 2005)
• Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
• Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
• Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
• Stretching Your User Interface Design Muscles (April 16, 2008)

Technorati Tags: documentation, hands on, Knowledge Management

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,