Solution Evolution


Note: I apologise in advance for this being an infomercial for Box. I assure you that was not my intent when I started writing this post.

monkey-1538315_1280A few weeks ago (Oct 10 – 12) my new colleague (I’ll explain later), Greg, and I were at BoxWorks in San Francisco. For those of you who don’t know, BoxWorks is Box’s annual conference, and a must-attend event for those interested in content management, especially cloud first content management. A topic that came up more than once was OpenText’s purchase of Documentum. Specifically, what it means for Documentum customers, and what they are thinking. I’ll give you a hint; https://www.youtube.com/watch?v=7FPELc1wEvk.

Let me just say that Aaron Levie owes Mark Barrenechea a great bottle of Scotch, a bouquet of roses, and a hand-written thank you note. If OpenText hadn’t bought Documentum I doubt you’d hear of so many Documentum customers getting ready to bail, and taking a serious look at Box as a viable replacement.

More recently, we had a couple of very relevant and telling conversations; the first was with a Box customer looking to get off Documentum; the second was with Box. I also had a conversation at last year’s BoxWorks event with someone in a highly regulated industry. Their company is a sizeable Box customer and is, reluctantly I think, still required to use Documentum for some of their more regulated content. I’m fairly certain that they’d prefer not to have to rely on Documentum. For what it’s worth, I had this conversation prior to the closing of OpenText’s purchase of Documentum, but we all knew it was coming.

This is just me being long-winded in telling you that I have decided to join e-Wave Solutions (the Greg I mentioned is Managing Partner). We’re a small company headquartered in Calgary, Alberta, Canada. In a nutshell, we bi-directionally integrate content management systems with SAP. Greg invited me down to BoxWorks, we had some interesting conversations, I got excited, Greg got excited, and we literally shook hands on a deal on the flight home.

Anyways, I digress a little … where I’m actually going with this post is that there is going to be an evolution of Box within client organizations. It won’t simply be spread and sprawl, like we see with so many ECM implementations that begin life in one department and eventually spread throughout most of the organization. Certainly this will happen with Box, but with the added advantage of (easily) encompassing the extended enterprise (i.e.: external stakeholders).

No, the evolution of which I speak is about starting as a relatively simple content management implementation and evolving into actual business solutions. Yes, legacy ECM platforms are certainly capable of this as well, but most haven’t gone down that path for one reason or another.

For Box customers this evolution is going to happen one of two ways, or, more likely, in a hybrid manner. Customers are going to sign up for Box to solve some pretty simple content management and collaboration uses cases. Once they have this initial set of use cases sorted out, they are going to get a visit from their friendly neighbourhood Box representative and be shown “the art of the possible” (I really, really hate that phrase!). Once they see what can be done with Box and its myriad integrations, they are going to start crafting solutions that solve business use cases.

As much as Box, paired with some of its available integrations can do, it can’t do everything. And this is where that second type of solution evolution comes in, and it’s called Box Platform.

I’m fairly convinced that organizations wanting to have content centric business solutions are going to need to build applications that tie together disparate repositories with business logic. Today, a basic premise of Box is that all your content is in one place; that’s not realistic, nor will it ever be. Even legacy ECM platforms relied on Business Process Management Systems (BPMS) to tie together content and logic from multiple systems in order to deliver business solutions, rather than content management solutions.

A client that I have spoken with intends to use their content management system (CMS) for loan origination. That’s cool, but, other than the content, there is nothing in the CMS that helps with loan origination. The business logic is in an ERP tool and the content is spread across multiple repositories, one of which is Box. Currently, they really have no way to tie everything together in order to deliver an elegant, functional, efficient solution to their users and clients. However, once they go down the Box Platform path, and they will even if they don’t yet know it, they will have the tools necessary to build an end-to-end solution for loan origination.

Think about all the different content centric / reliant use cases that every organization has that they use every day. Think about their desire to go mobile and go to the cloud with as much as they can. That’s when the beauty and the magic that something like Box Platform happen; it allows organizations to build content centric applications that transcend technical, geographic, and organizational boundaries. A little over two years ago, when Box Platform initially became available, I was pretty excited (as you can tell if you read this); there is no reason for me to change my mind. Box customers looking for solutions beyond content management and collaboration are going to evolve into Box Platform customers. When that happens the potential impact of Box products such as Relay, Skills, and Graph (all announced at BoxWorks, all coming soon) is going to be even more important than it is today.

 

The BA and the Shiny Objects


diamond-1186139_1280A few weeks ago I was approached about working with an organization to help them put together a new SharePoint 2013 site to replace the one they currently have (SP2010). The business unit that approached me is responsible for engaging with stakeholders when the company wants to build infrastructure in their operating region; let’s call the unit EE (external engagement) for the sake of discussion.

Now, before I get all ranty and critical, you should know that EE wasn’t getting much love and attention from IT; this post is not about assigning blame to EE or their Business Analyst, with whom I’ll be working pretty closely. The fact is that there are problems in how IT engages with the business that are way beyond the scope of this post. As you read this post, keep in mind that a business case has been prepared and approved by IT (a VP) and EE (a Director and an SVP).

To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.” That quote is the first sentence of the main body of the approved business case for the project. The case goes on, in excruciating detail, to describe in non-quantifiable terms how implementing various features and functions available in SharePoint 2013 will benefit the department. What the case doesn’t contain is any sort of goal or objective from the business indicating why the project is necessary and what the measurable business outcomes ought to be. Nor does the case contain any criteria upon which project success will be based.

If I were to summarize the business case as it’s currently written, it would be something like “There’s a bunch of cool SP2013 stuff that isn’t being used and we think we can use it to make our site look pretty and show people what we’re doing and we’ve started a Proof of Concept (PoC) that we’re going to finish soon to show you just how pretty those SP2013 things will look on our site and we’re going to do whatever we want whether it’s standard or not even if it’s stuff that other projects and departments are really responsible for. Okay?”

In addition to containing a shopping list of SP2013 features to be deployed, the business case also makes assumptions about the way in which many of the features will be deployed. Now, having some insight into the organization, I can tell you unequivocally that many of those assumptions are incorrect because they don’t comply with standards and guidelines that the organization has adopted. To be fair, had IT paid more attention, these deviations would have been caught and much time and money would have been saved.

I, and others, have advocated for trying to get the most out of the technology organizations have on hand. However, that doesn’t mean that organizations should invent requirements that provide no discernable business benefits simply to make use of some feature that’s currently sitting on a shelf. What it means is that, once real business needs and benefits have been identified, organizations should look at the tools they have on hand before going out to acquire something else. Of course, this should all be bound by an organization’s standards and guidelines.

Fortunately, the business case has been approved only to get the business requirements done. The organization uses a pure waterfall, gated SDLC so I’m going to use that to our advantage and try to get things back on the right track. I’m also going to try and get the PoC descoped or killed altogether. Things aren’t so far down the path that they can’t be corrected, but it will take a fair bit of cajoling and coaching of the BA. We’ll also have to get IT more engaged but I have a pretty decent PM to help with that bit.

Things to take away from this story:

  1. Only deploy technology based on identified and accepted business needs;
  2. Have measurable outcomes defined so you can actually determine whether or not you’re succeeding;
  3. Business and IT are partners and must work together;
  4. If your BA isn’t that strong, make sure they are properly coached and supported;
  5. Don’t sign off on a business case that doesn’t contain business objectives, business drivers, or success criteria;
  6. If you’re not going to comply with corporate standards and guidelines, cool, but have solid justification for not complying[1];
  7. If the first sentence in your business case is something like “To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.”, you don’t actually have one;
  8. Shiny Object Disease is both preventable and curable.

 

[1] Many years ago I had a contract gig with a major airline. My sole responsibility was to evaluate non-standard IT requests to determine whether or not the provided justification was sufficient enough to warrant approving the request. I.e.: Standards and guidelines can occasionally be broken if there is valid justification.

Technology Doesn’t Guarantee Success


spamont1There’s an old saying in car racing that goes something like “you can’t win the race in the first corner, but you can lose it.”  There is a similar truth when talking about software. The right software will not fix your problems, but the wrong software will surely exacerbate them. This, then, is a little story about choosing the wrong software.

Just prior to Christmas 2015 I took on a small project in Vermont. It was a bit of a weird situation in that the project was a mashup of two projects I’d done the previous year; the client was in the same business as another client, and the project was the same as a different client. No matter.

The client wanted to find out why their staff wasn’t in love with the Enterprise Content Management (ECM) solution they’d deployed a few years earlier and why things were failing. With a few exceptions this could have been a copy of an assessment I did for a university (detailed in this post & case study). The key differences were the technology chosen and the business the two organizations are in. In the case of the university, at least they chose the right type of technology for their needs. The folks in Vermont kinda, sorta, almost made the right choice, but not quite.

Back in 2008/09 their legal folks decided that they needed something to manage all their documents, so they went out and sourced a document management product targeted to professional services organizations. At the time no one was thinking holistically about what the organization needed. Whatever, it’ll all work out. Uhm, no.

As they were researching what to buy, they determined that their compliance and procurement departments had similar document management needs, so decided to deploy whatever they bought to those groups as well. There’s nothing wrong with trying to get more bang for your buck, assuming that the fit is right. Right?

My client went out and selected a product and got it implemented. Now, the implementation did not go smoothly, but that was nothing to do with the product and everything to do with selecting a less than stellar implementation partner. However, that’s not what this story is about, though you really need to be careful about selecting an implementation partner.

Once they got the implementation under way, they decided that the product they chose would be their ECM standard. There was a tiny problem; the product they selected was not an ECM product. As stated on their website [name withheld] “is the global leader in professional work product management”. The vendor’s target market is primarily law firms. Over the course of the project I spoke to the vendor and a couple of peers that work for organizations that use the vendor’s tools. They all agree that the product is not suitable as an ECM platform. The two peers I spoke to said that the product is very good if you use it for what it’s designed to do, but you’d be mad to try and use it as an ECM platform. To get back to my race car analogy; it’d be like trying to compete in the Dakar with a Formula One car.

But really, how bad could it be? Well, prior to implementing the product, everyone in the company knew where to find stuff, even though it was a pain. While they weren’t thrilled about using file shares, FTP, and email to store and share content, they knew how to work with the tools they had, regardless of how prehistoric they were. Now that they have the new platform, most people in the company are more than a little fed up:

  • They file stuff and can’t find it again;
  • They’re supposed to send links to colleagues, but have to rely on email because security is borked;
  • Where previously there were standards, now many have their own way of doing things;
  • Irritation with previous tools has been replaced, in many cases, with hostility;
  • This list is not complete.

It’s gotten so bad that my client is seriously considering ripping out the solution they implemented and going back to using file shares. I wish I were kidding.

As my university client found out, choosing the right technology is no guarantee of success. However, as my Vermont client found out, choosing the wrong technology is a guarantee of failure. Choose wisely and do all those other things that come before selecting and implementing technology. After all, a solution / system is a combination of people, processes, and technology.

Adopting ECM – A Case Study in Failure


Head in HandsEarlier this year I completed an assessment of Alfresco for a university client. The university licensed Alfresco several years ago and did not have much success. They hired me to find out why, and what to do about it. The options they wanted to look at were to continue on with Alfresco or switch to SharePoint. An option they weren’t willing to consider was a cloud based option. I gave them one anyways, based on Box. Unfortunately I was asked to remove that option from the final report. Oh well.

While the platform in question was Alfresco, I can’t stress enough that the failure had nothing to do with the platform. Under the circumstance nothing would have succeeded. You can read a bit about it in an earlier post here.

I’m trying something a little different; because of my altruistic nature I am making the final report available as a downloadable PDF. I figure there’s stuff in it that many could use, and perhaps critique that would be helpful.

I want to thank Laurence Hart for his contribution to the report and the overall project. Thanks, Laurence. You can follow Laurence on twitter at https://twitter.com/piewords and check out his blog at http://wordofpie.com/.

Anyways, just follow the link and you ought to get to the report (no fees, no signup, no tracking). Feel free to provide feedback.

University ECM Assessment – I’m using Box to share this content. Please let me know if you have any issues.

Image: “Paris Tuileries Garden Facepalm statue” by Alex E. Proimos – http://www.flickr.com/photos/proimos/4199675334/. Licensed under CC BY 2.0 via Wikimedia Commons

Guerrilla Tactics – IG Whether or not they want it


Gas Mask VeggiesOn September 18 the Information Governance Initiative hosted a twitter chat to discuss their 1st annual report. At some point in the chat I referred to myself as using Guerilla tactics to apply Information Governance practices in client projects.

Question 3 of the chat was “Do you have any active InfoGov projects under way at your organization?” Now, I’m a consultant so for me the question’s really about my clients’ organizations. My answer to the question was “No. My client has biz projects that are being framed by good #infoGov practices.” Followed by my comment “I am turning into an IG Guerrilla Tactician.”

Just because your client doesn’t have IG budget, programs, or projects, doesn’t mean that good IG practices can’t be infused into the projects that are happening.

I have yet to work on an Information Governance project for a client – they just don’t want to hear about it. That doesn’t mean that I execute projects while ignoring IG practices. For example: I am currently working on a couple of SharePoint projects for a client. One project is to develop a site for their regulatory team to build and submit applications to a regulator. The second project is to create and publish field reference manuals. Both of these projects have concrete business objectives; neither has any sort of IG or IM as part of the mandate. In fact, until I got involved no one was even thinking about applying any sort of overarching IG/IM policies or procedures into any of the projects, much less on an organization wide basis.

The client’s environment is rife with poor information governance and management practices:

  • Content duplication;
  • Emailing attachments instead of links;
  • Information silos;
  • Keep everything forever;
  • No centralized accountability for information;
  • Won’t mention the fustercluck that is their SharePoint environment;
  • No metadata standards or taxonomy;
  • Severely limited search capability;
  • No use of automation for capture, tagging, sharing, or routing of information;
  • A rudimentary file plan and retention schedule that is largely ignored;
  • Etc.

The funny thing is that many people at the client know that much of what they’re doing is wrong, even if they don’t know why it’s wrong. What they don’t know is how to eliminate the bad practices and replace them with good practices (forget “best practices” they really only exist in theory). They also don’t know, in all cases, what a good practice is.

We start with Principles of Holistic Information Governance (PHIGs). The clients like them because they’re common sense and written in English; they’re also loose enough so they can be adjusted for the business being supported / addressed. We also use an iterative approach to designing and building the solution (it’s very agile-like) that involves all the major business and technical stakeholders (the pure tech stuff takes place off-line). Our focus in these projects, beyond solving the problem, is really on two things: 1) eliminating waste (effort and info); 2) delivering a solid user experience. We also impose a lot of rules around how information is created, managed, and delivered. To illustrate:

  1. Thou shalt send links, not attachments (client VPN is an obstacle that’s being dealt with in a separate project);
  2. Thou shalt use versioning rather than sending more copies with “v2_0_3_d_SOMEGUY_Edits” in the file name (change mgt and training required);
  3. Thou shalt label thy contributions appropriately (we’ll help by implementing some workflows and forms);
  4. Thou shalt not make copies when thou needst them not (metadata and user roles will help users find what they need, proper backup & restore will be implemented);
  5. Thou shalt not keep thy stuff indefinitely (ah, retention and disposition policies will finally be enforced);
  6. Thou shalt not facilitate unauthorized access to information in thy care and keeping (keep it in the repository, where it can be secured);
  7. Thy content is not thine, it’s thy employer’s.

As we’re working on things like metadata models, user roles & groups, user interfaces, and other stuff, we’re doing so with the view that we’ll be creating a set of practices that the organization can adopt for all projects going forward. We’ve even got a couple of really hot SharePoint people on the project that are helping us to define repeatable SP practices. There’s only one tiny problem with our approach …

can-of-worms

At a recent Steering Committee meeting, our venerable Project Manager invited two guest speakers: 1) Jason – to talk about SP standards and best practices; 2) me – to talk about PHIGs and IM best practices. Jason and I said the same things, albeit focusing on our particular areas of expertise. All was well until the VP of IT realised that while we were doing some really good things on the project, these things were totally under the radar. Much to her credit, instead of demanding that we revert to the client’s methodologies (which were in part responsible for the current situation), she began asking what needed to be done to leverage the good things we’re doing on this project and apply them across the organization.

So what’s next? Well, the client is having me get involved in at least one more of their projects; SharePoint will be the deployment platform and IG will provide a foundation. It’s not a SP or IG project; it’s an HR project that relies on information. Sometime in October Jason and I will be invited to speak to the corporate governance council; Jason will talk about SharePoint and I’ll talk about PHIGs. The whole point of our attendance will be about how to get this heavily regulated client to adopt good practices for managing their information and the technologies they use to access it. Pretty cool, I think (I might even wear a tie).

Sometimes you’ve just got to sneak IG into your clients’ projects the same way that you sneak veggies into a recalcitrant child’s diet.

Give it Away – The Value is in the Knowledge


If I were to start an enterprise software company today, I’d give the licenses away. No, I am not thinking about open source at all. I’m thinking about services, non-core functionality, and integration. I’ll stick to Enterprise Content Management software, but the principles are applicable to any enterprise grade platforms or suites (we can debate what “enterprise” means until the cows come home to roost, but not here or now).

Let’s face it; you can go and pick almost any large ECM suite and the core functionality is going to be pretty much the same across all of them. For the sake of this discussion, let’s define core functionality as:

  • Check in / check out
  • Versioning
  • Basic search
  • Metadata
  • Security
  • Basic workflow
  • Audit
  • Some sort of UI (usually pretty crappy)

There is no substantive value differentiator to be had in choosing one over another. In fact, if any one of those items were missing, I doubt the software in question would even qualify as an ECM tool. I also think that in the very near future, file synching and sharing (e.g.: EMC’s Syncplicity and OpenText’s Tempo Box) could become core functionality (if it were my company it would be).

So, I’m going to give you the basics for free and I’m not even going to charge you for training and maintenance. I will charge you for implementation (if it’s on premises or on hosted infrastructure) and support, though. Why would I be so generous? Because I am really friggin’ smart. I want your organization to deploy, use, scale, and extend my software. I want you to realize that what really sets my software apart from the competition is the people I’ve got advising you, architecting your solutions, and deploying to your people.

What enterprise is going to live with just core functionality beyond a proof of concept phase, if that long? Even if they do, how long until they figure out that they’ll get way further if they hook up content services (yes, I said services) to other enterprise or line of business systems.

Don’t get caught up in the whole “if it’s free there’s no value” thing; it’s bogus. You need to understand the difference between cost (what you pay) and value (what you get). Besides, I already told you it’s not free, sort of. You’re going to have to implement the software. I or a partner can do it for you, and you’ll get billed. You can have your internal folks do it, and you’ll get billed to get them trained. It comes down to paying for the knowledge and expertise, not for the tool.

The value proposition for core content services (or content as a service if you prefer) is in pushing the content to other systems (processes+people+tools), and in being the core repository for content across the organization. Once your content is in the repository and being managed with the basics, only then am I going to start charging you for the add-ons. Add-ons are not by any means trivial, but they are not core for all organizations. For example, Digital Asset Management (DAM) – not everyone needs it, but to those that do it’s critical. And I am going to charge you for it (license and services). Hey, you want to use someone else’s DAM solution because it’s more suitable for your organization? Cool, but I am going to charge you for the integration. Same goes for web content management, ediscovery, records management, migration tools, large file transfers, etc. Integration to desktop tools, other enterprise systems, line of business systems, and cloud services? Damn right I’m gonna charge you.

“But what happens when partners do the initial implementation? You won’t make any money.” Truthfully, I don’t care. What I do care about is being at least as diligent about selecting partners as you are about selecting technology and service providers; I want partners that are every bit as invested in your success as I am. I want you, me, and the partners to be a triumvirate. If I really want a shot at success, I have to make sure that you succeed, regardless if you engage me directly or not. The only way I am going to do that is to support my partners as much as I support you, and to be there when their skills have gaps.

“But they’re a partner, how can they have skills gaps?” Well, because they’re partners and not my staff. Partners are never going to be as close to the product as those who build the product; it’s a fact. Besides, they’re out in the field implementing stuff and gathering feedback. That’s what I want them to do. And if I’ve set my partner model up properly partners are integrated into my processes and supported. My partners are also a revenue stream.

I don’t want any schmoe that’s done one implementation and read some stuff to be running amok out there. I want partners that can do as good a job, maybe even better, than my own staff can. I am going to spend time and money making sure partners are up to the task, and for that partners are going to pay me. If you want to work with the schmoe, that’s on you. Don’t come crying to me when it all goes wrong. Do come to me to help you fix it. I promise not to say “I told you so”. As long as there’s long-term success, I’m not too concerned about short-term faux-pas.

Anyways …

I don’t own or run a software company, and I’m not about to start one up; I’m an analyst/consultant with Digital Clarity Group. We help organizations get stuff done, including selecting technology and service providers. I hope that I’ve made you think about a few key things as you ponder your technology and vendor choices:

  • Cost does not determine value – lots of open source and low cost tools are every bit as good as stuff you’d pay a fortune for;
  • Regardless of cost, knowledge is far more valuable than tools;
  • Clients, service providers, and vendors must, must, must be in a symbiotic relationship to truly succeed.

And if you happen to be looking for some guidance on selecting technology or service providers, reach out; we’re happy to chat. You should also check out our European and North American service providers guides (note that they are specific to the Customer Experience market).

Book of PHIGs – Introduction Draft


A while back I mentioned that I was going to try to write a book. Well, I’ve started it at last. Between losing my job and spending time at the cabin I’ve not really been motivated or focused. I’ve been spending my time looking for work, but also enjoying rural life at my cabin. I have also found that this writing thing is a lot harder than it looks. Anyways, here’s a draft of the introduction to my as yet untitled book of PHIGs. Let me know what you think.

I used to think that people were an organization’s most important resource, but I don’t think that’s the case any longer. You see, some things have changed over the years: 1) Organizations put more time and effort into making sure they have the right information than whether or not they have the right people; 2) Missing key information causes more consternation than when a key person is missing (vacation, prison, dead, etc.); 3) Organizations will happily jettison people they think are no longer required, but hold on to useless information for eternity; 4) Organizations don’t pay the people that manage information nearly enough.

If a person unexpectedly leaves their job the organization copes and moves on. If key information vanishes right before a planning cycle … different story. So why do organizations suck so bad at managing information like the asset it is? I don’t know and I’m not going to try to figure it out. This book is more about helping organizations stop sucking at managing information. As for better pay for information management people … fight your own battles people.

What is Information Governance?

Information governance is all the rules, regulations, legislation, standards, and policies with which we need to comply when we create, share, and use information. Governance is mandated internally and externally. Done correctly (i.e.: holistically), information governance allows organizations to conduct business better and meet all their information related obligations while minimizing risk. Done incorrectly (i.e.: in a silo’d manner), information governance may help organizations met obligations and reduce risk, but business efficiency is sacrificed.

Why do Information Governance?

We can find everything we have, we just don’t know if we have everything we’re supposed to find.

The above was a statement made by a director at my first ever Enterprise Content Management gig in 2006. Back then I don’t think the idea of Information Governance (IG) went far beyond IT security and perhaps Service Level Agreement (SLA) management. Even today, IG is not really thought of in an holistic way, applied to managing all aspects of an organization’s information assets.

In order to make the most effective and efficient use of information, it needs to be properly managed and governed from cradle (creation / capture) to grave (destruction / archiving). Holistic information governance makes organizations info-efficient by providing the means to keep what’s needed and legally dispose of what’s no longer necessary. Holistic information governance results in faster, better decisions, reduced information related risks, reduced ediscovery costs, and reduced information storage costs.

Principles of Holistic Information Governance

The first thing you need to understand as you read the PHIGs is that no distinction is drawn between records and non-records. From a business execution perspective the difference is irrelevant, from an evidentiary perspective it’s minimal since any information you have can be used against you in proceedings.

Whether the information is structured, semi-structured, or unstructured (there`s no such thing) makes no difference. Format and storage location are similarly unimportant to the PHIGs, as are the devices (personal or corporate) used to create or edit the information. The only thing that matters is whether or not the information is needed by the organization to either conduct business or meet obligations.

The PHIGs are really based on understanding how an organization uses information to conduct business. Understanding has to happen at the micro (department, process) level and at the macro level to be truly useful. Not all information is equal for all organizational stakeholders; therefore it cannot be governed the same way across the entire organization.

The PHIGs are not an information approach to information governance; they are a business approach to information governance. The intent of the PHIGs is to help organizations analyze their information assets and apply the right level of governance based on how the information is used / needed to conduct business.

Images Preview

Accountable RiskCoverImage RiskQuadrant PHIGsandPrinciples

BYOD – Run What Ya Brung


This was originally posted on the AIIM Community on 2012-05-30.

In the interests of full disclosure; I use a corporately issued laptop, a self-provisioned smartphone (employer pays service), a self-provisioned tablet, and a personal laptop. My tablet, while being hugely convenient and making my life easier, is not necessary for me to live or work. This post was written using my personal laptop and tablet. I used MS Word and OnCloud to write it. The Word file is stored on Google Drive. Yeah, I believe in BYOD (Bring Your Own Device). I also think the cloud’s a good thing.

One day I’d really like to see what percentage of the overall workforce really needs to bring their own device to work, or would even benefit (need vs want) from doing so. 9-5ers, bank tellers, receptionists (can we still call them that?), gov’t front counter staff, fast food employees, gas station attendants, call centre staff, billing clerks, accounts payable clerks, refuse collection agents, … these and a whole bunch more jobs have no stake in BYOD.

Anyone whose work ties them to a desk, executing fairly structured tasks can get by quite nicely with whatever hardware their employer has plunked down for them (assumes that HW and apps are suitable for the job). Oh, they may want to bring in their tablets or smartphones, load up on apps, and do their work from the sidewalk while having a cigarette. But I really don’t give a rat’s ass and neither should you. Can you honestly tell me that someone who processes invoices is going to benefit from being able to do so on a tablet instead of on a PC? I thought not.

Don’t get me wrong; I am not diminishing the value of the jobs that people do or what they contribute to their organizations and/or society at large. What gets me is this whole consumerization of IT thing that’s going on. The next time you hear “I have such cool gadgets at home, why can’t I have them at work?”, consider this answer; “YOU DON”T BLOODY NEED IT!!!”. You know what they need? They need the right information, proper training & support, a decent organizational culture, paths for self-fulfilment, and recognition that what they do means something.

On the other hand, there are many job functions that can definitely benefit from BYOD. Most of you reading this are probably in one. I’m in one of those roles, but there’s still lots of stuff that I need to do at work that can’t get done on my phone or tablet. When I say that, I mean it’s either just not possible or so cumbersome as to be not worth the effort. Taking meeting notes, writing docs, & emailing are all pretty good on my tablet, a little less so on my phone. Running demos, drawing diagrams, entering timesheets, and doing expenses just can’t be done. That does not mean I will give up my tablet or phone. Hell no! What it means is that unless my job changes I am going to have to be content with running multiple devices to get my job done. Oh, I could just go back to using only my laptop, but that would be silly.

Assuming BYOD is the right path …

Security and privacy are major concerns. What’s going to happen if someone loses their tablet or phone? What’s going to happen if there is a discovery order or FOI request and employee procured devices are in scope? Employees who use their own devices are going to be accessing & storing corporate content as well as personal content on the same device. Some of them are going to let friends and family use those devices for all sorts of stuff. You can’t tell your employees not to because they paid for the devices. What are you gonna do about it?

One of the really nice things about having a tablet or smartphone is that I can be mobile. That means that I don’t need to be connected to my corporate LAN and I can still get the stuff I need to do my work. Not all the stuff, but most of it. It’s not just content that I’m referring to, it’s applications as well. If you’re going to make a move to BYOD it’s on your shoulders to make sure that your team has access to the content, applications, and processes that they need to do the job. If your BYOD is limited to a single platform (e.g.: iOS) you may be lucky because you’ll only need to provision apps that work on a limited set of devices. If, however, you’re going true BYOD, well … you could run into some difficulty. Not only are you going to have to deal with security and privacy issues, you’ll also have to get into the app development business, unless there are already apps available from the usual sources (which I really doubt). I’ve used apps developed by organizations that theoretically work across multiple devices; many have fallen short and the user experience simply sucks. Oh, those apps you’re going to build will have to be integrated to those line of business systems your organization runs to get stuff done. Think of them as additional UI’s and functions that you’ll need to build, maintain, and support.

Another nice thing about BYOD, depending on your perspective, is that lotsa people have their favourite device(s) with them pretty much all the time. That means they can respond to stuff from bed, the beach, while watching TV, while watching the kids at the playground (saw this woman almost get smoked by her kid on a swing while she was occupied with her iPhone – yes, I would have laughed), what/where/whenever. It’s really cool that you can get someone to respond at anytime, but remember that YOU ARE INFRINGING ON THEIR PERSONAL TIME. Granted that it’s likely their fault because they’re using the same device to watch Formula 1 videos on Youtube and respond to RFP’s but you can’t do anything about it because I bought the device so there. Nyah. Nyah, nyah! Sorry. Anyways, there are times that folks need to respond immediately, and BYOD certainly facilitates this. But, there are also time when folks need to chill without worrying about work. You’re the boss so I expect you to set the right tone and provide the right example.

So what’s my point? BYOD is a good thing in the right circumstances. Refuse collection specialists won’t benefit, but knowledge workers and field staff likely will. It’s also a pretty safe bet that if you allow your people to work with tools that they actually like and see as cool, they’ll be a bit happier and maybe even a bit more productive.

BYOD is appropriate based on the role, not the organization. In my job as a consultant it’s perfectly reasonable to allow me to use whatever device I choose. However, the same can’t be said for the people that process invoices, even though they bring as much value to the organization as anyone else. Have at ‘er and consider the following before going all BYOD:

  1. Are devices your major issue? You’re freakin’ lucky if they are. Most orgs have way more serious stuff going on than what can be solved by allowing someone to do their job on a tablet.
  2. Can you secure your stuff properly? My wife doesn’t want to see quarterly sales projections and my boss doesn’t want to see my wife & I [fill in the blank with whatever you want, you dirty devil, you].
  3. Do you want to get into app development? You do? How many platforms & form factors & screen sizes/resolutions do you want to develop for? Oh, and support? And maintain?
  4. Privacy. Closely related to the security thing. Yes, they are different. Go look it up if you don’t believe me.
  5. If you go BYOD, can your users still access everything they need to do their work?
  6. What’s the impact to employee working hours going to be? They’ll have the gadgets with them 24/7, will you expect them to be available/reactive 24/7? Shame on you if you will.

I’m not saying that BYOD is a bad thing, just think about it a bit before you commit.

The House that Jack Built


It starts out really simple; build us a thing that allows some people (all with common objectives / properties) to do some business with us. Easy, right? It is so far. Then things get interesting.

As other business units hear about what’s going on they want in on the action. As the original business unit finds out what is possible they want to extend functionality and include additional stakeholder groups. As executives realize the possibilities they decide they’re going to hang the entire organization’s “social strategy” on this thing that really started as something truly simple.

In some cases projects morph into programs because they become victims of their own success. Normally this is not an issue for either the vendor/SI or the client. However, when the mindset going in is really that of a project, changing the mindset to one of a program is not the easiest thing in the world to do. Typically what happens is that you end up with a bunch of projects being executed, somewhat in parallel, with little real coordination, and a high risk level of failure for all the projects.

Everyone on the planet worth listening to regarding ECM has said that ECM is not a project; it’s a state of being (maybe not everyone said that). The point is that ECM is not a thing; it is a concept of how to work with information in all its glorious forms. When you start implementing ECM you need to approach it as a cumulative exercise, the value of which increases over time and scope (not by throwing more bodies at it).

Start with something small and simple. For example; replace that $80K photo copier / collator / hole puncher behemoth with a document management solution that lets you distribute stuff electronically. Sure you’ll raise the ire of those two old biddies whose entire public sector career for the last umpteen years has been to be the gatekeepers of that big-ass machine. So what? Work with them and turn them into your first user adoption success story. But don’t stop.

Each additional piece of effort needs to build on the success of preceding wins. It doesn’t matter if you’re building upon deployed solutions, lessons learned, change management, …., it only matters that you keep building and moving towards your eventual end goal. Hint: the goal line keeps moving.

One other thing that REALLY matters is to have a plan. Your plan will change. New stuff will come in, some stuff will get thrown out, and priorities will change. This-is-o-kay. It does not mean you develop a plan and then toss it. No, no, no. It means you develop an initial plan and adjust it as situations dictate. It also means that you better have a damn good change management plan in place.

If you do not have a plan and a program mindset, and you’re lucky enough to have a resounding success with your first ECM dalliance, and “they” want more, … if you are very, very lucky the worst that will happen is that you will end up breathless (like I get when I read The House that Jack Built to my daughter) and stressed. However, in all likelihood you will end up holding the bag for an unmitigated disaster. And you will deserve it for not having a plan.

Have a plan.

Have the right mindset.

Build on success.

Be flexible.

Communication Breakdown


http://www.youtube.com/watch?v=bZNkLyQSZVg

Let’s pretend you’re working on a major project that has multiple stakeholder groups, each with agendas, priorities, philosophies, etc. Now let’s also pretend that the project (it’s actually a program) has been envisioned by the CEO or some such all powerful being. Let’s agree that all the stakeholder groups, in order to keep their jobs, have bought into the CEO’s vision of the future. Why, then, is it that no two groups can actually agree on how to move forward? Why, in some cases, does one group actually try to diminish the value of another (it’s not a .net vs Java thing)? It’s because they don’t communicate effectively.

Communication is not about the loudest voice winning. Communication is about articulating your points in a manner that can be understood by your audience. Communication is also about LISTENING. The communication issues on this entirely fictitious project are really due to nothing more than a bunch of alpha dogs peeing on the same spot to mark their turf.

The reality is that they are going to have to find a way to communicate effectively; because this project is not going to be scrapped (someone would lose face – another communications gaffe). Coming in hard with an iron fist in a velvet glove isn’t going to work because there would be a massive backlash from the user community, resulting in really bad things happening to a lot of people.

One of my roles as a consultant is to facilitate communication between stakeholder groups. It’s my job to take everything in and send it back out in a way that offends no one (or offends everyone equally). The toughest thing to accomplish is to convince everyone that all the good ideas are theirs (fosters buy-in and ownership).

My point is this: if your project is being hit by internecine warfare, you need to do something about it. It’s all well and good to have a communication plan that includes posters, coffee mugs, cult-like rallies and all that blather, but if the people that have to define and build the solution can’t come to some sort of agreement the whole thing’s a waste of time.

If you don’t have the resources internally to fill the facilitation and liaison roles, engage a consultant.

The totally fictitious project is an ECM project, but poor communication will kill any type of project.

%d bloggers like this: