Why not? Is it because employees are really lumbering oafs, resistant to using a computer?  Many organizations portray their users to be this way; particularly in government, the employees are pegged as obstinate elderly, practically incapable of sending an email.   But in my experience, this portrayal is false – I have had devoted users upwards of 70 years old, burning with zeal to get something new and innovative.  There is one common theme, however, that occurs in implementations and may have something to do with employee reluctance, and that is lack of communication.

I am not talking about “information,” that is, sending out an en-masse email saying “Change is Coming!” But real, honest, interactive communication between individuals. If an organization merely sends an email, and then six months announces mandatory training, is that communication?  Well, if it were a marriage, I think it’d be headed for the court room.

Large technology initiatives  are rarely introduced for their own sake.  Most often, they are connected to a need to improve business processes or management of the organization.  Unfortunately, achieving those benefits is not purely technological in nature, but rather is dependent on human beings.  Without the cooperation of the humans, you simply don’t accrue the benefits. You may get some benefit, like you would if you were upgrading a server, or replacing a sticky keyboard – but you don’t get real change, the awe inspiring, wow-this-is-so-cool change, that an organization needs to rejuvenate itself and its business process.

So how can the organization communicate the change, instead of just sharing information about it? There are a couple of key points.

1. Be very clear about what the change IS.  Don’t skirt the issue, do not lie, and do not pretend you don’t know. People, especially your own employees, are not fools and they can tell when you’re trying to fool them, even via email.

2. Establish what the goals and benefits are.  This should be as long a list as possible, and it should be detailed. It should not just be in consultancy speak, but in terms employees can understand.

3. Make it a discussion. Have a town hall. Have massive conference calls that are an open forum. Embrace questions, and meet dissenters head on.  If this change is truly necessary, you’ll be able to respond to their concerns and allay their fears – if you’re just wasting money though… see point 1.

4.  Have a plan, and ask feedback on it.  Too many times, organizations have an implementation plan that is just, well, crazy. And they send it out at the last minute, employees are dumbfounded then indignant, and no one is happy. Incorporating employees into the process will not only engage them, but it will also result in a better plan.

5. Do what’s right for your employees and your organization.  At the end of the day, it’s really NOT about cost. Because a failed implementation is going to cost you way more than dollars, it will cost you goodwill, employees, and your dignity.  If you don’t feel an approach is right, if you don’t like a template, say so.  Demand it be done differently.

6. Embrace Change. Sometimes the very folks who insist on change don’t see how resistant they truly are.  It’s possible, even likely, that some of the ways your organization does business are just…wrong. And bad. And inefficient.  Try to remember you’re spending millions of dollars to change, truly change, and not just recreate a newer version of the same old system.

I’m a huge fan of Komodo Media’s Social Media Network Icon set. The icons are simple and elegant and they’ve become quite popular on the internet. Recently we were building an application here an needed an icon for Google Buzz and decided to build one to fit the Komodo Media icons, as the set has not been updated with one yet.

Matching the Komodo Media icons, the icon is in 32px and 16px size. Credit to the aesthetic goes to those guys entirely. I hope they’ll update their icon set soon as I’m sure it will be a little more polished that what we quickly put together.

I’ve provided the icons here. Feel free to use them or modify them as you wish.

Download

Cross-site engagement is a particular interest of ours here at PreferenceSet. More traffic is moving off of traditional websites and onto social networks where it cannot be tracked or measured using traditional tools. Yet understanding the relationship between different entities and content is increasingly necessary to gather meaningful insight into the way an organization or company makes use of its own online presence. Despite this trend, the current crop of tools leave users mostly in the dark.

Largely due to their use on Twitter, link shorteners quickly became the tool of choice for measuring a link’s impact and reach when shared on social networks. By revealing to users how many times a link has been clicked, link shorteners with analytic features at least give users a sense of how effective their Tweets are. Bit.ly has become the defacto standard, providing additional detail on readers’ location and device.

Yesterday, Google and Facebook announced their own link shorteners, goo.gl and fb.me, respectively. While neither Facebook nor Google have yet to announced any analytics feature, there is already some speculation that Facebook will offer this feature. Google already has one of the best analytics tools available, and it would be a logical next step for them to integrate the products.

Bit.ly also announced an addition to their service, Bit.ly Pro. The new service provides deeper analytics and some custom branding for select customers.

But even with these additional features, all of these services only return raw data. Data such as hit counts or referrer information is without actionable insight, and as a result, largely useless.

Avinash Kaushik writes on his blog about the limitations of these analytics tools.

Most twitter analytics tools just do data puking. They find numbers that can be computed and then proceed to puke at you as many as they can find, with wonton disregard of value being provided or outcomes being measured…. You must pause and think: So what is this saying? What action can I take?

There are some new services being developed attempting to answer this question. Avinash cites several of them, such as Klout. These services focus on analyzing users on Twitter, however, not the links themselves. We at PreferenceSet are working on our own solution to this problem, specific to online fundraising over social networks.

Larger incumbents, such as Facebook and Google may be slower to experiment with new metric types, as a result of their large user base and existing conventions. The absence of any details on even basic analytics from either Google or Facebook, on top of their very late entry into the market, reinforces this. In general the industry will continue to evolve with more and more advanced analytics analysis. This may give newer market entrants an opportunity to outflank the larger players in a very important part of the emerging cross-site social structure implied by social networking tools.

The original mindset behind the development of Enterprise HRIS was to develop a “Custom Off the Shelf” product that could be purchased and implemented, then changed minimally in order to accomodate customer requirements.  They were touted as ways to cut both costs and timeline – a massive replacement of an entire HR system could be done, hypothetically, in as little as 6 months.  There have been great successes in the private sector in implementing these systems – efficiency gains, cost savings, standardized business processes leading to improved productivity and the like.

The federal government, always eager to follow the private sector, began to examine the idea of standardization in the realm of technology and along with that, the COTS products.  But, unlike the private sector, the feds implementations have not gone so well. 

This is for several reasons, which I will tell with harsh truths against both sides.  Firstly, the providers of the service often see the government as a proverbial cash cow — slow and ignorant, with billions of dollars; what’s not to love about doing business with the feds?  They milk the government for all it is worth, often inserting services that are not necessary or that could be done by the government itself (like documentation, or revised business process maps).  Government contracting officers, because they understand contracts and not IT, assume the price is fairly quoted. This is why it is not unusual for an implementation to run over $100 million, with many option years.  I will go ahead and throw it out there – if there is a great team of smart motivated people, it should NEVER, EVER, EVER take you more than two years to implement anything. Unless…

Secondly, there are contingencies that affect the timeline.  Most notably, the cash cow itself.  That is, the lumbering stumbling often incoherent government cash cow, that has so much redundancy, paperwork, and processing time that it’s well nigh impossible to do anything with speed or certainty.  Also the cash cow has a problem making decisions – no one wants to make one – and if they do, they’d better make that decision in absolute compliance with about a million federal statutes.  But they’ll have to read those first. And then they’ll have to discuss. And then they may want to consult someone higher up. But that person’s calendar is full and they won’t have time to sit down and chat about making a decision until next week. And then after that chat, there has to be some additional research. And maybe they want to ask that guy in Finance his opinion too. But he retired already. Oh. So then… you get the point. The cash cow is maddeningly slow, in addition to being governed by rules that are open to some level of interpretation which no one wants to take responsibility for interpreting.  Work grinds to a halt, but people are still being paid.  So these constant delays affect timelines, budgets, and work schedules – not to mention morale, which often starts high and ends with everyone hating each other intensely.  And the federal statutes create significant constraints for the project; who can do what tasks and when, what approvals have to be given, and what exact processes must be followed to achieve anything.  Most of the time, these processes and tasks create days and weeks (if not months) of additional wait time, in which valuable resources are tied up in procedure matters.  Sometimes, missteps in the project lead to severe repercussions and financial impacts even though there was no intention of violating the statutes – leading to further costs, further delays, and a generally chaotic and frustrated environment.

Thirdly, federal implementations fail for a reason far more important, and the real meat of today’s post.  While all this effort is going on, and RFPs are being written, the government never asks the fundamental question of whether off the shelf products are truly capable of the flexibility necessary to accomodate federal requirements.  In one case, there were 29 steps in approving the posting of one person to one job.  Each step based on criteria changes depending on the posting, the timeframe, the organization level, and the supervisor who requested the position in the first place.   Sometimes the criteria changes based on personal preference, or inconveniences like illness.  There is no COTS workflow engine in the world that can handle that kind of variability. And that’s just one tiny microcosm of the federal requirements in the COTS universe — Providers attempting to do what cannot be done, and charging the government for the attempt.

So.  If you have an organization with hundreds of customizations, some of which may never work well via COTS software, and each customization costs thousands of dollars… why not revisit the question of custom applications?   Most federal government applications were originally custom jobs – developed and maintained in house.  Each one was tailored, built from scratch, and exactly fit the organization because it was driven solely by the structure, requirements, and rules that drove the business. When add ons or changes were needed, they were made, and sometimes the code got …well…ugly. But they WORKED.  The speed of technology meant that all too soon, the developers and technical staff supporting the application skills were outdated, and so was the system, but it still worked. Which is why today there are payroll systems (still functioning) that were constructed in 1978.

There is a lot of value in updating and standardizing these systems, because maintaining them is a nightmare and finding people to do so is getting harder each year (no one in today’s universities particular wants to learn COBOL, for example).  So the federal government, blames the maintenance hardship on the application itself, and decides to move from a customized, completely integrated system that exactly matches their business needs to COTS products that

1. don’t match their business needs
2. require millions of dollars to design, build and test
3. require millions of dollars in training costs for users
4. require millions of dollars to CUSTOMIZE so that they can even be used

Which begs the question… if you’re going to pay millions to customize a system… why not pay millions to get a custom system, and save yourselves the money and time on all the aches and pains associated with business process change and training?  As a former SAP consultant, I must admit I love packaged solutions. But I have seen the epic failures that occur when highly customized organizations, with a deeply engrained cultural and specialized business processes, attempt to implement an off the shelf product. It is painful, it is long lasting, and honestly… I’ve never seen one that worked well in the end.  Whereas, on the custom applications I have been part of, the clients are always ecstatic to get something beautiful that they themselves helped design that works perfectly for their organization.

Which brings up another point about COTS products vs. custom applications – specifically, the web applications.  The COTS GUIs are ”vanilla” (or as I call it ”waaah-nilla” and boring.  They all look exactly the same when rendered on the web, because they are actually the same.  But custom web applications are glorious. They are streamlined and sexy, they are memorable, they suggest that the organization is efficient and modern and outstanding – even when it may not be.  A well designed web front end can entice applicants, can provoke readers, can inspire and engage users.  In contrast,  there’s the stodgy COTS front end, exciting as stale white bread, that looks the same for every organization except for their logo floating in the header.

Otherwise, the new technologies of the world for building custom applications aren’t unwieldy, don’t take years to implement, and they have really neat features.  For example, Ajax (which isn’t really “new” but is much newer than the technologies which construct the COTS products).  Ajax can prefill text boxes and drop downs, it can make simple web pages ‘come alive’ for the user.  It dazzles them, so to speak, and so they feel their organization is updated and have more confidence in using it. A fully performing web application can be built in weeks, not months, with a small team (no more billing for 40-60 consultants, taking up your office space). Thus a custom application can be built for much, much less. 

With a custom application, the real investment dollars would go into making sure that IT staff’s skills remain up to date and that they can maintain and innovate. Organizations can spend millions on their own people, instead of spending millions on a system that will take years, may never work, and that employees will complain about anyway.

OPM’s recommendations regarding the HRIS implementations are interesting in that they recommend further consolidation to HR Line of Business Shared Service Centers (HR LOB SSC) - in other words, not only are agencies recommended to shove themselves into an expensive standardized system, they are also recommended to accept support from outsourced employees who are without business process or agency specific knowledge. I’m not sure exactly why anyone would ever want to do this, even if the idea could be proven to have specific financial benefits… (which, for the record, on paper it is shown to be more efficient and less costly. In real life I am not convinced that this is the case). 

I will take a specific example of a custom element of an HRIS solution – e-recruitment.  A custom application that I know of has the following statistics:

• Supports about 30,000 users total, with various clients worldwide
• Is highly customized per client but very easy to customize, on the spot
• Can be designed and built in weeks by a team of 5 people
• Cost: 100-150k for system, 150-160k per year in licensing fees

On the other hand, a HRIS e-recruitment system (I won’t name the brand) took:

• 4.5 MONTHS for design (9 individuals, with travel, 40 hours per week)
• Had not even been built and no money was charged for build at the end of that timeframe, but if build were done it would take another 4 months
• Was incredibly difficult to customize and in some cases the customizations would likely not work as desired by the client
• Cost estimate for design, build, test and deployment quoted to customers?  2.5 MILLION.

Numbers like that don’t lie.  In this case, the custom application is a better choice.  The hilarious part is that in terms of appearance – the look and feel – the two applications are incredibly similar, with the custom software being slightly more attractive.  There is almost identical functionality offered.  The difference is that one system is a boxed product, and therefore having an enhancement is a ’special’ ‘additional cost’ item. For the other product, there is the expectation that there will be lots of special items – therefore there is no additional cost.  Both Providers are reputable and filled with intelligent people – so the cost savings doesn’t mean any diminishing in quality.  In fact, it is a better fitting product in less time.   This is one select case, but I think the evidence is compelling – the federal government should really invest some time (and thought) into the future role of custom applications in their organizations.

But there was really no need to scale most of the application.  The admin interface would not be used heavily, and usage would likely grow predictably.  The only element on the application that might grow quickly and demanded high scalability was the actual URL redirection – that is, turning our shortened URLs into long URLs.

So we decided to separate our this piece of the application and build a separate web service.  URLs are created and served from a very lightweight Sinta application which is under 100 lines of code.  This application is hosted on a cloud based web service that can be instantly scaled depending on usage.  The Rails application queries the Sinatra application to create URLs and to read URL statistics.  This is done via RESTful web service.

An additional benefit of this method is we get a working API for integration with other services as well.  We’ve already implemented this on Contribune, a social news site.  Posting a story automatically creates a Giv.to URL for each posting.