Use the window below to chat with me (if I'm online ...)
Use the edit nick field above to let me see your name.
cazh1: on Business, Information, and Technology
Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Wednesday, January 31, 2007
More on (sic) experience with wikis
More on (sic) experience with wikis
no, that's not a typo ...
Preamble: This starts out sounding like a diary entry, but some interesting wiki-focused observations are found below - including metrics!
Catching up on old items in my feedreader: Back in November, TechCrunch had an item on AboutUs,whichat
first glance looked at little self-referential, a web site on web sites. Digging in a bit more - we find it's a wiki about web sites, which is still seemed a tiny bit redundant, but then I wandered over to my page - hey, it's already been built! And look, someone else has pointed out one of my postings!Interestingstuff,
so I started to edit the entry, cleaning up some of the info.
Nifty tools: The thumbnail of this site was a bit outdated - a makeover last weekend brings you the current Noir look - so I searched to find out how to get it updated. A few short clicks brought me to DomainTools.com, where the WhoIs pagegives
a full set of information plus a thumbnail - and let's you schedule your site's thumbnail for a refresh. I check back in 15 minutes - updated! Impressive.
You'll Never Walk Alone: While I am happily self-aggrandizing, I get an incoming IM from my blog!
<aside> This was weird and fun - as part of the aforementioned makeover, I added the little chat widget in the upper right - a very nice IM client / plugin from Meebo. Highly recommended in it's own right - fairly robust, I am seriously thinking of switching to it for all of my IM accounts (sorry, Trillian!) </aside>
On the other end of the chat was Mark Dilley , a definite wiki maven. He's involved with AboutUs and a group called RecentChangesCamp,andwe
had a fairly interesting conversation that wound around a few concurrent threads ...
Wiki Syntax Challenges: I commented about the multiple wikis I am getting involved with - behind-the-firewall using DokuWiki, a personal, best-practices-and-critical-data wiki for my USB drive using TiddlyWiki, and a few nascent ideas for 'net projects using MediaWiki.
I've noticed the challenge of multiple syntaxes; every wiki seems to have a little different take on headings, bold, numbered lists - definite hurdles for folks who really don't want to document things. Mark pointed me towards Creole, trying to establish a common wiki markup language. I'm pleasantly surprised to note that my wiki engines of
choice are all in the top 10 in popularity, and all support Creole (various versions).
Wiki Adoption: Mark also pointed to an interesting page at RCC: PatternLanguageForWikiAdoption. It reads like a set of discussion notes from a brainstorming session, but captures some recognizable archetypes. I spoke to some of the challenges of
wikis in a "small" group - we did some traffic metrics at year end, and noted that after the initial euphoria and/or curiosity, the group isn't making a lot of edits. We introduced this technology attempting to break down barriers to information sharing, but come to find out that maybe it's [low] interest / ability / priority, not [lack of] capability, that keeps us from capturing our organizational knowledge.
Effective communication is hard ... surprise, surprise ... but we keep hacking away at the issues ...
via Knowledge Jolt, here's a nice video of Tony Buzan, the originator of the mind mapping concept. What struck me was his focus on the mechanics of the mind map - curved lines and single words.
I've writtenpreviously on
MindManager, which I perceived was the best package out there. I note that it does not render with curved lines, and it doesn't train the single word idea.
I'm using mind maps more and more, but I still have lots to learn.
Defining an Effective IT Metrics FrameworkHad a really good conversation about metrics the other day. We've been discussing ways to express how our systems are performing, delivering value, and staying available - and I'd like to use the same general structure for all systems, regardless of function (transactions, integrations, analytics) or platform (Wintel, AS/400, Open Systems). For each type of metric, we need to understand two dimensions:
Performance against some Target. This can either be a baseline (a minimum or average expected score), or a threshold (over which the system loses efficiency; we may want to define both.
Trend over time: We may need to show sustained improvement, or use trends to predict when a threshold will be reached and plan accordingly.
We defined four fundamental types of metrics we want to understand and monitor for all systems:
Availability: I need to be able to access and use the system; expectations vary (24x7 vs "9-to-5"), but I should be able to quantify readiness. This metric requires a baseline, such as "98% uptime".
Capacity: Expressed in growth rates, but can also refer to a system's ability to work on some volume of tasks at any one time. Here, we might set a minimum baseline when first implementing the system, and a threshold to monitor before the next expansion (think disk space or memory).
Performance: Think speed, especially response time; how fast can I get stuff done? Here , we should set a baseline expectation; application response time for a transactional system might be quite different than an analytics system.
Thruput: How much work gets processed over time; how much work can I get done at any one time (or over some time period). A typical baseline would be a performance target (project tasks completed per month).
As we reviewed this framework, it became apparent that we could use it for people and groups as well as systems. Some examples:
Availability might track the mundane, like attendance - but why not track skills development and training (our "availability" to work on different types of technology?)
Capacity measures total time for projects (versus system maintenance). Process improvement reduces time required for maintenance, makes more time for projects.
Performance could include qualitative reviews based on peer reviews, surveys, etc.
Common Thruput measures include service desk calls answered, problem tickets resolved, projects completed, and programs written.
The next challenge will be to define metrics that can fit into this framework. More to follow ...
Metapost - Lifespan, terms, new editor, and lining up the big series
A post on posting ...
I got a comment today from a post that is just under two years old - interesting, the life span of this stuff.
I don't have a sales background, so I had to google Jorge's terms: FAB - Features, Advantages, Benefits; - Attention, Interest, Desire, Action
I will say that any tech manager should look into taking a sales class (or read a book, listen to some tapes ...) where they would explain terms like that. It's good to understand the psychology and process of the sale, even if you don't want to do it for a living.
I have recently been referring vendors / potential vendors to some of my previous posts, hoping they could improve their approach, especially in terms of the most effective ways to do business with me. Sometimes, it makes you want to write a book ...
I've upgraded to the new version of Blogger, so my desktop blogging tool no longer works. I'm using this as an excuse to work on one of my "resolutions" for the year, trying to eat some of the Web 2.0 dogfood. I agree with the vision that web-based applications will be a significant, viable, relevant part of the future of application delivery, and I aspire to design systems / solutions that take advantage of that architecture - so I need to start converting how I do what I do to be more web-based.
<aside> I'm very comfortable recommending solutions, and evaluating potential technology partners (ie. consultants / contractors / colleagues) when I have hands-on experience building, implementing, training, and using the technology in question. I kinda like to know where the potholes are, and when stuff is being shoveled at me, dig?</aside>
So - I've found WriteToMyBlog , an excellent web-based blogging editor. It's free (nice), and comes with plenty of features - my favorite is the button to add links (lots of extras, check out the hover text on these links!). I did have some trouble with Firefox and the AdBlock plugin - I've sent in my comments / observations, hopefully they can do something to resolve it. Still - a highly recommended site.
I have a long list of design-oriented sites / items that I want to blog about - some really interesting stuff, and I'm starting to see how I can explain that ephemeral, yet critical connection between technical skill and design sense. My challenge is that it's not the kind of easy message that fits into a single blog post.
I will use my newly-found fave process - Mind Mapping - to try to put some order to the lightly connected thoughts. The challenge, I think, will be how to break it up effectively into separate posts; it's not a linear topic, like theseseries were. I suspect I will need to rely on the hyperlink to connect the threads. Should be interesting ...
If your objective is a "sense of urgency", or maybe "time to value", please don't think this gives you carte blanche to push patchy, chewing-gum-and-bailing-wire solutions out into production. Expect the expectation that the production systems' availability level must be maintained.
Confused? It sounds like I'm taking two opposing sides ... I want speed and quality, and doesn't the Iron Triangleforce you to pick between the two?
It's possible, of course, you just need to practice a little discipline. Pay attention to the spirit, not the letter, of the "law". So how to reconcile the two ideas?
Fast, iterative Push-to-Test: If you're in a complex production environment (like an ERP), use the Test environment to get your iterations in front of your end users / testers. You can get the ideas out there, people can see what you mean, but the ultimate push into production only happens after a thorough, hopefully regressive, test.
Segment your Content: If you have decent change management capabilities, you can segment low-risk changes to production (like HTML and PDF files on a web page) from high-risk changes (like DTS scripts that process financial transaction imports). Fast-track the low risk stuff; better yet, completely automate it!
Formal Change Management Process: This may seem like old hat to the larger IT groups, but for those smaller organizations that have not experienced the pleasures of Sarbox ... a decent change management system (or even a hack one) should track all changes, keep a log of who and when, and make back ups of the before and after - so you can put things back they way they were.
I think, however, the most valuable thing you can do before claiming to be an Agile adherent is to Read the Definition of Agile: Please don't make the mistake that incremental releases skip or shortcut the testing process!
My other working title was How I Learned to Stop Worrying and Love the Methodologies ...
I'll admit, I am a vocal advocate for the agile mentality. It appeals to my practical side, the time-to-value, impatient, western business mindset shared by most of the executives I have worked for and with. The "universal truth": no one like to write requirements, and most people don't know the full requirements until they see the finished product (DWIMNWIS). Agile, iterative development is the way around this challenge.
Still, there was always that nagging doubt, especially when it came to foundational, transactional, run-the-business ERP stuff. SARBOX, 99% uptime, and highly-integrated systems all demand a very structured, controlled, rigorous QC process - that's traceable, auditable, yada. Some form of waterfall continues to be the best way to ensure success; also, the folks working on these systems have built their successful, fault-tolerant careers on this approach. Why mess with success?
The conversation was with a potential project partner, discussing something web-enabled that would faciliate processes for order/product information. The project had tight timelines - in retrospect, maybe a bit too tight, but we had to start somewhere. The hidden truth, of course, was that most of the magic was going to happen after the fancy web page gathered up the information; we had to initiate transactions, schedule production, etc.
All the meetings with preliminary partners were an effort to find out how they might approach such a project - was there a SCRUM in our future, or would they stick to the waterfall?
This potential partner made no decision, promising to work iteratively for the web stuff, and structured when hooking to the ERP. Were they waffling? No, just facing the facts: these methodologies work in different environments because they address specific needs. The real problem with any methodology / process / tool is when you try you apply it to all situations - that's just not realistic.
This was one of those things that was obvious ... once someone points it out (kinda like 30% of an MBA degree) ...
<aside> I've always felt that MBA school was 50% stuff you already knew, 30% stuff that was obvious - once someone pointed it out to you, and 20% really new information. </aside>
I've been using that phrase a lot recently at work. It's really a callout to the process- and procedure-driven; let's open up a bit to a less structured, iterative development / project process. We're implementing a number of things - PMO, project methodology, wiki / KM, stuff like that - that sit at a lower priority level than the "formal" business projects. Most of the forward progress happens during the slack time of the day, nights and weekends, and "deliverables" appear in various states of completion.
Regardless of what most folks say, this is still intrinsically foreign to many folks in IT. I don't believe it is an age-based phenomenon; I notice it more in folks who have worked in large corporate environments, often for more than 5-10 years at the same place. A contributing factor is "career homogeneity"; if one has not worked in a variety of roles, in a variety of industries and companies / organizations, there can be resistance to agile-style projects.
Atwood observes another contributing factor - the tools we use. For many, MS Project is the critical hammer for every nail, and the waterfall mindset is baked into the heart and soul of the gantt chart. Waterfall traps many into the firm belief idea that requirements are understood, defined / definable, and fixed. His pair of posts also reflect on the difficulties of estimating / predicting / scheduling of software development projects - more reason to work on your agile tendencies.
<aside> Note that requirements and change orders can be a critical source of tension, disconnect, "lack of alignment" between IT and the business. It's natural for folks to work with a new capability for a bit and find their ideas for effective use of the data start firing. The IT project team will push back - the plan, schedule, and budget are complete! Real business value is locked up in the new insights of these business users, and an agile delivery style (many releases, smaller feature sets) can bring a lot more value. </aside>
Anyway, I came across a pair of posts I thought were interesting:
Macomber writes about Toyota's "relentless attack on complacency". Something to note for companies driving Lean / Six Sigma initiatives for the new year. There is a steady drumbeat at Toyota, always looking for the next improvement. It strikes me that this is closely related to the agile development / fluid requirements meme, a bit of a reality check; I can't understand the next improvement (requirement) until I see the sum of all improvements (development) to date. The "project" is never complete. The requirements are always changing. And yesterday's terrific idea can very easily lead to additional insights, and get tossed out / reworked tomorrow. The value is not in the destination, but the journey.
Patton put out a pretty deep post about how "tricks and techniques" (insight? understanding?) trump process and methodology for design work. Ok, I had to read it twice before the light started to go on, but to me, there's an ever-present oxymoron of design/process when diving into a new project. If you can pick up the threads and make the insights (at the very least, open your mind for the possibilities), then real value-adding work gets accomplished.
Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
Copyright (c) 2004-08 James P. MacLennan All Rights Reserved
All trademarks and copyrights on this site are owned by their respective owners.
Comments are owned by the individual posters. All articles, blog entries, and other content on this site are licensed under a Creative Commons License
