cazh1: on Business, Information, and Technology

Often, when trying to figure out how to "make things happen", your focus switches between multiple targets. What am I doing? Why am I doing this? And How can I get the others to understand what I am doing? Real change happens along a continuum that stretches from The Big Idea to Real Results, and people / organizations that want to make real change happen need to understand the different elements along the way.

Yes, I know - earlier, I suggested that one should pick a specific area (people, process, or technology) to develop real skills in. Still true, but what about those who aspire to leadership, who want to make change happen across the organization? A single person doesn't need to be expert in each of these areas - but leaders should actively work in all of them. Aspire to be a jack of all trades, a master of none; the ability to develop a vision, communicate it with impact, build something actionable, and follow through with the implementation are bankable skills that effective, impactful leaders need.

For each of these "elements", think of about their definition - but also think of them in context with the other elements of the continuum. A leader with an impractical vision is just a dreamer; breakthrough science that is not well communicated will just sit on the shelf.

Inspiration

Defined: The ability to imagine what is possible (aka Vision). This doesn't have to be something as earth-shattering as Avatar or the next iPad - businesses are crying out for "innovation" (sorry for the buzzword) in areas as mundane as cost controls, Lean, and revenue growth. Make no small plans, but have the courage and the energy to stretch. Recognize the organization's practical limits - but don't sell them short, they might surprise themselves (and you!) 

In Context: There is a fine line between imagination and inspiration; we need something that can be implemented in our lifetime. Flights of fancy can broaden your horizons, but you must eventually deliver real business results. This is where you can enable acceptance of the 80/20 rule - a practical vision that sees when enough is enough, that knows when to trim down the requirements to get 80% of the value with only 20% of the effort.

Art

Defined: Change often involves ideas, processes, or relationships that are difficult to understand, simply because they involve remixing the As-is with Something New, to create the Could Be. Sometimes it involves visualization - understanding a new structure, a changed process flow, or a hidden trend in the numbers. Sometimes it involves vocalization - an explanation or observation that needs just the right written or spoken words to trigger understanding and acceptance.

In Context: As goods and services are commoditized, and descriptive data becomes freely available in deep detail, the value and importance of design continues to grow. Well designed and executed words, pictures, sounds, thoughts, and ideas are the competitive differentiators that businesses always look for. Great leaders may possess acute verbal and/or visual communication skills, but don't discount your abilities or overestimate the pizazz required to make change happen in your organization. Just invest time on a regular basis, thinking about the design of things you see and hear every day. What images capture you eyes and your imagination? How do some texts convey meaning without boring you to tears?

Science

Defined: Sooner or later, you will have to create something that doesn't exist - a new tool, a simplified process, an effective data visualization, a useful report. This will always involve some specific "science" - knowledge of a programming language, a drawing tool, a data query, a report writer. At one point or another, sustainable change must manifest itself as a repeatable, measurable process or event - and sooner or later, you have to be able to translate your hand-waving to something that actually works.

In Context: Inspirational ideas need to find their way to the screen or the printed page, so they can be communicated, and communicated again. The best design ideas need to manifest in the final product. And the best ideas must bridge from the tip of the pencil to something (a program? a web site? a document? a project plan?) that can be executed. The best leaders can still summon hands-on skills when needed; if you are in IT, have you built something interesting in the past few months?

Execution

Defined: The classic "rubber hits the road" - results derive from making something happen. This could be the execution of a process, but can also refer to the coordinated steps in a project plan that implements a new system, or establishing rules, structure, and predictability where previously there was random action. Science has created something, now it's time to get it implemented - and, to make sure the promised results are delivered.

