cazh1: on Business, Information, and Technology

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

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

Labels: business value of IT, collaboration, documentation, hands on, Knowledge Management, presentations, productivity, project management, Web 2.0

posted by James P. MacLennan at 8:13 PM | Permalink | 0 Comments

Low Tech SharePoint Hack: Project Status Indicator

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

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

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

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

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

The JavaScript Trick

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

A Lot of HTML for a Little Indicator

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

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

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

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

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

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

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

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

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

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

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

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

Effectiveness Testing

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

Previously ....

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

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

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

Labels: application development, development, hands on, presentations, project management, SharePoint, tech management

posted by James P. MacLennan at 3:06 PM | Permalink | 0 Comments

Hacking the Google Chart API from Excel

a bit of code on a Saturday night ...

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

Click on the picture for a full-size image!


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

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

Sub CreateSparklinesDisplayFile()
  
   Dim sOutFile As String
   Dim iStartRow, iStopRow As Integer
   Dim iStartCol, iStopCol As Integer
   Dim i, j As Integer
   Dim sDataString As String

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

   Open sOutFile For Output As #1

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

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

   For i = iStartRow To iStopRow
      Print #1, "<P>" & Cells(i, iStartCol).Value & "</P>"
      Print #1, "<img src='http://chart.apis.google.com/chart?"
      Print #1, "chs=100x35"       ' Size (length x height) of final graphic
  
      sDataString = "&chd=t:"
      For j = (iStartCol + 1) To (iStopCol - 3)
         sDataString = sDataString & Cells(i, j).Value & ","
      Next j
      sDataString = sDataString & "0,0,0|0,0,0,0,0,0,0,0,0"
      For j = (iStopCol - 2) To (iStopCol)
         sDataString = sDataString & "," & Cells(i, j).Value
      Next j
      Print #1, sDataString
 
      Print #1, "&cht=bvs"
      Print #1, "&chbh=a,2"
      Print #1, "&chco=CCCCCC,FF3300"
      Print #1, "&chds=0,100,0,100'"
      Print #1, "title='" & Cells(i, iStartCol).Value & "' />"
      Print #1, ""
   Next i

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

   Close #1

End Sub

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

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

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

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

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

</body>
</html>

Some things I noted when constructing this stuff ...

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

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

Previously ...

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

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

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

Labels: application development, business value of IT, development, excel, hands on, presentations, technology, vba, visualizations

posted by James P. MacLennan at 11:03 PM | Permalink | 0 Comments

Zodiac of Knowledge Capture

Labels: collaboration, design, documentation, innovation, Knowledge Management, presentations, visualizations, Web 2.0, wiki

posted by James P. MacLennan at 10:20 PM | Permalink | 0 Comments

Inspiration, Images, Insight, Imitation, Innovation

Labels: design, innovation, presentations, visualizations

posted by James P. MacLennan at 9:58 PM | Permalink | 0 Comments

I Think I'm Learning SAPanese ...

Labels: documentation, Knowledge Management, presentations, SAP, supply chain

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

Excel 2007 is a BOB system (Bag'O'Bugs)

Labels: development, excel, hands on, powerpoint, presentations, technology

posted by James P. MacLennan at 7:11 PM | Permalink | 0 Comments

Linkfest: Data Visualization

Labels: design, facebook, innovation, presentations, technology, visualizations

posted by James P. MacLennan at 11:25 PM | Permalink | 0 Comments

Where to Start? (2 of 2) Metrics & Measurements

Bullet point #1 in your executive-friendly PowerPoint about "Achieving Operational Excellence in IT" covers Process and Procedure; so how do we measure our effectiveness? I'm a big proponent of Metrics and Measurements as well - but often times the biggest challenge is where to start?

Measure the Unmeasured

In most organizations (especially manufacturers!), the business has plenty of Key Performance Indicators (KPIs) that tell them how much productivity they are seeing, how much money they are saving, and how they are driving out variable costs. IT metrics don't need to focus on those things - and it's often difficult to get the business to share their control of the message.

Better to just focus on the behavior, performance, and availability of the system. For a start, try tracking uptime/availability. What percent of the year is the system available, with no problems? To be fair, you should define actual expected hours of service; is the system really expected to be 24x7? Or is it critical to be available and working from 4am to 9am - to get the day started, schedule the shift, print the reports, etc. These metrics help tremendously when the system does experience a hiccup; for end users up in arms over the lack of computing services this morning, point out that the system has had 99.9% uptime over the past year or so. Most folks understand the "five 9's" concept, where each additional decimal point of uptime costs an order of magnitude more $$.

For example ... this system is only used from 6 to 6, and never on the weekends. You didn't budget for high-availability / clustered / failover / megaservers, did you?

Click on the picture for a full-size image!

Another trick you can do with usage report: if 30% of the reports on your server never get executed, consider taking the first set of reporting requirements for your next project, asking the user to prioritize it all - and postpone work on the bottom 30% of the reports! You will cut a ton of time off the development phase of your project, and the metrics suggest that most of the stuff you cut would never be used anyway! Note that I said we'd postpone the work - we can always go back and add critical missing reports later.

Visibility: as Important as Readability

This framework should give you a jump start on what to measure; you really need to focus on how you will deliver your pictures to the target eyeballs. Nice stats, but how are you going to let folks know the score? If you are fortunate enough to have a robust portal environment, and can configure plug-ins with graphs and such, your job should be easy. You'll still have to learn to configure, feed the data, and automate - if not, the administrivia hassle will lead to neglect.

If your portal platform doesn't do the graph thing - or if the plugin renders unreadable graphics (go read Tufte!), you may need to fall back on charts driven from spreadsheets. These can look great, but the mechanics of getting the finished picture on a web page can be a bit tricky. Start small - take your first baby steps with a simple uptime graph, and figure out how to publish and distribute with minimal effort. Once you get the hang of it, you can move on to more challenging metrics / communications.

Lies, Damn Lies, and Statistics

When dealing with metrics, you need to be careful and thoughtful when drawing conclusions or postulating cause-and-effect. Consider this first picture, showing the breakdown of help desk tickets between "just-in-time training" and true break-fix issues.

Click on the picture for a full-size image!

One might infer that the user base has slowly but surely devolved over time. Trained employees leave the company or move on to other roles, new folks take their place. Training classes no longer exist, and little knowledge transfer takes place. The company is getting progressively dumber, and no one can stop the madness ...

Well, maybe not. let's look at the same metrics, but presented as actual volumes ...

Click on the picture for a full-size image!

This is a completely different picture; the marked decline is almost entirely in "break-fix" issues. Clearly, IT has been spending much of their time fixing the nagging little bugs and annoyances that lead to user problems. The number of "How-to" calls has been reasonably steady ... maybe this means that IT could stop programming and start working with the business on knowledge capture and retention ...

• Spam Graph redux (nice filter!), and an interesting meme I stumbled upon (May 24, 2005)
• Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
• Defining an Effective IT Metrics Framework (January 21, 2007)
• Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
• Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
• Where to Start? (1 of 2) Process & Procedure (August 5, 2008)

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

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

Labels: business value of IT, design, documentation, Knowledge Management, presentations, tech management

posted by James P. MacLennan at 8:25 PM | Permalink | 0 Comments

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 | 0 Comments

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 | 0 Comments

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 | 0 Comments

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 | 0 Comments