cazh1: on Business, Information, and Technology

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmaclMacLennan,

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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


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.

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

• Improves communications, reduce e-mail clutter
• First impressions
• A New Communication Platform For A New Web

Generally Con

• The Microsoft Bob of the New Millennium
• The moral equivalent of sliced bread
• Is Easier To Understand Than…

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

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

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

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

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

I think most of us have seen this phenomenon before; sometimes it manifests as an open willingness to trade quality as just another feature (as measured by the amount of testing before code is put into production). Documentation is another common sacrifice - too often we accept e-mail summaries or PowerPoint outlines as a reasonable facsimile for knowledge capture.

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

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

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

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

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

Previously ...

• 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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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,

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan

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

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

Twitter at a Conference

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

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

Apotheker

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

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

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

Plattner

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

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

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

Elsewhere On the Web

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

Previously ...

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

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

Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan