cazh1: on Business, Information, and Technology

Managing Change: Inspiration, Art, Science, and Execution

2010-03-15T22:41:00.001-05:00

Often, when trying to figure out how to "make things happen", your focus switches between multiple targets. What am I doing? Why am I doing this? And How can I get the others to understand what I am doing? Real change happens along a continuum that stretches from The Big Idea to Real Results, and people / organizations that want to make real change happen need to understand the different elements along the way.

Yes, I know - earlier, I suggested that one should pick a specific area (people, process, or technology) to develop real skills in. Still true, but what about those who aspire to leadership, who want to make change happen across the organization? A single person doesn't need to be expert in each of these areas - but leaders should actively work in all of them. Aspire to be a jack of all trades, a master of none; the ability to develop a vision, communicate it with impact, build something actionable, and follow through with the implementation are bankable skills that effective, impactful leaders need.

For each of these "elements", think of about their definition - but also think of them in context with the other elements of the continuum. A leader with an impractical vision is just a dreamer; breakthrough science that is not well communicated will just sit on the shelf.

Inspiration

Defined: The ability to imagine what is possible (aka Vision). This doesn't have to be something as earth-shattering as Avatar or the next iPad - businesses are crying out for "innovation" (sorry for the buzzword) in areas as mundane as cost controls, Lean, and revenue growth. Make no small plans, but have the courage and the energy to stretch. Recognize the organization's practical limits - but don't sell them short, they might surprise themselves (and you!)

In Context: There is a fine line between imagination and inspiration; we need something that can be implemented in our lifetime. Flights of fancy can broaden your horizons, but you must eventually deliver real business results. This is where you can enable acceptance of the 80/20 rule - a practical vision that sees when enough is enough, that knows when to trim down the requirements to get 80% of the value with only 20% of the effort.

Art

Defined: Change often involves ideas, processes, or relationships that are difficult to understand, simply because they involve remixing the As-is with Something New, to create the Could Be. Sometimes it involves visualization - understanding a new structure, a changed process flow, or a hidden trend in the numbers. Sometimes it involves vocalization - an explanation or observation that needs just the right written or spoken words to trigger understanding and acceptance.

In Context: As goods and services are commoditized, and descriptive data becomes freely available in deep detail, the value and importance of design continues to grow. Well designed and executed words, pictures, sounds, thoughts, and ideas are the competitive differentiators that businesses always look for. Great leaders may possess acute verbal and/or visual communication skills, but don't discount your abilities or overestimate the pizazz required to make change happen in your organization. Just invest time on a regular basis, thinking about the design of things you see and hear every day. What images capture you eyes and your imagination? How do some texts convey meaning without boring you to tears?

Science

Defined: Sooner or later, you will have to create something that doesn't exist - a new tool, a simplified process, an effective data visualization, a useful report. This will always involve some specific "science" - knowledge of a programming language, a drawing tool, a data query, a report writer. At one point or another, sustainable change must manifest itself as a repeatable, measurable process or event - and sooner or later, you have to be able to translate your hand-waving to something that actually works.

In Context: Inspirational ideas need to find their way to the screen or the printed page, so they can be communicated, and communicated again. The best design ideas need to manifest in the final product. And the best ideas must bridge from the tip of the pencil to something (a program? a web site? a document? a project plan?) that can be executed. The best leaders can still summon hands-on skills when needed; if you are in IT, have you built something interesting in the past few months?

Execution

Defined: The classic "rubber hits the road" - results derive from making something happen. This could be the execution of a process, but can also refer to the coordinated steps in a project plan that implements a new system, or establishing rules, structure, and predictability where previously there was random action. Science has created something, now it's time to get it implemented - and, to make sure the promised results are delivered.

In Context: Starting a new process, stopping an old process, and bringing structure where there is disorder are the typical end results of most business projects, the ways that enterprises create value. However, inertia and entropy are powerful natural forces, and blasting through resistance (this is the way we've always done it ...) often relies on a strong idea, communicated effectively and designed efficiently.

Master of None

I think the toughest challenge for some entrepreneurs is to know when to call for assistance. There is value in knowing everything about a single area (the biggest vision! the best programmer!), but sustainable success often comes to those who know when to call in the experts. The best business results scale across multiple people, teams, locations, business units, processes ... so why shouldn't the best leaders scale across multiple resources?

Never stop learning, never stop improving your skills in all of these areas - but know when to bring in the experts to see results that surpass your expectations.

Previously ...

News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
Technical Debt and the Cost/Benefit of Knowledge Retention (July 27, 2009)
Collaboration "in the Wild": Some Observations (November 15, 2009)
Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)
Managing Change: Pick Something, and Do It Well (February 14, 2010)

Technorati Tags: change management, design, development, documentation, innovation

Managing Change: Knowing, Understanding, Empathizing

2010-02-28T20:45:00.001-06:00

Do you know your job, or do you really understand your job? One difficult part of change is getting people to see the difference.

Of course, this is seriously delicate stuff - you can't just walk in and ask people if they understand what they are doing. You know you'd be insulted if someone asked you the same question. (Come on ... not just a little?) But think about it - how often have you had this conversation ...

" ... I look at the TPS Report every morning, and I look for something that is negative in this column. If the layout of the report changes, I can't do my job; you are gonna have to relayout this new version of the Report."

In other words ... I don't understand my job, I don't think on the job - I just respond to the stuff I am used to looking for.

The great unstated truth is that most folks don't understand what they do. They didn't implement it, they inherited it. They know the how, but not the why. Plus, human nature makes us avoid admitting our own ignorance.

As a result, resistance to change means resisting anything that upsets the As-Is. Unfortunately, the As-Is has a stealthy way of changing in little bits over time; that, and the fact that the folks who originated this particular process have probably moved on, taking their understanding with them. And so starts the slow, steady spiral to complete irrelevance, and slavish adherence to non-value adding work.

Empathy Helps Overcome Entropy

To make change happen in these environments, it helps to have - and demonstrate - empathy for how people feel and think, to lower the resistance and open the minds.

Show your self-knowledge, and humility, by freely admitting when your understanding falls short. As a team member - speak up! in public! when you don't understand the underlying process. As a manager - encourage folks to raise their hands and ask for help. And please - make it easy for me to seek help off-line, after the meeting ends, so I don't have to demonstrate my ignorance in public.

Realize, however, that there is a significant requirement to Get Things Done; we don't have time to stop and deconstruct everything. There is a significant business value in having a repeatable, lean process, and all of this 'search for understanding' is wasting daylight. Balance the importance of understanding with the need to get stuff done, by designing, documenting, and implementing lean processes with incremental improvements, that can drive results on day one, but can also mature and improve over time.

Set the expectation that Understanding the Job is just as important as Getting It Done - but don't forget that we are getting paid by our Results, not our Understanding.

Previously ...

Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions) (June 12, 2008)
A Plea for Empathetic Communication (November 16, 2008)
Failing Faster (June 14, 2009)
Frustrating Paradox: Simple and Difficult (September 1, 2009)
Collaboration "in the Wild": Some Observations (November 15, 2009)
Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: change management, collaboration, people management

Managing Change: Pick Something, and Do It Well

2010-02-14T17:08:00.001-06:00

This is the first in an series of posts on Managing Change ... look for more over the course of the next few weeks ...

A common way of expressing the wholistic nature of a project is to talk about "People, Process, and Technology". I'm not sure who came up with this little gem, or in what context, but I've been hearing it a lot lately. No particular reason, I think, just that it seems to be gaining a bit of status as a second-tier buzzword or something.

I've noticed, however, that people seem very comfortable talking about People, Process, and Technology in the As-Is or To-Be states - but precious little time is spent about the difficulties in getting Change to happen in any of these areas. Project teams and project leaders need to be effective at making Change happen with People, Process, and Technology; maintaining the status quo is comfortable, and envisioning the "nirvana" Future State is easy, but the real challenge comes in making the transition from A to B.

Project teams need people that have Change skills:

People Change - Soft skills and Emotional Intelligence are typically required, but effective team leaders need to be able to command a room of strong personalites and competing agendas. Some meeting facilitators are direct, and can shout folks down and/or eloquently shift the group's understanding. Others work indirectly, creating understanding and acceptance in non-threatening, semi-private conversations.
Process Change - It's easy to say "automate a mess, and you get an automated mess", but the challenges of process redesign are known to many folks. A certain amount of patience and insight is required to ferret out muda (waste) in the process, to understand and identify the critical elements / tasks, and to aggressively involve the eventual process owners, cementing their commitment for implementation by making them part of the design.
Technology Change - Typically the easiest (and preferred) work area for IT folks, but for those who want to make a difference in IT, it takes the ability to understand and implement new technologies quickly, in a sustainable and supportable fashion. Points are taken off for quickly implementing a fragile system.

WIIFM?

Looking for ways to create concrete objectives for yourself or your teams? The significant Value Add that projects and project teams bring to organizations covers all three areas - People Change, Process Change, and Technology Change. Improvement and effectiveness doesn't come from raw skills in People, Process, or Technology, but a demonstrated ability to make Change happen in any and all of these three areas.

The opportunity, of course, is to pick one or two of these areas, and build your skills in making Change happen. If you aren't good in front of a group of people, and are more comfortable working directly with the technology, work on your Change skills by understanding new developments and methods, and figuring out how to use that stuff to make projects and processes happen faster, with higher quality and more predictable outcomes. Looking for a stretch? Get into Process design and development; it's not always about the bits and bytes, but systems thinking is a big plus, and Process skills are often a great way to bridge from Technology to People skills.

Do you express your value to your team, and your value to the company, in terms of People, Process, and Technology skills? If you want to be successful in IT, work on demonstrating your value by making change happen in those areas. At the very least - be able to articulate how you have succeeded / can be effective at making Change happen.

Previously ...

Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Best Practices for Requirements Gathering Sessions (December 7, 2008)
KM Overcomplicates: Heisenberg Impact on a VBA Quickie (February 8, 2009)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
If I Told You a Fractal Solution, Could You Change the CEO's Mind? (December 6, 2009)
Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: business value of IT, change management, innovation, people management, project management,

Quantifying Business Benefit of Collaboration Tools (or, What Is This Meeting Costing Me?)

2010-01-24T20:13:00.002-06:00

