cazh1: on Business, Information, and Technology

Underwhelming experiences with Google Wave

2009-10-17T20:22:00.001-05:00

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

The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Hacking the Google Chart API from Excel (January 17, 2009)
KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
Practical Applications of Twitter in Manufacturing? (April 5, 2009)
Five Stages of Twitter Relevance (April 21, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: collaboration, hands on, innovation, Knowledge Management, Social Networks, technology, twitter, Web 2.0,

Introducing ... Google Wave

2009-10-13T20:30:00.001-05:00

Thank you for signing up to give us early feedback on Google Wave. We're happy to give you access to Google Wave and are enlisting your help to improve the product.
To accept your invitation, sign into Google Wave at the following link ...

Well, maybe not the most exciting email I've received over the past few years, but it was nice to get the [sorta] early notice. I'm definitely in the second wave, but I'll not look a gift URL in the mouth.

Of course, no early impressions just yet - the interface upon start up is spare, looks like Yet Another Email Client. I will check out the introductory video(s) - I typically do my best learning by playing around a bit (without reading any manuals), then watch a demo or get an expert to give me a quick tour - and then I'll get serious. Something to do this weekend, or while waiting around during the Next Big Go-Live (project at work).

Like previous Google apps, this one came with invites - but this is 2009, man, and I've got Tweetdeck at the ready! Soon after receiving the invite, I put the word out (via LinkedIn, too), and got a number of responses from fellow adventurers looking for their own golden ticket.

I have no idea how long it will take to close the loop - my Wave page/inbox/site/thingie makes it look like I've added these folks to a List of Indeterminate Length, with no ETA on delivery. Still, I think it might be interesting to gather their feedback into a mini review of this newest communication technology. More to follow ...

Previously ...

Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
PMO Nirvana is a Conversation, not a Schedule (February 22, 2009)
Practical Applications of Twitter in Manufacturing? (April 5, 2009)
Five Stages of Twitter Relevance (April 21, 2009)
Real Business Users and SharePoint (July 14, 2009)
Training and Learning: A Different POV (August 18, 2009)

Technorati Tags: collaboration, design, hands on, innovation, Social Networks, technology, twitter, Web 2.0

A Company is like a Sphere

2009-09-15T20:49:00.001-05:00

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

A company is like a sphere.

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

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

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

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

Previously ...

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

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

Frustrating Paradox: Simple and Difficult

2009-09-01T21:33:00.001-05:00

I think this is one of those fundamental concepts that, once it is pointed out to me, become self-evident and obvious (ie. why didn't I think of that). I'm curious if other people agree ...

When something is simple to describe, it is difficult to create.
When something is difficult to describe, it is simple to create.

I've seen these principles illustrated in different areas of business and technology; understanding this relationship can relieve frustration and provide hints on where to focus your efforts when working on a project.

Simple is Difficult

Simple Idea: My favorite example is the phenomenon of "smart part numbers", where organizations find it convenient to encode attributes about a product in the item / SKU number. This makes it easy for people to read labels and reports, find parts in the warehouse, and work with line items on an order. Unfortunately, implementing systems & processes that rely on "smart part numbers" can be problematic; reports and queries rely on multiple pieces of information embedded in a single field / column; SQL queries are tough to write, and reports & other programs become notoriously difficult to maintain.

"Lean" Process: Somewhat related is the phenomenon where business processes are rarely documented. Everyone in the group knows how to start with the Order, through Make-to-Ship, and back to the Cash. The problem usually hits when we experience turnover or some other staff change; our well-oiled machine starts to slip up, and performance gaps appear as the new team member doesn't fully understand know or understand everything that is required / assumed of them.

User Friendly: I've written before about documentation that insists on screen prints for every step of a process. I can empathize with the end-user on this; this level of hand-holding is extremely helpful, because it makes it easier to learn a new system or technique. Unfortunately, documentation at this depth is expensive and time-consuming to create & maintain - and is typically done best by folks whose primary job is documentation / communication (ie. not the folks who are asked to create this stuff).

Simple to Use; "Elegant": There is a related demand for software and websites that are easy to use, truly user-friendly and possessing intuitively obvious interfaces that everyone can just run with. These don't require complicated manuals, but they do require an awful lot of skillful programming to deliver such use and simplicity. I am working on a simple, small Web application (more on that later ...), where I'm trying to develop something that will elegantly solve a specific problem, yet be truly intuitive and obvious (dare I say fun?) to use. The challenge, however, is cross-browser compatibility; in the past few evenings, I've discovered some amazingly intricate problems with how CSS and PNG works with the Microsoft browsers - and have had to go to extraordinary lengths to make the website look the same on Firefox, Safari and Internet Explorer.

Difficult is Simple

The reverse argument can be behavioral and cynical; "time is money" drives some to oversimplify. However, "agile" design and development can be a practical tool when trying to maximize sustainable output.

Difficult Idea: I think the time-and attention-starved workday contributes to an unfortunate amount of oversimplification. If there is a complex project or difficult issue to deal with, get ready for the unending stream of peers, partners, subordinates, and "higher-ups" asking about status and root cause. Unfortunately, these people have limited time available to waste on active listening and understanding; typically, they will demand a short summary. They just want to know that the problem is in hand and getting handled.

Rapid Development: McConnell notwithstanding, some teams use "rapid development" as a convenient shorthand for "quick-and-dirty programming that relies on hard coding, flimsy structure, and a lack of testing".

With some extra work, reusable logic can be modularized, interfaces can be abstracted, and simplistic, utility programs can be replaced with flexible, fault tolerant modules that can be reused and extended. This particular brand of good cooking takes time, and a bit of design foresight.

Hard to Use; Hard to Understand: Of course, if you focus on Time to Completion, driving to get stuff done, focusing on deadlines over quality, it's not surprising that systems and processes are hard to use, and communication pieces are difficult to understand. As an old Army officer once told me, "if you want it bad, you get it bad".

IT's Challenge - Fighting the Good Fight

Of course, the "good cooking takes time" argument typically doesn't go over well with most businesses. The pressure on IT, really any business area, is to learn the local tools and techniques, and leverage work that has been already done. In addition, there has to be some points awarded for systems that don't require help desk support, processes that don't require handholding, and follow-up training in the weeks after go live.

Communication with management and the business is just as critical, just as difficult and just as rewarding when you get it right. Your counterparts in the business aren't dense - they just need things explained glibly yet completely. Master this, and Le monde est votre huître.

Faire de la bonne cuisine demande un certain temps.
Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire.

Classique - - Moderne

Previously ...

Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Best Practices for Process Documentation: Iterations (2 of 3) (September 17, 2008)
Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
The Delicate Art of Pushing Back (July 5, 2009)

Technorati Tags: best practice, business value of IT, documentation, presentations

Training and Learning: A Different POV

2009-08-18T22:04:00.001-05:00

The topic was training users for an upcoming project rollout, and the debate (as always) roamed back and forth between "traditional" (classroom training, scripts & workbooks) versus "experiential", pairing existing users with their counterparts (who are new to the system), walking through the basics (screen navigation, terminology, and step-by-step instructions for the most common required tasks). Training methods are a common area of debate and discussion with system implementation folks, and I can make a great case for any and all sides.

Task Oriented

(This is where I adopt my Pat Buttram voice) I remember back in the day ... we had "green screens", text-based terminals running applications that flowed like the languages they were written in; procedural, top-down, ordered and neat. There was only one path through each process ("This is the way you set up a vendor and cut them a check ... This is the way you set up a lease and charge the rents ... "). The training material was also very orderly - each step of the process was lovingly detailed, keystroke for keystroke. For more aggressively user-friendly documentation / training material, authors included a screen print for every step of the way.

Documentation Lament Part 1

sneakernets

High Concept

I remember when my kids were in their early grade school years; I was impressed to learn that some of the first math classes that they took were all about pattern recognition. Brilliant, I thought - that's the best way to learn how to work with the gooey (graphical user interface, or GUI) applications that were supplanting the chewy (character-based user interface, or CHUI) apps from the old days.

As computers became more powerful, programmers built apps to take on event-driven, flexible format tasks that matched the environments they were implemented on. Sure, there were wizards to take you through some basic operations, but when you're typing a document, manipulating artwork, or laying out your spreadsheet, there's no start-to-finish process - you are "creating". Training for this software is not about step-by-step processes, but complex operations built with common component tasks. The Microsoft Office suite taught us all that there are certain patterns to modern software (ribbon notwithstanding) - all menu bars were populated with the same basic component tasks. Top left always had File Open / Close, Edit Cut / Paste - and Help can always be found at the rightmost position of your menu bar.

The challenge, of course, is that not all people excel (so to speak) at conceptual learning. Us old folks grew up memorizing multiplication tables, and we've built our careers on a certain facility (based on familiarity) with the step-by-step.

Documentation Lament Part 2

File, Open

Follow That Guy Around

Of course, the most common training method of all is the modern apprenticeship - follow someone around that knows what they are doing. For companies of all sizes, it still amazes me how many important processes are not documented. Some might claim they are forced into this modus operandi by expedience and/or a slimmed down the workforce; I think it's just human nature. It's hard to get people to effectively document how they do what they do.

Don't get me wrong - I freely admit my preference for this approach, especially when it comes to new programming languages. I can read a technical manual with the best of them, but I do like to have at least one sitdown with an experienced programmer, watching over the shoulder as they take me through the development cycle (edit, compile, debug, run). Just show me on the screen how it works; once I can do my first practical [hello world()], I can grab the book, refine my skills, and catch up on the theory.

Good, Bad ... I'm the guy with the gun

Truly, there is no right or wrong answer here. Different people learn things differently; some react better to the spoken word, other prefer the printed, and some folks need to have step-by-step instructions laid out for them. Note that I purposely do not suggest that procedural versus object-oriented learning is a generational thing; I know plenty of old folks that do just fine with the object-oriented, creative, free-form, self-directed style of learning.

The key is that trainer / communicators must be facile in many different methods, and quick to understand which method will work best for your target audience.

Previously ...

Sometimes analogies work amazingly well ... (July 14, 2005)
Of course we can pay for that ... if it makes business sense (November 7, 2005)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
Stretching Your User Interface Design Muscles (April 16, 2008)

Technorati Tags: documentation, hands on, Knowledge Management

Perfect IT

2009-08-04T21:44:00.001-05:00

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

How to Cheat at the PMO Prioritization Game (December 14, 2007)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
Failing Faster (June 14, 2009)

Technorati Tags: business value of IT, collaboration, people management, project management, tech management

Technical Debt and the Cost/Benefit of Knowledge Retention

2009-07-27T21:26:00.001-05:00

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:

developed by Ward Cunningham

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

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)
Innovation That Matters - Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
Over / Under Communication for Project Managers (June 29, 2009)

Technorati Tags: collaboration, documentation, Knowledge Management,

Real Business Users and SharePoint

2009-07-14T22:22:00.001-05:00

Introducing buzzword-compliant technology like a wiki, or integrated collaboration spaces like SharePoint, will typically go well with a motivated audience like your internal IT department. But if you really want to understand how this stuff works, try it with "real people" - line employees in sales and marketing, operations, and finance.

Sure, you've heard complaints from these folks (they have better PCs at home, the SAP/Oracle UI is brutal compared to Amazon and AT&T U-Verse, and why can't they just connect their new iPhone to the corporate mail server?). Be warned; demanding users are not necessarily technically savvy when it comes to groupware.

Case in point; we are working a rather large project (many months in length, over 100 people throughout the business) using SharePoint as our collaboration space - and learning an awful lot about what we thought we understood about ease-of-use and intuitive user interfaces. Our collaboration space is a basic SharePoint project site, featuring the usual suspects - a Shared Document library, an Issues list, and an Announcements section. Simple right? Well, maybe not ...

Documents Check In, but they Don't Check Out

Just kidding, the actual check-in / check-out mechanism works fine. It's just very interesting that this basic concept of version control is lost on most end-users.

But let's start with the document library itself - it looks like a really nice version of File Explorer, but becomes very frustrating to folks when they try basic tasks like drag-and-drop. Yes, we found the simple solution - there is an option to open the folder in Windows Explorer, but since this menu option is buried right above the file list, it's hard to find - certainly not "intuitively obvious".

Version control was a difficult thing to explain - thank goodness for the tight integration with Office 2007. We found it easier to show folks how to edit documents with a simple double-click - that works just like their shared folders on the old file server! You can explain the concepts of version control quite easily, but the whole check-in / check-out, keep-a-copy-on-your-local-drive thing just gets too complicated. We did have to deal with the one-time task of checking in a new document after you upload it, but after that, they just open the files directly, and that's it.

There is one feature of Shared Document libraries that I really like - the ability to add custom attributes to documents that can appear as columns in the view. Makes it easier to sort / select / search on documents, and people "get it" relatively quickly. Just go easy on the version control.

... Here's a SharePoint Tissue

I think the most powerful and elegant feature of SharePoint is the flexibility you have with basic list management - even with WSS. Truly, this stuff should cover over half of the "fancy" automation tasks that folks are are asking for. However, I'm still surprised / dismayed by the fact that SharePoint doesn't include a standard graphical indicator - you know, the classic "stoplight" (green is good, yellow warning, red means um, er...). I've written about this one before - why can't I have a simple datatype (vs. putting together a sneaky little script to make it work).

I also have a significant warning / insight about trying to do too much with your Lists. Do you realize that most end-users in a typical SMB have older CRTs? I'll bet you still have a large number of 15" CRTs with slightly foggy tubes, on their last legs (but too expensive to change out for all but the executive staff) (ok, and IT too, sorry). In addition - well, let's just say that I'm not the only one whose eyesight is beginning to fail them; I can't tell you how often I've tried to talk folks into moving their screen resolution higher than 800x600 - but it just doesn't work.

What's my point? Before you put too many columns in your Lists, or too many gadgets on your Site, check with the average user to make sure that it looks okay on their Screen. Heck, before you even begin your design, use SMS or a simple script to poll the user community and find out what kind of screen resolutions have been set. Catering to the lowest common denominator is not a cop-out, especially when the point of a collaboration site is to get people to actually participate!

Push vs. Pull Messaging

(Another opinion:) I think most powerful aspect of collaboration sites is the aggregation of all knowledge about a project into a single, searchable repository. When people send project updates or resolve issues / hold discussions over e-mail, all that knowledge is buried and quickly lost inside people's inboxes. In SharePoint, a typical Announcements web part (yes, I know it's just another kind of List) is quite practical as a messaging medium, because folks can sign up for e-mail alerts.

