cazh1: on Business, Information, and Technology

Agile Methods in a Waterfall World: Speaking In Code

Labels: application development, design, development, hands on, tech management

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

Linkfest: Data Visualization

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

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

Facilitating Innovation: Establishing an Environment of Possibilities

I'm exchanging email with someone interested in establishing a skunk works, and they are asking some very interesting questions about the nature of innovation and the ingredients for an "environment of possibilities" ...

... things are ... [as they are] because someone already tried unsuccessful alternatives ... [This] begs the question: when it is required, how can rapid innovation be achieved?

Rapid innovation comes when the environment allows it and the skill sets enable it.

• An "environment of possibility" just means that folks are given some time to experiment with new technology, and access to the resources required to play around a bit.
Caveat: The challenge, of course, is that many folks expect the employer to allocate x% of their 40 hour work week, and provide training classes and server space to mess around with. Invest a little personal time and capital - in IT, it doesn't take much to build a solid development / test environment and start teaching yourself!
• I believe that the "innovation skills" are in everybody. But just like any other activity, success is 10% inspiration and 90% perspiration - individuals / teams / organizations need to build their innovation muscles by doing.
Caveat: A critical requirement for this piece is has to be ok to fail. The corporate culture must expect a failure rate for new ideas - remember, if it was easy, we'd probably already have thought of it!

... I value both history and future opportunity and am seeking a balance. Is this the same in your experience?

Well, Santayana was right - "those who do not remember the past are doomed to repeat it". But history should tell you specifically what tactics to avoid, but not necessarily what strategies will fail. Opportunity will be a mix of many things, and what was true at one time may no longer be true now. Look at imports from China - recent increases in transportation costs are making that strategy a loser for lower valued goods.

Process: How does ... leadership successfully position a think tank or innovation team so that it is (a) buffered from mundane corporate operations and politics while (b) it remains sufficiently connected to executive leadership and operating divisions for its ideas to be acted upon? (I'm assuming that the skunk works is outside the normal corporate business structure.)

Ah, this is an incredibly important question. Skills and environment aside, I've seen successful innovation happen only when the team was sufficiently empowered to get ideas implemented. Sometimes this comes from executive sponsorship from just the right person - but not as often as folks think! The cynical or weak of heart prefer to wait until they are granted permission to work on a project or idea.

The "drivers" that get stuff done do so because they have all the rah rah stuff (vision, drive, energy, whatever), but they also typically have knowledge of how things work in a company. Sometimes this means a long-time employee, who has relationships with the folks that control the key people, resources, and decisions. Sometimes this means the uber-techie who already knows how the various pieces of process and technology work, so they know how to call out the resistors when obstacles are thrown in the way (no budget! no approvals! too difficult! systems can't do that! it's against policy! yada ...). And you don't have to be a long-term member of the organization to be successful; experiences from multiple industries, organization, technologies, etc. can all be applied by someone with imagination and drive.

So, leadership needs to stack the deck for their innovation team by ...

• Carving out time in their schedules; don't just add this to everything else on their plate - take something off!
• Provide visible executive sponsorship. You need to be able to pull that card out every once in a while (You need to make this change because the CEO said so ...) - not often, but now and again ...
• Staff the team with a mix of long-term and newer employees
• Identify a team leader that has the right mix of hands-on technical (this cannot be a administrative role only - they have to be able to do something!), business, and relationship-building skills. They must be able to spot the opportunity through the hype, understand how it translates to business value, and then communicate that effectively and concisely to those who need to support it
• Hold their feet to the fire - the team should have goals and objectives, it's not a license to play!
• Let them fail! The most successful baseball players fail 70% of the time!

Also, the skunk works must remain connected to operations - they'll have to implement the "big ideas" eventually, and it's always good to remain grounded in reality. Make participation on the team a part-time thing for most; consider rotating different people in from various areas of the company, so everyone has a chance and all remain connected to the base business.

What lessons have you learned from the skunk works experience that you can apply to the innovation process? What broad, meta-issues and narrower specific issues has your project illuminated and solved (or at least, what questions has it posed)?

Aside from the organizational and change issues mentioned previously, I have found that innovation efforts often target things that are perceived as issues, but they are actually symptoms of more fundamental behavioral or structural problems. Web 2.0 tools and techniques are often lauded as new ways to unlock the wisdom of the crowds, connect with the new work force, or counter the flight of knowledge leaving the company upon retirement. Unfortunately, some of these efforts struggle due to what I call the Law of Large Numbers, which basically says that what works on the Internet doesn't always work at a corporation.

Also, it always seems to boil down to "Change Management" - an overused buzzphrase that just says change is hard (especially from a vending machine). There are many ways to address this (education, repetition, participation), but management always needs to understand that corporate operating processes typically don't catch on like consumer products - here today, gone tomorrow (look how fast the Apple iPhone turned over a new version!)

• Motivating Maintenance Programmers (January 6, 2005)
  
• Moving to Eclipse Ia - Relevance (June 1, 2005)
  
• Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
  
• My Favorite Paradox (August 13, 2005)
  
• Subtle Anarchy (August 22, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• Guidelines for Success with your Skunk Works project (June 19, 2006)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  

Technorati Tags: design, development, entrepreneur, innovation, operations, people management, tech management

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

Labels: application development, design, development, entrepreneur, innovation, people management, productivity, project management, tech management

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

Sample Interview Questions for MS Project

I still get interesting, unsolicited pings from the meebo widget on my blog site. I've got a Pidgin plugin that connects to meebo, so when it says I'm available, I am definitely at the keyboard, hacking away at something - and usually able to answer the quick message. Still, sometimes I'm amazed at the depth and detail of the inquiries.

Last week, I got into an interesting conversation with someone about MS Project interview questions. At first, I thought they were the hiring manager, looking for some material for their incoming candidates. Later, I found that this was a candidate, anticipating questions on their depth of knowledge in using the popular gantt-generator. Points awarded for being proactive! (note - he sent me his resume, so if you are looking for someone good, let me know ...)

I have published interview questions in the past, and have written/compiled sample questions for a number of programming languages - but I've never seen a decent check to validate if that incoming job candidate has some "chops" in MS Project. It would be a pretty handy thing to have - if a position requires experience with complex projects, such skills would be prima facie evidence that they can deal with complexity and rigor. Of course, it's not a direct indicator of their soft skills, but that's another conversation ...

So, I sent a request off to Andy Kiss, a colleague who has excellent PM and MS Project experience, and added his ideas to a quick eMail I threw together for my web-IM connection. Below, I've fleshed the Q&A out a bit, for your consideration.

As I created these sample questions, I noted many areas that do not necessarily have right/wrong answers. There is a certain art along with the science, and any experienced PM will have some (preferably strong) opinions about what works and what doesn't. You aren't testing for a specific skill level as much as a solid understanding of the theory and fundamentals, and war stories showing how they have applied these skills and made MS Project work for them.

Do you have a sample project plan you can walk me through?

Before they come in for the interview, see if the candidate can bring along a sample of their work. Ask them to bring in a paper copy, explaining that this should alleviate any concerns about distributing confidential or proprietary information in electronic format (they can keep the samples when they leave). Actually, you need to take a look at how they present a complex project in a relevent yet informational way (since review meetings with stakeholders typically take place over paper copies). How good of a communicator are they?

How do you add or delete a standard or custom column/field?

A bit of a trick question: there are many ways to add (or insert) a column/field, typically they will brute force Insert or use a macro. You should never delete a column/field that contains data; recommended approach is to hide the column.

Interviewer could drill in to the candidate's use of custom tables, views, fields, and filters. Have they set up templates? How do they manage consistency among multiple projects? Do they use automation or templates to develop standards and make incremental improvements for each project they work on?

Why would you embed contractor time within a Project plan? How do you do it, and where do you get the quickest information relative to contractor costs?

There are multiple reasons for contractor time, the most obvious would be the need to account for all tasks and dependencies. The candidate should also come up with a rationale around capturing cost - they need to demonstrate a focus on schedule and budget. It's also interesting to see where in the project proposal process they bring in high-level Project plans, with resource-loaded tasks and time lines, to develop initial estimates for the inevitable cost/benefit conversations.

Specifically, to get this done, you need to add contractor cost per hour on the Resource Sheet. Costs could be a blended rate (for High / Medium / Low skilled tasks) or specific rates for known resources. The candidate should be able to speak intelligently on how and why to create a blended rate - averaging hourly costs for full-time employees and contractors, the total project budget (when approved) gives you the flexibility (ie. the budget) to bring in external contractors when internal resources are occupied with other work.

How do you best embed resource availability within your plan?

Use a Standard calendar, noting non-working time for all resources. Then, embed out-of-office for specific individuals as needed. If you skip this step, you risk creating an inaccurate schedule, by hampering Project's ability to extrapolate accurate future dates.

You can sneak into a soft skills conversation here, by talking about the requisite negotiations for resource time within the business (I already have a full time job ... no time to work on this ...)

How do you model meetings and non-working time in a project plan?

There are a number of different methods - including ...
• Model all resource participation at 80% available time
• Change the default calendar to 6 hour work days
• Create weekly, 5-day (duration) tasks, for 1-4 (effort) hours per week, and assign everybody to this task

Candidate should be able to talk about the pros and cons of whatever method they select.

How would you best configure the critical path to be very obvious within your plan?

Format - Text Style - Item to Change; Select Critical Path and adjust color to Red or something else equally eye catching. Extra points awarded if the candidate is sensitive to the typical lack of color printers in many organizations - how does your Red come out now, hmmm?

Here's another opportunity to move into a soft skills conversation, with war stories about significant critical path moments in past projects, or discussing how to explain critical path to the project team.

Explain how Earned Value fields are used to compute Schedule Variance - and why this is important.

Schedule Variance (SV) = Budgeted Cost of Work Performed (BCWP) - Scheduled (BCWS)

Cost Variance (CV) = Budgeted (BCWP) - Actual (ACWP) Cost of Work Performed

Project Earned Value is a simple concept (are we ahead of schedule? Budget?), but most folks don't use it. It's an indicator of how good the candidate is at tracking an active project (as opposed to just using MS Project as an estimator / high-level planner).

Can MS Project be used to track an agile development project, and if so, how?

There is no right answer to this question, I've heard opinions on both sides. However, if someone can give a cogent, detailed answer either way, they are demonstrating their knowledge of agile and/or Project

What are your favorite MS Project books / web sites?

Project planning, estimating, tracking, and communication are possibly the most complex, nuanced area that Microsoft's family of Office-related applications hopes to support. Experienced, professional PMs should be actively looking to expand their skill sets with a variety of resources.

Have you done any VBA automation with MS Project?

This is not as common as Excel programming, but it might give some insight into their depth of understanding of the Project "database". Some folks automate look/feel issues, so printouts always look the same (consistency breeds familiarity). Other uses macros for particularly tricky utilization or costing calculations. The candidate should be able to glibly describe the benefits and challenges of automation with this tool.

I welcome comments / feedback on this list! If/when I get a decent number, I'll put together a nice little interview guide, suitable for download and re-use.

• Lots of interesting stuff going on in IM and Presence (April 6, 2007)
  
• Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
  
• Five Key Skills for Successful Project Managers (June 18, 2007)
  
• Five Best Conversations with my Meebo (web IM) Client (August 29, 2007)
  
• The Five Fundamental Rules of Project Management (October 15, 2007)
  
• Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
  
• PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
  

Technorati Tags: best practice, development, documentation, hands on, interview, ms project, microsoft project, project management, tech management

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

Labels: application development, design, documentation, microsoft project, ms project, PMO, tech management

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

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

Data Visualization: 'Life' of Open Source Projects

Part of the "art" of communicating IT and business abstractions - technical challenges, project roadmaps, budget performance, customer relationships, IT effectiveness - is landing on the right visualization. A picture tells a thousand words, and if you can draw the picture well, your target audience will grasp these concepts quickly, and (potentially) get insights that were otherwise difficult to attain.

I have a large backlog of web links to point to, posts to write that I'll probably start cutting into, now that I've seen this latest bit of visualization ... via Slashdot ...

A student at UC Davis has created some stunning visualizations of open source software contributions, including Eclipse, Python, Apache httpd and Postgres. From the website: "This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before."

As a developer, I can draw connections between the narration of significant events and the "flow" of objects. I've used these tools/platforms for some time now, and the story told by the animation connects nicely with my understanding of these tools' "personalities" - gives some insight on how they "grew up".

Python: This one fits my understanding of a typical open source project; lots of work by one primary, maybe one or two secondary developers, with fits and starts, bursts of activity. Over a period of time, a limited number of additional authors contribute, and things slowly expand until critical mass is hit, and Python is released to the public. Then, a flurry of activity as the popularity takes off ...

Apache: I was fascinated to see this project start off as an exercise in documentation - and stay like that for the longest time (code doesn't appear until about a third of the way through the movie). Like Python, Apache is a focused platform/application, and had a fairly concentrated core of developers and modules - unlike ...

Eclipse: I watched this movie first, but it belongs last in the To-View list. Eclipse is a wide-ranging platform with a large number of modules/functions - and a correspondingly large number of developers. It's amazing to think that the overall project could maintain such a high-quality, unified vision.

I'd love to see the Linux video ...

• Another Spam Graph - The Impact of Spammers Changing Tactics (September 17, 2004)
  
• Communicating Complex Technical Concepts (March 21, 2005)
  
• Spam Graph redux (nice filter!), and an interesting meme I stumbled upon (May 24, 2005)
  
• Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
  
• Build a Framework: Your chart junk is my roadmap / vision statement (December 27, 2005)
  
• Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
  
• Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
  
• Measuring and Reporting IT Value (1 of 2) (November 16, 2007)
  
• Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
  

Technorati Tags: design, innovation, presentations, technology, visualization

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

Labels: design, technology, visualizations

posted by James P. MacLennan at 10:07 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 | |

The Innovation Generation and User Interfaces

I don't intend for all my posts about Millennials joining the workforce to be anti-youth. There are some significantly good things this new generation can bring to established organizations - ways of thinking that foster innovation and forward-progress in how organizations use information.

For example, let's talk about user interfaces (UI). I'm not an old man, but I remember the advent of IBM's Common User Access standard. DOS-based computers and early GUIs introduced UI variety, and the resulting lack of consistency took part of the blame for systems that were hard to learn (and therefore hard to use). CUA promised consistency, greater productivity and information effectiveness.

Fast forward to the modern Internet era, and it's clear that "common user access" is no longer a baseline requirement for effective use of information. Cutting edge web sites pride themselves on their innovative, engaging, and unique front ends. Every website you see is different, yet it doesn't take people much time to figure out how to order a book on Amazon, browse for peripherals at CDW, or bid on stuff on eBay. These are mainstream Internet users I'm talking about; the tech-savvy are just the ones coming up with a new and different clown suits** for the same old services.

**And by 'clown-suit' I mean 'innovative dynamic XMLSocket/AHAH/AJAX-based exploitative web 2.0 social mashup,' of course. (props to findmemp3)

However ... isn't it interesting that those mainstream Internet users, productively surfing at home, are the same folks in your office complaining about difficult-to-use ERP systems? In this world, UI consistency is not an issue (okay, except when an acquisition is folded inelegantly into another framework). The challenge is with system designers and developers that lack an understanding of what makes a user interface effective and engaging - something that most longtime corporate system developers have never really been trained in.

Not that the newbies (sorry, Millenials) coming in to our IT departments automatically know how to design an effective interface - they are just more open to it, and they understand it better when they see it. Admittedly, "I know it when I see it" is hard to describe and extremely hard to train. However, now I must link to one of the few presentations I've ever been able to get a lot out of without having the presenter present to me ...

| View | Upload your own

Now, I certainly can't explain Kano Modeling and the more theoretical stuff, but it really starts to click on slide 15 when he showed a hierarchy of needs for user interaction. The slides lay out basic ideas that resonate, and terrific examples that you can recognize from your daily travels through the Internet. These applications speak to you, not at you, and make the act of using them a pleasurable experience. Simple stuff like conversational error / warning / guidance messages, effective use of pictures and words, and the value of "less is more".

I think a critical differentiator between an application accessible via the public Internet and the typical internal, corporate application is a fundamental assumption [on the Internet] that you cannot hold your user's hand through the process. The information presented, and the user's experience, has to stand on its own - because it is impossible to know who, when, and where your stuff is going to be used. This raises the bar for usability and scalability, but it's a great model to emulate for internal development in this lean economy.

So how do you make the jump between internally-focused developer and externally-savvy innovator? I'd start with Anderson's presentation - see if it "speaks to you". I think you'll either get it (and your mind will open up), or not (and you need to burn a few hundred hours surfing websites and experiencing the difference).

• Communicating Complex Technical Concepts (March 21, 2005)
  
• Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
  
• A blast from my past - game programming for the TRS-80 (October 5, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
  
• Open Source Insights on Enterprise Software Business Models (March 14, 2007)
  
• Lighten Up, Francis - Loosen Up That PowerPoint (April 14, 2007)
  
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
  
• Butting In to the Conversation: PM Communication Tools (February 26, 2008)
  
• The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  
• The Innovation Generation - Communication Styles (April 1, 2008)
  

Technorati Tags: design, development, innovation, Web 2.0,

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

Labels: application development, design, development, generational diversity, millenials, tech management, Web 2.0

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

The Innovation Generation - Communication Styles

There've been many articles in recent weeks about the tech-savvy Millennials and their impact on future work. I concede, even welcome the changes that business will need to introduce in response to these new expectations, but I don't see the massive change that some writers seem to think is inevitable. The world will not change to accommodate the Millennials, but relevant and effective new working styles will definitely be adopted where they make business sense.

I will certainly agree that communication styles will change. For example, there will be a greater reliance on (and expectations of) instant and ubiquitous connections - with people, information and technology. IM is already on the way out, and texting is the way to go; my high-school-aged daughters think nothing of racking up thousands of text mails every month.

Unfortunately, this kind of freewheeling message content is going to run headlong into the litigious real-world. Many companies are still struggling over records retention standards and expectations. Public companies will need to maintain some control over messages that could contain proprietary or inside information. Corporate survival and protection from liability are clearly not on the minds of students as they post embarrassing pictures on Facebook pages, and even adults get trapped by unfortunate text messages that come back to haunt them.

Don't get me wrong - I'm a huge believer in alternative messaging styles and flexible collaboration. I've managed and/or participated on multiple "collaborative" teams - people from different companies, zip codes, time zones and countries. Separation by time and space has been a business challenge for years, but you could set up a shared FTP folder, or swap e-mails about projects, as long as I've been working. The teams that succeeded understood the differences between working across the hall and working across town, and moderated their communication styles accordingly, using the best tools available.

The value the Millennials bring is a de facto openness to collaboration tools. To them it's not something new that they need to learn; they expect the rest of us to already be there. Their rude awakening will come when they need to invest some change management time getting us "old folks" to catch up to their fast twitch messaging style; they won't be able to pass us by because we've got the organizational and process knowledge. (that's why we're on the team, right?)

• CIO Mag - Decision Evolution (October 11, 2004)
  
• Fast ticket to getting left behind (February 15, 2005)
  
• International Meetings - Pick a Convenient Time (April 1, 2005)
  
• War Stories from the Change Management front (August 21, 2006)
  
• Consarned whippersnappers (Generational Diversity) (May 20, 2007)
  
• Innovation That Matters - Substance Over Style (January 12, 2008)
  
• The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  

Technorati Tags: collaboration, design, generational diversity, innovation, Knowledge Management, millenials, people management, productivity, Social Networks, tech management, Web 2.0

Labels: collaboration, design, generational diversity, innovation, Knowledge Management, millenials, people management, productivity, Social Networks, tech management, Web 2.0

posted by James P. MacLennan at 9:38 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 ar