cazh1: on Business, Information, and Technology

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

Is SharePoint WSS dangerous to SharePoint contractors?

2009-02-04T23:10:00.001-06:00

Firing Up Internal Opportunity

It was true last year, but even more so now; SharePoint is very important for corporate IT, both strategically (medium- and long-term) and tactically (short-term). Sure, it's a terrific way to iterate on collaboration, internal portals, document management, etc. - "enabling innovation" in every buzzword-compliant sense. But there is solid benefit for even short-sighted, plodding, tactical IT - and it's all about staff retention.

SharePoint WSS represents a nice opportunity for folks in IT to get some hands-on experience, building relevant (if small) applications with some "cutting edge" technology. Staying "cutting edge" is important for most IT folks, but let’s face it – most of us don't work in software development houses. The typical manufacturing company spends <3% of revenue on IT; on top of that, the current economy has everyone focused on cash flow. I was speaking with a vendor yesterday evening, who told of his interactions with IT management in multiple companies over the past few weeks - and the primary concerns all had to do with system availability and cost cutting.

This nuclear winter environment, freezing spend on training & tools, would typically drive all your best IT talent away - we all want to work on latest and greatest, and experience non-trivial growth in our skills. So, how might you feed this "edge mentality", with little or no cash?

SharePoint provides both sizzle and steak ** - it’s got market hype, it looks and feels significantly different than your current, boring green screen stuff, and it’s fast twitch (small projects, lower priority, low risk if something messes up). With all that going for it, it should be easy to get internal folks to work on the new, quick and dirty stuff that the business wants.

** Ok, maybe not Morton's, but it's not Steak and Shake, either!

Drying Up External Demand

Unfortunately, I think this leaves SharePoint consulting houses bereft of good opportunities. Cash-hoarding businesses turn inward for their development needs - and this time, they can get good-looking results!

I remember when .Net came out a few years ago - had a very enlightening conversation with a typical small-firm rep. Microsoft's new technology platform was great for sales, the story went, because the projects all took 30% less time than before (such a deal!) Unfortunately, the other shoe soon dropped, and the sales team had to generate 30% more business just to keep the pipeline full and billable hours flat to the previous year. The downward pressure on rates wasn't a help, either.

Stable [end-user] companies may not fear large turnover in the current economic client, but the good ones will continue to stress internal training and new technology skills. I see plenty of SharePoint interest (and resulting bandwidth) from internal IT - where will this leave the contractors?

Previously ...