Don't underestimate the attraction of the e-mail. People are used to getting information delivered to them in their inboxes - it's expected! All I'm saying with my Announcements list is that you have to subscribe to the information and pull it towards yourself (versus expecting me, the project manager, to remember to push it to you - and everybody else that might be interested).

Real-world learning: this concept didn't take long to grab hold in our project. It makes sense, people understand it relatively quickly.

On The Good Side

Don't get me wrong, there is lots of good that's going on. Now that the larger project is getting used to this new collaboration space ...

... our issue tracking list gets better every time someone touches it - and now we have consistent consolidated issue lists for all aspects of the project
... we are advancing our state-of-the-art for shared authorship; there is a lot more visibility to who is working on what, and we're getting more participation than a normal project
... the combination of all these different pieces - shared documents, issues, announcements, and other things - are massively facilitating communication, and it is noticed by the folks on the team

Yes - these collaboration tools will definitely will bring huge value and streamline communications to your project. Just don't think it's easy or obvious.

Previously ...

Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Butting In to the Conversation: PM Communication Tools (February 26, 2008)
The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
The Innovation Generation and User Interfaces (April 9, 2008)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Is SharePoint WSS dangerous to SharePoint contractors? (February 4, 2009)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)

Technorati Tags: collaboration, hands on, Knowledge Management, people management, PMO, project management, technology, Web 2.0, wiki,

The Delicate Art of Pushing Back

2009-07-05T18:33:00.002-05:00

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

PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
How to Win at the PMO Prioritization Game (December 18, 2007)
Don't Accept Snap Answers Too Quickly (July 6, 2008)
The Power of Paper in Business Communications (October 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
PMO Nirvana is a Conversation, not a Schedule (February 22, 2009)
Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)

Technorati Tags: collaboration, innovation, people management, PMO, project management, tech management, vendor management

Over / Under Communication for Project Managers

2009-06-29T20:16:00.001-05:00

It is often said that you can't over-communicate, but I'm willing to bet most folks - and especially your project sponsors - underestimate the cost and effort of this critical component of project management. Consider this fair warning - and a good checklist for folks wanting to get into IT, project, or functional management.

Media

To achieve any decent amount of success, you have to be a good communicator with both face-to-face and written / published media.

And by "good" I mean both "comfortable" and "effective". You should feel good in your own skin, confident that you can carry a conversation at all levels of an organization. And you also have to be an effective communicator - able to get your point across with the right amount of detail, not too much or too little. Another effectiveness challenge is the ability to balance between personalized, one-on-one written & oral communication, and insightful, understandable mass communication.

Translations

You may not realize how many different "languages" you speak - and effective managers must be reasonably fluent ...

Languages - Finance, Operations, Sales & Marketing; business groups have just as many confusing specialty words as the techies in IT
Dialects - Do you speak Oracle or SAPanese? Experienced in small companies or large corporations? Public vs. private? Entrepreneurial or slow growth? High volume low profit FERTs, or low volume, high margin custom products? The concepts are all the same, but sometimes the specific words are different.
Slang - Slightly different than dialects - all companies, organizations have local shorthand term so that over the years in their particular organization to mean very specific, nuanced things.
Sound Bites - A form of speech where a complicated topic is reduced to a single word or phrase. For example; ATP. Are we talking about master data, settings on time fences, the process of checking for availability, or the policies around A, B, C and D companies? Sound bites can sneak into conversations and you could be discoursing for 15 minutes before you realize you're talking about two vastly different things.
Strata - Management v. line, Middle v. executive management. Depending on what level of the organization you're talking to, you will need to change the level of detail that you go into. Typically, higher up in the company means a lower level of detail that they want to wade through.

Change Management

Volumes have been written on this topic, but most people have trouble coming up with a concise definition of what this means. To oversimplify - but drive right to point: change management is typically about delivering "bad news".

However, "bad" can mean different things. It can be "disappointment": the date will slip, we're over budget, or we can't fit this feature request into the schedule. However, adjusting expectations as early as possible is one of the basic skills of a good project manager. You need to be willing to deliver bad news like this as early as possible.

The other significant area of "bad" - walking into an organization, a group of people, or a individual's cube, and letting them know that the way they have been doing things for years is about to change. Sure, it's easy to say that "change is hard" and "change is inevitable", but you yourself probably don't like change in your established rituals. Empathy is the key here.

Lessons Learned

As with many other things, the more project communication you do, the better you get. Some of the more common lessons learned:

Defensive project teams will often negotiate for delay by asking for / waiting for More Communication, and complaining about Not Enough Communication
In any project plan, you will underestimate the time required for communication, the number of times you'll have to repeat the message, and the ability of the team to consume your communication in various forms of delivery media
You will definitely underestimate the time required for follow-up and follow-through to make sure it's Done
You will overestimate the amount and quality of existing documentation, and the ability of the project team to bridge the gap to the required level of documentation

Here's the killer -

If you try explaining to management about the problems / challenges of communication, they won't listen and/or won't understand (yes, that is a tight loop)

Machines will never replace us - but this is one case where sometimes, you might wish they could.

Previously ...

Communicating Complex Technical Concepts (March 21, 2005)
Euphemisms, and a career-extending paradox (July 11, 2005)
Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
War Stories from the Change Management front (August 21, 2006)
Communication is the responsibility of ... (August 19, 2007)
The Five Fundamental Rules of Project Management (October 15, 2007)
Butting In to the Conversation: PM Communication Tools (February 26, 2008)
There ain't much IT in IT Management (May 7, 2008)
Can you, should you, bother Executives with The Details? (May 30, 2008)
More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions) (June 12, 2008)
The Power of Paper in Business Communications (October 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
I Think I'm Learning SAPanese ... (November 22, 2008)

Technorati Tags: communication, documentation, Knowledge Management, people management, PMO, project management, tech management,

Failing Faster

2009-06-14T11:30:00.002-05:00

Here is a simple question to ask yourself: do I insist on solving problems myself? A noble goal, until it takes too long to get the answer. Why don't we fail fast enough to ask the question to someone who knows? Remember, we pay a ton of money for annual maintenance to our enterprise software providers, so we should [more quickly] be "giving up", and submitting the question to the "experts" to get to answers quickly.

In an earlier post, I asked Would you like me to Google that for you?, which is kind of a sideways slam - IT people can and should be able to get questions answered on their own. So, why is it that some folks search Google or consult other experts, and get their questions answered quickly - versus insisting on figuring things out for themselves? My personal theory is that they're not "lazy" enough; I've got many other things to do, so I want to find a quick way to answer those questions. (Note that laziness also makes me want to find the good, solid solution and not the quick-and-dirty one, because I don't want to have to come back later - I'm proactively lazy.)

It possibly has something to do with maintaining face in front of your manager ("I think someone expects me to figure this out …"). Corporate culture may tend towards a desire to get something "done to quality"; I have to get 100% of my requirements into the finished project, and if it takes a long time - so be it. Or, it could just be that you are lost in the problem, and are not aware that time is flying and nothing is happening.

It may take a bit of humility, but the truth is often more humbling - folks don't care if you solve the problem, they just want the problem solved.

However, it is also true that when the dust settles, people will remember that you got the problem resolved - method is less important than results.

Previously ...

There ain't much IT in IT Management (May 7, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
Would you like me to google that for you? (March 11, 2009)
Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)

Technorati Tags: collaboration, design, development, people management, productivity, project management, tech management

Who owns Master Data in your company?

2009-05-30T15:14:00.001-05:00

I've had to respond to this question, inside and outside of the company, in a number of different conversations over the past few days. It's interesting, because this is one of those conversations where semantics mean a lot - what people say is just as important as what people don't say. I only mean that people assume their listeners have precisely the same understanding of the concepts - which is often a mistake.

Case in point - who owns the Master Data? It seems obvious to many IT folks, having dealt with ERP and data warehousing in the past, that the business owns the Master Data - it's their business, right? Then why so often does the business look to IT to take the lead on cleansing / populating / defining / loading Master Data?

Business owns the Master Data

... they make the decisions on specifics. What should the next item number be? How should we structure the routings? Who defines the standards for bin / storage location / building / plant / campus identifiers? What is the desired format for capturing customer street addresses consistently? How will we set up the chart of accounts?

The business knows that who and the why of Master Data.

On the other hand, and in most companies ...

IT pwns the Master Data

Yes that is the correct spelling. For those who don't know, it’s a hacker term; when I pwn the system, I have a root, I have a system admin access. I understand the technical underpinnings and details - I know how everything fits together. I know how to do anything I want with the system.

In Master Data terms - IT understands the data architecture and the interdependencies. They know all the transactions required to enter data into the system, and what security roles are in place to limit access to those transactions. IT also has tools and knowledge on how to extract data from the database and batch import data en masse.

IT knows the what, when, and how of Master Data.

What does that mean?

When an organization needs to get its Master Data in shape, it's going to be a team effort between business and IT. The business must take the lead, making and clarifying decisions and driving the details. But IT absolutely needs to be right by their side, helping with the mechanics.

Previously ...

Putting Data into Context (February 28, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
War Stories from the Change Management front (August 21, 2006)
I Think I'm Learning SAPanese ... (November 22, 2008)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)

Technorati Tags: best practice, design, people management, project management, SAP, tech management,

Notes from SAPPHIRE 09

2009-05-16T10:45:00.001-05:00

Yesterday at work was "catch-up day" from a week at SAPPHIRE 2009, the annual user conference for SAP. As with the JDA/Manugistics conference earlier this year, there were concerns that attendance was going to be low, because so many companies are limiting travel expense. At the conference, I did hear that attendance was only was 60% lower than last year.

Conferences like this are great opportunities for IT to do a ton of learning - about the specific technology, of course, but also about the state of mobile computing and collaboration, tools that we are apparently trying to get the rest of the business world to adopt. Experiential learning, real-world experience - always better to talk about something that you know works / doesn't work in a practical setting. (No, I don't suggest you replace Quicken with SAP at home, although that might be a growth area for BbD).

Twitter at a Conference

I wrote up my trip report / internal blog entry yesterday (Friday), but I was twittering a lot during some of the sessions, so it was an easy write up - I just cut-and-paste from my personal timeline. Using the Blackberry during the conference was a pretty good experience; I could take fairly detailed notes on what was being said - plus, I can throw out passing Tweets on the way. Near-real time knowledge sharing - very nice for folks in the Tweeterverse, watching the information go by.

Unfortunately, it's a bit difficult to engage in a Tweet-versation with these client devices; the screen is too small, and you only see what you are typing. I did, however, latch on to the #sapphire09 hash tag to come up with a workable monitoring process. I found that search.twitter.com presents a decent RSS feed, one that the Blackberry browser consumes quite nicely. I don't know if this is a "native" RSS reader in the blackberry, but it worked amazingly well - I made a passing mention of one of the sessions I attended, and someone asked for more detail - so I ended up tweeting almost every slide.

Apotheker

The Tuesday morning address by Leo Apotheker started with some doom and gloom about the economy, but that was just a lead-in to SAP's new branding message of promoting "clarity" for the enterprise; making pertinent business information easy to access, easy to see. Some of my tweets from the speech … I clearly (sic) have a different editorial style ...

Apoetheker starting with the doom and gloom #sapphire09 7:38 AM May 12th
My inner cynic is subsiding - I actually like the appeal for "clarity" #sapphire09 7:42 AM May 12th
Are "clear enterprises" like "glass houses"? (Sorry, cynic is back) #sapphire09 7:44 AM May 12th
Is he about to say sap could have prevented the economic collapse? #sapphire09 7:56 AM May 12th
Ah, just the story of how goldman sachs did ok because they actively manage risk #sapphire09 7:57 AM May 12th
We need a simple example of how a manufacturer manages risk #sapphire09 7:58 AM May 12th
SUGEN KPI Framework for enterprise support - nice focus on transparency #sapphire09 7:59 AM May 12th
Props - a pretty effective live demo of a blackberry enabled work process #sapphire09 8:03 AM May 12th
The carbon footprint app looks interesting - this is a recurring theme for recent presentations for me #sapphire09 8:17 AM May 12th
I think its a harsh. retroactive self criticism when this "speedy query" demo admits that a simple query would take 'weeks' #sapphire09 8:27 AM May 12th
SRO crowd at presentation for information "dashboards" - yet another recurring topic, still unmet need #sapphire09 1:11 PM May 12th
Sap guy was apparently unable to say "eat our own dogfood", too closely related to microsoft hhh #sapphire09 1:19 PM May 12th

The most interesting areas of Leo's conversation had to do with the metrics being created by SUGEN (not), a collection of all the national user groups (like ASUG). SAP continues to get lots of pushback from the customer base about their increased support fees, and these metrics are going to allow us all to see how SAP is performing.

Plattner

The Wednesday morning address by Hasso Plattner, one of the founders of SAP and a pretty interesting guy, started out like a technical lecture at engineering school about in-memory databases and columnar data. By the end, it had transitioned to a Business Objects demo and a tool "easy enough that a CEO can use it". Here are some tweets from that speech …

Hasso on speed [sic] - spotlighting the reams of data and the need for decent access tools #sapphire09 7:44 AM May 13th
Hasso is very professorial - if it weren't for the subject matter, methinks more would pass on the talk #sapphire09 7:53 AM May 13th
Ok, reading other #sapphire09 tweets now - is a shoe dropping right now? Re sap and hardware ... #sapphire09 7:57 AM May 13th
Someone should register spaghettibeforecooking.com #sapphire09 7:59 AM May 13th
Maybe hasso's point is that clarity / speed yap from yesterday is not smoke and mirrors - solid tech supporting this sales stuff #sapphire09 8:16 AM May 13th
Insert only - like the old one-write accounting systems - ledgers in pen. Make a mistake, back it out. Complete auditability #sapphire09 8:19 AM May 13th
Is insert only / read only db stuff analogous to RISC chips? Who needs elegance when you think Real Fast. #sapphire09 8:20 AM May 13th
Head-snapping shift from professor to jester #sapphire09 8:23 AM May 13th
Hasso rips on EIE processing (everything in excel) #sapphire09 8:24 AM May 13th
Oh, I think he just said he is talking about t-rex #sapphire09 8:29 AM May 13th
Hasso is definitly tech at heart, rips into classic demo style of demo on mini data set #sapphire09 8:30 AM May 13th
hasso's enthusiasm is honest, like the literate engineer given a moment of exec management's attention #sapphire09 8:34 AM May 13th
Awesome animated pipeline #sapphire09 8:41 AM May 13th
Boy he started slow but has he hit stride in last 10 min #sapphire09 8:43 AM May 13th
Table scans not considered harmful #sapphire09 8:48 AM May 13th

