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 ...
Facilitating Innovation: Establishing an Environment of Possibilities
Facilitating Innovation: Establishing an Environment of Possibilities
I'm exchanging email with someone interested in establishing a skunk works, and they are asking some very interesting questions about the nature of innovation and the ingredients for an "environment of possibilities" ...
... things are ... [as they are] because someone already tried unsuccessful alternatives ... [This] begs the question: when it is required, how can rapid innovation be achieved?
Rapid innovation comes when the environment allows it and the skill sets enable it.
- An "environment of possibility" just means that folks are given some time to experiment with new technology, and access to the resources required to play around a bit.
Caveat: The challenge, of course, is that many folks expect the employer to allocate x% of their 40 hour work week, and provide training classes and server space to mess around with. Invest a little personal time and capital - in IT, it doesn't take much to build a solid development / test environment and start teaching yourself!
- I believe that the "innovation skills" are in everybody. But just like any other activity, success is 10% inspiration and 90% perspiration - individuals / teams / organizations need to build their innovation muscles by doing.
Caveat: A critical requirement for this piece is has to be ok to fail. The corporate culture must expect a failure rate for new ideas - remember, if it was easy, we'd probably already have thought of it!
... I value both history and future opportunity and am seeking a balance. Is this the same in your experience?
Well, Santayana was right - "those who do not remember the past are doomed to repeat it". But history should tell you specifically what tactics to avoid, but not necessarily what strategies will fail. Opportunity will be a mix of many things, and what was true at one time may no longer be true now. Look at imports from China - recent increases in transportation costs are making that strategy a loser for lower valued goods.
(and now, the "How-To Questions About Skunk Works")
Process: How does ... leadership successfully position a think tank or innovation team so that it is (a) buffered from mundane corporate operations and politics while (b) it remains sufficiently connected to executive leadership and operating divisions for its ideas to be acted upon? (I'm assuming that the skunk works is outside the normal corporate business structure.)
Ah, this is an incredibly important question. Skills and environment aside, I've seen successful innovation happen only when the team was sufficiently empowered to get ideas implemented. Sometimes this comes from executive sponsorship from just the right person - but not as often as folks think! The cynical or weak of heart prefer to wait until they are granted permission to work on a project or idea.
The "drivers" that get stuff done do so because they have all the rah rah stuff (vision, drive, energy, whatever), but they also typically have knowledge of how things work in a company. Sometimes this means a long-time employee, who has relationships with the folks that control the key people, resources, and decisions. Sometimes this means the uber-techie who already knows how the various pieces of process and technology work, so they know how to call out the resistors when obstacles are thrown in the way (no budget! no approvals! too difficult! systems can't do that! it's against policy! yada ...). And you don't have to be a long-term member of the organization to be successful; experiences from multiple industries, organization, technologies, etc. can all be applied by someone with imagination and drive.
So, leadership needs to stack the deck for their innovation team by ...
- Carving out time in their schedules; don't just add this to everything else on their plate - take something off!
- Provide visible executive sponsorship. You need to be able to pull that card out every once in a while (You need to make this change because the CEO said so ...) - not often, but now and again ...
- Staff the team with a mix of long-term and newer employees
- Identify a team leader that has the right mix of hands-on technical (this cannot be a administrative role only - they have to be able to do something!), business, and relationship-building skills. They must be able to spot the opportunity through the hype, understand how it translates to business value, and then communicate that effectively and concisely to those who need to support it
- Hold their feet to the fire - the team should have goals and objectives, it's not a license to play!
- Let them fail! The most successful baseball players fail 70% of the time!
Also, the skunk works must remain connected to operations - they'll have to implement the "big ideas" eventually, and it's always good to remain grounded in reality. Make participation on the team a part-time thing for most; consider rotating different people in from various areas of the company, so everyone has a chance and all remain connected to the base business.
What lessons have you learned from the skunk works experience that you can apply to the innovation process? What broad, meta-issues and narrower specific issues has your project illuminated and solved (or at least, what questions has it posed)?
Aside from the organizational and change issues mentioned previously, I have found that innovation efforts often target things that are perceived as issues, but they are actually symptoms of more fundamental behavioral or structural problems. Web 2.0 tools and techniques are often lauded as new ways to unlock the wisdom of the crowds, connect with the new work force, or counter the flight of knowledge leaving the company upon retirement. Unfortunately, some of these efforts struggle due to what I call the Law of Large Numbers, which basically says that what works on the Internet doesn't always work at a corporation.
Also, it always seems to boil down to "Change Management" - an overused buzzphrase that just says change is hard (especially from a vending machine). There are many ways to address this (education, repetition, participation), but management always needs to understand that corporate operating processes typically don't catch on like consumer products - here today, gone tomorrow (look how fast the Apple iPhone turned over a new version!)
Previously ...
- Motivating Maintenance Programmers (January 6, 2005)
- Moving to Eclipse Ia - Relevance (June 1, 2005)
- Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
- My Favorite Paradox (August 13, 2005)
- Subtle Anarchy (August 22, 2005)
- The "Army Rangers" model for IT Professionals (January 2, 2006)
- Guidelines for Success with your Skunk Works project (June 19, 2006)
- Innovation That Matters - Substance Over Style (January 12, 2008)
Technorati Tags:
design,
development,
entrepreneur,
innovation,
operations,
people management,
tech management
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: application development, design, development, entrepreneur, innovation, people management, productivity, project management, tech management
Where to Start? (1 of 2) Process & Procedure
Where to Start? (1 of 2) Process & Procedure
If you need a one-slide, three-bullet, PowerPoint special for describing the basic tactics for "How to Achieve Operational Excellence", try these:
- Process and Procedures
- Metrics and Measurements
- Continuous Improvement
The first two are nicely alliterative, but you might consider substituting Standards and Processes as your lead-off if we're talking about an IT, Finance, or Engineering department.
Now What?
Of course, now you have to generate the details; the "motherhood and apple pie" routine only lasts thru the first meeting. Here's where many organizations discover that it's hard to know where to start. Most people find a blank sheet of paper intimidating; they prefer editing to creating. Also, folks are easily overcome by the volume and complexity of all of the processes they go through every day.
<aside> And for some reason, people seem to gravitate to the most difficult thing to document - "experience". It's like whistling - hard to describe on paper, but easy to demonstrate, with multiple variations and endless complexities. How can I possibly convey my thought processes when I'm debugging a system, triaging a set of problems, or pulling together those first few critical design elements?
Well okay then - let's not think about that right now. We'll talk ourselves out of any process documentation before we even start! <aside>
Start Simple
For every job, there is a recurring list of "stuff" that folks do every day - administrative and busywork tasks that must be done, just to keep the wheels turning. This is the kind of "process" that lends itself very easily to documentation (and, afterwards, automation, but that's another post). It's the little things that you do, unnoticed until you take a vacation day or call in sick. All of a sudden, things stop working or start breaking, because you weren't there to reboot the server first thing in the morning, or clear a cache, or check a job queue for stuck items ...
So a great place for your team to start is to build a ToDo list of repeating tasks. It can be a simple text file, a Word document with nice formatting, a spreadsheet with convenient rows and columns - it really doesn't matter. My personal favorite is the spreadsheet - I use tabs to break up the lists into nice sized chunks ...
Click on the picture for a full-size image!
I've posted a few simple files on my Source Code page:
There are some nice features in the spreadsheets - like color coding for when a task is done (x) or undone (o). Also, the current day, week, month are highlighted automatically.
Collaboration Suggestion
If this idea makes sense, consider skipping the documents / spreadsheets, and create this as a wiki page (or collection of pages). Then, the entire group can add their recurring tasks - and the group will develop a shared master list. This makes it much easier to encourage shared tasks, standardization of work, etc.
Note: Does this structure remind you of 43 Folders and Getting Things Done? Well, that's definitely in the ballpark, but GTD focuses more on personal productivity. Daily / Weekly / Monthly Process Lists add structure and enhance productivity for a group. If you can scale the ideas in David Allen's book to help an entire group - and make it easy for folks to join and leave the group - go for it!
Some Task List Best Practices
- Tasks on the lists should be one-liners. "Reboot the Server" or "Empty a Job Queue" are great, but if a single task actually has a series of process steps involved, best make that a separate, more detailed task list
- Continuous improvement and ongoing documentation are themselves recurring tasks; consider putting a task to start each day thinking about items that are on your plate today that could/should make this list
- The sample spreadsheet features the color-coded "checkmarks" that indicate when a task is complete. If you use a wiki (like TiddlyWiki), there may be plug-ins / extensions (like this one) that allow you to put checkboxes in the wiki itself. Checking the box when something is complete makes you think through each process step-by-step; if you just scan the lines every day, it's easy to slough them off. Plus, it's psychologically satisfying to see all those unchecked items get crossed off the list!
Previously ...
Technorati Tags:
best practice,
collaboration,
documentation,
Knowledge Management,
operations,
productivity,
tech management,
Web 2.0,
wiki,
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: collaboration, documentation, Knowledge Management, productivity, tech management, Web 2.0, wiki
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!
However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!
Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...
What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.
Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.
... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...
Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!
Previously ...
- Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
- Misapplying the Pareto principle (January 7, 2006)
- Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
- Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
- The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
- Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
- Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
- Defining an Effective IT Metrics Framework (January 21, 2007)
- Defining the Business Value of a Project (October 25, 2007)
- Innovation That Matters - Substance Over Style (January 12, 2008)
- Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Technorati Tags:
best practice,
business value of IT,
innovation,
Knowledge Management,
operations,
supply chain,
technology,
twitter,
Web 2.0,
youtube,
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: business value of IT, collaboration, documentation, innovation, productivity, twitter, Web 2.0, YouTube
Desperately Needed Features for eMail Clients/Servers
Desperately Needed Features for eMail Clients/Servers
Via Knowledge Jolt, here's an article from KM world with some interesting statistics about folks engaged in enterprise search - but it was a tangential quote from the author that caught my eye. When asking corporate knowledge workers about using public Internet search engines, she found that ...
... although only 2 percent [of corporate searchers] said they used the company intranet, 13 percent stated that they were looking for internal company information. That's puzzling.
Not puzzling to me! They're looking in their e-mail inbox!
It's a common hassle of IT departments - mailbox management (and the lack thereof). Everyone's inbox seems to have thousands of documents, gigabytes of information, and zero organization or structure. There are a couple of interlocking problems here:
- Backup: IT is typically expected to cover everything - and after a few years, a few thousand e-mail accounts, and a few gigabytes apiece, well that's an awful lot of tape. More to the point - your backup window gets smaller and smaller, as you watch tape after tape load up with what you know are incredibly redundant inboxes.
- Upgrades: Heaven forbid you try to convert from one mail server to another, or go through a major upgrade. The migration process will go on forever, because you have to convert all of that ... stuff.
- Document Retention Policies: Something new from last year - the idea that a company must be able to produce any e-mail / electronic document requested by a court. Please, no eMails (IANAL) - I'm not up on all the details here, I just know this is one of the reasons why we can't simply delete all eMails older than six months.
To solve problems 1) or 2), IT departments will attempt to impose a size limit of a few gigabytes. This will be met with a few typical reactions ...
- 10-15% of your users will far exceed the targeted max inbox size. This is the typical Pareto situation, where the storage needs of a few outweight the needs of the many. Worse yet, this group is typically composed of the Marketing department (huge attachements), everyone in Legal (never delete anything, lots of document scans) and a collection of significant Executives (including the CEO) who get cc'd on everything and have zero time or interest in organizing ephemera.
- Invariably, you'll get pushback along the "disk is cheap" line. Last month I bought 750GB of storage at Best Buy for $180 - why can't you throw some cheap disc in the old data center? Unfortunately, those that have time to provide these helpful suggestions typically don't have the interest in hearing about the growing stack of backup tapes.
- Bottom line - there's simply no good business case for taking time away from anyone's busy day to organize their desk; they either do it or they don't. Mailbox quotas are IT's way of trying to tell you to get your life in order - and that is pushing rope, completely ineffective unless the person actually wants to change. It doesn't grow revenue, and it doesn't save cost (well, not much).
Now, I don't have any ultimate answers here, but I am trying to lay out the basic premise behind what I think are two very simple ideas that would have a huge impact on the growth of corporate America's eMail-boxes. I gladly invite someone to tell me why these things aren't features of every mail server; of course, I'd rather have someone to tell me how to get this done!
Proposed: Eliminate the Reply All feature: Or, at least make sure the default option is Reply to Sender, and put at least four mouse clicks and/or keystrokes between the casual eMailer and the option to share their wisdom with their cohorts on the To: line. We've all seen annoying threads expanding in our inbox - it must be the default! I say that only partially in jest - I have accidentally hit Reply All a few times - nothing too embarrassing, but it was, a bit too easy to make the mistake.
Proposed: When replying to a e-mail that sports a file attachment, mail clients should delete attachments from the reply by default. It makes little sense to reply to a note and return the original. If you've made changes, you'll be attaching your updated file anyway. I've seen way too many e-mail responses that say, in effect, "I agree". No need to send it back, just tell me you're OK with this. Of course, they'll hit Reply All (see above) because for some reason, I need to be informed that you agree with a copy of the thing I already have a copy of ...
These two options, I believe, would quickly eliminate the majority of useless duplication in corporate eMail servers. My last suggestion, is less about prevention, more about cleaning things up. Of course, I wouldn't be surprised if something like this already exists; I can even imagine how to write it. I just don't have the time ...
Proposed: I want a utility that scans each mail thread in my account, and selects the earliest occurrence of an attachment. Then, the thread is traversed, and all duplicates of that document are replaced with a text reference to the e-mail that contains the original. A simple concept, this would certainly save me a lot of manual effort needed when cleaning out my own inbox.
Any other simple ideas out there for mail management?
Here are some more recent eMail stuff from my blogroll ...
Previously ...
Technorati Tags:
application,
best practice,
development,
innovation,
Knowledge Management,
productivity
Labels: application development, business value of IT, development, Knowledge Management, productivity, technology
Why are those Old Programmers so slow in picking up on the Intarweb?
Why are those Old Programmers so slow in picking up on the Intarweb?
A significant difference between us old-line IT coders and the new graduates is the variety of our platforms and tools. I'm not talking about the large number of languages and tools learned over the course of a career - we all have a healthy collection of certifications and acronyms peppering the bottoms of our resumes. I'm talking about the amazing array of stuff required to get development done on a single project, "right now".
Over the past few weeks, I've been doing a little development at work. This is my idea of fun - in between the PowerPoints and project status meetings, I try to sneak in a little hack or two. Actually, I'm not doing the heavy lifting on this one; I'm working with one of the guys on my team, and we're putting together some ASP code to generate RSS feeds from the SQL database we use to track our projects. He's done most of the raw research and the base coding, I'm just prettying up the final package.
As a department, we're moving towards Microsoft as a strategic platform, but we're certainly not there yet - so this is definitely a skunkworks-type project. For this "fun stuff", we're using technologies that will plug nicely into our general strategic direction, but at this point there are no standard toolsets or integrated development environments in broad use.
So, to get the job done this afternoon, I've been cycling through the following ...
- In window #1, editing the .ASP file with Crimson; source files are sitting on the development server
- In window #2, testing code using IE ... no integrated debug environment for my ASP syntax, but I manage (just a little trickery - switches flip between RSS and HTML output)
- This is just debugging the basic code - to validate the RSS XML, I View Source from IE (opening window #3) and cut and paste into the W3C validator (window #4)
- For the SQL queries and database hacking, I've got window #5 for Enterprise Manager and #6 for Query Analyzer
- After debugging, I push to the test server manually, using File Explorer in windows #7 and #8
- Everything looks great, so I switch to window #9, which has another chunk of ASP that generates custom URLs for the RSS feed (we've added selectivity, aren't we crafty?)
- For the final test, I have RSS Bandit open in window #10. I create multiple new feed URLs (#9) and add to the Bandit config, to see what I get
- If I made a syntax error in the RSS (missed something between #4 and here), I have to flip back to window #1 to clean it up
- Oops, almost forgot ... like any good coder, I've got TFMs open, but it's not just one manual- window #11 is my multi-tabbed Firefox, Googling all sorts of sites to get references for RSS, ASP, and SQL
Sounds crazy, I know. I could/should go out and get Visual Studio or something. But like I said, we're not fully in production in this Microsoft development environment. We're innovating, right?
I've done open source development on my own in the past, and it's much the same thing - multiple different platforms, tools, and languages. For example, when working on my own site, I'm fixing configuration files and writing code in HTML, CSS, PHP, and mySQL. To get things working, I'm dealing with the configuration files for Apache, Eclipse, PHP, and mySQL. Edits in Eclipse and Crimson, pushing around source with FTP, fighting firewalls and routers, developing in Windows while production is in Unix.
This madhouse of multiple tools, languages, and platforms probably sounds quite normal - if you've been working heavy with open source and/or Web 2.0 for a few years. But imagine presenting this to legacy IT folks, working in their version controlled, standardized environments. The typical "road to the future" brings five new technologies, three new IDEs, and one or two basic system architectures that are all very different from tried and true.
Does this mean you can't teach an old dog new tricks? Not at all - most are quite anxious to learn, and have done so continuously over the years. However, this is all starting to feel like the first time we switched from procedural languages (COBOL, RPG, Pascal, Fortran) to OO and event-driven stuff (Visual Basic, PowerBuilder, SQLWindows). We went from offense to defense, from being controlling and orchestrating to reacting and trapping. Not that it was bad or wrong - just different.
Does this mean the experienced coder is washed up, and has nothing to contribute? Ask the folks in Big Pharma, having dealt with the FDA and validated systems. Ask the folks working with Finance in public companies, having dealt with SarbOx. Healthcare and HIPAA. Retail and RFID. Not to mention having to debug a lot of other people's code, and knowing when to step through or just refactor.
Running to the future, juggling multiple multilingual windows, and demonstrated facility with the newest tools is all good, but it's just one of many attributes that determine who on your team is worth 50 others. Have a little patience ...
Previously ...
- Things for the DIY programmer to consider (March 14, 2005)
- Tracking patent submissions via RSS (June 1, 2005)
- Turning a new page, and working on that home development environment (July 27, 2005)
- My Favorite Paradox (August 13, 2005)
- Analog and Report Magic Log File Formats (September 10, 2005)
- Fighting with MS Access and version incompatibility (September 26, 2005)
- Digging into open source for a New Big Project leads to Yak Shaving (November 4, 2005)
- Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies (November 6, 2005)
- The "Army Rangers" model for IT Professionals (January 2, 2006)
- SQL Hack for Reporting Project Phase and Status (December 19, 2007)
Technorati Tags:
design,
development,
documentation,
hands on,
innovation,
tech management,
technology,
Web 2.0
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan
Labels: application development, development, generational diversity, hands on, innovation, millenials, productivity, tech management, technology, Web 2.0
The Innovation Generation - Communication Styles
The Innovation Generation - Communication Styles
There've been many articles in recent weeks about the tech-savvy Millennials and their impact on future work. I concede, even welcome the changes that business will need to introduce in response to these new expectations, but I don't see the massive change that some writers seem to think is inevitable. The world will not change to accommodate the Millennials, but relevant and effective new working styles will definitely be adopted where they make business sense.
I will certainly agree that communication styles will change. For example, there will be a greater reliance on (and expectations of) instant and ubiquitous connections - with people, information and technology. IM is already on the way out, and texting is the way to go; my high-school-aged daughters think nothing of racking up thousands of text mails every month.
Unfortunately, this kind of freewheeling message content is going to run headlong into the litigious real-world. Many companies are still struggling over records retention standards and expectations. Public companies will need to maintain some control over messages that could contain proprietary or inside information. Corporate survival and protection from liability are clearly not on the minds of students as they post embarrassing pictures on Facebook pages, and even adults get trapped by unfortunate text messages that come back to haunt them.
Don't get me wrong - I'm a huge believer in alternative messaging styles and flexible collaboration. I've managed and/or participated on multiple "collaborative" teams - people from different companies, zip codes, time zones and countries. Separation by time and space has been a business challenge for years, but you could set up a shared FTP folder, or swap e-mails about projects, as long as I've been working. The teams that succeeded understood the differences between working across the hall and working across town, and moderated their communication styles accordingly, using the best tools available.
The value the Millennials bring is a de facto openness to collaboration tools. To them it's not something new that they need to learn; they expect the rest of us to already be there. Their rude awakening will come when they need to invest some change management time getting us "old folks" to catch up to their fast twitch messaging style; they won't be able to pass us by because we've got the organizational and process knowledge. (that's why we're on the team, right?)
Previously ...
Technorati Tags:
collaboration,
design,
generational diversity,
innovation,
Knowledge Management,
millenials,
people management,
productivity,
Social Networks,
tech management,
Web 2.0
Labels: collaboration, design, generational diversity, innovation, Knowledge Management, millenials, people management, productivity, Social Networks, tech management, Web 2.0
Power Outage Follow Up - Observations
Power Outage Follow Up - Observations
A couple of hours after my last post, the power came back on in the building and all was right with the world. My dissatisfaction with Dell battery life was confirmed - I only got in about an hour of work before everything died away. It's clear that my current choice of notebook precludes me from a great amount of truly roaming activity.
On the other hand, I am finally switching from hardwired to wireless connections when in the office - even at my desk. I can switch buildings, work from home, etc. and never change my basic startup process for getting connected. It's a small thing, but I'm all about continuous improvement and the cumulative effect of multiple processs changes over time.
My most interesting insight came a bit later in the morning. After a few more folks got to the office, and there was nothing else electronically to do (thanks to the weak batteries), a small group launched into conversation on a project that was experiencing some issues. I noticed a palpable sense of relaxation while talking - driven, I think, by a unstated assumption that we had no nothing else to do. However, I think the fact that we had no pending distractions (meeting in 15 minutes, other work to get done) plus a severely limited potential for interruption (by phone calls or e-mails), and no diversion of attention (ie. typing on the keyboard while taking part in the meeting) was a significant productivity boost. The conversation was fairly robust and free-flowing - the ideas came easier, the alternatives made more sense.
For team productivity, there is definite value in getting away from the office and shutting off all connections. Freedom plus focus makes a difference.
Previously ...
Technorati Tags:
best practice,
collaboration,
design,
Knowledge Management,
operations,
people management,
productivity,
tech management
Labels: collaboration, productivity, tech management
Optimizing the Wrong Part of Knowledge Management
Optimizing the Wrong Part of Knowledge Management
I sat in on the report-out session from a kaizen event this week, and something occurred to me as I reviewed a ton of interesting findings in a very short time ...
Best Practice
Self-contained deliverables are the most powerful tools for knowledge knowledge transfer you can have in your organization. I'm talking about a document that stands on its own, and effectively communicates an idea without needing the author nearby to explain anything.
The topic doesn't matter - conceptual white paper, status presentation, process map / instructions, design specifications, etc. The format doesn't matter - Word (document), PowerPoint (presentation), Excel (spreadsheet), Project (plan), Visio (diagram), and so on. The telling event is when this deliverable is sent out as a pre-read before a scheduled meeting or review. If written well, the time allocated for the meeting is spent discussing questions, clarifications, exceptions, and/or additions - as opposed to explaining the document itself.
Reality Check
Creating self-contained deliverables is hard; it takes skill in a number of different areas to create clear and concise prose, relevant statistics and metrics, relevant and impactful visuals. It's also time-consuming - well structured examples, screen prints, illustrative diagrams require skills in multiple technologies. Of course, before all the fancy words and beautiful pictures, you have to be able to lay out the opportunity / problem / situation so the reader can quickly get up to speed on the relevant points.
The other challenge, of course, is finding the time to create the content, capture the message, make the connections. It's always hard to manufacture enough time.
So, what ends up happening? People tend to optimize the knowledge capture process; minimize time spent creating documents by putting together enough material to facilitate the conversation, capture the main points, and help them remember everything that they want to review when in front of the team.
The Problem
Unfortunately, this misses the bigger picture. By reducing the time I spend capturing the knowledge, I'm increasing the time required to pass it along; I am sub-otimizing the knowledge transfer process. If I don't give my content out for a pre-read, I'll burn half of the meeting time getting roomful of people up to speed on stuff they could have read the day before.
It doesn't stop there; the same content would need to be discussed with anyone else who might be interested. And, since we've already established that time is scarce for all, these next conversations rarely occur; the opportunity for transferring the knowledge to more people is lost, and as memories dim, the value captured in the original meeting is, for the most part, gone ...
... or (more likely) concentrated in the head of the person who originated the whole thing. And people wonder why organizations have trouble retaining knowledge, or why groups develop "super users" that create unfillable voids when they move on.
Catch-22
Unfortunately, when confronted with this situation, most people under time pressure will make the obvious choice - stick with what you know. If you're facing a deadline, capture the information that you need and deliver the details face-to-face. There's safety in numbers with this approach; I think 80-90% of the business world takes this route. It gets the job done and no one is really faulted for going this way.
Breaking the Cycle
However, as I've noted before, there is a lot of power and possibility when you can leverage your knowledge across many people, without regard to time or place. If you want to do more in your organization, leverage more of your time, and/or get your ideas across quicker than the next person, you need to develop skill in creating self-contained deliverables.
There is no single method or style to create self-contained deliverables. Anyone can do it, but you need to figure out how to adapt and adjust your personal communication style, and change the things that are ineffective. My favorite methods:
- Borrow Liberally: Most of the things that I've learned about documentation and communication came from other people, other things I've seen, read, or heard that particularly worked for me. A writer's effortless prose, a presenter's terse yet effective pitch, a diagram's elegant visualization. Develop the habit of looking for stuff that works, and the curiosity for decomposing it into methods you can use for your own communication.
- Study Minto and Tufte ... and other practitioners of the art of communication. Minto's Pyramid Principle is very effective when introducing a reasonably complicated new idea in a short amount of space. Tufte will teach you how to strip out the extraneous information while packing in the pertinent; he's talking about diagrams and visualizations, but it works for your words, too!
- Use the Right Tool for the Job: Every MS Office application has the ability to draw squares, circles, and lines - diagrams in the midst of your spreadsheets, project plans, and documents. But nothing beats Visio for quick diagrams that give precise control of placement, size, and alignment. Similarly, I love Excel's ability to quickly create beautifully structured tables of information, in a way that gives me fine-grained control over row heights, column widths, font sizes, number alignment, and other effects. Sure - PowerPoint can do a diagram or a table, but it's much quicker to build it in Visio or Excel and paste into PowerPoint.
Note: Learn how to paste as an Enhanced Metafile, not as an OLE object - you'll thank me for it.
- Get Feedback: Ask someone whose opinion you trust, and who is at least a decent communicator themselves. Ask them if your written documentation was clear, and did it explain everything they needed to get the whole picture. Better yet, become your own harshest critic; use the voice recorder or videotape your presentations - are you convinced by what you see / hear? Pick up a old document or diagram you created - can you still get meaningful information out of the content or was it really dependent on context?
Take responsibility for the communication - if only to save yourself from the hassle of repeating yourself again and again and again ...
Previously ...
- Current Writings on Presenting Complex Information Visually (July 9, 2004)
- Communicating Complex Technical Concepts (March 21, 2005)
- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- Euphemisms, and a career-extending paradox (July 11, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- Look your best with little effort - Excel, Project VBA for Page Formatting (June 11, 2006)
- Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
- Five Under-Emphasized PowerPoint Best Practices (May 7, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Communication is the responsibility of ... (August 19, 2007)
Technorati Tags:
best practice,
design,
documentation,
Knowledge Management,
marketing,
presentations,
productivity
Labels: design, documentation, Knowledge Management, marketing, presentations, productivity
Hidden Gold in Automating Recurring Processes
Hidden Gold in Automating Recurring ProcessesHere's a typical IT scenario: each quarter, you need to check audit user access to a critical application. Your internal security standards require that you revoke access for those who haven't been on the system for over 90 days. I've seen this before, and the process (at the time) had many challenges:
-
It's manual; we did a quick-and-dirty set of steps years ago to cover the minimum requirements, that involves extracts from application logs, file transfers MS Access and MS Excel, and some emails
-
It's not drop-dead simple, because there is a list of exceptions - user IDs that were always kept active, even if they haven't been used
-
The overall process was never documented
Coupled with the fact that this only happened once per quarter, and involved less than five total effort hours to take care of, the easy response was to just get the task done and move on. But I think this is penny wise and pound foolish; there are long-term quality Problems to be avoided, and short-term Opportunities for internal staff development that we were passing up!
Problem: If we continued to just do the minimum, to satisfy the requirement, it was no surprise that over time, steps were omitted. The lack of documentation forced folks to repeat steps from memory, and pass along the process word-of-mouth as roles rotated and/or people turned over.
Opportunity: Simplifying things required some automation; nothing too difficult, but definitely interesting and non-trivial; for example, we needed a custom table for the exceptions. For staff members looking to build technical skills, this was a perfect training opportunity; small risk, small time requirement - a perfect filler when you are burnt out on the big project and need a bit of an escape.
Of course, the push-back was always the same: I Have No Time For This. Most can easily envision a total solution that is simple, uses familiar technology, gets rid of the multiple platforms and manual processes, and is sustainable. In this case, however, it would take about 16-32 effort hours to get done, and who has the time?
The solution was to attack the problem in baby steps; make the overall process a little better each time. For isses like this, you don't need to solve all of your problems now, and it's OK to leave the work unfinished until next time. However, the key is that you must commit to making a small improvement each time you "touch" the thing.
For example - back to the user access audit. For a first pass …
-
The current task owners walked through the process with me, and I took scratchy notes on paper and in a Notepad text file - stashed on my hard disk
-
I got the Access database extract and Excel spreadsheet that counted the days. I iterated on the spreadsheet, automating the counts and the formulas for computing days since last log in.
-
I returned the list of users who hadn't signed in for 90 days, which were then manually matched against the list of exception user IDs.
This work was a one-time add of about three effort hours - a small start, but a teeny platform on which to build.
A few months go by, and it's time for pass two ...
-
I moved my scratchy notes into a shared document and iterated on the process, mostly just cleaning them up to be somewhat legible
-
I still received the list of users and their last access date, but this time I got the list of exceptions. I iterated on the spreadsheet to take this into account
-
I still sent the results back, but note that now (and never again) does the next person in the process need to edit out the exceptions
This work was another one-time add of two or three hours; but we'd already simplified the overall process, and we saw the total effort (including process improvements) starting to decline.
Next iteration ...
-
We teed up a programming project to build an exception table and automate the log extracts - nothing more than a couple hours of effort
-
I took a final cut at the process documentation in the shared area, then turned it over to the operational support team
Note that each time you iterate on something like this, you need to feel comfortable with the idea that these works in process, these "interim deliverables", are clearly unfinished, even raggedy. It shouldn't matter, because each time you touch it, it gets a little bit better. Plus, the priority was originally low enough that a totally manual effort was OK, so what's wrong with documentation that is incomplete?
Incremental improvements on the primary goal (automated user audits) with tasty side benefits along the way (mini side projects to keep stretching your tech chops) … win-win.
Technorati Tags: productivity
Labels: application development, productivity
