21st Century Battle Command Training is "Infield Practice"

The latest edition of the US Army's Engineer Professional Bulletin contains an article I composed about the Fort Bragg BCTC's training solutions and their applicability in a Battle Command environment.

Thanks to Engineer for the opportunity to contribute to a such a great professional journal!

Direct Link: 21st Century Battle Command Training is "Infield Practice"

Entire Edition: US Army Engineer Professional Bulletin (Sep - Dec 2010)

DIKW is the backbone of KM

I have been reading about a construct called DIKW (Data, Information, Knowledge, Wisdom). This is a very simple methodology and makes a lot of sense. Also known as the Wisdom Hierarchy, this is sometimes defined as a a chain or pyramid, however, in today's data rich environment's I prefer to look at DIKW as a continuum or cycle that is never ending. This post is by no means a statement of the perfect KM solution - merely an additional consideration.

We use buzz words all the time. Collaboration, Productivity are easy to pick on. What do they really mean? The ability to create a document? Post it to a portal of some sort? Email or chat with someone about the posted document? In the US Army, we tend to emplace systems and abruptly state "We do KM". The presence of SharePoint does not equal organization KM. Database systems and spreadsheets certainly provide functional tools for our data and most individuals / organizations make information out of data (charts and tables are easy). The software tools we use are extremely important (many of our current tools are lacking but that would make for another post entirely).

The hurdle in DIKW is Knowledge then Wisdom. We must put all that data rich information to use and apply it to our processes and procedures to shape a knowledge base. The information is perceived and reasoned with as we begin forming knowledge and eventually we begin to gain wisdom as we apply knowledge to the way we operate and collaborate as individuals and teams. That is all well and good for a "text book" definition.

What about the real world? I like DIKW's simplicity for gauging where I am and where my team is. One can apply this to an overall effort or even components of the overall effort.

• Are you processing and presenting data as information?
• Are you providing information in an organized manner within operational procedures as knowledge?
• Are you building wisdom?
• Is your team collectively processing and presenting data as information?
• Is your team collectively providing information in an organized manner within procedures as knowledge? Does it shape the way you operate?
• Is your team collectively building wisdom and using it in strategy?

I believe DIKW is the backbone of Knowledge Management (KM). This gives every KM Officer, KM System Manager and even the actual Knowledge Workers a simple tool to guide their work and honestly measure the achievement of KM's real goals.

What do you think?

Bits: Ushahidi Crowdmap, Productivity Suites

1. Ushahidi: Ushahidi means testimony in Swahili. This crisis mapping technology was brought bear by an African organization amid the turmoil after the Kenyan elections of 2008. This is a platform for crowd sourcing SA - a capability to provide a means for any and all people in an area to contribute information about events in a particular area. The platform found huge success in the aftermath of the earthquake in Haiti. A new offering from Ushahidi, Crowdmap, is a thin client version to be stood up and deployed rapidly by end users anywhere via the commercial internet. Imagine locals, local government and NGOs being able to add incident information to Crowdmap amid a crisis. Note that CrowdMap is cell phone SMS capable (this is significant in disaster areas and 3rd world regions). Powerful stuff.
2. Productivity Suites: Word processors, spreadsheets, and presentation software have long been grouped and called Productivity software (a relic term from pre-Web 2.0 of course). I have always been amazed by the government and military use of MS Office with its huge licensing costs and maintenance). Most End Users of productivity suites only use the bare bones essential functions - even if they are PowerPoint Ranger tabbed. Why pay big fees for a ton of functionality when cost effective solutions are available? Open Office has been around for quite sometime, offers a very robust desktop productivity suite and is free. In the web based realm, Zoho's "fake Office" solution and Google's Apps for Gov would meet the need, provide huge cost savings and, arguably, increase End User / Team productivity! Need I say more?

A win / win - "Google Apps for Gov"

Google's launch of Google Apps for Gov is a huge step in the right direction for End-Users (and the budget). Until now, it seems the gov has merely been dipping its toes in the Web2.0 waters. Use of Social media has skyrocketed, but full on adoption of new age web capabilities is a rarity. This may be the belly flop off the high dive needed to serve as a catalyst.

A few key points on Google Apps for Gov:

1. FISMA certification, a private cloud based on US soil and additional security measures.
2. At $50 per user per year, this is huge savings in licensing fees of traditional enterprise capabilities (HW and SW).
3. Google Apps and its WYSIWYG characteristics are well suited to more than meet the needs of most government agencies (fed, state and local).
4. Google Apps use readily enables hardware agnostic as well as mobile use.
5. Rapid adoption and integration of new apps such as Google Wave, Marketplace apps.
6. The Navy is already using Google Apps (on a .com) for InRelief - one can only wonder if more .mil adoptions will occur.
7. Is Chrome OS next?
8. Microsoft is shaking in their boots.

This is a win / win situation. Gov budgets are tight and gov Knowledge Workers are disgusted with outdated and out paced software tools (read MS Office, MS SharePoint, MS Exchange, MS etc). This capability is now wide open for the .gov domain and may very well take over the landscape - I would not be surprised if swarms of government entities rapidly adopt this solution.

For more details, read PC World's story.

Enable US Army Knowledge Workers

I recently had the thought (and shared)...

"Good Knowledge Workers blur this line: Creating/enabling then DOING with IT tools."

Here is an expansion on that thought in the context of US Army IT End Users...

3 simple facts:

1. GUIs were first established to empower End-Users (and sell computers to the masses). End-Users now had a huge array of software that could be used, but make it do much more, a user had to consult the programmers. 
2. YouTube taught a generation about URLs and HTML. These are terms and concepts once relegated to developers and technicians. This has forever changed the landscape. Technical terms, concepts and sharing have become the norm. 
3. There is a huge difference between SharePoint and Google Sites. Beyond primitive read, upload, download, you need a CS degree to do simple back-end stuff (and a lot of licensing money) in SP. You only need to be literate to find huge success in Google Apps. I chose this example, but everyone has their own examples of this. Same comparisons could be made for ATCCS, ABCS and New Age Non-POR systems.

Knowledge Workers (War-Fighters included) toe the line between developing, tweaking IT tools and using these tools in the daily execution of their work. These are trained experts in a field using IT tools they have been trained on to execute their mission, they then become the experts to consult on development of said tools (no different in the Mil, Gov, Civilian or Private sectors). These experts are thirsty for info and new tools to use. This thirst leads to wanting inter-operable tools to mash-up and tweak for their own peculiar use. The current state of commercially available OS, desktop apps, web apps and social media generally meet this need. Knowledge workers like GUIs and understand the underlying "nuts and bolts" to a certain extent (that is why lack of interoperability upsets them - they are just smart enough). To be quite honest - if the GUI does not work / makes no sense, if they cannot import info from an authoritative data source, if they cannot export correctly... they do not use it (US Army POR and Non-POR system use comes to mind - the guys behind TIGR back in the dark ages just may epitomize this).

Developers must remember the audience - the End User. Do not get freaked out because your business model is changing, make your money now from use NOT maintenance. Build it on the back end, provide authoritative data sources and let the End-User control and USE the front end. Handle the code, data sources, SDKs and APIs but allow GUI based app creation and intuitive user interfaces too. Military endeavors are paying close attention to this. The US Army Enterprise initiative is moving forward rapidly. I believe they are on track with planned permeation of network and enterprise capabilities, but apps may suffer due to uphill fights with entrenched IT contracts (we should not need a zillion Field Service Representatives (FSR) for each system / app like the Verizon Network commercials).

Every single War-Fighter is a Knowledge Worker and their IT use is getting ready to explode (imagine the first time you saw the Internet and now your use of it today). They will have it in their barracks, offices, TOCs and pockets. This is bigger than the Knowledge Management Officer (KMO) deal. Industry must make IT capabilities unique, useful, application based, inter-operable, standard, data portable, web based, mobile, synchronized and off-line capable - give them what is now the standard Knowledge Workers.