This was pretty interesting technology - high-speed, insert only databases. Not sure what that means for the long term of our existing databases, data warehouses, and hardware. But hey, it's only capital - right?

Elsewhere On the Web

General interest / watchfulness towards the SAP strategy, as the company faces questions like technology platforms, support fees, and a new CEO …
Fortune magazine’s totally non-technical take on Leo Apotheker …
Vinnie Merchandani’s summary of show hilights, plus insights on SAP’s long-term strategy
SAP and Social Networking – I didn’t catch these presentations / conversations, but many are writing / tweeting about it …
Definite focus during the week on Business Objects … it actually looks pretty good …
Some summary comments from ZDNet …

Previously ...

Two observations from SAPPHIRE (April 24, 2007)
Supply & Demand and Expectations for SAP talent in the US (April 30, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Five More Realities for Driving Business Value from Technology (January 30, 2008)
The Innovation Generation - Communication Styles (April 1, 2008)
Opportunistic Insights from the RSS Stream (June 5, 2008)
On the Road: Business Travel, Fall 2008 (October 13, 2008)
Field Notes: Video Conferencing for Business Conversations (March 22, 2009)
Five Stages of Twitter Relevance (April 21, 2009)

Technorati Tags: blackberry, collaboration, SAP, sapphire, sapphire09, #sapphire09, technology, twitter

Wikis in High School

2009-05-03T15:17:00.001-05:00

Last month, Vinson wrote about the use of wikis in school projects, and it reminded me to dust off some notes I took from a conversation with my daughter Sean MacLennan, late last year. It was a history project about World War II, and the class was asked to compose their reports on a wiki. Sean is a pretty good writer, and she likes to write, so I was interested in her thoughts on the wiki as a medium, and the collaborative process ...

Since there were so many parts of WWII, the wiki format helped, because you could break it down into categories - chunk up the tasks into parts. Plus, we could create the categories we wanted, under the outline [stubbed out by] the teacher.

There were 24 kids in the class, but this was a project across multiple history classes [4], so we're talking about 100 authors. All were split into groups of 3-4, each had to do part of the shared paper. Each group had their own subset of the assignment, and built their own mini-wiki - a home page plus 10 pages of "categories" or topics.

We literally started with a blank sheet. The assignment handout had the high-level outline, but we had to key it into the wiki / web site to get things started.

So, much of the lesson was about the mechanics of the new medium.
Q: How did you carve up the assignment?

We used the sidebar to create the sub pages and a table of contents. Everybody got in a workgroup, discussed how to divvy up the categories, and then started to work on their own pages - add the page, then fill it out. We got to give feedback, too - we had to critique each other's work, but it was more like "ooo, stop, you are adding too much text". I noticed some competition / peer pressure starting, to add as much as the other people.

We could add pictures, links to other web pages, and references to Wikipedia with a hot link to it.

One challenge I noticed: some were copying and pasting from the web, and adding no value or reading what they were copying (ex "... if you look at the picture below ..."). Some were not putting a lot of effort into it, and the others thought this might bring the group's grade down; we were definitely nervous about it.

"Peer review" extended to looking at other pages in your own group and grading them.

So, participative collaboration is part of the lesson as well - the group dynamic, and the idea that not everyone wants to be an author. She also hit the issue where one person needed additional training, and hands-on assistance with some of the mechanics (ex. how do I make a table?) - yet another form of collaboration, and plus awareness of the need for web 2.0 tools to be easy to use (transparent vs opaque?)

What about grading?

There was no coordination on look/feel of the overall structure - once the groups had their subset, they just did their own thing. However, the grade for the group was partially based on whether or not all the information came across. No bonus for the group grade on style points; one person's page could include images, maps, even videos, and another page could just be text cribbed from elsewhere. The individuals got points on their content, but the only part of the group grade was simply whether or not the list of categories was covered. There was some part of your grade for content, however - had to include at least one image, table, graphic, etc., and those had to be spread out reasonably well. There was a target list of 10 content add-on elements, and they had to be spread evenly across the group.

So it was a technical learning event - how to build a page and add content (text and other) - but not a qualitative thing (how good was the writing?).

Any last comments?

No, just get this done and go set up the Wii to the internet, so I can Mario Kart with my friends!

Clearly, there is more than one way to collaborate!

Previously ...

Consarned whippersnappers (Generational Diversity) (May 20, 2007)
Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
The Innovation Generation - Communication Styles (April 1, 2008)
Stretching Your User Interface Design Muscles (April 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)

Technorati Tags: collaboration, Knowledge Management, Web 2.0, wiki

Business Benefits of Social Networks Exist, but ...

2009-04-25T23:10:00.001-05:00

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

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

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

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

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

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

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

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

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

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

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

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

Previously ...

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

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

Five Stages of Twitter Relevance

2009-04-21T22:36:00.005-05:00

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?

Pointless: This has absolutely no value add, a complete waste of time - get back to work!
Cute: An interesting and different communication medium, but I gotta get back to work. Maybe over lunch ...
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 ...
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 ..
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)

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

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

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

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

Practical Innovation Lessons from Software Vendor R&D

2009-04-16T22:03:00.001-05:00

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

The Innovation Generation - Communication Styles (April 1, 2008)
The Innovation Generation and User Interfaces (April 9, 2008)
There ain't much IT in IT Management (May 7, 2008)
Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Inspiration, Images, Insight, Imitation, Innovation (December 19, 2008)

Technorati Tags: design, innovation

Location, Location, Location: Terminology Confusion in ERP Projects

2009-04-11T19:12:00.002-05:00

Have you ever experienced the clash of terminology that results when supply chains are brought together, due to acquisition or merger? The typical scenario: different groups using multiple terms to describe where product is manufactured at and shipped from; folks use terms like "location", "plant", and "site" interchangeably, and confusion can result - are we talking about SAP configuration? Wide-area network architecture? Rollout plans?

To communicate effectively, it helps to clarify things. Here is a starter list of terms from projects I've been involved with. Care to add / edit the list?

Generic Terms

A building is what it sounds like - four walls and a roof.
A facility could refer to one or more buildings.
A campus is a generic term for a group of buildings.

Specific Terms - ERP

In SAP, a Plant is a place where materials are produced, or goods and services are provided. A Plant is made up of one or more buildings.
In some Warehouse Management Systems (WMS), a Warehouse refers to a single building. In SAP, a Warehouse is a collection of Storage Areas; a building can contain multiple storage areas, and a warehouse can span multiple buildings.

Specific Terms - WAN

A Site typically designates a point-of-presence to the Wide Area Network (WAN) - a cluster of WAN devices that connects one or more buildings to the network.

Details!

A Chinese proverb states, "Wisdom begins with calling things by their right names." When bringing companies and cultures together, project managers need to pay special attention to the words; we must be very precise with our language, so everyone understands that we are all talking about the same thing.

Previously ...

Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
Need to watch my terminology (August 16, 2005)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Communication is the responsibility of ... (August 19, 2007)
The Five Fundamental Rules of Project Management (October 15, 2007)

Technorati Tags: best practice, documentation, Knowledge Management, project management, SAP, supply chain

Practical Applications of Twitter in Manufacturing?

2009-04-05T16:33:00.001-05:00

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

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

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

The Tweeter as Information Source

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

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

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

The Tweeter as Information Consumer

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

