cazh1: on Business, Information, and Technology

Best Practices for Process Documentation: Iterations (2 of 3)

Labels: business value of IT, collaboration, documentation, hands on, Knowledge Management, people management, tech management

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

Where to Start? (1 of 2) Process & Procedure

If you need a one-slide, three-bullet, PowerPoint special for describing the basic tactics for "How to Achieve Operational Excellence", try these:

• Process and Procedures
• Metrics and Measurements
• Continuous Improvement

The first two are nicely alliterative, but you might consider substituting Standards and Processes as your lead-off if we're talking about an IT, Finance, or Engineering department.

Now What?

Of course, now you have to generate the details; the "motherhood and apple pie" routine only lasts thru the first meeting. Here's where many organizations discover that it's hard to know where to start. Most people find a blank sheet of paper intimidating; they prefer editing to creating. Also, folks are easily overcome by the volume and complexity of all of the processes they go through every day.

<aside> And for some reason, people seem to gravitate to the most difficult thing to document - "experience". It's like whistling - hard to describe on paper, but easy to demonstrate, with multiple variations and endless complexities. How can I possibly convey my thought processes when I'm debugging a system, triaging a set of problems, or pulling together those first few critical design elements?

Well okay then - let's not think about that right now. We'll talk ourselves out of any process documentation before we even start!  <aside>

Start Simple