In Context: Starting a new process, stopping an old process, and bringing structure where there is disorder are the typical end results of most business projects, the ways that enterprises create value. However, inertia and entropy are powerful natural forces, and blasting through resistance (this is the way we've always done it ...)  often relies on a strong idea, communicated effectively and designed efficiently.

Master of None

I think the toughest challenge for some entrepreneurs is to know when to call for assistance. There is value in knowing everything about a single area (the biggest vision! the best programmer!), but sustainable success often comes to those who know when to call in the experts. The best business results scale across multiple people, teams, locations, business units, processes ... so why shouldn't the best leaders scale across multiple resources?

Never stop learning, never stop improving your skills in all of these areas - but know when to bring in the experts to see results that surpass your expectations.

Previously ...

• News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• Technical Debt and the Cost/Benefit of Knowledge Retention (July 27, 2009)
• Collaboration "in the Wild": Some Observations (November 15, 2009)
• Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)
• Managing Change: Pick Something, and Do It Well (February 14, 2010)

Technorati Tags: change management, design, development, documentation, innovation

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

This is the first in an series of posts on Managing Change ... look for more over the course of the next few weeks ...

A common way of expressing the wholistic nature of a project is to talk about "People, Process, and Technology". I'm not sure who came up with this little gem, or in what context, but I've been hearing it a lot lately. No particular reason, I think, just that it seems to be gaining a bit of status as a second-tier buzzword or something.

I've noticed, however, that people seem very comfortable talking about People, Process, and Technology in the As-Is or To-Be states - but precious little time is spent about the difficulties in getting Change to happen in any of these areas. Project teams and project leaders need to be effective at making Change happen with People, Process, and Technology; maintaining the status quo is comfortable, and envisioning the "nirvana" Future State is easy, but the real challenge comes in making the transition from A to B.

Project teams need people that have Change skills:

• People Change - Soft skills and Emotional Intelligence are typically required, but effective team leaders need to be able to command a room of strong personalites and competing agendas. Some meeting facilitators are direct, and can shout folks down and/or eloquently shift the group's understanding. Others work indirectly, creating understanding and acceptance in non-threatening, semi-private conversations.
• Process Change - It's easy to say "automate a mess, and you get an automated mess", but the challenges of process redesign are known to many folks. A certain amount of patience and insight is required to ferret out muda (waste) in the process, to understand and identify the critical elements / tasks, and to aggressively involve the eventual process owners, cementing their commitment for implementation by making them part of the design.
• Technology Change - Typically the easiest (and preferred) work area for IT folks, but for those who want to make a difference in IT, it takes the ability to understand and implement new technologies quickly, in a sustainable and supportable fashion. Points are taken off for quickly implementing a fragile system.

WIIFM?

Looking for ways to create concrete objectives for yourself or your teams? The significant Value Add that projects and project teams bring to organizations covers all three areas - People Change, Process Change, and Technology Change. Improvement and effectiveness doesn't come from raw skills in People, Process, or Technology, but a demonstrated ability to make Change happen in any and all of these three areas.

The opportunity, of course, is to pick one or two of these areas, and build your skills in making Change happen. If you aren't good in front of a group of people, and are more comfortable working directly with the technology, work on your Change skills by understanding new developments and methods, and figuring out how to use that stuff to make projects and processes happen faster, with higher quality and more predictable outcomes. Looking for a stretch? Get into Process design and development; it's not always about the bits and bytes, but systems thinking is a big plus, and Process skills are often a great way to bridge from Technology to People skills.

Do you express your value to your team, and your value to the company, in terms of People, Process, and Technology skills? If you want to be successful in IT, work on demonstrating your value by making change happen in those areas. At the very least - be able to articulate how you have succeeded / can be effective at making Change happen.

Previously ...

• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Best Practices for Requirements Gathering Sessions (December 7, 2008)
• KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
• Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
• If I Told You a Fractal Solution, Could You Change the CEO's Mind? (December 6, 2009)
• Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: business value of IT, change management, innovation, people management, project management,

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

The short answer, as you know, is that it's impossible to tell you how to be insightful and imaginative in a single blog post. All I can do is point you in the general direction, and (hopefully) ignite a little spark.

What's the Goal? and, Where to Begin?

I previously talked about the growing calls for effective data visualizations; we have access to all this great information, and there are insights in there somewhere - but we need just the right point of view to rise above the cloud of data and see the real opportunity. It helps if you have experienced that rush of insight when looking at a particularly impactful graphic; not just a good looking slide, it calls out something important in a particularly effective way. Haven't we all watched that earnest TV lawyer pull the winning argument out of the blue [right before the final commercial break] and win the big case?

Of course, it's not enough just to want it - you have to have a little reverse-engineering in your soul. You need confidence & bravado (I can and should be able to create those killer pictures), hunger & curiosity (how did they do that?), and confidence to know that you can - with a little hacking. It also helps to have the blissful ignorance to assume that it's within your technical grasp.

Step 1: Find Someone who Knows - and Follow them Around!

I'm a big fan of the "follow him around" method for learning new technology - not classroom instruction, more like a series of specific examples of applied technology. I had seen plenty of examples of presentations that I thought were very effective, but I didn't understand what was happening, what exactly was making them so effective. I had to find someone that could talk about putting together effective presentations - and had the good fortune to attend a seminar by Edward Tufte. Sure, you get some nice books, great to page through - but like most technical manuals, they don't really make sense until you've watched Tufte deconstruct the graphics. I learned the importance of taking extraneous ink off the page, and how scale, color and shape can illustrate and/or obfuscate. I didn't walk away from that experience with specific skills as much as clarified ideas - and a hunger and curiosity for more.

Step 2: Find Lots of Examples - and Steal some Inspiration!

Over the past few months, I've been following a number of blogs dedicated to ideas around information visualization - more skilled practitioners to follow around! The links below to take you to particularly interesting examples; your task is to subscribe to them all and regularly scan for ideas ...

Information is Beautiful

• Great Visualizers: Mike Deal charts The Beatles - I don't know exactly what that graphic is that shows the keys of Beatles tunes, but it looks cool - I want to figure out what it's showing, and how to build one

Cool Infographics

• The Caffeine Poster, How Much Caffeine Are You Drinking? Made all the more interesting by this follow-on post, The Making of The Caffeine Poster
• 16 Infographic Resumes, A Visual Trend Resumes done in graphics? Well, maybe not for me, but these are great examples of packing a lot of information in a small area - and, making the message stand out in the crowd!
• Pink Floyd Timeline of Band Members
  

Flowing Data

• 11 Ways to Visualize Changes Over Time – A Guide It's not always about examples of applied data visualization - there are plenty of mini-tutorials gettin published, like this one
  

EagerEyes.org

• Understanding Pie Charts Another techniques post, this one deconstructing peie charts. I never knew why I wasn't a big fan of the pie, but this article points out a lot of stuff that's pretty obvious (now that you mention it ...)
  

Chart Porn

• Haiti This blog is just a non-stop source of interesting examples
  

New York Times

• Another common source of terrific information visualizations is the New York Times - many folks blog about the most effective examples, even our friends at Ask ET
  

Step 3: Get Your Coding Hands Dirty!

Remember, after you are done being wowed by the presentation - figure out how you could build one.

• The old stalwart Excel comes with an ever growing list of graph types. Can't find the one you want? Try to hack at the standard stuff using VBA!
• Sometimes a blog post will point you to some utilities. No, I never heard of Gource, but you can bet I'm looking for a project to use it with!
• Open source has a lot of interesting tools out there - from jQuery addins to full-blown BI suites - lots of tools to load up with your data.
  

Remember - get inspired, find some starting points, and get building! the only way to really understand how to create insightful, impactful visualizations is to do a lot of experimentation.

Previously ...

• Stretching Your User Interface Design Muscles (April 16, 2008)
• Data Visualization: 'Life' of Open Source Projects (June 16, 2008)
• Another Take on Enterprise Open Source (February 18, 2009)
• Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)
• A Company is like a Sphere (September 15, 2009)
• Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: data visualization, design, development, hands on, innovation, presentations

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

Between business requests and breathless vendors, I am getting caught up in the growing tide of interest in "data visualizations" - managers requesting highly interactive, highly graphical, highly intuitive analytics interfaces (think Minority Report). But what are we trying to accomplish here? We keep on hearing about "executive dashboards", a heads-up display of in-my-face KPIs, or statistics and exceptions delivered automatically to my e-mail and/or Blackberry. However, when I ask management folks to get a bit more specific - how would you actually use this information? Is there an interest in doing the drill down, the click through, the hand waving? Not so much - basically, I've heard that folks are satisfied with what they have (ex. daily sales reports or customer service metrics), and are not necessarily interested in micromanaging through their staffs (by drilling down through graphical views on their desktop).

The real interest is in giving the right "stuff" to middle management and team leaders ...

1. Data Sets - access to transactional data in enough detail to permit mixing, matching, slicing, and dicing, to identify and target hidden opportunities for business value (growth and/or savings)
2. Data Access Tools that provides fast and flexible manipulation of the figures
3. New and different Data Visualizations to enable insight and help target opportunities

... and we can iterate on these already:

• The first item - access to data - is getting easier over time. Projects like data warehousing and ERP implementations have taught companies the value of clean transaction data and correct & complete master data. We are also expanding the number of folks that know how to do basic query and extract operations, from all sorts of transaction systems (on premise and in the cloud), into data sets that can be manipulated off-line.
• Next - most folks can and should be happy with Excel and pivot tables - especially with the improvements in Office 2007 and beyond. It's becoming easier to specify filters, cross tabs, and aggregate operations, and Excel can also handle reasonably large data sets - tens of thousands of rows.

We are certainly not "finished" with #1 and #2 - still plenty of work to do in terms of data cleansing, data access and basic manipulation. However, the biggest opportunities for improvement in 2010 are in the area of visualizations - new and different ways to display multidimensional data.

Here's a simple example of profitability analysis using a visualization that is not available in Excel:

Click on the picture for a full-size image!

This type of graph is called a tree map or heat map. It's a basic query - show gross sales by customer for a number of product families, but this clever picture shows a number of things in a two dimensional view:

• Area in the graph represents sales - represented in dollars
• White borders denote product families - like Cookies, Diet Snacks, and Organic Food
• Red borders carve out specific customers
• Color represents degree of profitability - the most profitable are bright green, and the least profitable are bright red.

With a quick explanation of what you are looking at, targets of opportunity jump out at you - go for the big red boxes (like C) to cut the non-profitable stuff, or the really green boxes (like A) to sell more of the really profitable stuff. You can also get a bit more imaginative, looking for the right blend of size and shade to find customers "on the edge" of going really green (how can we make B as green as their neighbor, A)?

Creating Opportunities for Insight - Playing with Visualizations

To really get at #3, we may need better tools, but we also need some new and different communication design ideas. What types of data visualization are possible, given the dimensions of the data we have? Which visualizations might lead to some interesting insights? Or, take the opposite view - given a particular data set, what truths are in there, and how might we draw a picture of that (to clearly illustrate these truths for the interested observer)?

Clearly, there is no cookbook approach to something like this. It takes a certain amount of insight and imagination, and that is a critical skill combination that most IT departments, by nature, simply do not have. IT and Finance are two areas where structure and process typically trump design sensibilities.

No, I'm not saying that there is no artistic ability anywhere in IT; it just doesn't come out very often as we labor away on our project deliverables. As previously noted, corporate IT is typically not rewarded for design - just results (done = good, "good" = meh).

I don't think that the business is asking for fancy tools as much as creativity and new ideas for ways to represent business questions and answers. Instead of the same old bar charts and tables of color-coded numbers - is there a better way to visualize this data to facilitate insights?

Next … sources of inspiration ...

Previously ...

• Stretching Your User Interface Design Muscles (April 16, 2008)
• There ain't much IT in IT Management (May 7, 2008)
• Data Visualization: 'Life' of Open Source Projects (June 16, 2008)
• Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
• Hacking the Google Chart API from Excel (January 17, 2009)
• Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)
• Who owns Master Data in your company? (May 30, 2009)