The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
Stretching Your User Interface Design Muscles (April 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
Field Notes: Lean Times for IT Services (November 29, 2008)
Hacking the Google Chart API from Excel (January 17, 2009)

Technorati Tags: application, collaboration, design, development, hands on, innovation,
SharePoint, Social Networks, technology, Web 2.0

News for Wombats: Taming Unreasonable Requirements

2009-01-26T19:44:00.001-06:00

I've heard from a couple of friends about some "classic" project requests - dilemmas they have recently faced. These unreasonable requests can be turned into something achievable and, potentially, more relevant / meaningful to the requestor, by approaching the problem from a different direction.

Request for Data: the Analytics Project

Classic scenario #1 arrives courtesy of the external Experts, analytic genii (sic) promising to reveal secrets of profitability and sources of revenue buried deep within our data sets. Their "simple request" is to pull all data from the system - customers and orders, vendors and payments, items and inventories - all classified by OBC; the Obvious and Brilliant Categories that, when summarized and sorted, will unlock our Big Opportunities.

Pulling data from the system is easy, but the desired attributes often do not exist in the system - or, they exist, but we have not (to date) filled in those details on our orders / payments / inventories. So, IT is asked to coordinate the bursting of data into separate spreadsheets, and distributing data sets to various areas of the business, to the people who know how to categorize the uncategorized.

Note the hidden work the consultants have pushed down. IT must frame the question to the business (can you categorize this data?), but they are often left with the task of explaining the original project and justifying this interruption. Remember, when the programmers came in this morning, this Data Collection project was not on their radar screen. Of course, this is perceived as IT resisting, being uncooperative ...

Sound familiar? It should, I've seen it at many companies, many functional areas of the business. There are some Obvious Truths that jump out when you think about this for a bit ...

The Data is not Missing - we just never collected it before. Truth is, if we were already categorizing data this way, we'd probably be paying attention to the Big Opportunities already!
You're Just Moving the Work from the analysts to IT. True, internal IT will probably know the quickest way to get the most accurate data, but why push off the communication / explanation stuff?
There is a Hint of Diminishing Returns here. If 100% of the data is categorized, a simple pivot table will elegantly show all the data, totaled by attribute and sorting the Big Targets to the top. However, most of the time spent is getting the "long tail" of special cases categorized; wasted work, because they won't make the Pareto cut.

Aha - that last one gives us a hint on how to slash the amount of work required to get actionable data in a reasonable amount of time. Haven't the external Experts seen data sets like this a million times? They are, after all, selling their experience in the problem space - why not engage in some targeted research? Based on experience, for companies of our type and size, what do you expect the answer to be?

What cross selling opportunities are the most common?
What aggregate buying typically get the most bang for the buck?
Which product families are typically the slow movers?

Jump start the data categorization by guessing the Pareto sort, and target that data for characterization ...

Download 100% of the data – must always be able to do a hash total to prove we have it all
The download / work files have blank columns for every requested attribute
Scan through and mark all the data for the target category

Battling What "They" Say

A similar problem is often faced when proposing system and process change. A classic refuge of the change resistant is to stand behind an Unassailable Truism with a potential for problems ...

Not all of Our Vendors are ready for EDI ...
A great idea - but how will this impact The Customer?
You can't apply these changes to All Products ...

Well, yes, but this isn't helping us get to the benefits represented by this Cool New Thing; you are just defining Problems, not Solutions.

Still, this one can be fairly easy to defeat, by getting a bit more specific. Which vendors / customers / products are we talking about? Usually, there are just a few key instances where critical relationships (vendor or customer) must be maintained, or important product attributes will guide decisions / changes. Target these specifics, and don't try to develop solutions / rule sets that will work in all imaginable cases (diminishing returns, again).

News for Wombats

The phrase comes from an old Monty Python show, where a series of terribly redundant news programs, specific to parrots, gibbons, and wombats, pointed out that in all cases, "no parrots / gibbons / wombats were involved". (Hey - it's funny in context. Not everybody appreciates Fibber McGee, either). The point is - when time is of the essence, and you are looking to balance a complete design with relevant action, it helps to focus on the specifics.

Previously ...

Interesting Design Sessions (October 21, 2004)
Of course we can pay for that ... if it makes business sense (November 7, 2005)
Misapplying the Pareto principle (January 7, 2006)
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
Five Key Skills for Successful Project Managers (June 18, 2007)
Tactics for Controlling Project Scope (January 5, 2008)

Technorati Tags: best practice, collaboration, design, Knowledge Management

Hacking the Google Chart API from Excel

2009-01-17T23:03:00.001-06:00

a bit of code on a Saturday night ...

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

Click on the picture for a full-size image!

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

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

Sub CreateSparklinesDisplayFile()

   Dim sOutFile As String
   Dim iStartRow, iStopRow As Integer
   Dim iStartCol, iStopCol As Integer
   Dim i, j As Integer
   Dim sDataString As String

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

   Open sOutFile For Output As #1

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

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

   For i = iStartRow To iStopRow
      Print #1, "<P>" & Cells(i, iStartCol).Value & "</P>"
      Print #1, "<img src='http://chart.apis.google.com/chart?"
      Print #1, "chs=100x35"       ' Size (length x height) of final graphic

      sDataString = "&chd=t:"
      For j = (iStartCol + 1) To (iStopCol - 3)
         sDataString = sDataString & Cells(i, j).Value & ","
      Next j
      sDataString = sDataString & "0,0,0|0,0,0,0,0,0,0,0,0"
      For j = (iStopCol - 2) To (iStopCol)
         sDataString = sDataString & "," & Cells(i, j).Value
      Next j
      Print #1, sDataString

      Print #1, "&cht=bvs"
      Print #1, "&chbh=a,2"
      Print #1, "&chco=CCCCCC,FF3300"
      Print #1, "&chds=0,100,0,100'"
      Print #1, "title='" & Cells(i, iStartCol).Value & "' />"
      Print #1, ""
   Next i

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

   Close #1

End Sub

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

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

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

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

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

</body>
</html>

Some things I noted when constructing this stuff ...

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

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

Previously ...

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

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

Zodiac of Knowledge Capture

2009-01-15T22:20:00.001-06:00

The start of a new year gives me a rare chance to measure my knowledge capture output over time. I maintain electronic journals for the various projects I am driving, business units and functional areas I support, and people I work with. This results in a hundred or so separate MS Word documents, with generally the same format - still, it would be quite tedious to take a word count each week to check my outout.

However, at the beginning of the year, I start a new folder and a new set of Word files - which means that after week 1, I have the easiest scenario for figuring out how much data entry for the week. And, since last week was typical, I set out to total up my data entry - starting with tthe personal journal files, but including other media:

Format     Words
=====     ======
MS Word   15,300 in 22 documents
Notes      3,000 in 4 documents
Blogs      3,100 in 6 entries in 4 blogs
MS Excel 500 in 5 spreadsheets
Notepad    500 in 4 text files
Mind Maps    300 in 7 maps
Twitter      900
Power Point 700 in 5 presentations
Wiki         500 in 2 wikis, 2 different dialects
          ------
          24,800 words in 1 week

Hmm, that sounds like a lot - accoprding to this guy, I could / should be writing eight books per year ...

But then I though of all of the other formats that I was not counting ... texting via phone, IM over eight different accounts (thanks, Pidgin!), emails over four different accounts (and four different clients). And what about the code? That wiki item at the end got me thinking; most wiki syntax is faux-HTML, right? But I've also had to do work just this week in HTML, CSS, ASP, SharePoint, VBA, dokuwiki, TiddlyWiki ...

This whole exercise conjured a series of images in my mind, avatars for a new Zodiac of Knowledge Capture ...

Sisyphus: The never ending task of documentation. At times, my "backlog" gets so big, I just file a big chunk away under Future Projects ...

Hercules: Prodigious output should be the expectation, not the exception. The world / your work group is ever-hungry for more structured knowledge, and they don't want to wait thru the backlog - they want stuff now!

Job: Patience is a must - you will write stuff and get no response for months ... but every once in a while, a glimmer of hope. Had a conversation this week with someone who noted my Emotional Intelligence post from 14 months back (!). They had seen a class offering at a local college, and we ended up talking about how applicable the skills are to our jobs.

Mandelbrot: You need to be facile when plotting and navigating many levels of abstraction. The reader needs to absorb slowly, peel the onion one layer at a time ... but they better be able to drill to the required level of detail!

Pavlov: Repetition - Don't be surprised when you have to repeat, repeat, repeat, over and over, until you get folks used to the idea of going to the wiki, searching the portal, reading the manual.

Deming: Constant Improvement must be in your mind all the time. There is always a better way to get an idea across (which relates to ...)

Xerox: Imitation is the sincerest form of flattery. Let's not lose sight of the goal - capture and transfer knowledge . So, if you see a more effective method of communicating - learn from it!

Tufte: Clarity in communication is everything. You might think this one should be Strunk, but Tufte drives for clear and effective communication graphically / pictorially, as well as in the written word.

Muse: Don't rule out creativity; you are competing in the market of attention, and you need to capture the mind before it's ready to receive. You also can't always rely on the Same Old Stuff when capturing knowledge; keep experimenting with different tools, take the best, leave the rest.

Cthulhu (CNZ?): Develop skills at multi-tasking, maintaining many threads at once (or multiple arms). Multi-platform, multi-editor, multi-laungauge, multi-markup, etc.

Heisenburg: Be aware that documenting processes can be like measuring them - you will probably introduce some change. This is "stealth process improvement", and might even be manifest laziness (it's easier to document a simplified process ...)

This zodiac needs a twelfth sign - any ideas?

Previously ...

Heisenburg KM (July 13, 2004)
Communicating Complex Technical Concepts (March 21, 2005)
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)
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
Innovation That Matters - Substance Over Style (January 12, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)

Technorati Tags: design, documentation, hands on, innovation, Knowledge Management,
Web 2.0, wiki,

Back to the Future: Twitter "microblogging"

2009-01-09T22:41:00.001-06:00

"That's pretty good, Johnny, but that ain't the way I heerd it. . . ."

I recall when all this "blogging" talk started, way back in 1999 or so (thanks to Hallett for a decent history). The idea was to post thoughts and feelings, observations about technology, society, or whatever - anything from a daily diary to a project notebook. Scoble and others became (in)famous for posting multiple times a day.

Time marches on, and the medium has morphed over the years. Blog post frequency (BPF?) stopped being the measure of success; sites became electronic versions of trade magazines, marketing slicks, talk radio .. along with the occasionally Really Good Blog (couldn't resist), capturing knowledgable insights or technical tricks.

Then along comes Twitter, which has made little sense to me to date. Well, ok ... let's say my appreciation for the applicability of this site has slowly matured - along with their ability to avoid the Fail Whale. And I've seen another recent burst of activity - mini-Twitter apps, breaking news source, alternative interfaces, even metrics for personal validation. When talk turns to monetization and open source competitors appear, I guess you've arrived.

I recently happened upon Mr. Tweet, who has helpfully suggested a series of influential tweeters to follow. When Kawasaki and Scoble appeared on the list, it was like a flashback to the old days ...

... but this actually got me a bit more enthused. Posting multiple times per day makes a bit more sense when it's only a brief thought - and Twitter enforces brevity with the 140 character limit.

<aside>

Strunk

squeeze in

</aside>

So, now I'm trying to post more frequently on Twitter during the day, like a blogging old-timer - encouraged, I will admit, by posting into a tweetosphere more amenable to spontaneous connection; a few thoughts during a Sharepoint presentation brought a quick response from a SharePoint guru and author, with more than a few tech details on some of the finer [Share]Points (aiw).

We'll see how long this lasts ...

Previously ...

Twitter (March 22, 2007)
New Twitter features starting to make things more relevant (June 3, 2007)
Thoughts During a Power Outage (March 27, 2008)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
On the Road: Business Travel, Fall 2008 (October 13, 2008)

Technorati Tags: blog, Knowledge Management, twitter, Web 2.0,

Third Time's the Charm? Blackberry Bold

2009-01-05T23:11:00.001-06:00

I recently had to part ways with my Blackberry Pearl - some heartache, I suppose, but time and product innnovation march on. There is a lot to like about the Blackberry Bold - I am definitely happy to have made the change ...

same problem

Try as I may

Acceptable Form Factor: Yes, the Pearl was "perfect" because of it's candy-bar size - unlike the classic 7200 series, which felt strange when held up to your ear as a cell phone. Bottom line - the Bold still fits comfortably in jacket, shirt, and pants pockets. Plus, when I'm using it as a phone, I've typically got the Bluetooth headset plugged in.
QWERTY is Back: You can get used to the predictive typing on the Pearl's compressed, two-letters-to-a-key keyboard, but the Bold's "standard" layout has help reduce my typos considerably (alas, I have to take ownership of misspelings again).
So That's What WiFi is For ... It didn't register until I connected to my local Tomato to get out to the intarweb - much faster than anything I'd ever seen before, very useful.
Improved Screen: More real estate really helps here, and the applications are much more useful. Not just the "native" Contacts, eMail, and Calendar clients, but the web browser as well; pages just render better on this thing. I mean, it was usable before, but now it's actually quite effective.
More Applications: A few more games, big deal - I don't play in meetings anymore. However, there is a wide range of free, Blackberry-aware apps that are really useful - the Google suite, of course, plus Facebook and the Wall Street Journal. I've even re-downloaded Twitterberry, which has made a few updates since I last played with it (trying microblogging again ...)

iAmbulanceChaser

Subtleties that Really Deliver: No, I'm not an iPhone hater - but I have discovered a number of little features - not widely talked about, but spot-on useful - that apparently are not matched in the BBKWT. Face it - the Blackberry is spooky self-aware that it's a phone, first and foremost; open up an eMail, and if a phone number appears in the body, you can click on it to initiate a call. Or start a conversation with Messenger, and click the green phone button - a pop up asks if you want to call the person you are chatting with. Nice.
My Desktop: I also like the fact that I can add custom folders and rearrange icons, even moving them within these new folders. The home screen gives me space for six icons, so I've got a folder for messaging apps (email, gmail, IM, SMS, and tberry), Internet apps (browser, Google apps, WSJ, Facebook), plus direct licks to calendar, contacts, and Google Maps (my fave application for the handheld).

No, it's not perfect - I don't understand why I can't create shortcuts for my favorite web sites (Bloglines, Ping, Weather Underground, etc.) in the folders - but I can see myself growing more independent from the luggable [notebook]. If I could only get a decent VNC client ...

Previously ...

eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
My first month with the Blackberry Pearl (February 26, 2007)
Rare event: Design problems with my Blackberry Pearl (May 24, 2007)
New Twitter features starting to make things more relevant (June 3, 2007)
Communication is the responsibility of ... (August 19, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
The Innovation Generation and User Interfaces (April 9, 2008)
Stretching Your User Interface Design Muscles (April 16, 2008)
Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
On the Road: Business Travel, Fall 2008 (October 13, 2008)

Technorati Tags: blackberry, design, hands on, innovation, productivity, technology, twitter

Inspiration, Images, Insight, Imitation, Innovation

2008-12-19T21:58:00.002-06:00

Just a quick post on this pre-holiday weekend, with my design-leaning kids out of school / back from college for the holidays, and a general sense of creativity mixed in with the holiday spirit.

Inspiration ...

... can come from many places. Nothing new there, but I like to get inspiration for X from looking at a different kind of Y. Spice up a presentation? Browse a library of web site designs. Capturing a business process? Learn about alternative user interfaces. Brainstorming a new concept? Wander through an image library.

Images

There were more than a few postings over the last few months, regarding Multicolr Search Lab. This site is stunning, both technically (practically defines "intuitive UI") and creatively (very easy to lose yourself in different color combinations). Pick your favorite corporate colors, and even staid corporations could find some interesting CC-licensed photos to liven up their presentations. (Funny, I can't get a decent kelly green option on the site - bummer).

Insight

I've posted before about visualization libraries, but here's one I've found since then - A Beautiful WWW is a great site to monitor if you like visualization technicques, and are willing to surf and experiment. This post is a nice summary of libraries - potentially helpful for presentations, applications, even reports. Next time they ask for Yet Another Ledger Report, you be the one to shoot Old YALR, and replace him with a total page featuring a few Tuftettes (sorry, sparklines).

Imitation

I'm never above a sincere bit of flattery, and often look to other sites for design inspiration. SitePoint and A List Apart will often post about the techniques required to spin your own magic, but they will also refer to plenty of examples - check out this list of 15 sites to browse for some design inspiration (some I've seen before, but PatternTap was a particularly good one!).

Innovation

The most interesting stuff I've stumbled upon lately are innovative mixes of site design, UI, and search - for images. A result set of similar offerings, really ...

Pixolu (via) starts with a keyword, and then lets me pick images that are close to a mental image I'm trying to capture.
A little bit quicker, a little less free-association, is the "show similar images" option over at Live Search. Points for speedy response, however.
Today's addition (ibid): Google Image Search (that old stand-by) - a new search attribute that limits the results by image style.

All dynamite stuff, but I think I'll rely on Pixolu for my style of stand-up.

Previously ...

Communicating Complex Technical Concepts (March 21, 2005)
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
Moving from Search to Find: Anticipate the Next Big Problem (April 16, 2007)
Data Visualization: 'Life' of Open Source Projects (June 16, 2008)
Linkfest: Data Visualization (September 6, 2008)

Technorati Tags: design, innovation, marketing, presentations

Best Practices for Requirements Gathering Sessions

2008-12-07T19:05:00.002-06:00

It's been a while since I've led an interactive requirements session for an interactive application - but it's kind of like riding a bike. After a few minutes, the old habits come back, and the iterative ideas and cascading creativity starts to flow. What has changed, however, is the application platform, the office environment, and the various knowledge capture tools at our disposal.

So, in the spirit of knowledge retention and sharing, here's a brain dump of ideas that make for a better requirements gathering session ...

Think of it as an interactive presentation - so all of the classic prep rules apply. Arrive early, get set up and have everything running before people arrive
Make sure you can bring the original application (if it's a rework) up on the screen: check in advance that you can attach to the network
The best sessions are interactive, with application mock-up tools. Have a copy of Visio, PowerPoint or something similar ready to go - so you can paint screens and interactively work things while they watch
Use a room with a big screen TV or projector, so your audience can "see over your shoulder" as you work. However, if possible, you should face your audience - have them look behind you at the screen / projection, while you look at the display on your laptop.

This allows you to have a conversation with the folks opining on needs and wants, and lets you see their facial expressions as you dummy stuff up.
This also allows your audience to see what you are typing. They are proofreading your work - not for typos, but to make sure their understanding of the words / ideas you are talking about are being captured correctly.

Make sure you know where the local printer is, and can print to it. Waiting for a series of changes to be "painted" on the screen may take too long; it might be easier just to take a print screen and mark it up

When sketching on paper, have a couple of different color pens on hand, and color-code your scribbles; red = follow up / things to fix, blue = talking points, etc. When capturing ideas on the hard copy, your fixes & follow-ups are easily distinguishable. A highlighter might be good idea, too.

re: typing / data capture: Consider using a simple text editor, Notepad or something similar. Key is not to worry to much about formatting the text or correcting typos. As long a you can decipher your hacking, that should be ok

However, a spell checking word processor might be preferable to Notepad - your typos will get automatically fixed up

Always number your requirements / items to attack. Then you have a finite, trackable list of stuff that is either go or no go

Consider creating an auto-numbered spreadsheet for a Requirements list - you can bring it up on the screen as well. Create additional columns for notes, resource assignments, effort estimates - stuff like that

Bring a digital voice recorder to the session. Let the folks know that they are being "taped" - but it's only so you can go back and replay the discussion while cleaning up your notes. This will also allow you to stop typing and continue the in depth conversation - which is where all the value is
Set clear expectations of what you want to accomplish in the meeting - and set a time limit; iterative work is easily digested when taken in small bites

There is a lot of power in truly collaborative requirements sessions - the ultimate users of your system will readily accept the results when they are truly part of the design process and experience.

Previously ...

Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Another caveat for the erstwhile agile developer (January 15, 2007)
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)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)

Technorati Tags: best practice, design, development, innovation