For every job, there is a recurring list of "stuff" that folks do every day - administrative and busywork tasks that must be done, just to keep the wheels turning. This is the kind of "process" that lends itself very easily to documentation (and, afterwards, automation, but that's another post). It's the little things that you do, unnoticed until you take a vacation day or call in sick. All of a sudden, things stop working or start breaking, because you weren't there to reboot the server first thing in the morning, or clear a cache, or check a job queue for stuck items ...

So a great place for your team to start is to build a ToDo list of repeating tasks. It can be a simple text file, a Word document with nice formatting, a spreadsheet with convenient rows and columns - it really doesn't matter. My personal favorite is the spreadsheet - I use tabs to break up the lists into nice sized chunks ...

Click on the picture for a full-size image!

I've posted a few simple files on my Source Code page:

• Recurring Tasks01.txt - Text File - easy to convert to your wiki!
• Recurring Tasks02.ods - OpenOffice Spreadsheet, with sample tasks
• Recurring Tasks03.xls - (Excel version, saved from Open Office)

There are some nice features in the spreadsheets - like color coding for when a task is done (x) or undone (o). Also, the current day, week, month are highlighted automatically.

Collaboration Suggestion

If this idea makes sense, consider skipping the documents / spreadsheets, and create this as a wiki page (or collection of pages). Then, the entire group can add their recurring tasks - and the group will develop a shared master list. This makes it much easier to encourage shared tasks, standardization of work, etc.

Note: Does this structure remind you of 43 Folders and Getting Things Done? Well, that's definitely in the ballpark, but GTD focuses more on personal productivity. Daily / Weekly / Monthly Process Lists add structure and enhance productivity for a group. If you can scale the ideas in David Allen's book to help an entire group - and make it easy for folks to join and leave the group - go for it!

Some Task List Best Practices

1. Tasks on the lists should be one-liners. "Reboot the Server" or "Empty a Job Queue" are great, but if a single task actually has a series of process steps involved, best make that a separate, more detailed task list
2. Continuous improvement and ongoing documentation are themselves recurring tasks; consider putting a task to start each day thinking about items that are on your plate today that could/should make this list
3. The sample spreadsheet features the color-coded "checkmarks" that indicate when a task is complete. If you use a wiki (like TiddlyWiki), there may be plug-ins / extensions (like this one) that allow you to put checkboxes in the wiki itself. Checking the box when something is complete makes you think through each process step-by-step; if you just scan the lines every day, it's easy to slough them off. Plus, it's psychologically satisfying to see all those unchecked items get crossed off the list!

• Transitioning Process and Projects (July 30, 2005)
  
• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Hidden Gold in Automating Recurring Processes (May 28, 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 Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
  

Technorati Tags: best practice, collaboration, documentation, Knowledge Management, operations, productivity, tech management, Web 2.0, wiki,

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

Labels: collaboration, documentation, Knowledge Management, productivity, tech management, Web 2.0, wiki

posted by James P. MacLennan at 9:51 PM | Permalink | |

Enterprise 2.1: Exiting the Trough of Disillusionment

"What will you do with that car if you actually catch it?"
-- what the cat asked the dog (from the Chicago Reader, circa 1989)

So you've gone all "Enterprise 2.0", spinning up a wiki, a blog, and a SharePoint or Drupal server inside your firewall. Now what happens?

The groundswell of interest in "cool tools" brings a wave of users and a burst of feed reader activity - for a few weeks. Before long, however, the organization will get some rush orders, a month-end close, a project deadline, and/or a few vacations on the team ... and the same old excuses begin to weasel their way into the conversations. Folks begin to realize that collaboration and participation is more than reading (I actually have to type something into this thing?). Management styles are tested, and we find out if KM can be pushed on or pulled from the group. The questions start on a familiar note ...

Why?

The classic pushback against documentation; we see no immediate value added. When I'm programming or implementing a system, I'm making stuff happen; when I'm documenting, I'm only creating files that no one reads (and some ambient white noise for my cube neighbors). Of course, if there's only one person in the department that knows how the system works, and if they happen to be out on vacation when a problem arises, it's all hands on deck and a general scramble to figure out how things work. Imagine your consternation when you find out it's a five-minute fix ... if only they had written something down ...

There's also the career flexibility issue; if you're the only one that knows how something works, you'll never be able to move to the next interesting technology - stuck maintaining the Unknown System. Unfortunately, a plea to the value of Future Flexibility doesn't help when you're dealing with someone who likes to maintain control over the Predictable Present. Sooner or later, the benefit of getting rid of their inflexibility far outweighs the cost of reengineering anything ... it's just delayed pain.

Who?

Another classic question (who is supposed to write this stuff? Not Me!), with a contemporary twist ... the collaborative tools allow us to quickly broaden our audience/author pool, including folks outside of IT. In fact, this is a significant difference from fads gone by - non-IT folks are getting exposed to collaborative documents on publicly available, open environments like Wikipedia and Google; it's getting easier to talk to a growing number of people about interacting in a collaborative environment; the team isn't limited to the techies any more!

Which?

A much more important question - which platform should we use to capture this knowledge? When do you use a blog versus a discussion forum? Will I wiki, or should I SharePoint? Choosing IM over eMail is easy, but when should I tweet instead?

If you're working on this question, it's actually a good sign - folks have enough hands-on to understand the good and the bad about a variety of collaboration media. Experience is your best guide here; wiki's are great for fast entry and immediate distribution, but (IMHO) it's difficult to maintain a table of contents, index, or any multi-chapter / multipage chunk of knowledge. At home, I'm building the fifth generation of my home software development environment, and I've already passed over my personal wiki tool as unsatisfactory. Too many processes and interlocking technologies surrounding the servers, development environments, and push-to-production processes. It's much easier to create an actual Administrator's Guide (sample); a formal document with table of contents, chapters, diagrams, even page headers and footers. If I bothered to print it out, it'll look great - but I don't care about the paper. I like the structure that a book gives me - this is broad collection of information about a set of technologies and processes required to do one basic thing.

Each of the different Web 2.0 / KM tools has different strengths and weaknesses - flexible info structures, formatting efficiencies, ease of distribution, and support for collaboration / version control. The light will come on when you understand your biggest problem is collecting the knowledge; presentation, distribution, search, and sharing are covered nicely by the various intranet technologies, but the magic is in the making.

Doom and Gloom - and a Silver Lining

Disruptive technologies come and go, there are no silver bullets, and there's always a problem somewhere. If the environment is user friendly, it won't scale. If users accept the concept, they won't have the time to create content. If you can get all of these budding authors to write prose that is readable, you'll struggle with making it findable.

But hey - we're trying to pull out of this "trough of disillusionment" - so focus on the things that Web 2.0 does well ...

... and focus your attention on the "next version" (2.1) - practical questions of why? who? which?

• The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
  
• Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
  
• Moving from Search to Find: Anticipate the Next Big Problem (April 16, 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 Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
  
• Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
  

Technorati Tags: blog, collaboration, documentation, Knowledge Management, people management, Social Networks, twitter, Web 2.0, wiki

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

Labels: blog, collaboration, documentation, Knowledge Management, Social Networks, twitter, Web 2.0, wiki

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

Finally! Relevant Applications for YouTube and Twitter in the Enterprise!

If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!

However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!

Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...

What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.

Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.

... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...

Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!

• A VC in Vacationland
  
• Be Excellent
  
• Gemba Panta Rei
  
• Lean Blog
  
• LEAN Executive Blog
  
• Lean Reflections
  
• Leaning Towards Agility
  
• Learning about Lean
  
• LM - Industry News
  
• My Journey as Lean Champion
  
• Required Reading
  
• Sage Advice
  
• SCM Pulse
  
• TPM Log
  

• Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
  
• Misapplying the Pareto principle (January 7, 2006)
  
• Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
  
• Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
  
• Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
  
• Defining an Effective IT Metrics Framework (January 21, 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)
  

Technorati Tags: best practice, business value of IT, innovation, Knowledge Management, operations, supply chain, technology, twitter, Web 2.0, youtube,

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

Labels: business value of IT, collaboration, documentation, innovation, productivity, twitter, Web 2.0, YouTube

posted by James P. MacLennan at 1:58 PM | Permalink | |

IT and the Business are Closer Than You Think

A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).

Problem Resolution is Everybody's Problem

A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it's illogical to worry about stuff like this. We've implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn't anticipate - so the only people that will experience the bugs will be the people using the system.

It's inevitable that end users will find your problems, and that's nothing to be concerned about - we're all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about - how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?

Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements amd/or testing scenarios complete? (... apparently not ...) When projects are well run, and it's a true partnership between IT and the business, misses like these are everyone's problem.

Nature Abhors a Vacuum

Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren't under control.

On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can't accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest - but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.

In the End, We're All [Bad] Programmers

Check out this article from CFO.com, detailing a number of "worst practices" that folks in finance to see their counterparts doing that make them cringe. Sound familiar?

• Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
• Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can't remember the original assumptions (design), you may need to rework (refactor) the entire thing
• Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
• Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
• "Now It's Here; Now It's Not": at times it's too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
• The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)

In summary, the author provides this sage admonition ...

Treat the development of a spreadsheet - any spreadsheet - more like writing a term paper with footnotes and a bibliography.

See that? Accountants and programmers should aspire to be ... students?

• Heisenburg KM (July 13, 2004)
  
• Does IT make you productive (or, are you an existentialist or a fatalist)? (February 26, 2005)
  
• Things for the DIY programmer to consider (March 14, 2005)
  
• Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
  
• Sometimes analogies work amazingly well ... (July 14, 2005)
  
• Of course we can pay for that ... if it makes business sense (November 7, 2005)
  
• Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
  
• Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• Stretching Your User Interface Design Muscles (April 16, 2008)
  
• There ain't much IT in IT Management (May 7, 2008)
  

Technorati Tags: best practice, business value of IT, development, documentation, tech management

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

Labels: business value of IT, development, documentation, people management, tech management

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

iTunes Upgrade Freeze Resolved - and an Enterprise KM Observation

As many of you know, one downside of a career in IT is that we get pressed into [unpaid] service as tech support for the family's troubles with technology. My college-bound daughter has purchased her MacBook, and will soon find out (to her dismay) I have little hands-on experience with that platform. However, for many years both of my daughters have tethered their iPod to the family Windows desktop - I've done or thing or two over there. Fortunately (unfortunately?), I only get the call when the problems are significant, and the last big problems were no exception (two weekends down the drain ...).

They had successfully filled the hard disk to 98% capacity, and performance had slowed to a crawl. I had to chip away at the cruft left behind by months of downloads, ripping, and 'net surfing (BTW - can anybody explain why iTunes insists on making so many hidden copies of these songs?). The Internet is a wonderful thing - I got my crash course in the state-of-the-art for rescue disks and other file recovery utilities and processes - interesting stuff, but that turned out to be the easy part. The time-consuming problems came when I had to reinstall, and then upgrade, iTunes. After applying the latest version (7.6), I started it up - and nothing. No familiar library lists, no album covers - no music.

Being the techie type, I opened up Task Manager and saw all the right services running, but nothing appeared on the screen, So, a-Googling I went, and (consistent with previous experience), I saw I was not alone. I found threaded conversations, troubleshooters in forums, even a number of decent write-ups on Apple's site. Again, I learned an awful lot about stuff I didn't know before - the vagaries of registering DLLs (sccbase.dll slbrccsp.dll sccsccp.dll slbcsp.dll slbiop.dll and, of course, wmasf.dll & wmidx.dll), artifacts like iTunesAddIn.CalendarHelper, and useful utilities like Dependency Walker.

Still, after hours of struggle - nothing; color me frustrated, especially because the helpful folks on the other end of my browser didn't seem to have a consistent solution either. Then at dinner, my oldest daughter mentioned that she's seen this non-starter problem before. "I just plug in my iPod and the problem goes away". No - it couldn't be that easy ...

... but it was. Restart the PC with a freshly installed upgrade - nothing on the screen, but I can see iTuneshelper.exe and iPodService.exe running. So I plug in the iPod and voilà, the crisis is over. Too simple, and I'm not sure if this is the solution that will fix things for everyone, but I want to capture this knowledge here as a favor to the next beleaguered dad who follows in my footsteps (hence all the tech stuff in the paragraphs above - Google search bait).

An Observation: Knowledge Management (KM) in the Enterprise

The ultimate solution was straightforward and simple, and I'm surprised that Apple's upgrade instructions do not indicate any need to plug in the iPod to get things going. I don't know if the plugging-in step is required - plenty of hits from my Google searches, but I didn't get the sense that 80% of iPod users were having this problem.

I also noted that in all of these results / conversations, it's rare to see a final, definitive solution captured. The write-ups are helpful for narrowing in, but I suspect after hours of struggling with iPod and PC, folks are just relieved to be done with it, and don't think to come back to close the knowledge-capture loop by documenting the ultimate solution.

This phenomenon happens in the enterprise as well, especially when working on stressful internal projects or hot bug fixes for extended periods of time. You're so sick of the problem that you don't want to re-hash the process by capturing the detailed step-by-step in a nice, clear document. When you're working on a product your company offers for sale, it makes sense to capture this knowledge - you can expect many users will call in with similar experiences. On the other hand, seeing well-constructed root-cause documentation for internal development or processes is rare.

Mitigation: For the tech going through the problem-solving process, a very effective approach is to keep a log of the things that you're trying, and each dark alley you go down. This will make it easier at the end to go back, clean it up a bit, and put it in the knowledge base as a final document. The other way to drive this knowledge-capture behavior is to simply to require proof of full documentation before something is pushed into production. This is overhead and "bureaucracy" that most techies dislike, but it should drive better quality over the long term.

• Bug bad, bug good, bug Bug (May 18, 2005)
  
• The "Army Rangers" model for IT Professionals (January 2, 2006)
  
• Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
  
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
  
• Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
  
• The Joy of Programming, the Challenge of KM (May 5, 2007)
  
• Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
  

Technorati Tags: best practice, documentation, iTunes, iPod, hands on, tech management, technology

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

Labels: application development, documentation, itunes, Knowledge Management

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