Web 2.0 Technology and Manufacturing

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

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

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

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

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

Previously ...

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

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

Field Notes: Video Conferencing for Business Conversations

2009-03-22T10:52:00.001-05:00

This past week saw my first experience with video conference calling - something obvious to consider in these tight economic times. Some observations -

I got quick feedback that my original camera position was disconcerting for the others. I had put it off to the side, which made me look “off camera”, almost in profile, while in conversation. As I thought about it, I agreed - because if I was looking at me, it would be weird / annoying. I do not like it when the person I am talking with is not looking me in the eyes.
On that note - when we're in a conversation, I'm typically looking at a 6” circle around your eyes. When on a business / working video conference, however, I’m looking at a 2 x 2 inch square picture of the speaker - because we all have other windows open, looking at documents / programs under review. It’s feels more like a “talking heads” newscast than a conversation ...
… but you have to take the good with the bad. The ability to bring up a spreadsheet or presentation or application on a shared screen is quite powerful - participants can “see what I see”. You just need to understand that this is a multimedia conversation, and not simply a replacement for a phone call.

On the other hand - my family uses Skype to stay connected with our daughter away at college. When we make the call, we’ll flip the video feed to full screen - and since the web cams on our respective laptops are perched right above the screen, our eyes are focused reasonably close to the other person's face. Simple conversational video calls, without the multitasking overhead, are reasonably effective.

Microphone configuration is also very important; some folks are using headsets, while I use the microphone incorporated in the video camera. I prefer this arrangement; I’m already comfortable with using a speakerphone on normal calls, and prolonged use of an earpiece gets a bit annoying. The key, however, is to get everyone to correctly configure microphone settings. Everyone's volume was a little different, and it impacted the smooth flow of conversation.
We are using inexpensive web cams, not highfalutin’ conference calling hardware. In this scenario, the system does a reasonably brilliant job of flipping camera control to whoever is speaking. This seems obvious, but I noticed that when I was speaking, your remote view doesn't bother flipping to your feed - it stays on the last speaker. This can be a tad disconcerting if that person reverts to typical conference call habits, and looks away / does a little multi-tasking.
I also noticed that people were much more cautious, or overly polite, about talking over one another. I assume that as we get used to holding conference calls in this format, we’ll get more comfortable with the interruptions.

Later in the week, I had a long conversation with a colleague in Germany. Here, the video call format is very effective. Typically, I prefer face-to-face conversations to phone calls - you can react when someone's facial expressions signal a lack of agreement or comprehension. Of course, this is not practical with meine freunde in Deutschland, where language differences exacerbate the situation. The video call solves that problem immediately and effectively - I found myself communicating in face-to-face mode now, with hand gestures (ex. air quotes) and facial expressions indicate agreement, keep the conversation moving along.

Like any bit of technology, reality is not as smooth as the sales pitch makes it out to be, but still a very effective tool, and something that can be experimented with quite inexpensively.

Experimentation leads to experience, leads to effectiveness.

Previously ...

International Meetings - Pick a Convenient Time (April 1, 2005)
Challenges when demoing / training / pitching complex systems (May 23, 2005)
eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
Hand writing recognition - harder than colored bubbles (November 19, 2005)
Waiting outside their office (February 14, 2006)
Catching up on Mind Mapping; collaborative tools and some "market research" (May 13, 2007)
Alternative KM Tools (3 of 3) (September 25, 2007)
Power Outage Follow Up - Observations (March 28, 2008)

Technorati Tags: collaboration, hands on, Knowledge Management, productivity

Low Tech SharePoint Hack: Project Status Indicator

2009-03-14T15:06:00.001-05:00

I'm doing a little hacking in SharePoint that is pulling together a few ideas from the past:

Keeping my tech skills sharp
Knowing when to search for the answer (vs. stubbornly sticking with DIY)
Communicating status tersely but effectively

Apparently, I'm also trying to answer a question that is meaningful to many others, as it is used as an example in the Help files for Microsoft's online SharePoint guides, the add-on Web Parts we use here, and many other places. Why doesn't Microsoft make something like this a standard feature?

Note that I had some fairly specific requirements in mind for something that I would consider "low tech". this should be an approach that the average (read: non-IT) SharePoint site admin could use. I don't want to require third-party controls, nor do I want to require the use of SharePoint Designer. I'm also shying away from image files - little GIFs to show red, green, and yellow icons; I have established a style for displaying project status in that works great with PowerPoint and Excel, and I want to use the same images consistently on the collaboration space.

Of course, I wanted to get to a solution in a reasonable amount of time (ie. Speed to Value, or being proactively lazy). A few Google searches turned up a number of resources with different approaches. The best resource was this site, loaded with excellent SharePoint hacks - including one simple concept that requires me to tweak my ground rules, just a bit. To get this to work, I have to include a JavaScript routine on the page; however, I learned a nifty trick, one of those things that is fairly straightforward, but still has to be pointed out to you before you "get it".

The JavaScript Trick

You don't need SharePoint Designer to install JavaScript routines or special CSS on the page. All you need to do is install a Content Editor Web Part (CEWP) somewhere on the same page as your list. You can bring up the Source Editor and insert any scripts, you want, nothing will display about the routines will be available to the other controls / web parts on the same page. I'm not going to copy the code here - these guys deserve the web traffic for their work, so, go to this page to copy the script.

A Lot of HTML for a Little Indicator

The actual HTML for the "green" indicator (~) looks like this: .

Unfortunately the font changes based on which indicator you need - this table shows the various components for all of the status indicators.

Status	Code	Font	Color	Result
Green	˜	Wingdings 2	green
Yellow	p	Wingdings 3	#FFCC00
Red	n	Wingdings	#DC143C
Complete	ü	Wingdings	black

My solution adds three calculated columns to the list. Why three? Well, yes, you could do the whole thing with one computed column, but the nested IF statements would be brutally complex, and I was hoping for something "self-documenting" (ie. clear and simple).

The SharePoint list in question is a typical Issue Tracker - and the first step is to define what the different statuses (statii?) are going to be. Here, I am only allowing Open (Red, Yellow, Green) and Closed - nothing like resolved or in process or proposed - we'tll keep it simple.

I then added three Calculated columns, and defined the formulas like this:

Status_Char = IF([Issue Status]="Open - Green","˜",IF([Issue Status]="Open - Yellow","p",IF([Issue Status]="Open - Red","n","ü")))

Status_Font = IF([Issue Status]="Open - Green","Wingdings 2",IF([Issue Status]="Open - Yellow","Wingdings 3",IF([Issue Status]="Open - Red","Wingdings","Wingdings")))

Status_Color = IF ([Issue Status]="Open - Green","green",IF([Issue Status]="Open - Yellow","#FFCC00",IF([Issue Status]="Open - Red","#DC143C","black")))

I've tweaked the colors - standard yellow and red don't look good with a white background. (I burned at least 30 minutes fiddling with the color tones, to make something that was visibly yet subtle. Gotta know when to go fast and when to dither over the details ...).

Add a fourth column for the actual status indicator; we use the CONCATENATE function to build the HTML string as specified above. The surrounding <DIV> is used by our borrowed JavaScript function to signal the browser to turn this little bit into true HTML.

Status_Color = CONCATENATE("<DIV><font size=4 color=",Status_Color," face='",Status_Font,"'>",Status_Char,"</font></DIV>")

Effectiveness Testing

