cazh1: on Business, Information, and Technology

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,

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

Some block-and-tackle IT management stuff for today - taking a long, hard look at the IT budget, a task that is less-than-pleasant for many. Most of my peers have already cut any and all low hanging fruit - it's time to start thinking aggressively.

Software Maintenance for the Small Stuff

Most have concentrated on their ERP and other large, strategic vendors - but what about all of those little invoices that come every year - development tools, management utilities, network monitors, etc. After a while, it really adds up - but too often, we look at the relatively small amounts and just approve the dollars without a thought. It may be time to gather up these little guys, and take a good, long look.

• Why pay for something that we rarely use? Typically, I have purchased perpetual rights to use a product, but I pay annually to keep on support. Why not let the support / maintenance lapse, but continue using the product (on the rare occasion I need to)?

• Even if I use the software a lot - why pay maintenance if I rarely call support? Does the vendor offer support on a time-and-materials basis? Don't dismiss this option out of hand - I find it difficult to believe that a vendor will turn down an opportunity to start hourly billings in the event that something significant goes wrong.
• Do I really need to pay support if I have scheduled a project in the near future to get it decommissioned? Just looking to realize the savings a bit earlier ...

Alternatives and Duplicates

Are there alternatives available that would cost less on an annual basis?

• Do I have any point-solutions that can be replaced by unused, duplicate functionality in my ERP system? Something to consider, especially if the solution was implemented a few years ago. Perhaps the R&D group from your ERP vendor caught up to their competition?
• Is third-party support available? Rimini Street is the classic ERP example - possibly some consulting firms will offer support for the more mature, niche-stuff in your portfolio?
• Of course, there is always open-source; no acquisition cost, and [typically] no annual maintenance.
• Are there applications in your portfolio with similar / duplicate functionality? This is common for even mid-sized shops, especially as time passes and those pesky vendor developers keep improving and extending their core products.

Compare your Risk Requirements with Reality

As much as we grouse about vendors, IT departments often mimic their behaviors, especially when justifying software maintenance and infrastructure redundancy based on FUD (Fear, Uncertainty, and Doubt). How often does this stuff really fail? How bad is the software, how loaded with bugs, that we simply must have access to (and faithfully apply) every patch?

I'm not looking for a storm of protest here - I have plenty of "war stories", just like you, of timely support calls that provided just the right patch, and untimely hardware failures that went unnoticed because of well-engineered failover. However, it's time to think aggressively, and re-examine / revalidate all of your assumptions.

• How about reducing our level of telecommunications failover – can we get cheaper / slower backup circuits? 
  
• Consider sharing backup servers between multiple applications - where the first failover application takes over, eliminating the second apps safety net.
• How often do my techs end up solving the problem for the vendor - how much value am I really getting, especially for the really mature stuff?

“Risk” is always powerful word, especially when dealing with a conservative management group. However, for this exercise we can’t just accept the powerful but un-valued justification of “risk mitigation” – we must quantify risk on an historical basis. For example - if we talk about dropping support for a software product, we can and should quantify how often we had to call up the vendor for support / help, or how many bugs we’ve fixed by applying a vendor patch.

Here's the most important idea; we should be able to draw a clear line between cost and quality (where, in this discussion, "quality" = "risk mitigation"). If we want this level of quality, we have to pay this much money. If we want to save money, can we accept a lower level of quality (or, a higher level of risk)?

I always go into budget reviews with the idea that the business is asking for a thoughtful discussion of tradeoffs, and not dictating targets (no matter what the memo specifically says!) More often than not, the Finance group or the General Manager is asking questions like "how can we save $X ?", or "what would it take to reduce by Y% ?". The cost vs. quality/risk tradeoff is something that can and should be a joint decision between IT and the business.

Previously ...

• Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• There ain't much IT in IT Management (May 7, 2008)
• IT and the Business are Closer Than You Think (June 28, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• The Delicate Art of Pushing Back (July 5, 2009)

Technorati Tags: business value of IT, IT management,

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

Where do these great analogy ideas come from? Full credit - I got this one from a speaker at the SAP Research Center in Palo Alto, last spring.

A company is like a sphere.

As it grows, volume increases much faster than surface area, and the large a company gets, way more people get embedded and hidden from the end customer than are on the fringe, in customer-facing roles.

As a general rule, this is a bad thing. Well, maybe a less-than-optimal thing - what percentage of your corporate attention span is customer-focused?

Our Challenge is to poke some pockets into the surface, and get more surface area exposed to the outside air.

• Will this help a company go farther? It seems to work for golf balls ...
• Will this make the company more human? Perhaps, in a self-fulfilling / reverse fractal kind of way ...
• Will rough edges generate incremental profit? Some counterintuitive friction ...

Previously ...

• Heisenburg KM (July 13, 2004)
• Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
• Misapplying the Pareto principle (January 7, 2006)
• Interesting How the Mind Works (October 1, 2007)
• Innovation That Matters - Substance Over Style (January 12, 2008)
• Failing Faster (June 14, 2009)

Technorati Tags: business value of IT, CRM, entrepreneur, innovation, Knowledge Management, marketing, people management, SAP, Social Networks, Web 2.0

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,

When I see / read articles like this, or hear the breathless claims of vendors, pundits, and True Believers, I'll privately chuckle to myself. All of this stuff - social networking, collaboration, and innovation - are 21st century takes on good old Knowledge Management (KM), circa 1998.

Do these sound like presentations from your recent Enterprise 2.0 conference?

• Managing Cultural Change to Create a Knowledge Sharing Environment
• Effectively Managing Information Overload in the Information Age
• Information Content and Security in Document Management Systems
• Using Technology and the Project Management Workbench to Accelerate Product Development Efforts
• Shifting the Burden of Knowledge Sharing to All Employees

I dug up an old copy of the proceedings from a KM conference from 1998; if I did a global replace on "Innovation" for "Knowledge", I could probably get a bunch of folks to sign up today!

Ok, a little sarcasm is fun, but once you realize the similarities, there are other parallels with 1990's KM efforts - not the least of which is the identification of business benefits. Anyone involved with projects back then can testify to the difficulty in predicting hard benefits - clearly quantifiable impact on top line or bottom line, derived in a predictable, measurable manner. Sorry, it just didn't work out that way for KM - and it won't for Social Networks, either! The hype cycle will prevail ...

Hard Benefits of Social Networks Do Not Exist, but ...

Why do people insist on expecting a hard business benefit from social networks, or a payback from a project to implement a funny-sounding technology (wiki/blog/tweet) inside the enterprise? Has anyone ever gotten a quantifiable business benefit from participating on Facebook, LinkedIn, mySpace?

Well, yes, actually - plenty of folks have connected with friends / colleagues, collaborated on business ideas, come up with innovative new approaches - actually monetized all the goofy sounding tools. I myself have written about successes, and have made connections I could never have anticipated. Heck, the old KM conference guide has a couple of case studies as well.

Ah, but do you see the pattern? Business benefits are not predictable, they are always opportunistic and anecdotal. Success is characterized by stories of the home runs (rarely accompanied by comparable stats on strikeouts, by the way). You can't implement a social network within a company or a group, and predict how much and when the profits / savings / growth with start rolling in. You are setting up an environment of opportunity - nothing more.

When I hear people talk about business value or business return of social networks as if they could predict it, I cringe. They're trying to apply financial controls on something that's governed by chance - you can't do it. The incorrect assumption is that you can control good luck - but you can tweak your chances.

Active networkers know - I'm talking about people that have been networking for years, when connections were made face to face. Career coaches would exhort us to get out there and build our professional network - make the office visits, get on their calendar, develop some connections. You have no idea what could happen from any one connection or conversation - nothing might happen or something might happen - you trying to make your own luck.

What is it they say, luck is 10% inspiration and 90% perspiration? Social networking is just automation for some of that 90%. And benefits will happen - just don't ask me when.

Previously ...

• RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
• Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Dueling Collaboration Portals (November 23, 2008)
• Practical Applications of Twitter in Manufacturing? (April 5, 2009)

Technorati Tags: business value of IT, collaboration, innovation, Knowledge Management, LinkedIn, Social Networks, twitter, Web 2.0, wiki

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

I'm already fielding internal (as well as external) questions about the application of Twitter in a manufacturing company, and I'm developing a reasonably good model, I think - one that will apply to the hard-core, salt-of-the-earth, manufacturing business leader that I've worked with at many organizations. This "maturity model" approach has been used before; back in December of 2008, Bhagarva sketched out the Five Stages of Twitter Acceptance - but that model only helps existing bloggers and social networkers understand this terse little idea spitter. Kind of like explaining OOP to a COBOL developer - I get the general idea of coding (communicating), but you've changed some of the basic rules like procedural vs. event handling (short and immediate vs. in depth and permanent). This doesn't help explain YACMTTCDFE (Yet Another Communication Method That They Can't Distinguish From Email) for those still struggling with Web 2.0 and Social Networks. If it doesn't arrive in their Outlook inbox, I'm still facing an uphill struggle getting them to understand the mechanism, let alone the concept. However, I'm getting a decent level of results when I draw parallels to concepts that these folks "grew up" with. The level of understanding and acceptance directly correlates to the level of relevance that the Twitterverse might have for their current information sharing needs. They typically ask ... How exactly do I understand Twitter and it's relevance to my work day?

1. Pointless: This has absolutely no value add, a complete waste of time - get back to work!
2. Cute: An interesting and different communication medium, but I gotta get back to work. Maybe over lunch ...
3. Web-Based Texting: Conversations about nothing in particular, but at least you're starting to connect. Not sure how it is better than IM, but some don't even use that ...
4. A Cocktail Party (or maybe the corner bar): Twitter is filled with cliques that are easy to eavesdrop / butt in on - a chance to develop your skills and awareness, and engage larger, targeted networks with pointed conversations about specific topics that I deal with every day. But no pressure, we're just hanging out ..
5. A Community: Like a trade group, guild, or local Chamber of Commerce, one that requires and rewards participation. At this highest level, Twitter is both a source and a use of awareness, knowledge and understanding; conversations are multi-directional, real business value is being generated.

I can illustrate these levels with examples from my favorite Twitter Search columns in my Tweetdeck (Search:SAP)

1. Do I really care if the sap is running this spring?
2. Funny, I get hits when people watch sap-py movies. Oh, those wacky homonyms ...
3. Twitter as a job board - every SAP job listing pops up. Wait, did I just see a trend tweet by?
4. Hmm, lots of interesting SAP practioners are talking about live projects and cutting edge programming work ...
5. Interesting conversations pop up when Oracle buys Sun, or SAP announces the latest product enhancements - I can get a near-real time pulse on market sentiment

I've piqued their interest, but now they want to know what "real business value" really means. I'll post on that next time ... stay tuned! Previously ...

• Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• I Think I'm Learning SAPanese ... (November 22, 2008)
• Back to the Future: Twitter "microblogging" (January 9, 2009)
• Zodiac of Knowledge Capture (January 15, 2009)
• Practical Applications of Twitter in Manufacturing? (April 5, 2009)

Technorati Tags: collaboration, hands on, innovation, Knowledge Management, SAP, Social Networks, supply chain, twitter, Web 2.0,

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

Over the past few weeks I've had a couple of interesting discussions about the introduction of Twitter to Manufacturing. When someone poses a question like this to me, it throws me for a minor loop, because for very basic, practical reasons, it just doesn't seem to apply. More keyboards & data entry on the floor? Not likely.

However, a few months ago I wrote this rather breathless item, expounding on a brainstorm regarding the use of YouTube and Twitter in a manufacturing setting. Back then, my summary point was about the value of alternative mechanisms for capturing and distributing process documentation. I noted that Twitter was less intimidating than other documentation tools - it's all about capturing status or best practices. But after the past few months of heavier use (@jpmacl), I typically explain Twitter as a keyboard-enhanced conversation - a "false path" for Lean aficionados if you are trying to capture knowledge (the Archaeopteryx of Manufacturing KM?)

But Twitter as an alternative communication medium for folks on the floor? I really don't think it's a good fit - and this is based on practical experience as well as a little common sense.

The Tweeter as Information Source

Are you trying to understand how Twitter would work in your environment? Don't think you can get it right without some decent hands-on time. You'll find that it's very intrusive - not something that you want on 100% of the time. For me, it makes sense when I'm catching up on notes for the day, clearing e-mails, scheduling meetings, or other lighter work that doesn't suffer greatly from periodic chirps from my Tweetdeck. It's running on the second monitor; every once in while I will glance over to scan the latest potentially valuable conversations to jump into.

