cazh1: on Business, Information, and Technology

More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions)

A recent post got a surprising amount of feedback - at least, different feedback than my other stuff. No flames, just folks agreeing with the ideas and wanting to engage in more direct conversation (phone calls, as opposed to blog comments or email - interesting ...)

I've noted that people like to second-guess and/or heap scorn upon their executive management team, seeing them as disconnected, clueless, and capable of speed without forethought. However, my experience tells me these attitudes are way out of line. Spend time in one-on-one meetings with them; listen when they ask probing questions during staff meetings, operational reviews, or any other meeting where they're going over details and weighing in with opinions. You can develop a much better understanding of where they're coming from if you attempt to walk a mile in their shoes - or just empathize a little bit.

These are common misperceptions that a typical organization has of the executive team ...

They Don't Make Decisions ... they just keep asking me for my opinion when I need them to make the call! Actually they're doing two things correctly; managing their time (because they can't micromanage the whole company) and empowering the organization (ie. giving you 1> credit for having half a brain, and 2> some leeway to make decisions). Remember, most organizations need problem solvers, not problem definers.

They Don't Consider All the Angles ... they skim the details and focus only on the big picture. People often make decisions without considering all the options and all the details; it’s a time management technique, relying on intuition backed by experience. It's just a tactic to help manage time, get on to the next thing - so don't take it personally. A better approach would be to give them the overview, let them know your decision for the go-forward approach - and then ask for feedback. If they disagree with your fundamental approach, I guarantee they will not be shy - they'll let you know right away. If you don't want them to make snap decisions that have huge impact, reduce their snap decisions to minor fine-points, and guide them where you want. If you really know your business and your audience, the executive input should be fine-tuning, not fundamentals.

They Resist IT / Technology ... the dinosaurs just don't get it! Truth is, they are much more technical than you think. I've had executives call out IT baloney about SQL queries, application response time, even e-mail attachments (I was told this attachment was too big to open - but later I was driving down the freeway at 80 miles an hour reading it on my Blackberry!). They don't need to understand the technology in gory detail, and you don't have to educate them on the nitty gritty - but they certainly need to understand how a given technology decision impacts total cost to implement, quality of the deliverables, speed-to-value, and ongoing cost to maintain.

They Aren't Paying Attention Well, not exactly. They will ask you to cut the details and get to the punch line, typically because they're thinking on a completely different level. You're probably worried about your departmental budget, annual performance goals, and/or resource constraints that put work for the next few weeks in jeopardy. They are thinking about making the month, making the quarter, and managing the owner's/shareholders' expectations for the next quarter or fiscal year. Also, they've got review sessions with engineering, marketing, operations, and finance - all scheduled between now and the end of the day. So, forgive them if they're not up to date on the differences between IE 7 and Firefox.

They Don't Understand the Problem Domain Actually, they typically have a deeper / more nuanced understanding of the business than most. They know (intuitively and factually) how to impact key numbers on the financials, and what levers to pull when they want to make a noticeable change. Questions that seem out of left field are actually efforts to make a connection between "why should I invest in this project?", and "how does this tie to one of my levers?".

Recognize that the executive team comes at the business from a different angle, and learn to listen to what is important to them - you'll raise your project success rate, demonstrate your value to the company - and maybe chill out a bit.

• Sell your Boss - Some Tech Observations (January 30, 2005)
  
• Fractal Business Issues - Katamari Damacy at Work (February 25, 2005)
  
• Communicating Complex Technical Concepts (March 21, 2005)
  
• Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
  
• Open Source as bargaining chip - driving business value of IT (October 30, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Build a Framework: Your chart junk is my roadmap / vision statement (December 27, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• Misapplying the Pareto principle (January 7, 2006)
  
• Defining an Effective IT Metrics Framework (January 21, 2007)
  
• Communication is the responsibility of ... (August 19, 2007)
  
• Defining the Business Value of a Project (October 25, 2007)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
  
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
  
• There ain't much IT in IT Management (May 7, 2008)
  
• Can you, should you, bother Executives with The Details? (May 30, 2008)
  

Technorati Tags: best practice, business value of IT, operations, PMO, presentations, tech management

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

Labels: business value of IT, people management, presentations, project management, tech management

posted by James P. MacLennan at 11:24 PM | Permalink | |

Can you, should you, bother Executives with The Details?

In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He's talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for "owning" (vision, design, execution, and ongoing support). I've seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives that they are championing. It's a slightly different scenario than described in Jeffery's post - reporting status "up the chain" versus "to the customer" - but multiple nuances of "don't bother me with the details" come into play just the same. My only suggestion to Jeffery would be to exercise a little empathy and adjust the message. Management needs to understand the details in spite of their objections or shortcuts; the trick is to understand what's behind this drive for the quick answer, and adjust the communication accordingly.

Fractal Attention Span

Challenge: People typically work on 7-10 major items at any one time; that's about as many as the brain can comfortably prioritize for chunks of their attention. Unfortunately, these to-do items / projects are fractal in nature, easily decomposed into multiple tasks and subtasks. Our prototype CEO needs to deliver increased revenue (3 key accounts in play), reduced costs (2 cost cutting and 3 productivity-enhancing initiatives), while driving down inventory (S&OP, SKU reduction, and supply network optimization projects). Oh yes, there is also a pending lawsuit, product R&D reviews, and the board presentation to develop. The VP of Sales has five territory managers working on different aspects of the three key accounts, and two project managers working on the cost-cutting - in addition to ongoing promotional planning and customer service issues. Sally, the lead project manager on the first cost-cutting project, is working towards a launch date of 15 July, and has 10 open issues with varying degrees of severity.

If I'm the CEO, and I have two hours to complete an Operations Review for the entire company, I have maybe five minutes to listen to Sally tell me about her piece of the VPs piece of one of my 10 hot items; do I really have time to hear about usability issues or the challenges of scheduling acceptance testing? All I really need to hear is the specific objective of the project, current status, maybe the next milestone date, and our current expectations for meeting the stated objective (vs. budget and/or need-by date). Anything else and my eyes will glaze over, because I've got 20 other people to get through, backlogs in voicemail and e-mail, two more meetings before the end of the day - and I'd like to get home before midnight.

Mitigation: This environment is hostile to knowledge retention (ie. you risk the CEO spacing out), so you need to focus on the critical information. I (the CEO) need to hear a clear objective, a plan to get there, and an active monitoring process. I don't care about the options available or the decision process for task 4.2.6.a on your plan - I just need to know you are planning the work and working the plan.

"I don't believe you" might mean "I don't understand you"

Challenge: Phillips' post captures his frustration when project sponsors ignore input on usability and data access. Features and functionality are stressed over the intended audience's capability and willingness to use what is being built. Experience in creating and implementating software-enabled processes teaches you the impact of a poorly laid out web page, but this is experience that your project sponsor doesn't have. They assume all software is built consistently (look at Microsoft Word and Excel!), and that Google, Amazon.com, and YouTube are "user-friendly" solely because they're on the web (web = friendly and easy, right?).

Regardless, your [sample] project sponsor is very aware of one fact; their integrated demand forecasting system, driven from a single database for security, consistency, and speed, does not exist. I want to see project milestones that deliver what doesn't exist!

Mitigation: First and foremost they are correct. This new system we're building doesn't exist - that's why we're building it. So if you're talking to me about work that doesn't directly deliver the list of requirements, I don't understand why we are wasting our breath.

Here's the trick; to save your personal sanity and preserve your credibility, assume good intent. They aren't saying I don't believe you - they are saying I don't understand how this topic relates to my requirements. Of course, you must connect the dots between the need for usability [in this case] and the eventual delivery of the expected benefits. The system is only as good as the quality of the data going in.

This is important - when talking about issues, decisions, or work that needs to be completed, you most always tie back to stated benefits.

Nature Abhors a Vacuum

Challenge: Blithely ignoring the fact that the executive team has many other things on their plate (see above) our intrepid project manager lays out five major issues and three options for each one. I, as CEO, got to where I am by Being Decisive and Making the Call - so if you're giving me the options, I'm going to start telling you what to do because 1) you're asking and 2) I need to move on to the next agenda item.

Mitigation: Heed that classic management one-liner - don't come to me with problems, bring me solutions. We all get paid plenty of money to solve problems, and it really drives execs nuts when all we do is define tough problems - and look to them for guidance. Believe me, most organizations will massively empower you to show some leadership and make your own decisions!

Not to worry - there are many control mechanisms in place to guard against bad decisions, but you need to control the message and flow. When presenting to the execs, don't lay out options followed by your preferred choice - it sounds too much like you're asking for their choice, that the project is dead in the water without their decision. A better method is to present your choice as the only way to proceed (this makes sense based on X and Y and Z). At this point, you can do a few quick bullets on the options, subtly giving the executive team an opportunity to ask probing questions and suggest alternatives. Trust me - if they have any issues, they will drill into these options and dissect your rationale. But when they don't ... progress!

The Myth of Executive Omnipotence

Challenge: In many companies, the executive team holds a magical sway. The staff adheres to their every whim; reworking this project "because the CFO said we should", reprioritizing that project down the list "because the CEO wants it that way". I love asking the "stupid" questions ... like Why does this need rework? What exactly does the CEO want to see as a deliverable from this team?. If you find yourself pondering (hmmm, I'm not sure exactly what he asked for, but he was pretty adamant - so we better deliver)

Mitigation: If your neighbor stops by to borrow a ladder or chat up the Fire game this weekend, you might have no idea that they are a COO or Vice President; she's just a regular person like you and me. So why would you grant them magical status in a workplace environment? Look, if you don't understand what they want, just ask for some clarification. You can make the [very safe] assumption that they are good men of business, and will react predictably to a business-based conversation. We had two options; here are the costs, benefits, and risks, and here's why were going to pick option one. If your assumptions differ from theirs, why can't you have an open conversation to challenge those assumptions?

Sometimes I think people are too self-conscious; no one wants to appear stupid and ask the General Manager to elaborate on what they're saying, because they aren't being very specific or they're making a logical or factual mistake. This is entirely possible, even probable - they may not understand the implications of what they're asking for, but since you the project manager, are defining problems not solutions, and since I've got 16 other things to do between now and quittin' time, I'll just start making decisions. I've seen plenty of projects get blown out of proportion and swerve down strange side routes because the executive said something, the team took it to be the One True Way To Go.

• Update them on what they are expecting to hear about
• Keep it to the relevant level of detail
• present solutions to any problems that pop up
• Anticipate some questions ...
       ... but don't offer up the details until asked
• If you failed to write down what they asked for, follow up ASAP
       ... and figure out how to listen better next time!

• Fractal Business Issues - Katamari Damacy at Work (February 25, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Funny, how techies talk to each other (September 11, 2006)
  
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
  
• Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
  
• Five Under-Emphasized PowerPoint Best Practices (May 7, 2007)
  
• Defining the Business Value of a Project (October 25, 2007)
  
• Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  
• 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)
  
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
  
• Butting In to the Conversation: PM Communication Tools (February 26, 2008)
  

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

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

Labels: business value of IT, Knowledge Management, people management, presentations, project management, tech management

posted by James P. MacLennan at 8:43 PM | Permalink | |

No Silver Bullet for Group Collaboration over Distance?

Lots of organizations have to deal with the challenge of implementing standard work and best practices over physical distances. With sales offices, distribution centers, and manufacturing locations scattered across the country, what's the best way to get people who know their stuff to collaborate on process improvement - and then take that knowledge back to their home office?

While wrestling with this challenge, one executive I know preemptively ruled out videoconferencing. It's a common suggestion, but the general feeling was that it's just not useful, has never proven itself in practice.

I happened to agree with the idea that videoconferencing wouldn't help in this situation. The team was talking about productivity improvements for an assembly process - workstation layout and hands-on participation was required to effectively work out the wasted movements. However, when defending the No Webcams position to some gadget freaks around the table, we came up with a/the fundamental flaw with remote video: it lacks spontaneity.

Historically, videoconferencing was set up in specific rooms that had to be reserved in advance. For higher quality connections, equipment is expensive, and the expense had to be pre-approved. Advances in digital cameras brought devices mounted on desktops, but this tied you to that specific location. Today's nifty notebooks have built-in cameras, but these can be tough to use with a group of people (crowding around).

Yes it's possible to use videoconferencing, but the physical limitations tend to quickly dim the excitement of all but the most diehard tech fans. In practice, local process improvement teams would just walk over to the workstation in question, skull out the best way to do something, and take a break for some coffee by the time we had the webcam hooked up ...

Lack of spontaneity is probably why the vast majority of PowerPoints are delivered with printed decks, and not overhead projectors. It's still more time efficient to quickly print off a few copies than it is to chase down a projector, lug it and your notebook computer into a conference room, get everything hooked together, and try to remember how to switch to the external monitor. (Hmmm, good thing they added all those cool slide transition effects ...)

Truth is, having paper copies isn't all that bad. Some folks like to take notes on their handouts and file them away for future reference. The medium of communication has its own utility, a sort of residual value that most people understand how to use. The same is true for fancy collaborative technology like videoconferencing. The magic is in the actual conversation, but that can get lost in the struggle to get the technology working before you can actually use it.

Does this mean that collaboration technology is doomed to failure? Of course not - knowledge capture and reuse, and differences in physical location and time zones, are still problems for organizations that rely on the "old way of doing things". You just need to pick your tools judiciously, and build up to the fancy stuff over time.

• Wiki's will not work if people don't already have an interest / desire / skill / method for creating documentation. Wikis solve distribution and access problems, but they don't make people suddenly want to write.
• Blogs will not work if people don't already have the need to communicate while competing for people's attention. Blogs solve time and distance chanllenges and facilitate simple Q&A, but they don't automagically endow authors with reader empathy.
• Collaboration Spaces will not work if people don't already have the need to share documents and edit them within a group. Collaboration Spaces solve version control and tracking hassles, but they don't help groups create impactful documents where none existed before.

We needed to see productivity improvements in component assembly within 60 days, so flying a couple of key people around the country was a small price to pay for the quality of work that we got. We took a small step forward - getting process experts to a different location, to put faces to names, and empathize over common challenges, experience the satisfaction of defining a workable solution - and experience the joy of business travel. Maybe next time we could look into videoconferencing, because interpersonal relationships and understanding of the power of shared best practice has already been established.

• Implementing Intranet on Speed: An Uh-Oh Moment (July 31, 2004)
  
• Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• More on (sic) experience with wikis (January 31, 2007)
  
• Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
  
• More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
  
• Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
  

Technorati Tags: best practice, blog, collaboration, innovation, Knowledge Management, presentations, productivity, Web 2.0, wiki,

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

Labels: blog, collaboration, innovation, Knowledge Management, presentations, supply chain, Web 2.0, wiki

posted by James P. MacLennan at 10:59 PM | Permalink | |

Stretching Your User Interface Design Muscles

A follow up to my previous post on innovation in user interface design:

• If you want to keep up with cutting edge thinking on technology - in a very approachable, effective format - ReadWriteWeb is a must for your feed reader. I'm constantly amazed by the number of solid articles they generate every week. Here's one from a few weeks ago with a series of video examples of imaginative thinking about user input:
• User Interfaces Rapidly Adjusting to Information Overload
• Another ReadWriteWeb article, and this one relates well to the Stephen Anderson presentation I linked to before. It talks about user interactions (web forms) that empathize with and engage the person working with the site. Excellent examples of usability "in the wild":
• Good UI Design: Make It Easy, Show Me You Care
• (via Aggregated Intelligence) A very effective way of designing any interaction with data (web form, application dialog box, even a paper report) is by prototyping. I have long favored MS Excel for working out database designs and report layouts; it's very simple way for end users to capture what they want to see, quickly rearranging and adjusting until it is just right. For on-screen dialogs, try PowerPoint; the second link below takes you to a "toolkit" of GUI components that let you work up sample screens / user interactions very quickly, using the comfortable environment of PowerPoint. Another option might be Visio - I've used versions of that package that included shape templates with lots of user interface widgets. Bottom line - it's a lot easier to sketch something out than to have to actually build something "real".
• UI Design - Prototyping
• PowerPoint Prototyping Toolkit (release 0.2)

Also from the first article above ... if you don't think there's a difference between corporate IT UI and the consumer Internet - does this ring true for you?

• If you want to be more than a programmer, stop programming (April 8, 2005)
  
• Sometimes analogies work amazingly well ... (July 14, 2005)
  
• Fighting with MS Access and version incompatibility (September 26, 2005)
  
• Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
  
• Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
  
• The Innovation Generation and User Interfaces (April 9, 2008)
  

Technorati Tags: design, development, hands on, innovation, powerpoint, presentations

Invisible Technorati Tags: cazh1, FEI, Front End of Innovation, James P. MacLennan, jpmacl, MacLennan,

Labels: application development, design, development, powerpoint, presentations

posted by James P. MacLennan at 8:52 PM | Permalink | |

Optimizing the Wrong Part of Knowledge Management

I sat in on the report-out session from a kaizen event this week, and something occurred to me as I reviewed a ton of interesting findings in a very short time ...

Best Practice

Self-contained deliverables are the most powerful tools for knowledge knowledge transfer you can have in your organization. I'm talking about a document that stands on its own, and effectively communicates an idea without needing the author nearby to explain anything.

The topic doesn't matter - conceptual white paper, status presentation, process map / instructions, design specifications, etc. The format doesn't matter - Word (document), PowerPoint (presentation), Excel (spreadsheet), Project (plan), Visio (diagram), and so on. The telling event is when this deliverable is sent out as a pre-read before a scheduled meeting or review. If written well, the time allocated for the meeting is spent discussing questions, clarifications, exceptions, and/or additions - as opposed to explaining the document itself.

Reality Check

Creating self-contained deliverables is hard; it takes skill in a number of different areas to create clear and concise prose, relevant statistics and metrics, relevant and impactful visuals. It's also time-consuming - well structured examples, screen prints, illustrative diagrams require skills in multiple technologies. Of course, before all the fancy words and beautiful pictures, you have to be able to lay out the opportunity / problem / situation so the reader can quickly get up to speed on the relevant points.

The other challenge, of course, is finding the time to create the content, capture the message, make the connections. It's always hard to manufacture enough time.

So, what ends up happening? People tend to optimize the knowledge capture process; minimize time spent creating documents by putting together enough material to facilitate the conversation, capture the main points, and help them remember everything that they want to review when in front of the team.

The Problem

Unfortunately, this misses the bigger picture. By reducing the time I spend capturing the knowledge, I'm increasing the time required to pass it along; I am sub-otimizing the knowledge transfer process. If I don't give my content out for a pre-read, I'll burn half of the meeting time getting roomful of people up to speed on stuff they could have read the day before.

It doesn't stop there; the same content would need to be discussed with anyone else who might be interested. And, since we've already established that time is scarce for all, these next conversations rarely occur; the opportunity for transferring the knowledge to more people is lost, and as memories dim, the value captured in the original meeting is, for the most part, gone ...

... or (more likely) concentrated in the head of the person who originated the whole thing. And people wonder why organizations have trouble retaining knowledge, or why groups develop "super users" that create unfillable voids when they move on.

Catch-22

Unfortunately, when confronted with this situation, most people under time pressure will make the obvious choice - stick with what you know. If you're facing a deadline, capture the information that you need and deliver the details face-to-face. There's safety in numbers with this approach; I think 80-90% of the business world takes this route. It gets the job done and no one is really faulted for going this way.

Breaking the Cycle

However, as I've noted before, there is a lot of power and possibility when you can leverage your knowledge across many people, without regard to time or place. If you want to do more in your organization, leverage more of your time, and/or get your ideas across quicker than the next person, you need to develop skill in creating self-contained deliverables.

There is no single method or style to create self-contained deliverables. Anyone can do it, but you need to figure out how to adapt and adjust your personal communication style, and change the things that are ineffective. My favorite methods:

1. Borrow Liberally: Most of the things that I've learned about documentation and communication came from other people, other things I've seen, read, or heard that particularly worked for me. A writer's effortless prose, a presenter's terse yet effective pitch, a diagram's elegant visualization. Develop the habit of looking for stuff that works, and the curiosity for decomposing it into methods you can use for your own communication.
2. Study Minto and Tufte ... and other practitioners of the art of communication. Minto's Pyramid Principle is very effective when introducing a reasonably complicated new idea in a short amount of space. Tufte will teach you how to strip out the extraneous information while packing in the pertinent; he's talking about diagrams and visualizations, but it works for your words, too!
3. Use the Right Tool for the Job: Every MS Office application has the ability to draw squares, circles, and lines - diagrams in the midst of your spreadsheets, project plans, and documents. But nothing beats Visio for quick diagrams that give precise control of placement, size, and alignment. Similarly, I love Excel's ability to quickly create beautifully structured tables of information, in a way that gives me fine-grained control over row heights, column widths, font sizes, number alignment, and other effects. Sure - PowerPoint can do a diagram or a table, but it's much quicker to build it in Visio or Excel and paste into PowerPoint.
Note: Learn how to paste as an Enhanced Metafile, not as an OLE object - you'll thank me for it.
4. Get Feedback: Ask someone whose opinion you trust, and who is at least a decent communicator themselves. Ask them if your written documentation was clear, and did it explain everything they needed to get the whole picture. Better yet, become your own harshest critic; use the voice recorder or videotape your presentations - are you convinced by what you see / hear? Pick up a old document or diagram you created - can you still get meaningful information out of the content or was it really dependent on context?

Take responsibility for the communication - if only to save yourself from the hassle of repeating yourself again and again and again ...

• Current Writings on Presenting Complex Information Visually (July 9, 2004)
  
• Communicating Complex Technical Concepts (March 21, 2005)
  
• I have nothing to say and I am saying it and that is poetry (April 6, 2005)
  
• Euphemisms, and a career-extending paradox (July 11, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Look your best with little effort - Excel, Project VBA for Page Formatting (June 11, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• Five Under-Emphasized PowerPoint Best Practices (May 7, 2007)
  
• Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
  
• Communication is the responsibility of ... (August 19, 2007)
  

Technorati Tags: best practice, design, documentation, Knowledge Management, marketing, presentations, productivity

Labels: design, documentation, Knowledge Management, marketing, presentations, productivity

posted by James P. MacLennan at 10:14 PM | Permalink | |

Butting In to the Conversation: PM Communication Tools

Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I'll add my voice, with both input on the topic and observations on the method.

The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis - you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional - you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.

Truth be told, the most valuable tools in the project manager's communication kit is typically Ctrl+C and Ctrl+V.

Another one of McDonald's posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord ... )

I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.

It must be that time of year - I've gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare - the dollars are better spent supporting the business.

However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?

Every PMO I've ever worked with / built up relied all or in part on locally developed tools; the cobbler's children can usually hack up something serviceable. And to borrow a phrase from Lee White - most of the skills for project management and collaboration comes from creating the tools, not having the tools.

(Method) Not the Right Tool for the Job

I'm not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone's comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first - so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I'm not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.

Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.

That's the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can't figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.

I've written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate ...

1. Use an Announcement to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only - out from you to the readers of the web page.
2. Use a Blog to make an observation, deliver a status update - capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
3. Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse, with threaded conversations and branches and such.
4. Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits - but not full-on discussions.

Authors Note: I officially despise ecto at this time. This is the second time that I've written this post - spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I'm switching back to w.bloggar for now - gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.

• Implementing Intranet on Speed: The Beginning (July 27, 2004)
  
• Communicating Complex Technical Concepts (March 21, 2005)
  
• Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
  
• Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
  
• Guidelines for Success with your Skunk Works project (June 19, 2006)
  
• Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
  
• Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
  
• Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
  
• What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
  
• More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
  
• Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
  
• The Right Web2.0 Tool for The Job (July 16, 2007)
  
• Communication is the responsibility of ... (August 19, 2007)
  
• Five Simple Rules for Project Names, plus Four Sample Lists (January 7, 2008)
  
• Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
  

Technorati Tags: collaboration, PMO, blog, Project Management, PowerPoint, Web 2.0, tech management

Labels: blog, PMO, presentations, project management, tech management, Web 2.0

posted by James P. MacLennan at 10:00 PM | Permalink | |

Rules of Golf - Project Prioritization Process Needs Clear Documentation

Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:

Blogging is Easy ...

The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.

Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.

... but Empathizing (with the reader) is Difficult

I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.

Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...

• Most people think the same way I do ...
• ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
• ... and write about that

Self-Policing the Content

What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.

Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.

Communicating is Still an Art

Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.

Where Are the Comments?

Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].

• Heisenburg KM (July 13, 2004)
  
• I have nothing to say and I am saying it and that is poetry (April 6, 2005)
  
• Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
  
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
  
• What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
  
• More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
  
• Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
  
• Communication is the responsibility of ... (August 19, 2007)
  
• Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
  

Technorati Tags: blog, collaboration, Web 2.0, wiki

Labels: PMO, presentations, project management, Web 2.0, wiki

posted by James P. MacLennan at 10:17 PM | Permalink | |

Communication is the responsibility of ...

Corporate Knowledge Management (KM) is hard. Hard to introduce, hard to teach/coach, hard to require, hard to create. Which, added all up together, often make it hard to use.

It may sound like unfounded pessimism, as the Internet is loaded with examples of successful collaborative sites that aggregate and repackage knowledge - it's been doing that for years, ever since there were Compuserve forums and bulletin boards. Unfortunately (for the corporate environment), the Law of Large Numbers takes care of locating enough motivated authors with a knack for the written word, and thousands / millions reap major rewards. Internal, corporate KM doesn't benefit from the high traffic / exposure of the public intarweb.

I'm often surprised that I keep chasing this particular windmill; maybe I am truly lazy, and would love it if I could disintermediate myself from all of the project and system status updates. There is definite value for IT managers, even business managers, dealing with unmaintainable systems and an overdependency on a few key resources. There is also value for those who possess this knowledge; I've known many developers who couldn't shake free from their system support role with a obtuse system, simply because they were the only one who knew the magic required to keep the thing running.

At a recent internal presentation, I tried to illustrate with a comparison between Then and Now. In the "old days", when cc:Mail, Lotus Notes workflow, and black & white HP LaserJets ruled the roost, "knowledge" flowed in one primary direction - in, to me.

Then

• Information arrives in my in-box
• Project leads, managers, supervisors, and trainers push information to folks who need to see it
• If it’s not in my eMail, on my hard disk, or printed out on the shelf at my desk, I’m not aware of it
• Communication is the responsibility of the communicator

In hindsight, I could disavow responsibility for knowing about stuff, because it wasn't adequately communicated to me.

Times are different now - even eMail is falling out of favor with those entering the work force in the next few years, and we are inundated with IM, SharePoint, RSS, Twitter, internal wikis & blogs ... a new tool every day. Even our "standard" publishing tools are under attack - note the rise of Linux and Macs as viable platforms for corporate desktops. Office 2007 has introduced a radically new UI, and Vista requires a POS* on each desktop - so adoption won't be as quick and as pervasive as XP and O2K. The fight between OOXML / ODF and a host of other document formats just indicates the rising popularity of multiple authoring tools - it ain't all MS Office any more ...

Now (1 of 2)

• Information is available in many formats, media …
• … and there is no single “correct” format
• Information is available inside and outside of my team / department / location / company
• It is impossible for publishers to know all potential consumers
• If it’s not “at my fingertips”, I suspect it’s out there somewhere …
• Communication is the responsibility of the communicatee

It seems that the responsibility arrow now points to me - and I, being a bit of a technology geezer (if you believe my teen daughters), might correctly feel some pressure. However, it's not as simple as that - where does this content come from? In the past - project leads, managers, supervisors, and trainers were "publishers", but now, there is architectural pressure, in the form of Web 2.0 and collaboration tools, that level the playing field and make us all publishers.

Now (2 of 2)

• Everyone is a [potential] publisher; everyone has knowledge/skills/experience to contribute / share
• Information can be published and consumed in many formats, media …… and there is no single “correct” format
• Information is desired / required inside and outside of my team / department / location / company
• It is imperative for publishers to anticipate all potential searchers / “consumers”
• Communication is the responsibility of the communicator

Hope springs eternal, and I prefer to see these challenges as opportunities; indeed, the message of my presentation tried to make this point. Of course, one could choose to watch it all go by, and decide not to participate ... but don't be surprised when the person next to you starts to change their effectiveness (and prospects) ...

Next ... all is not lost, some interesting new tools I've recently added to my set ...

* Piece of Skylab - originally, slang for large boombox, now refers to any sufficiently engadgeted / loaded desktop / notebook. AKA Cray Notebook or Cray desktop

Previously ...

• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
• Thoughts on Why Tech Folks Hate Documentation (July 08, 2006)
• Moving from Search to Find: Anticipate the Next Big Problem (April 16, 2007)
• Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
• The Joy of Programming, the Challenge of KM (May 05, 2007)
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
• Driving Participation and Contributions on Internal Blogs and Wikis (July 07, 2007)
• The Right Web2.0 Tool for The Job (July 16, 2007)
  

Technorati Tags: blog, collaboration, knowledge management, SharePoint, tech management, Web 2.0, wiki

Labels: blog, Knowledge Management, presentations, Web 2.0, wiki

posted by James P. MacLennan at 3:56 PM | Permalink | |

Five Under-Emphasized PowerPoint Best Practices

Catching up on old links that I wanted to comment on - here is a selection regarding some PowerPoint best practices, including five of my personal favorites that I don't often see in those ubiquitous articles / postings detailing the Secrets of Presentation Success ...

Under-Emphasized PowerPoint Best Practices

• Never Embed Objects: I grew to dislike embedded objects years ago, when computers could barely handle the launch of an Excel instance from within Word, or Visio from within PowerPoint. This approach also explodes the size of the file, making it difficult to eMail around the office. A much better approach - build the drawing, the table, the project plan, etc. in the source application as a separate file. When finished, copy to the clipboard, and paste into your presentation using Edit, Paste Special-select the Picture (Enhanced Metafile) option. You get a nice, small object, that looks exactly like you want - you can even resize it to get things just right.
• Use the Right Tool for the [Drawing] Job: Related to #1 - if you need a drawing of an organization chart, a project gantt, or a process map, don't hack it together using the drawing tools within PowerPoint. Go to an application that's loaded with excellent drawing features, and create the image you need; then, paste the result into the presentation using the method outlined in #1.
• Same goes for tables of figures; don't kill yourself with a manually created / formatted table; use Excel to build your figures, do full formatting (including conditionals!), and just paste the results into your PPT file.
• Shrink your Graphics Files: Put a single image into your presentation (ex. for that useless Company Products slide you want during the introduction), and your file goes to multi-MB just like that. A better approach would be to get a decent graphics editor, convert the image to a GIF file, and learn how to save as an Optimized GIF - this will really shrink the size of the image,making it much more manageable.
• via lifehacker, here is an excellent tutorial from Agarwal, telling how to use the Compress Picture functionality in PowerPoint. This is especially helpful if that corporate standard template insists on slapping your logo on every slide.
• Don't Read: When presenting front of a group, or walking through a deck around a table, it's exceedingly bad form to read the bullets. More often than not, everybody in the room can read as well as you can; besides, you sent the file out for a pre-read, right? Right? The key is to pick off the major points you need to make, not recite every single one. Another option is to provide more detail, specifics around the text on the screen - the slide is just a prompter for your pithy examples and amazing depth of understanding.
• Don't Forget to Breathe: I need to remind myself of this one all the time: you've practiced so many times, and you're aware of the dwindling time allotment (45 slides in 30 minutes, hmmm). Young captured this nicely in this post, especially Hack #2. When I rush through my sentences and start to run out of air, I will stop to breathe; it was nice to read Young's statement that the audience doesn't really notice this.

Do you like Top 5 lists? Check out ProBlogger's latest Group Writing Project ...

Technorati Tags: graphics, PowerPoint, Visio

Labels: presentations

posted by James P. MacLennan at 11:02 PM | Permalink | |

Project Status Dashboards Best Practice (and a PowerPoint trick)

For a simple, easily understood indication of project or task status, nothing beats the Traffic Light metaphor (Red / Yellow / Green). My IT organization is putting together standards for Project Status indicators in our PMO application; an interesting series of discussions and emails around the assignment of those Green / Yellow / Red (GYR) status lights ...

Words: What do we display on the screen? Green / Yellow / Red means ...

• Good / Fair / Poor? Hmm, nobody really wants to say their project is "poor"
• Good / Caution / Warning? Slightly better, but semantics can be a delicate thing
• On Time / Late / Really Late? This assumes that all projects "health" is based solely on the time dimension - what about features and budget?

We settled on what I think was a brilliant suggestion (not mine); just say Green / Yellow / Red. Most business audiences will understand your meaning without a translation guide - the whole point is to focus the conversation on the reds and the yellows, so we can take corrective action.

Ideas: A longer series of discussions developed around the ground rules for setting these status flags.

• We set the baseline assumption that we're only talking about active projects. Rothman's recent post added a fourth color, blue, to indicate completed projects, but aside from the color-blind issue (see below), I find it easier to relegate closed / completed project to another list, a separate slide - a different conversation altogether.
• To a great extent, a project's status is subjective, and in most organizations, you have multiple PMs assigning status. How can a dashboard view have meaning without some level of consistency? The challenge is that different projects have different critical success factors, typically one of four - scope, quality, time, budget. Our solution was to capture the critical success factor in the project description:
• Is there a critical must-have feature?
• Are there rigorous testing and documentation steps to be completed?
• Is this a time-boxed project, working to a deadline?
• Is the project budget capped?

Whatever the critical success factor is, the project status assignment becomes simple:

• Green: On target
• Yellow: We are approaching the limits of our success factor
• Red: Missing the critical success factor is imminent (or) we have missed

<aside> I still believe that there are only three success factors, and quality is a feature - but I lost that argument (hhh) ... </aside>

Pictures: Many applications have some form of status indicator icons available for reports and displays. The visual analog o