Yes, this could have been done with a single calculated field - it's just a little bit easier to debug this way. In any event, it s a relatively large amount of code for a fairly simple effect - was it worth the effort? The ultimate test came when reviewing the list of open issues with the project team - and folks understood what was being communicated immediately. No explanation necessary - the conversation focused on the item marked "red" right away. If we just displayed the words "green", "yellow", or "red", it would take a bit more mental effort to understand what was being communicated. I really want folks to think about the solutions, and not waste brain power trying to understand the problems. A little extra effort in the code is just right.

Previously ....

The good and the bad about being a hands-on tech manager (January 25, 2005)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
Is SharePoint WSS dangerous to SharePoint contractors? (February 4, 2009)

Technorati Tags: development, hands on, PMO, presentations, project management, SharePoint, tech management

Would you like me to google that for you?

2009-03-11T23:12:00.001-05:00

Got some rare Re-Tweets today on a techie insult - so snappy, I had to write a post to use it for a title!

Deep in the problem analysis and debugging process, the typical IT hack experiences counter-balancing pressures that impact decision making - Capable Independence vs. Speed to Value.

Capable Independence is just fancy-talk for the idea that I should know what I'm doing.

Ego 1 - Who needs manuals, I wrote this thing from the ground up?
Ego 2 - Vendor support is useless, I teach them stuff whenever I call ...
Delusions of Center - I've been working on this ERP, for this company, for 15 years - I should know how this works!
Paranoia - If I have to ask for help, they might think I'm not worth keeping around ...
Pride - I should be able to figure this out myself ...

Actually, I think the truth is a bit more mundane; everybody is really busy, and it just seems quicker to figure it out for yourself than to search for some other resource, that might have a ready answer. Bottom line is, the rate-determining factor is the idea that I should be able to solve this problem - so the problem won't get solved until I figure it out!

Speed to Value is the idea that I need to get an answer quickly - time is of the essence. Unfortunately, taking the "I can(must) do this myself" option may seem quicker, but in practice, folks will jump to what they know vs. really understanding the root issue - and (more often than not) come up with a less-than-optimal solution.

I want the optimal solution - quickly, but implemented with the least amount of effort, taking advantage of standard product functionality, and (therefore) easiest to support in the long run.

Know What You Don't Know

One of my favorite war stories involves Amit, the brilliant (truly) analyst with 10+ years experience on our ERP, in multiple companies supporting multiple business models. He's seen it all, right?

We were trying to send nightly extracts to a data warehouse, so I asked Amit if he could identify all records that had been changed in the last 5 days. Amit said No (almost immediately), and I was Skeptical (just as quickly). IMNSHO, most transaction systems mark records with something like a ModifiedDate field (one of my favorite triggers ...), and I was assuming that our ERP, being a solid mid-tier platform with a long history and a lot of customers, would have also implemented this basic idea.

I knew Amit was super busy, and suspected he was answering off the top of his head - but I also knew him to be humble, open-minded, and down-to-earth "Look," I said, "I know you are a terrific programmer, with deep knowledge of the system, and I don't want to insult you, but I am going to ask what seems to be a very basic question. I don't mean to insult your capabilities, I just need you to answer very specifically ..."

know categorically

not know how

never heard of that

The answer-off-the-top-of-my-head is a way for me to quickly address a question just to get it out of my way. Sometimes "no" means "I don't know how to do that, and I don't have any time to research this". I was pretty sure my good friend Amit was trying to slough off the question, because he was already working on 50 other things for me ...

Irregardless, I asked Amit to take the time and research the question, because I was sure that any decent ERP would have this field. Next day, Amit came back to me in said "thanks for asking so specifically; I actually did not know if the system could do this, and so I did the research". Unfortunately, he was right - lo and behold, the system did not have a LastModifiedDate in one of the tables I was looking for, so we had to hack and an alternative method.

But it was still worthwhile to ask the question.

Failing Faster, Getting Lazy

Why do we insist on solving problems ourselves, and limiting the solution set to what we know? Why can't we let our self-directed searches fail fast enough to ask around for someone who might know more? Remember, your company is probably paying plenty for annual maintenance on the big software platforms - we all should [more quickly] be "giving up" and "failing", submitting the question to the experts to quickly get some answers.

In an internal blog, someone posted a brutal techie diss - Would you like me to Google that for you? The source was frustrated that the rate-determining analysts weren't even taking this basic step. My personal theory is that they're not "lazy" enough - I've got many other things to do, so I want to find a quick way to answer those questions.

The business doesn't care if we know the answers - we get credit for solving the problem!

ps. Note that "laziness" also makes me want to find a good solid solution and not a quick and dirty solution, because I don't want to have to come back later - I'm proactively lazy.

Previously ...