This scenario would never work on the manufacturing floor. There's no way the Environmental Health & Safety folks will allow anything to distract folks from completing the tasks at their workstation.

Besides, hitting the keyboard for status updates is exactly the kind of non-value-adding data entry that Lean mavens are working to eliminate.  Note that when I say "non-value-adding", I am referring to Finished Goods; standard work, training and knowledge retention are important in a Lean world, but not while you're actually getting work done.

The Tweeter as Information Consumer

On the other hand, if there is a Tweetdeck-style application available, running on a screen that is visible to an entire workcenter - well, maybe the folks on the floor can be _consumers_ of Tweets. Then again, it's just another RSS application, nothing Twitter-specific.

Web 2.0 Technology and Manufacturing

Are manufacturing firms using Twitter? I'd say that few are - and it's based on the "personality" of a typical manufacturing company.

• IT is typically <3% of total revenue - not an environment that fosters experimentation / cutting edge IT work
• Lean is a growing force in manufacturing, and Lean is decidedly anti-computer - so no one will have a keyboard at the ready to start Tweeting!

Now, to be fair, you could cherry pick high-tech manufacturers; certainly, there are many engineering departments that are sharing information and communicating real time. But when I hear "manufacturing" I'm thinking line managers, shift supervisors ... not typically the keyboard types. They like their push-to-talk phones, and that's really all the instant communication they need.

Aren't there any potential benefits of Twitter for manufacturing? Directly - not much, I'm afraid. However, as with any area of the business that traffics in knowledge capital, the Design Engineering and Manufacturing Engineering folks might find benefit in information-sharing collaborative networks and "real-time" connections.

Note, however, that I am greatly interested in hearing counter-examples of the above. Anyone aware of interesting Twitter-ing on the floor?

Previously ...

• The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
• RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
• Opportunistic Insights from the RSS Stream (June 5, 2008)
• Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• The Power of Paper in Business Communications (October 22, 2008)
• Back to the Future: Twitter "microblogging" (January 9, 2009)

Technorati Tags: best practice, collaboration, hands on,
innovation, Knowledge Management, operations, productivity, supply chain, technology, twitter, Web 2.0,

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

We continue to iterate on our PMO processes - managing too few resources and too many project requests, an environment I have consistently seen in every IT group I have ever worked with. Our latest discussion concerned the concept of FIFO work on projects ...

... when presented with five things to do, I will only [emphasis added] work on them in the order received.

This is an exceedingly poor assumption for your personal run-rules, and a short-sighted objective for a PMO that needs to be aligned with the business.

You can't assume or aspire that your PMO can be a finite scheduler for IT. There is too much variability, softness, lack of clarity, process, etc. on most projects – especially at the Application Layer. Once you get anywhere close to business process and the fluid nature of business requirements, you have to have a strong element of agile, flexible resource scheduling and response.

<aside> One might say that the lower you go in the seven-layer stack, you have a better chance of finite scheduling this stuff – projects can and should be more highly predictable, highly engineered. </aside>

Another bit of the conversation uncovered an interesting insight; is there "too much" communication overhead? The effort involved to document something completely, to build a detailed work plan, to create a detailed, multi-line resource forecast – yes, these all represent large chunks of work that do little to make something happen on the screen / in the database. However, the value of such effort is quite high, because the results facilitate complicated conversations in the future. It’s just like the idea of capturing requirements early on – saves tons of rework later.

<aside> That last analogy begs a contrast to agile development - but agile values and requires focused communication and rapid iterations, which can be tough in an environment of thin resources and a high volume of "open" projects. Some elements of the classic waterfall are helpful when keeping multiple plates spinning. </aside>

A final quote - actually heard someone summarize the situation as "we just have a lot of slow projects". There are two important problems contained in that sentence - "a lot", and "slow". You have more control over quantity and duration than you may think ...

Previously ...

• End-around the Prioritization Process (August 14, 2004)
• Communicating Complex Technical Concepts (March 21, 2005)
• If you want to be more than a programmer, stop programming (April 8, 2005)
• Subdivide a huge project list to simplify the prioritization process (October 27, 2005)
• Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
• Driving to a Decision on your Projects (February 10, 2007)
• Thoughts on Why Tech Folks Need to Sweat the Administrivia Details (July 14, 2007)
• PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
• How to Cheat at the PMO Prioritization Game (December 14, 2007)
• How to Win at the PMO Prioritization Game (December 18, 2007)
• Tactics for Controlling Project Scope (January 5, 2008)
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
• Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)

Technorati Tags: business value of IT, documentation, PMO, project management, tech management

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

Today's best conversation was with Christopher Young, of B2BSX, a startup software exchange where corporate IT departments can buy and sell their development efforts, and make a little cash to offset stressed budgets. It's an interesting idea, and spawned some ideas in a couple of different directions.

Andy Hardy, IT Director

Every company I've worked for has toyed with the idea of selling some of their custom-developed stuff - well, every company except the first one, since it was a software development house (we weren't playing around). My "growing up" years as a developer have really jaded me on the idea of selling the deliverables from IT- or business-funded projects, typically for one simple reason - everyone underestimates technical support.

Operating systems change, DLL or JVM dependencies must be managed, and no one reads the manual - they all want support over the phone. Unfortunately, wide-eyed project sponsors or IT directors with dreams of P&L responsibility see COGS limited to the price of a CD, and revenues that match their ERP packages - it's not that simple.

Vertical Open Source

A solution, as presented by B2BSX, is to tweak the open source model a bit, offering source code for specific customizations, at low cost (well, much lower that building it yourself, I would assume). No long term warranties, no 1-800 support lines, you are on your own - but you are getting pre-built solutions that you can adapt into your own business, jump-starting your efforts with a basic shell, and adding your own refinements later.

I think of it as highly verticalized open source - sounds like they are limiting things to SAP right now, and I'd expect to see very specific solutions listed. By vertical, however, I'm thinking about reports / queries / wrappers that are very specific to a particular type of industry - the "long tail" of software niches, where most IT departments really do need to tweak that "collection of best practices" you were sold. I'm expecting to see stuff that is too specialized for a global software company to bother adding to their product.

<aside> Maybe the "long tail" of ERP requirements is where the untapped value is for those guys ... </aside>

Custom Often Means Really Custom

Of course, there are still predictable hurdles for this model - not the least of which is the fact that this stuff is written by corporate IT. Hey, most of us have short deadlines and long backlogs, and little experience developing flexible software architected for iteration and flexibility. "Hard Coding" stuff is an academic Bad Thing that is often required to git 'er done (yes, I went there ...). Chris characterized this as software with tentacles, reaching all over your portfolio and gripping on tight - makes it tough to pull out and wrap into a nice package.

There may also be IP concerns - something to work carefully through with your legal department. Note: don't think that Legal has little to offer here, because every company should have some concern about IP and competitive advantage, even if you are not in the software industry. You should be maintaining control of your software IP when you customize COTS or contract work out - now might be the time to leverage it!

We're All from Missouri

I have no idea yet whether this exchange idea makes sense - but it could be just the time to look into this. We're all under budget pressures, and Mr. Young tells me that once you get the basic relationship set up, putting software out there takes very little effort.

Maybe this is where the real future of ERP is going. What if our maintenance fees kept increasing, but the acquisition costs plummeted - all the money is in the add-on services? The Xerox model, where you give away the copiers and sell toner and paper? Gives a whole new meaning to the term "copy protection" ...

Previously ...

• Driving cost savings with packaged software vendors (February 23, 2005)
  
• What should "open source" really mean to me? (1/2) (October 22, 2005)
  
• What should "open source" really mean to me? (2/2) (October 24, 2005)
  
• Open Source as bargaining chip - driving business value of IT (October 30, 2005)
  
• Open Source Insights on Enterprise Software Business Models (March 14, 2007)
• Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
  

Technorati Tags:
business value of IT, design, development, entrepreneur, innovation,
SAP, tech management, technology,

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

a bit of code on a Saturday night ...

I've written before about a simple way to measure and report IT value to the business - quantifying alignment with strategic initiatives  project spend in context. It all culminated with a single, simple slide - numbers, with some Tufte-esque Sparklines thrown in.

Click on the picture for a full-size image!