This post started off as an excuse to experiment with Google Docs, and this really neat feature I discovered - embedding a spreadsheet in a web page as a sharing method. However, it struck me as a potential way to cost justify the time, effort, and expense of implementing collaboration systems with the Most Cynical Among Us.

We've all been in large meetings, with tens of people from the project team, along with the expensive consultants, sitting around a table listening to the project manager read their slides to us. The meetings always get scheduled for a full hour (it's the default in our calendaring system!), and everyone feels the need to speak, if only to make sure their voice has joined the chorus of agreement.

However, many of the Most Cynical Among Us have observed the large number of people in the room, and asked the question "How much is this meeting costing me?" It's a worthy exercise to go through ... so I whipped up a little spreadsheet model to quantify the hard and soft costs ...

It doesn't take long to play with the model and see the dollars add up; even if you don't believe in tracking "soft costs", the amount of time spent in meetings can get really big, really fast.

Are status update meetings inherently a waste of time? Absolutely not - communication is critical, and most organizations typically don't do enough of it. An exercise like this just puts the potential cost, in time and money, in real terms - and reminds us to focus on maximizing that investment.

Can this meeting be avoided? Collaboration platforms (blogs, intranets, etc.) let us update the team virtually; people can get the information when it's most convenient for them.

Are we communicating effectively? Sometimes, face to face communication is required and preferred - especially when you need to monitor how the message is being received in real time. Hence the broad focus on effective presentations and impactful communications ...

Look at the cost of your last meeting - did you get your money's worth?

PS: I welcome any suggestions for improvements to the model - to request edit access or to get a copy, send email to jpmacl_docs@cazh1.com.

Previously ...

Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
Hidden Gold in Automating Recurring Processes (May 28, 2007)
Communication is the responsibility of ... (August 19, 2007)
Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: business value of IT, collaboration, hands on, people management, presentations, productivity, project management, Web 2.0,

Data Visualization: How (2 of 2)

2010-01-18T22:39:00.001-06:00

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

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

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

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

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

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

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

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

Information is Beautiful

Great Visualizers: Mike Deal charts The Beatles - I don't know exactly what that graphic is that shows the keys of Beatles tunes, but it looks cool - I want to figure out what it's showing, and how to build one

Cool Infographics

The Caffeine Poster, How Much Caffeine Are You Drinking? Made all the more interesting by this follow-on post, The Making of The Caffeine Poster
16 Infographic Resumes, A Visual Trend Resumes done in graphics? Well, maybe not for me, but these are great examples of packing a lot of information in a small area - and, making the message stand out in the crowd!
Pink Floyd Timeline of Band Members

Flowing Data

11 Ways to Visualize Changes Over Time – A Guide It's not always about examples of applied data visualization - there are plenty of mini-tutorials gettin published, like this one

EagerEyes.org

Understanding Pie Charts Another techniques post, this one deconstructing peie charts. I never knew why I wasn't a big fan of the pie, but this article points out a lot of stuff that's pretty obvious (now that you mention it ...)

Chart Porn

Haiti This blog is just a non-stop source of interesting examples

New York Times

Another common source of terrific information visualizations is the New York Times - many folks blog about the most effective examples, even our friends at Ask ET

Step 3: Get Your Coding Hands Dirty!

Remember, after you are done being wowed by the presentation - figure out how you could build one.

The old stalwart Excel comes with an ever growing list of graph types. Can't find the one you want? Try to hack at the standard stuff using VBA!
Sometimes a blog post will point you to some utilities. No, I never heard of Gource, but you can bet I'm looking for a project to use it with!
Open source has a lot of interesting tools out there - from jQuery addins to full-blown BI suites - lots of tools to load up with your data.

Remember - get inspired, find some starting points, and get building! the only way to really understand how to create insightful, impactful visualizations is to do a lot of experimentation.

Previously ...

Stretching Your User Interface Design Muscles (April 16, 2008)
Data Visualization: 'Life' of Open Source Projects (June 16, 2008)
Another Take on Enterprise Open Source (February 18, 2009)
Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)
A Company is like a Sphere (September 15, 2009)
Why Corporate IT Fails when Competing with Consumer Tech ... and How to Change the Game (January 5, 2010)

Technorati Tags: data visualization, design, development, hands on, innovation, presentations

Data Visualization: Why (1 of 2)

2010-01-12T23:17:00.001-06:00

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

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

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

... and we can iterate on these already:

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

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

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

Click on the picture for a full-size image!

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

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

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

Creating Opportunities for Insight - Playing with Visualizations

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

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

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

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

Next … sources of inspiration ...

Previously ...

Stretching Your User Interface Design Muscles (April 16, 2008)
There ain't much IT in IT Management (May 7, 2008)
Data Visualization: 'Life' of Open Source Projects (June 16, 2008)
Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
Hacking the Google Chart API from Excel (January 17, 2009)
Practical Innovation Lessons from Software Vendor R&D (April 16, 2009)
Who owns Master Data in your company? (May 30, 2009)

Technorati Tags: data visualization, innovation, presentations

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

2010-01-05T22:26:00.001-06:00

I've been working with internal developers over the past few weeks, experimenting with a treemap / heatmap-style visualization that is quite interesting / insightful when loaded up with data, but very tough to configure and manipulate. We are also struggling with a presentation layer (surrounding this data control) that doesn’t adapt to the size of your browser screen, or behave well when placed inside a frame set or table.

I suspect our primary challenge - typical thinking for most corporate IT departments - is that we only work with the tool we know. The only way to display information in a browser from XYZ's data warehouse is to use their particular Web portal platform. We need to switch focus; let the data warehouse provide beautifully aggregated and accessible data, but go elsewhere for the presentation layer.

Corporate IT needs to develop a sense of adventure, a thirst for new and different ways of doing the same thing, and a curiosity about different presentation architectures (ie. there's more than one way to skin a cat). Manufacture some spare time, and get down to some serious "play", with CSS, HTML, and SharePoint (as previously noted, our target intranet platform); learn all you can about the level of control you have. Note that you probably have more flexibility than you think … but now we're playing with JavaScript, VBScript, or any number of client-side technologies.

Unfortunately, we all seem to get to the same creativity-killing question: "how do I charge my time?". Full disclosure: I'm a big fan of the timesheets and reasonable chargeback systems, quantifying IT alignment with the business - but therein lies the subtle yet significant difference with "the IT guys" and the iPhone / iPod / Kindle / Nintendo / Best Buy expectations of our business partners.

Rewarding Different Behaviors

Corporate IT is measured by and rewarded for projects - specifically, getting things done. In most organizations, that's where it ends; IT is usually not rewarded based on the ongoing use of the project deliverables; in fact, ongoing support ("maintenance") is expected ... a cost of doing business ... overhead ... part of baseline costs ... and, in a manner of speaking: free (no premium is paid).

It’s the exact opposite on the Internet and consumer IT; you are expected to build the stuff for free, and just give it away. You will get your rewards when people come to your website, click on your ads, buy your products, become sales leads. You’re rewarded after the build is complete – but (if you are good), you are rewarded over and over again.

Corporate IT – metrics for success stop when the project is complete
Consumer IT – metrics for success start when the development work is done

This also helps explain why Consumer IT delivers "stuff" that people like, that is intuitive, easy to use, and just works. Witness the apple iStore – developers earn cash only when they sell their apps, long after the build is complete. But it's not as simple as that - note that even though there are a huge number of apps out there, less than 5% are big successes (>100,000 users). Competition and market dynamics drive quality and innovative, creativity is rewarded when an app rises above the fray. Check out the disturbing collection below; how many different ways can you write the same, silly, popgun program? You'd be amazed ...

... yet five minutes of playing with each of these shooters, and you start to see the subtle variations and evolving methods that applications that get the most return visits.

Hope for Corporate IT - the Anti-PMO

The iGun story tells us about the darwinian action that comes with large amounts of repetition, duplication, and failure. Success can be quantified by your failures - how many failed experiments have you thrown out there, just to see what sticks? On the internet, preferably a lot - because that’s how you learn what works, and how to make the “really cool stuff”.

Corporate IT might stand a chance in an environment where experimentation and failure is encouraged (but not necessarily rewarded - we need to learn from our mistakes). In essence, we need to build an anti-PMO and give permission for folks to do stuff that has no apparent value.

What will it take for you to facilitate a more creative environment? For more ideas on establishing an innovation environment, check out this old post ...

Previously ...

The Innovation Generation and User Interfaces (April 9, 2008)
Stretching Your User Interface Design Muscles (April 16, 2008)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Five Stages of Twitter Relevance (April 21, 2009)
Failing Faster (June 14, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: business value of IT, design, development, entrepreneur, innovation, PMO

IT Budget Hacking (w$$t)

2010-01-02T16:05:00.001-06:00

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

Software Maintenance for the Small Stuff

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

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

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

Alternatives and Duplicates

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

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

Compare your Risk Requirements with Reality

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

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

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

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

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

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

Previously ...

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

Technorati Tags: business value of IT, IT management,

Bootstrap Market Research: Master Data Management (Results)

2009-12-17T21:11:00.001-06:00

As previously noted, I've been doing a lot of discussion and data crunching around "Master Data Management" lately - so I've "bootstrapped" a little market research project. It's still a work in process - responses are trickling in - but I thought I might take some time to summarize what I am hearing to date. A document is available for download here ... the super summary follows below.

Survey Methodology

Please note: I am obviously not a professional market research firm, so this is is an understandably limited sample. Still, I am hearing some interesting things that may put your own Master Data work in a bit more context.

I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
Please fill it out and email the result to BMRMDM@cazh1.com

I've received input from ten companies so far - large and small, with all sorts of ERP systems. If you care to add some information, I'll thank you in advance, and add it (sufficiently anonymized) to the summary results document (download from here).

Here are some of the findings / observations from the summary ...

Master Data Domains

The types of Master Data called out included the usual suspects - Customers, Vendors, Finished Goods, Employees. Others mentioned include Metadata, Packaging / Tooling (components), and Indirect customers (like Payors in managed care, or Buying Groups in B2B). The primary systems in scope included SAP, Oracle, JDEdwards, and QAD, joined by an eclectic mix of legacy systems and point solutions. Secondary systems called out included Siebel, JDA/Manugistics, and ADP (payroll) - plus more legacy / home grown / departmental apps.

Master Data initiatives varied, based on where the "current pain" is - R&D / engineering, CRM / Customers / Contracts / Pricing, and Finished Goods / Logistics were named by different companies as their particular focus areas. Other important considerations were things like geography (North America vs. ROW), and business structure (Enterprise vs. business unit vs. local plant).

A significant determinant of how folks thought about this problem was how their ERP is implemented - in a fully integrated "enterprise" (Finance, Order Management, Supply Chain, etc.) - and/or how the instances are divided (all enterprise, by location (geography) or by business unit).

Note, however, that relatively few respondents are concerned with synchronizing data across multiple instances - a popular callout / feature of some MDM solutions. they will speak of "integration", but a focus of the conversations were all around quality and process, not synchronization.

An interesting frustration from some of the respondees; the ERP system(s) do not capture all of the required attributes for an item, so these additional details are kept in a separate, siloed system. Easy examples would be specific attributes (like shipping material specifications), but there were multiple instances where [so-called] Master Data is calculated with complex formulas / rationale, so an Excel component is required (typically in the area of pricing / quoting details).

Note: I believe we should consider computation of pricing as a (potentially) complex process that occurs in it's own transactional / analytical system (aka "the magic gonkulator"). The output is master data - but the calculations don't belong in an MD system.

Size & Scope of Master Data

Predictably, there was a great variation in the responses - 100s to 1000s of customer, vendors, finished goods. However, the interesting trend was the notation that 10s of people (relatively large numbers, based on size of the company), were "responsible" (i.e. "did some of the data entry"). Could this be why there is interest in MDM and an MDM organization? Apparently, Master Data is often managed like a wiki - everybody is an editor.

Note This is not always "out of control" - companies that have reasonably sized groups are the same ones that speak of metrics and controls. However, few report the existence of a centralized data governance organization (see below).

Most organizations have no metrics in place; a few can speak to "data police", folks that actively monitor the data looking for issues. Best examples cited included "Health Check measures" (does data fit set of established guidelines / tolerances); vendor audits, and [results of] scrubbing (ex. Name And Address data against external sources).

When asked about the business benefits of a Master Data Management effort, most companies left this blank or said "none". I generally got the sense that hard benefits are difficult to quantify; notable exceptions seem to come from past pain. Some organizations spoke to inventory reductions and transportation savings - both derived from more accurate supply chain data, which is facilitated by clean, consistent, complete Master Data.

Master Data in the Organization

Many companies keep control / accountability at the functional area. However, companies with "enterprise ERP" implementations (full integration of Finance, Order Management, Supply Chain) typically call out ownership at the Enterprise level. It's not about the size of the company or the recency of their implementation - it's the degree of integration within the primary ERP.

Organizational specifics were tougher to get at - depending on how the company managed their master data. Generally speaking, companies that manage Master Data at a functional level (Customer Service, Purchasing, Finance) have organizational clarity. However, folks that say they manage at the Enterprise level had the wispier definitions for Title and Accountability

Of note: centralized MDM teams rarely manage the bigger projects (implementations, acquisitions, or special projects with large MD components) - but they will (out of necessity) participate. None of the respondents look to these organizations / people for project management skills. However, there were some good callouts for the communication / change management skills required for the role, especially where the group has to review implications of adds / updates [of Master Data items] with multiple groups that will/may be impacted.

Scope of Responsibilities

An interesting, consistent set of answers in this area; "Yes, we take ownership and accountability - but no, we can't measure it". To be fair, not all companies had that clarity of ownership, but the lack of sharp, clear quality metrics is noticeable. Content, Quality, and Governance are consistent in all of these companies … consistently not-well defined, not well measured.

Positives & Challenges

Funny how best practices in one company are challenges in another. There are two recurring themes throughout the responses; Quality and Complexity. The latter is interesting; this was the first point in the survey where the difficulties of Finished Goods Master Data were raised. Many companies call it out as a large challenge; all of them cite the complexity, the multiple facets (manufacturing, packaging, warehousing, transportation, pricing, costing) and the cross-functional nature

Full Results

The summary results document is available for download from here; I will add a version date on the page and keep it up to date as additional surveys come in.

Questions? Comments? Suggestions? Let me know ...

Previously ...

Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Five More Realities for Driving Business Value from Technology (January 30, 2008)
Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
Who owns Master Data in your company? (May 30, 2009)
Bootstrap Market Research: Master Data Management (What, Who, How) (November 30, 2009)

Technorati Tags: best practice, collaboration, CRM, documentation, ERP, hands on, Knowledge Management, SAP, supply chain, tech management, wiki

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

2009-12-06T21:22:00.001-06:00

As the new year approaches, debates over the "value" of IT and business projects intensify; it's not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I'm hearing more about the struggle to quantify business value, especially when selecting those few projects that will "make the cut". We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don't scoff - it is possible - more in a later post ...)

However, I think there's an interesting vision in some people's minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately - as long as they all have business values assigned.

I don't think assigning a value to every proposal is realistic, and certainly not something to aspire to - well, not directly anyway. There are a number of significant hurdles to deal with - the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn't think it up on their own (ie. close the patent office, we're done).

Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas - how could anyone to claim the ability (or the time!) to rank such a list from "best" to "worst" (or, since I don't propose projects are bad to begin with - "most best" to "least best")? Truth is, they don't - most of the business leaders I've worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?

Rules of Thumb

Most people have a favorite way of eating their elephants. Yes, one bite at a time - but where to start? How to carve?

Deliver Small, Iterate, and Evolve: The agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.

Focus on the Big Rocks: The biggest and toughest problems - or the projects with the most benefit - are sometimes so daunting that they intimidate us into dealing with "the easy stuff". Clear your calendar and tackle these larger opportunities first, else you'll never get to them.

Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people - in key positions, with monopoly knowledge. Simplify things by prioritizing their projects first - but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.

Practical Problem Solving

As I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It's important to understand the fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are juggling) is roughly the same. The sooner you can put yourself in the other person's shoes, and speak to them at the level of detail they (not you) need - the more effective your conversations will be.

Besides, they're paying you to solve problems, not define them.

Previously ...

Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
Innovation That Matters - Substance Over Style (January 12, 2008)
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
The Innovation Generation - Communication Styles (April 1, 2008)
IT and the Business are Closer Than You Think (June 28, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)

Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management

Bootstrap Market Research: Master Data Management (What, Who, How)

2009-11-30T21:08:00.005-06:00

I've been asked a lot of questions about "Master Data Management" over the past few weeks - what does it mean, who does it, and what are some tools and metrics that organizations are using to reign in this important aspect of ERP and analytics systems. I started reaching out to the folks in my professional network with some results, but I thought I might be able to leverage LinkedIn and Twitter to get input from far and wide. This "bootstrapped" market research might not deliver the depth and reach of the bigger technology research firms, but it will be interesting to see what can be gathered.

Bootstrap Market Research: Ground Rules

I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
Please fill it out and email the result to BMRMDM@cazh1.com
I'm trying to get input from a number of companies - large and small, with all sorts of ERP systems. So in return for your input, I'll be happy to email you an aggregated, anonymized summary of what folks are telling me. Please note that none of your specific answers will be tied to your company name in any way.

Some Definitions

What do I mean by master data? Compare and contrast to transactions ...

Transactional Data – describes “events”

Production orders, material movements, and confirmations
Customer orders, shipments, and invoices
Payments, credits, rebates, and returns
Journal entries

Master Data – describes “facts”

Finished goods, raw materials, and work-in-process
Manufacturing routings, warehouse picking strategies
Customers, vendors, employees
Organizations and hierarchies
Chart of accounts
(also referred to as Reference Data, Configuration Data)

The Question of Ownership

I've asked this question before – who owns Master Data? – but there may be some different understanding over what “ownership” refers to. Is the "owner" responsible for …

Master Data Quality?

Data Structure, including requirements and interdependencies
Process & Procedure for getting Master Data into the system
Access & Training for getting Master Data out of the system
Audits & Quality Checks to make sure corporate requirements and standards are met
Metrics & Visibility for critical Master Data processes, especially when adding new products

Master Data Content? (for example …)

Structure of the chart of accounts
Bin configuration and capacity
Modeling manufacturing processes in a routing
Product families, sales org hierarchies
Credit ratings
Material substitution

Benchmarking Survey Questions

The survey asks some high level questions in these areas:

Master Data Definitions
Size & Scope of Master Data
Organization Structures
Scope of Responsibilities
Positives
Challenges

There is also space at the end to bounce back some questions - let me know what else is on your mind!

AtDhVaAnNkCsE

Thanks (in advance) for your input - and watch this space for the results!

Previously ...

The Innovation Generation and User Interfaces (April 9, 2008)
Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
Who owns Master Data in your company? (May 30, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: application, best practice, collaboration, operations, supply chain, tech management

Hands-On Project: Offsite Strategy

2009-11-22T18:55:00.001-06:00

When I talk about having an "offsite strategy" meeting, I'm looking to get out of the office and have some good, "strategic" conversation over a cup of coffee or a beer. Back when I worked for a software development company, we did our best design work at a hot dog stand in Des Plaines, IL; since then, I've always found it more fun to conduct some "bidness" in the proper atmosphere ...

This was the germ of an idea that suggested a solid (simple, easy-to-remember) domain name and an interesting excuse to get some hands on with newer web technology. I've wanted to build a Google Maps mash-up for some time, and I've been seeing a lot of stuff about jQuery on Twitter - so as a break from a high-profile project at work, I hacked together something over the past few months that was both fun and practical (because, of course, it's important to be able to quickly locate a suitable meeting place ...)

Lessons Learned

Actually, the practical lessons learned from this project have to do with understanding modern web technology, understanding technology at a reasonable depth, and discovering a new value prop for Twitter ...

If you are just starting out, try developing with web APIs, and augmenting your HTML and CSS with jQuery, mootools, Scriptaculous, or Dojo. Code not your style? You should be looking at Google Wave and the Semantic Web - two other things on my radar screen.
If you are into code - well, this stuff is definitely getting more interesting. I found jQuery to be powerful yet complicated, definitely tricky. CSS for flexible layout is kids stuff - get ready to dive back into debug mode. The goal, however, is not to become an expert - just develop a healthy understanding of what is simple and what is difficult.
Twitter and the real-time web took on a whole new meaning for me - I use Tweetdeck, and often set up searches to watch a keyword like "SAP", "master data", or "jQuery". This has become a great source for better plugins, but you can also get a quick sense of the market - the best code gets the most RT's!

If you are an IT leader, you simply must be getting in depth with this stuff as soon as possible. Your Sales, Operations, and Finance counterparts are desperately looking for the Next Big Thing in cost savings and/or competitive differentiation - grab a mitt and get in the game!

Besides, I like to be able to understand the subtle nuances - what's easy and what's difficult - when the business starts to talk about collaboration, the cloud, integrations and interfaces, and usability. (Primarily so I can set their expectations correctly after seeing breathless demos and presentations from well-meaning vendors ...)

A Work in Process

OffsiteStrategy.com is really best behaved in Firefox and Safari, but I have put a ton of time into the site to get it somewhat well-behaved in IE6 and IE7 (still a little quirky). I've still got a list of features to add:

I'm not stuck on the Chicago area - check out Boston and Cincinnati, for example. I am working on adding a Search box to the map, so you can find _your_ location, then look for my fave in your area. Next time I'm in town ...
I don't have as many photos as my daughters (14GB!!), but I have some that might be fun to share. Again, mostly just looking for a reason to mess with Picasa and the APIs available there
I'm still hacking away here at the blog, and over on Twitter - and I've looked at some interesting scripts to pull data from those two platforms over to OffsiteStrategy.com, for some interesting visualizations.

Of course, if you have any feedback - or suggested locations - please let me know.

Credits / Further Reading

Like any self-teaching hack, I've constructed the site as a mix of original stuff plus techniques cribbed from demos and samples of work from other web developers. In particular ...

Google Maps

I've used the Google Maps API V3 as the basis for my Maps stuff. I have an API key, no big deal, but I just like the default navigation features that come with this version (try the scroll wheel to zoom in and out of the map - just like the real thing).
I got most of my ideas for the basic UI and map action from Marc Grabanski, but I had to augment a bit with stuff from this demo program to get the InfoWindows to work like I wanted.
I also needed this handy Lat/Lon tool to get the markers positioned exactly where I wanted them to go.

jQuery

A very nice library of routines, plus I'm amazed at how fast the universe of plugins is expanding. The important ones used on this site include ...

Rik Lomas' quickSearch plug-in, for the excellent filter action on the table of Locations
Christian Bach's tablesorter - did you notice that you can sort the table by clicking the headers?
I have made some progress dealing with the shortcomings of IE6 - thanks to Andreas Eberhard and his PNG-Transparency fix.
The dropdowns underneath the icons come courtesy of jQuery Tools - good UI stuff. I think there is more there than tooltips, but that will be for another project.
I used Mathias Bank's excellent plugin for parsing URL parameters - wanted to send nice-looking links in email to people, that would point them where we should meet.
When I'm done with a plugin (or my own code), and I'm keeping a local copy, I have used Dean Edward's JavaScript Compressor web app. It works fairly well, although with some code I get quirky results with the compressed results - need to keep fiddling with that stuff.

CSS

This site got me back into practice with CSS - it's been a while since I've worked in this area. I did add Eric Meyer's CSS Reset to the site, another attempt at insulating the IE6 users from unfortunate look/feel issues.

Miscellaneous Tools

I also got a lot of mileage out of a couple of other web-based goodies:

There are many color tools online, but Color Schemer Online v2 was the best for letting me quickly go from hue to hex.
I got all of my icons from Iconspedia, a great source for free stuff. I did search a lot on the IconArchive site - good stuff, I just didn't find any that I needed from there.
I've used the meebo chat widget before on my blog (up and to the right ...); it's pretty nifty, and I figured it would make sense to want to get a chat going while we are discussing where to meet up.

Source Code

Are you serious? Well, ok, look for the latest over here, let me know if I've forgotten anything ...

Previously ...

Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
Excel 2007 is a BOB system (Bag'O'Bugs) (October 5, 2008)
Hacking the Google Chart API from Excel (January 17, 2009)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Five Stages of Twitter Relevance (April 21, 2009)
Who owns Master Data in your company? (May 30, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: design, development, hands on, innovation, tech management, technology, twitter, Web 2.0,

Collaboration "in the Wild": Some Observations

2009-11-15T15:11:00.001-06:00

An Enterprise 2.0 dream scenario: implementing a complex project across multiple sites, in two different time zones, with a large team (well over 100). The team was reasonably savvy with collaboration tools; core team members were quite comfortable with Instant Messaging, and we have been relying on SharePoint for many months. A centralized, coordinated document repository; a single source, very public bugs/issues list - the foundation was in place for some time, so our "go-live weekend" experience was pleasantly predictable.

During this critical time, we had to coordinate with the multitude, and we did that with a highly structured "hour-by-hour plan", regularly scheduled "all-hands" conference calls, and web-based meeting places so all could review Completed, In Process, and Coming Soon tasks. After a successful weekend, we received plenty of positive feedback, and some interesting suggestions for improvements:

Conference calls were regularly scheduled, and featured tight agendas - which tended to limit individuals' ability to connect with the right person (until afterward). Since each location had a "war room" where the team gathered for the status calls, some suggested we leave the conference call open 24x7. I wasn't a big fan of this one, primarily because I'm the guy paying the long-distance bill ...
Few on the team are actively using Twitter, but one of the project leads noted that IM was quite popular, and imagined a Tweetdeck-like ability to see instant messages and responses that have gone out previously; "threaded conversations" that could be visible to all, helping collaborative problem-solving and knowledge transfer. I congratulated him on inventing Google Wave ...
Like most decent-sized companies, we have a highly structured Process for approving code changes into production - and like most decent-sized projects, we noted a few instances where promotions to resolve problems were delayed (while they worked their way through the Process). Might there be some streamlining opportunities here, since we are working on a high profile project with lots of oversight?

Of course, #3 was a non-starter, but the first two generated some good discussion, Yes, it's conceivable that we could augment our SharePoint site with a few new extensions or plug-ins to address the first two - but I'm actively working against any changes to our collaboration environments for a very simple reason - we're not finished with the big project. Phase 2 of 2 is coming in just a few weeks.

Am I being close-minded? Not really, I'm a huge driver of collaboration tools in the company. But, I'm also a realist - and I know two significant factors that argue against change at the time:

Prioritizing "Improvements": We are implementing ERP and other highly intrusive / foundational systems, and there's a lot of change that comes along with that. I understand that an organization can only take so much change at once - so why not focus on the stuff that's bringing real (ie. quantifiable, bottom-line, significant) business value.

New Collaboration Tools need Lead Time & Practice: Eight months ago, sharing files by e-mail and ad-hoc, unstructured meetings were the norm. To be fair, we were working smaller projects with teams of 10-20, and usually in no more than two locations. Over the past few months, as we were teeing up for Big Go-Live #1, we've been introducing the newer tools in small bits. For Go-Live Weekend, the team was already familiar with going to SharePoint for status updates, or recording a new Issue in the SharePoint list. The mechanics were old hat, and folks didn't need to think about it - which was nice, since we need them thinking about their Tasks. If we introduce new collaboration tools with little lead time before the Big Go-Live #2, Tasks will be interrupted with people struggling to remember how to communicate.

In the right setting, collaboration tools can clearly add value - even for the most conservative jaded technology users. However, you can't introduce something so new and expect people to "get it" in the short term. Better approach is to introduce the new tools early in the process, when there is no pressure. This lets the team build familiarity, understanding, and skills by the time you need to rely on these tools for critical communication.

Previously ...

Dueling Collaboration Portals (November 23, 2008)
Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
Five Stages of Twitter Relevance (April 21, 2009)
Over / Under Communication for Project Managers (June 29, 2009)
Real Business Users and SharePoint (July 14, 2009)

Technorati Tags: collaboration, entrepreneur, innovation, Knowledge Management, people management, project management, SAP, Social Networks, twitter, Web 2.0,

Underwhelming experiences with Google Wave

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

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

Problems

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

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

I Am Legend

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

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

Yet Another Email Client

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

Generally Pro

Generally Con

Maybe It's Just Me

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

Previously ...

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

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

Introducing ... Google Wave

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

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

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

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

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

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

Previously ...

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

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

A Company is like a Sphere

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

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

A company is like a sphere.

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

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

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

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

Previously ...

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

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

Frustrating Paradox: Simple and Difficult

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

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

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

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

Simple is Difficult

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

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

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

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

Difficult is Simple

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

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

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

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

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

IT's Challenge - Fighting the Good Fight

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

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

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

Classique - - Moderne

Previously ...

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

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

Training and Learning: A Different POV

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

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

Task Oriented

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

Documentation Lament Part 1

sneakernets

High Concept

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

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

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

Documentation Lament Part 2

File, Open

Follow That Guy Around

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

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

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

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

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

Previously ...

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

Technorati Tags: documentation, hands on, Knowledge Management

Perfect IT

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

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

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

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

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

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

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

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

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

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

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

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

Previously ...

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

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

Technical Debt and the Cost/Benefit of Knowledge Retention

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

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

Thanks to Jeff Atwood at Coding Horror, for calling my attention to this article by Martin Fowler on Technical Debt:

developed by Ward Cunningham

Now, before you write off Cunningham as a techie snob or an academic hold-out for unattainable perfection, listen to this healthy dose of reality ...

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.I think most of us have seen this phenomenon before; sometimes it manifests as an open willingness to trade quality as just another feature (as measured by the amount of testing before code is put into production). Documentation is another common sacrifice - too often we accept e-mail summaries or PowerPoint outlines as a reasonable facsimile for knowledge capture.

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

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

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

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

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

Previously ...

Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Innovation That Matters - Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
Over / Under Communication for Project Managers (June 29, 2009)

Technorati Tags: collaboration, documentation, Knowledge Management,

Real Business Users and SharePoint

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

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

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

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

Documents Check In, but they Don't Check Out

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

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

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

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

... Here's a SharePoint Tissue

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

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

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

Push vs. Pull Messaging

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

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

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

On The Good Side

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

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

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

Previously ...

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

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

The Delicate Art of Pushing Back

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

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

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

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

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

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

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

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

Previously ...

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

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

Over / Under Communication for Project Managers

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

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

Media

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

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

Translations

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

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

Change Management

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

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

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

Lessons Learned

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

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

Here's the killer -

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

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

Previously ...

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

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

Failing Faster

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

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

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

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

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

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

Previously ...

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

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

Who owns Master Data in your company?

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

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

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

Business owns the Master Data

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

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

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

IT pwns the Master Data

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

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

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

What does that mean?

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

Previously ...

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

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