Excellent analogy for understanding long-term cost of maintenance (January 9, 2005)
If you want to be more than a programmer, stop programming (April 8, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
The "Army Rangers" model for IT Professionals (January 2, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
There ain't much IT in IT Management (May 7, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)

Technorati Tags: best practice, innovation, Knowledge Management, people management, productivity, tech management,

PMO Nirvana is a Conversation, not a Schedule

2009-02-22T12:15:00.001-06:00

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

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

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

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

<aside>

seven-layer stack

</aside>

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

<aside>

waterfall

</aside>

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

Previously ...

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

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

Another Take on Enterprise Open Source

2009-02-18T21:40:00.001-06:00

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

Andy Hardy, IT Director

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

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

Vertical Open Source

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

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

<aside>

for

those

guys

</aside>

Custom Often Means Really Custom

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

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

We're All from Missouri

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

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

Previously ...

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

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

KM Overcomplicates: Heisenberg Impact on a VBA Quickie

2009-02-08T12:08:00.003-06:00

Got a simple request from one of the folks in Operations; we're sending out Excel spreadsheets for some quick data gathering, might we do a little basic input validation before they send in garbage that needs to be scrubbed? This person is very sharp, knows a decent bit about what is possible, and this is definitely not something that is worth a major project engagement; "throwaway technology", a particular fave of mine.

His request was simple - just want to make sure folks enter data into one or two required columns. I've done plenty of Excel VBA, and had figured out a simple approach while we were talking (it's all in the Before_Save() event, naturally), but I couldn't really tell him how to do it - he'd never programmed VBA before. However, I do have some rather large projects coming this year, and this person's group will be very important in making timely decisions, implementing change - so I figured that a little lagniappe here would pay big dividends down the road.

Of course, I knew there would be some I couldn't get all of his requirements right away - I've done many similar things in the past, and could anticipate a number of requests down the road. So, a few minutes of Q&A, and I got a decent set of requirements for future flexibility that, if I do a little extra coding now, I could make much simpler in the future.

you may want to jump to the bottom of this post for the lessons learned ... gets a bit tedious here ...

"Teaching Event" Explodes Scope

Of course, I didn't want to become the maintainer of another shadow system, so I need to keep this simple. And, I really think there is a lot of potential in quick-and-dirty Excel automation that would do great things for many companies - if more folks knew how to do it. So, I resolved to make the code as modular and self-documenting as I could; I will publish a generic version of the spreadsheet on my code page, so it might be useful Out There as well.

Then again, I have written before about the difficulties of documentation, and I fully appreciate the fact that knowledge capture, while always valuable exercise, adds a lot of overhead - time and complexity, and required concentration. So, I thought I could compound the complexity even more by journaling the programming exercise "real time", to get some measurements on how much of an impact "good" tech documentation can add. So, I'm composing this blog entry "real time", to capture a little data.

And, because I just can't seem to leave complex enough alone, I'll leave my Twitter client [current fave: TweetDeck] up, and do a little play by play for the Twitterverse as well. Not that I expect much feedback, it's Saturday evening; had a nice steak dinner with the family, hopefully I'll stay up through the end of the experiment.

Time Line - Saturday

8:55 pm
He gets a Bright Idea, and starts the blog entry.

9:15 pm
The KM preamble (above) is done, start opening windows. Before I get going, I'll have four apps open: Excel and the Excel VBA editor, plus a Google Doc (this entry) and Tweetdeck.

I did grab a sample of the spreadsheet to be sent out, with the various columns, header rows already defined, so that's a nice start.

9:18 pm
Fractal nature of KM - had an idea to #hash tag all the tweets together, so had to go retroactively tag first tweet. Maybe I can code soon ...

9:20 pm
Proof of concept / flow was just a message box in the BeforeSave event. Now, I'm off stealing code from old stuff - processing row/column arrays with somewhat predictable locations and dimensions. I need to make what are basically simple loops 99.99% driven with variables, no hard coding. This is the fundamental way to deliver flexibility.

I also will assume future applications that will have multiple tabs with a different data input table in each tab - so will need to build a master loop that runs thru all the tabs.

9:25 pm
Coding finally starts, with a search thru old ssheets. 2-3 more windows opened up. I'm commenting the code while I'm writing it, so the coding time isn't just raw coding

9:50pm
All stolen code, but built basic structure to process multiple sheets, handle errors at dropout at the end. I think folks might read this source code and get intimidated by VBA - hmmm, might not be helping things. Ah well, on we go ...

10:00pm
Some actual new code, still mostly cribbed from other projects - but I'm aggressively genericizing. Also, first comment from twitterverse (@faseidl). Will have to Follow commenters later.

10:05pm
Gonna steal some ReDim syntax, rarely do that, always have to reuse

10:15pm
Been coding for 45 minutes since the last debug, never timed it like this before, kinda interesting

10:33pm
Code is flying, flexible error checking loops all built - writing the magic line of code "If blank then error" now. Probably should structure this bit of code to allow for different types of error checks (<, >, limits, etc.)

10:45pm
Aha, basic loop works, but I made a mistake in my assumption of how to control the thing. I need to specify a column that I will assume is always filled - when I see a blank there, I stop checking. I'll have to write the "end of check" to be a warning "note: I am stopping here ..."

11:00pm
Ok, it's all done, tested, working just fine. Code was about 140 lines, not a lot. Will do final documentation and code clean up tomorrow morning - kinda tired right now.

Time Line - Sunday

9:45am
Ok, back to it - should be able to finish this up right quick, one would think. Some quick math on the time line above: Roughly 40 minutes (32%) of documentation, 85 minutes (68%) of coding. Not really quantifying how much longer the coding took because I was aggressively cloning (speedup), commenting (slowdown), and genericizing (slowdown).

The sheet works fine, but I do have some work left. Need to package it all up for the original requester, so he knows how to change things; also need to genericize the final thing, so I can publish it / share the knowledge. Again, I'm trying to capture the teaching moment opportunity.

First run throuught the code was to add comments / documentation so folks know how to extend it. The target audience ranges from technically savvy, but no VBA experience, to VBA hackers - I think it's all in how I structure the code.

9:59am
Getting some additional coding in - trying to take out as many opportunities for typos and such as possible. Restructuring the code so I only have to code the name of the tab to be checked once. I'm actually doing a bunch of coding here, trying to make maintenance as easy as possible - I know these aren't the most elegant methods, but I am growing conscious of how much time this is all taking. Tradeoffs, always tradeoffs.

10:18am
Code cleanup done - but in testing, noted something I forgot to add. Data checking loop ends with first blank in the "check column", but if that's a mistake, and there are data rows below, I should give them a chance to see that - so I'll let them know what I think has just happened. A bit more detail than just a "success" message - again, this is a data quality check based on my experience with similar spreadsheets.

10:31am
Fine, the actual programming request is done. An email to the requester to deliver, but then I need to finish the Distribution part of KM. Note how I am short cutting the knowledge transfer part of this exercise for the requester - in my email, I told him to let me know when I might drop by, to walk him through the editing / changing process.

Lazy? No, actually quite practical. I'll be walking him thru the process of making changes to VBA, and I'm not about to document that. Just show him how the basic sheet works, and give him hints on how he can read more , make simple changes if/when interested. I also need to make sure he understands this is not something that IT will "officially support" going forward - just a quick-and-dirty bit of macro coding for a friend.

10:37am
Now, I'm carving out the code, prepping a sample ssheet for sharing ... to be posted on my code page. Note that I'm doing some "documenting" by generating sample data, including an error!

10:52am
Here's is the part of KM that really drives tech folks nuts, methinks. It's "prep for final distribution", making everything digestible for a broad, unknown, unanticipated audience. Up until now, the total stands at 75 minutes (39%) documentation, 117 minutes (61%) coding - but from this point on, it's 100% documentation. Remember, if a tree falls in the forest, no one hears the sound; documentation won't help until the code is all checked in, text is cleaned up to be made readable, and everything is put where it can be indexed and found.

11:00am
Just starting the editing pass on this blog post - typos, prose formatting When I'm documenting on the fly, I'm not trying to make it look and sound pretty, I'm trying to capture the ideas. However, must invest in the look/feel of final product, else folks won't read it, understand it, or believe it.

12:00 Noon
I'll stop the timer on the documentation here - this is a ton of work compared to the size of the original. Just starting the editing pass on this blog post - typos, prose formatting. When I'm documenting on the fly, I'm not trying to make it look and sound pretty, I'm trying to capture the ideas. However, must invest in the look/feel of final product, else folks won't read it, understand it, or believe it.

Lessons Learned

Twitter definitely adds overhead - can't quantify it easily, and it was also difficult to keep remembering to post status updates there. Might be because it's still a new tool, I'm just getting used to it, but it's a different kind of overhead than the blog entry.
There is a chunk of complexity added because I'm flipping between different windows. Two large monitors helps, but KM requires multi-tasking; if your teams can't actively, effectively juggle four threads at once, you'll never get good documentation out of them.
Programming for speed? Hardcode, don't go for flexibility. The coding time was easily double since I was anticipating reuse, etc.
Only the one comment from the Twitterverse while the project was underway - not sure if that was time of day, target audience, or what. Twitter is still opportunisitc, hit or miss communication - hence the interst (I think) in building up follow lists (ings and ers).
Knowledge capture and sharing can be a relationship management and change management exercise as well. The ability to capture things in writing are important, but not everything
Final time stats, rounded off: Coding 120 minutes (60%), Documentation 80 minutes (40%). I can speed up coding with reuse and practice, but I can also speed up documentation with practice! Don't give up on documentation because it's going to shave 40% from all of your effort estimates - unless you honestly track all of the lost time spent looking up definitions, requirements, previous art.

KM is not free, but I think the value is only seen retroactively; folks that have gotten burned with lost requirements, or forced to do rework because the framer's intent was lost - they seem to be the folks skilled at and committed to KM.

Previously ...

Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)

Technorati Tags: best practice, blog, development, documentation, hands on, Knowledge Management, twitter