Well, technologies come and go, and without going into the boring details, I've had to come up with a new way to generate the mini-bar charts along the left side there. It ended up being a relatively straightforward task in Excel VBA - yes, of course the table of data is being driven from a spreadsheet.

Here's the macro that does the trick - I just create a little HTML file that generate the bar charts in series (please excuse the hard-coding) ...

Sub CreateSparklinesDisplayFile()
  
   Dim sOutFile As String
   Dim iStartRow, iStopRow As Integer
   Dim iStartCol, iStopCol As Integer
   Dim i, j As Integer
   Dim sDataString As String

   sOutFile = "C:\Temp\BizUpdates.html"
   iStartRow = 45   ' First row of data to be graphed     <<< Evil hard coding!
   iStopRow = 51    ' Last row of data to be graphed
   iStartCol = 12   ' First column of data to be graphed (includes column of series names
   iStopCol = 24    ' Last column of data to be graphed

   Open sOutFile For Output As #1

   Print #1, "<html><head><title>BizUpdate Sparklines</title></head>"
   Print #1, "<body>"
   Print #1, "<p>Sparklines for last 12-months spend, IT Projects, by Initiative</p>"

   ' Loop thru the lines in the table to generate the separate sparklines

   For i = iStartRow To iStopRow
      Print #1, "<P>" & Cells(i, iStartCol).Value & "</P>"
      Print #1, "<img src='http://chart.apis.google.com/chart?"
      Print #1, "chs=100x35"       ' Size (length x height) of final graphic
  
      sDataString = "&chd=t:"
      For j = (iStartCol + 1) To (iStopCol - 3)
         sDataString = sDataString & Cells(i, j).Value & ","
      Next j
      sDataString = sDataString & "0,0,0|0,0,0,0,0,0,0,0,0"
      For j = (iStopCol - 2) To (iStopCol)
         sDataString = sDataString & "," & Cells(i, j).Value
      Next j
      Print #1, sDataString
 
      Print #1, "&cht=bvs"
      Print #1, "&chbh=a,2"
      Print #1, "&chco=CCCCCC,FF3300"
      Print #1, "&chds=0,100,0,100'"
      Print #1, "title='" & Cells(i, iStartCol).Value & "' />"
      Print #1, ""
   Next i

   Print #1, "</body>"
   Print #1, "</html>"

   Close #1

End Sub

The output file looks something like this (a simplified version ...)

<html><head><title>BizUpdate Sparklines</title></head>
<body>

<p>Sparklines for last 12-months spend, IT Projects, by Initiative</p>

<P>Cost Reduction</P>
<img src='http://chart.apis.google.com/chart?
chs=100x35
&chd=t:52.25,65.3,72.15,33.15,33.95,33.65,47.7,92.88,79.49,0,0,0|0,0,0,0,0,0,0,0,0,70.57,87.85,55.25
&cht=bvs
&chbh=a,2
&chco=CCCCCC,FF3300
&chds=0,100,0,100'
title='Cost Reduction' />

<P>Growth</P>
<img src='http://chart.apis.google.com/chart?
chs=100x35
&chd=t:67.05,88.25,85.61,95.25,86.70,55.49,54.75,81.19,65.62,0,0,0|0,0,0,0,0,0,0,0,0,55.65,42.05,18.41
&cht=bvs
&chbh=a,2
&chco=CCCCCC,FF3300
&chds=0,100,0,100'
title='Growth' />

</body>
</html>

Some things I noted when constructing this stuff ...

• The Google Chart API seems to be picky about the order of the various parameters. I had some troubles getting the charts to work unless I output things just so
• I can control a lot about these graphs, but I couldn't get rid of the x-axis. Yes, there is a chart type for "sparklines" (cht=ls), but that's for line graphs only
• I am calling out the last three months spend in the table, so I want to highlight them in the charts, hence the little hiccup in the j loop

I can publish a version of my spreadsheet that puts it all together, just let me know ...

Previously ...

• Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
• There ain't much IT in IT Management (May 7, 2008)
• Where to Start? (2 of 2) Metrics & Measurements (August 12, 2008)
• Linkfest: Data Visualization (September 6, 2008)
• Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
• I Think I'm Learning SAPanese ... (November 22, 2008)

Technorati Tags: application, business value of IT, development, documentation, hands on, presentations, Excel, VBA,

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