Technorati Tags: data visualization, innovation, presentations

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

I've been working with internal developers over the past few weeks, experimenting with a treemap / heatmap-style visualization that is quite interesting / insightful when loaded up with data, but very tough to configure and manipulate. We are also struggling with a presentation layer (surrounding this data control) that doesn’t adapt to the size of your browser screen, or behave well when placed inside a frame set or table.

I suspect our primary challenge - typical thinking for most corporate IT departments - is that we only work with the tool we know. The only way to display information in a browser from XYZ's data warehouse is to use their particular Web portal platform. We need to switch focus; let the data warehouse provide beautifully aggregated and accessible data, but go elsewhere for the presentation layer.

Corporate IT needs to develop a sense of adventure, a thirst for new and different ways of doing the same thing, and a curiosity about different presentation architectures (ie. there's more than one way to skin a cat). Manufacture some spare time, and get down to some serious "play", with CSS, HTML, and SharePoint (as previously noted, our target intranet platform); learn all you can about the level of control you have. Note that you probably have more flexibility than you think … but now we're playing with JavaScript, VBScript, or any number of client-side technologies.

Unfortunately, we all seem to get to the same creativity-killing question: "how do I charge my time?". Full disclosure: I'm a big fan of the timesheets and reasonable chargeback systems, quantifying IT alignment with the business - but therein lies the subtle yet significant difference with "the IT guys" and the iPhone / iPod / Kindle / Nintendo / Best Buy expectations of our business partners.

Rewarding Different Behaviors

Corporate IT is measured by and rewarded for projects - specifically, getting things done. In most organizations, that's where it ends; IT is usually not rewarded based on the ongoing use of the project deliverables; in fact, ongoing support ("maintenance") is expected ... a cost of doing business ... overhead ... part of baseline costs ... and, in a manner of speaking: free (no premium is paid).

It’s the exact opposite on the Internet and consumer IT; you are expected to build the stuff for free, and just give it away. You will get your rewards when people come to your website, click on your ads, buy your products, become sales leads. You’re rewarded after the build is complete – but (if you are good), you are rewarded over and over again.

• Corporate IT – metrics for success stop when the project is complete
• Consumer IT – metrics for success start when the development work is done

This also helps explain why Consumer IT delivers "stuff" that people like, that is intuitive, easy to use, and just works. Witness the apple iStore – developers earn cash only when they sell their apps, long after the build is complete. But it's not as simple as that - note that even though there are a huge number of apps out there, less than 5% are big successes (>100,000 users). Competition and market dynamics drive quality and innovative, creativity is rewarded when an app rises above the fray. Check out the disturbing collection below; how many different ways can you write the same, silly, popgun program? You'd be amazed ...



... yet five minutes of playing with each of these shooters, and you start to see the subtle variations and evolving methods that applications that get the most return visits.

Hope for Corporate IT - the Anti-PMO

The iGun story tells us about the darwinian action that comes with large amounts of repetition, duplication, and failure. Success can be quantified by your failures - how many failed experiments have you thrown out there, just to see what sticks? On the internet, preferably a lot - because that’s how you learn what works, and how to make the “really cool stuff”.

Corporate IT might stand a chance in an environment where experimentation and failure is encouraged (but not necessarily rewarded - we need to learn from our mistakes). In essence, we need to build an anti-PMO and give permission for folks to do stuff that has no apparent value.

What will it take for you to facilitate a more creative environment? For more ideas on establishing an innovation environment, check out this old post ...

Previously ...

• The Innovation Generation and User Interfaces (April 9, 2008)
• Stretching Your User Interface Design Muscles (April 16, 2008)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Five Stages of Twitter Relevance (April 21, 2009)
• Failing Faster (June 14, 2009)
• Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: business value of IT, design, development, entrepreneur, innovation, PMO

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

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,