cazh1: on Business, Information, and Technology

When someone asks my opinion on their writing, I'll get fairly detailed; I've noted in the past that there is a lot of power and influence in the written word, and it's fairly important to get it done well, or your project proposals just never seem to get off the ground.

This particular proposal suffered from a lack of direction; it didn't take the reader (the decision maker) through a clear progression. Admittedly, the subject matter was a bit technical and mildly complex; even though this was a proposal for internal IT eyes, the prose didn't flow, and did not help the reader understand what we are asking for, and why.

I suggested that the subject matter - highly technical services - shouldn't impact the difficulty we were having in getting the basic idea across. A good way to validate the structure and effectiveness of a written proposal might be to show it to your high school or college-age children. The document should make a cogent argument that a reasonably intelligent person should be able to understand; it doesn't matter if they understand the technical specifics!

I saw Alice in Wonderland a few weekends ago, and noted that the plot takes a lot from Jabberwocky. Now, I'm not a "Carroll scholar" by any means; I recognized it, was even able to recite most of the lines - but I blame my high school English curriculum. It was [way] back in my sophomore year - we spent a week or so deconstructing the poem, and the teacher pointed out that you don't need to understand exactly what a jabberwocky is, or what a vorpal blade looks or sounds like - you can identify these foreign-sounding words and concepts (a Jabberwocky is a noun, vorpal is an adjective, and snicker-snak is an alliterative, sounds-like description) in context. You understand the story and the drama in the poem without completely understanding the specifics in the dialog, because it is a well constructed story.

The same goes for this technical proposal. This should be an effective writing piece made to educate; a business proposal, arguing for action or caution, must make an effective argument. The document's structure has much to do with the success or failure of the proposal - technical details are for a secondary, deep-dive pass, but the basic business argument should be apparent.



As a good common sense check for your writing effectiveness - run it past someone outside your team, someone with solid business sense but not necessarily a deep grasp of the details. There are many patterns for laying out persuasive arguments; learn them, before someone takes a vorpal blade to your next project plan.

Previously ...

• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
• Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
• Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
• Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
• Innovation That Matters - Substance Over Style (January 12, 2008)

Technorati Tags: documentation, marketing, PMO, project management

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

Spurred on by Blogger's decision to stop supporting FTP for publishing blogs, I have finally started the long process to implement a WordPress blog - hosted by myself, not Wordpress.com. To be fair, I am making this longer than it necessarily needs to be, but I am continuing my efforts to maintain a comprehensive Admin guide for all of my development efforts - configuring servers, installing software, etc.

Needless to say, this adds overhead and time, but it's worth the effort. I have invested around 40 hours of effort over the past four years on the document (an indicator of how often I get back to my development projects). Still, it pays off every time, because I have a reasonably well-developed SDLC and publishing process implemented, and I need to make sure each new project follows established standards - and adds to the standards when necessary.

Enter MySQL and WordPress - since I will be hosting my own blog, I need a new and different flavor of Development, Test, and Production environments. No more dabbling - I need to tighten up security and document the installation and maintenance processes for the database.

Which is where I hit a wall, of sorts; I could not successfully change the root password on the MySQL database, kept on getting the UPDATE command denied to user ''@'localhost' for table 'user' message.

Hours of surfing, searching, starting and stopping, installing and reinstalling, to no avail. However, I had seen the AppArmor framework mentioned a few times, and had seen error and warning messages in the system logs that kept hinting at something in that direction. So I finally followed the advice noted in this thread, and disabled AppArmor during the MySQL installation process. A few notes:

• Use the Synaptic Package Manager utility to enable / disable AppArmor; I didn't want to throw the whole thing out, just needed to disable (Mark for Removal) and then Install (Mark for Installation), did not want to completely smoke it (Mark for Complete Removal).
• After disabling in Synaptic (Mark for Removal), ran the mysql_secure_installation script from the command line for the umpteenth time - but this time, the password change for root user worked.
• Rebooted the machine, and reinstalled (Mark for Installation) AppArmor in Synaptic.

A quick validation that I could use the MySQL graphical admin tools and phpMyAdmin, and I was back to getting the Dev instance of WordPress going.

Ah, but now I have to get ready for the work week, and time is ticking away ...

Previously ...

• Home Development Workstation - Part 3 (May 18, 2008)
• Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
• KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
• Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
• Hands-On Project: Offsite Strategy (November 22, 2009)

Technorati Tags: MySQL, WordPress, development, documentation, hands on, technology

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

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 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,