Sponsored Links

Online Chat

Use the window below to chat with me (if I'm online ...)

Use the edit nick field above to let me see your name.

cazh1: on Business, Information, and Technology

Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...

Monday, March 15, 2010

Managing Change: Inspiration, Art, Science, and Execution

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

Technorati Tags: , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , ,

Sunday, February 14, 2010

Managing Change: Pick Something, and Do It Well

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

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , , , , ,

Monday, January 18, 2010

Data Visualization: How (2 of 2)

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

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

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

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

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

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

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

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

Information is Beautiful
Cool Infographics
Flowing Data
EagerEyes.org
Chart Porn
  • Haiti This blog is just a non-stop source of interesting examples
New York Times
Step 3: Get Your Coding Hands Dirty!

Remember, after you are done being wowed by the presentation - figure out how you could build one.
  • The old stalwart Excel comes with an ever growing list of graph types. Can't find the one you want? Try to hack at the standard stuff using VBA!
  • Sometimes a blog post will point you to some utilities. No, I never heard of Gource, but you can bet I'm looking for a project to use it with!
  • Open source has a lot of interesting tools out there - from jQuery addins to full-blown BI suites - lots of tools to load up with your data.
Remember - get inspired, find some starting points, and get building! the only way to really understand how to create insightful, impactful visualizations is to do a lot of experimentation.

Previously ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , ,

Tuesday, January 12, 2010

Data Visualization: Why (1 of 2)

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

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

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

... and we can iterate on these already:

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

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

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

Click on the picture for a full-size image!

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

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

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

Creating Opportunities for Insight - Playing with Visualizations

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

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

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

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

Next … sources of inspiration ...

Previously ...

Technorati Tags: , ,

Invisible Technorati Tags: , , ,



Labels: , ,

Tuesday, January 05, 2010

Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game

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

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , ,

Sunday, December 06, 2009

If I Told You a Fractal Solution, Could You Change the CEO's Mind?

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

Technorati Tags: , , , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , , , , ,

Saturday, October 17, 2009

Underwhelming experiences with Google Wave

Took some time today to work with the new communication meme - Google Wave. I wouldn't call it a fundamentally new way to communicate - well, not yet. I think Google is safe to continue with a "preview" label - clearly not even "beta" yet. No horrible bugs - at least on the Windows platform - but some obviously missing features. And, I am not all that impressed with the basic idea - it's just a mashup of Google Docs, instant messenger, and eMail.

Problems

All of my experimentation has been from a Windows machine - I am experiencing horrible performance issues with Firefox 3.5.3 on Ubuntu 9.04. I freely admit that this might not be a Wave issue - for the last two weeks, all of my Google sites (Mail, Docs, iGoogle, Reader ...) run brutally slow, timing out by graying the browser window. I know it's a weird issue because I can't Google for an answer (a disturbingly tight loop). Wave refused to even show me the stills from the introductory videos until I disabled Greasemonkey. Yes, I'm sure it has something to do with my setup, my installed plugins - I'm just surprised that the problems have been this stubborn.

So, to get anything done, it's back to Windows - still using Firefox, but no hint of platform troubles. Just an underwhelming experience with the fancy new toy.

I Am Legend

Interconnections on the internet are a wonderful thing; I put out a Tweet (sic) regarding my Wave invites, and a note in LinkedIn as well. Twitter generated the most responses, with folks I'd never met - great fun to connect like that. The following day, I got a note from someone looking to connect via Wave - I'm guessing from the information that I can see, this person saw one of my original notes via Friendfeed. Amazing how those copnnections were practically spontaneous ...

... while Wave feels like I'm in a walled garden. I still feel very cut off in the Wave world - a different domain from gmail.com means a new address to track, a new contact list to build. And it's difficult to find connections with folks you already know; I received another Wave invite from a friend, but since I didn't need it, I tried to figure out how to connect to him via Wave (I thought it a reasonable assumption that he, like me, has dived in). Unfortunately, I had to resort to an email message and some detective work to find out his Google ID - not something I could explain to most business users.

Yet Another Email Client

Yes, I am still at that opinion. Most of the opinions and articles I've scanned make it sound like we are working with a next-gen email client that does some of the basics right. I do note that the amplifiers tend to gush a bit, while the attenuators work hard to impress with wit.

Generally Pro
Generally Con
Maybe It's Just Me

One of my random invites went to this guy, who's review was a bit more positive than mind. Ok, maybe I'll jump into the with:public pool and wade around a while - it's probably the only way I'll really get it. However, I am very willing to be patient and continue the experiment - took me about 3 months to get Twitter.

Previously ...

Technorati Tags: , , , , , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , , , , , ,

Tuesday, September 15, 2009

A Company is like a Sphere

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

Technorati Tags: , , , , , , , , ,


Invisible Technorati Tags: , , ,



Labels: , , , , , , ,

Tuesday, August 04, 2009

Perfect IT

I once met with a rather thoughtful Project Manager to catch up on things. An interesting person to talk to – it’s the cadence and style of his chat, he's a fairly laid-back guy. I asked where his Stress comes from - he shows no visible signs of any, and it made me Ponder. We ended up talking about golf, IT Projects, and the “Search for Perfection” in our work.

So, what is “perfection” in the IT world? Is it being able to predict what will come true, and then everything hits as you foretold? Or does it appear when the programming / configuration / cabling is done, and everything does exactly what it was supposed to do?

Consider time-boxed (or agile) projects versus the traditional waterfall style. Is “perfect” acheived by hitting the date (but not getting all the requirements), or should we value delivery of all of the requirements (but not in the originally estimated time)?

Back in the day, we would work to write code that compiled “perfectly” - no severity level 20’s or 10’s, as we used to say in RPG.

What about fault tolerance, scalability, or quality of testing? These "requirements" deliver business value when [bad] things fail to happen (some tao to jones on). Note that these also become bargaining chips when time is tight … ephemera less valuable than squeezing in one last combo box.

Obviously there's no right answer, but my calm PM friend and I feel that one’s definition of “perfect” says a lot about whether or not you experience stress at work; this is when the conversation switched to golf.

Why do we both like Pasture Pool? Neither of us are competitive by nature; it’s more of a way to search for perfection (or burn an afternoon, or get some bidness done). And the interesting part is, it could be this never-ending search …

Where do you go when you can par your favorite course – for a lower score, or the next course to the left?

According to the zen PM, “if I’m a 15 handicapper, I could get down to 20 handicapper with more practice” [ok, he clearly plays more than I do], which led me to ask what exactly is a “perfect score” – is it par golf? zenPM suggested that a perfect score would be birdie every hole; I thought perfection could be when you hit every fairway and green in regulation, and you're down in two.

So is perfection “peak performance” [on time], “consistency and predictability” [on budget], or “strictly following the rules” [no 10’s]?

Then we had to get to our next meeting … back to the stress …

Previously ...

Technorati Tags: , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , , ,

Monday, July 27, 2009

Technical Debt and the Cost/Benefit of Knowledge Retention

A rather rigorous, Financial-sounding title for a high-concept line of thought ...

Thanks to Jeff Atwood at Coding Horror, for calling my attention to this article by Martin Fowler on Technical Debt:
    Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
Now, before you write off Cunningham as a techie snob or an academic hold-out for unattainable perfection, listen to this healthy dose of reality ...
    The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
I think most of us have seen this phenomenon before; sometimes it manifests as an open willingness to trade quality as just another feature (as measured by the amount of testing before code is put into production). Documentation is another common sacrifice - too often we accept e-mail summaries or PowerPoint outlines as a reasonable facsimile for knowledge capture.

You've probably seen this phenomenon where you work, and not just in your IT organization. Many areas of the business will rationalize over-budgeted schedules by summarizing critical findings in a brief email - or, worse, in a Status Update Meeting. "This is an expensive meeting", I might quip upon entering the room, seeing the conference table ringed with upper-and middle-managers, each weighing in with their understandings and opinions. Don't misunderstand me - these are typically very effective conversations, with exactly the right people; the folks that know and live the issues, and fully understand the implications of any process change. But my witty entrée was tragically accurate; the understanding and decisions developed at this meeting are too often lost a few minutes after the meeting ends, ideas with a half-life approximately 10 minutes into the start of the next meeting.

Think of it as a knowledge expense (vs. depreciation, as value is lost rather quickly). The expedience and effectiveness of face-to-face communication, with everyone in the same room hearing the same thing consistently and able to ask questions to validate their understanding, typically does not scale beyond the attendees. It's like listening to a band vs. buying the album (ah, more poetic than downloading ...).

In his article, Atwood continues along the Fowler / Cunningham thought process, discussing the need to budget a certain amount of time to pay down our technical debt by going back and finishing that unfinished work; document the things that you sloughed over, rework the inelegant parts of your database schema re code interfaces that rely us a little bit too much on assumptions.

The same can be said for process design and problem solving sessions - remain aware of your level of knowledge debt and budget time to document your findings. I like to call these chunks of captured knowledge "white papers" - I'll pause while you admire that stunning originality, but there's a method to my blandness. Calling these things "white papers" helps folks understand the purpose and value of such a document;  reasonably short and idea complete. The sweet spot seems to be two to four pages, well-organized, not too wordy, but clear enough that it remains effective months after the design or process rework sessions took place.

Just remember, organizations do the expedient thing all the time, streamlining meetings and decision-making by going light on the documentation.  Every once in while, you'll pay the cost of rework and rediscovery; as our experience grows, and our patience for such "wasted effort" grows thin, task effort times will increase as we invest a little bit more time in better, clearer documentation.

Previously ...

Technorati Tags: , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , ,

Sunday, July 05, 2009

The Delicate Art of Pushing Back

Commiserating a week or so ago with an old friend, struggling mightily with some external consulting firm providing technology talent, developing customer management systems for Big Sales Company. There were some critical dependencies on the server side, and the (internal) project team needed some on-site assistance working through the issues. Ad hoc phone support was just not cutting it - but the external project lead was pushing back. It's very difficult to get on-site, dedicated help for these in-demand DB technicians with little advance notice. My friend would have to wait a few weeks - which did not sit well, hence the commiserating.

Of course, I could easily see his counterpart at the consulting firm venting over his own frosty mug; I myself would feel ill-used (to some extent), because it’s not really reasonable for Big Sales Company to ask for something immediate like this – you just don’t turn these people on and off like a faucet.

I [politely] note that my friend is not the greatest at diplomacy, especially when dealing in shades of gray. He gets too specific, too black-and-white with his thinking; I really don’t think he’s empathizing with the components / teams he needs to work with to get the projects done. They are the subcontractor, the subordinate - he just wants to tell them what he needs, and expects them to hop-to and get stuff done. Don't define problems, define solutions, yada yada.

That’s not always the most effective way of dealing with the situation; it helps a lot if you can empathize some with the subcontractors / subordinate / supporting teams’ world. Understand the tasks you are asking them to do - so you know when they are sandbagging, but can appreciate when they are committing to getting some really significant stuff done. Don’t just tell people what to do – work together, in a partnership.

But then, as I said this, it occurred to me that this was all just a reflection of how this person manages up when working with the business. Ok, he's a bit older than me, so after all is said and done, he still thinks the business can ask for anything, can put any wacky requirements out there - and IT just has to figure out how to get it done. Of course, what's good for the goose is good for the external consultants - the frustration stems from the fact that the consulting firm is not behaving the way he thinks he would behave, if put in the same situation.

This is wrong on many fronts. IT needs to push back on unreasonable requests, if only to set the right expectations for what can happen. We need to help the business differentiate between what they want and what they need, to drill into root causes instead of fixing symptoms or papering over the tough issues.

The best PMs are good at managing up and down; pushing back (respectfully and constructively) on the project sponsors, and working with their supporting teams, not telling them what to do.

Previously ...

Technorati Tags: , , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , , , ,

Saturday, April 25, 2009

Business Benefits of Social Networks Exist, but ...

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

Technorati Tags: , , , , , , , ,


Invisible Technorati Tags: , , , ,



Labels: , , , , , , , , , ,

Tuesday, April 21, 2009

Five Stages of Twitter Relevance

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

Technorati Tags: , , , , , , , , ,

Invisible Technorati Tags: , , , ,

Labels: , , , , , ,

Thursday, April 16, 2009

Practical Innovation Lessons from Software Vendor R&D

I recently had the chance to listen in on a roundtable discussion involving a software developer's R&D group, discussing some of their thoughts on architecture. Some interesting ideas around "innovation" ...

Innovation vs. Cost Control

A question from the floor - how sensitive are the R&D arms of major vendors to existing investments in infrastructure for their installed base? Response was framed with a pair of quotes: "Innovation without disruption" is apparently one of their goals. However, is that just fancy talk? Doesn't true innovation only come from disruptive technology? And "Invention only happens once or twice, in the lab. Innovation is about taking Invention up to scale". This last one, I think, is the powerful bridge to reality; good ideas are just that, until you can make it a reality for the whole corporation, given limitations of scale plus existing policies / standards.

Innovation vs. Resistance to Change

This line of discussion also made me think that new IT tools / initiatives should be sensitive to our internal user's existing investments in knowledge / understanding. For internal IT, maybe an important, required conversation would be to agree on the layer / level down to which you will allow "disruption from innovation". A sensitive balance, and a tough level to identify.

Measuring Success

How does this R&D lab at a software developer measure success? "Productive end-customer adoption" - how many current customers are adopting this stuff in production? It's one of their KPI's, and a potential learning for corporate IT - could an internal development group's KPIs include metrics for internal rate of adoption / use of new stuff we put out into production? They also quoted "Crossing the Chasm", saying that 80% of innovation is "wasted" - never gets into production, sees the light of day. Is this bad? Nope, the nature of R&D is that a majority of the interesting ideas "fail".

Corporate IT rarely thinks of themselves like a software developer, but there are many lessons to be learned from those folks.

Previously ...

Technorati Tags: ,

Invisible Technorati Tags: , , , , ,



Labels: ,

Sunday, April 05, 2009

Practical Applications of Twitter in Manufacturing?

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

Technorati Tags: , , ,
, , , , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , , , ,