Isn’t There A Better Way To Build Government Software?

The awful performance of healthcare.gov has been a staple of the news as well as satire.  This cartoon in the New Yorker this week sums of the frustration of users – http://www.newyorker.com/humor/issuecartoons/2013/11/04/cartoons_20131028#slide=4

I normally don’t like to comment on hot news stories, but this one offers just too much of a teachable moment, especially for public officials who are not technologists, yet who will suffer public criticism when things go bad.

It’s worth noting that this is not the only case of Federal IT system problems.  Before healthcare.gov, the great cost and the long delays of the FBI case management system were in the news.  And, not to be outdone, New York City had a major scandal with its timekeeping system, both for the huge cost (close to $750 million) and the fact that there was a significant amount of that money diverted into the personal pockets of the project staff.

Indeed, costly and disastrous software projects are not just found in the public sector.  It only seems so because the public sector problems are more visible thanks to taxpayer funding, whereas the private sector can keep its mistakes better hidden.

In part, this review of bad projects reminds me of an old line in IT project management.  “Of the three goals of any the project – being within budget, on time, and of good quality – you’re usually only going to get two, but not all three.”  But, for the Affordable Care Act, is none of the three some kind of trifecta?

Part of the problem is that these projects cost way too much money.  That’s often because of rules intended to ensure everything is above board and serves the taxpayers’ interest, but which have the reverse effect.  And so ultimately, the purpose of the procurement rules is, as a well-intentioned government attorney once told me, to follow the rules – not necessarily to get maximum value for the taxpayers.  The big companies that dominate Federal technology projects have learned to master these rules and not necessarily do the best job.  Their reputations are also victims of this focus on process, rather than outcomes.

Another reason for the bloating of these projects is simple ego.  Some top executives have the belief that big important projects should have big budgets. 

Unfortunately, this attitude fails to distinguish the cost of writing the software from deploying it.  The cost of software development does not increase much if the number of users is 100 or 100,000. 

Obviously, the cost of deploying that software will increase in a linear fashion the more people who use it because the deployment may require more servers, more complex database arrangements, etc.

But spending hundreds of millions just to develop the software is usually unjustified.

So what can be done by executives who have to deliver new systems to the public, but feel they are enveloped in a fog of technical jargon so don’t question things until it’s too late.

Consider these alternative ways of handling software projects, none of which is really new, but seem to be not well known to non-technologists in both government and elsewhere:

  • Adopt the agile approach – this means having frequent deliverables and thus taking advantage of learning by users and developers.  It stands in contrast to the traditional practice of big requirements documents and all at once delivery of mammoth amounts of code.
  • Frequent testing, which is also a part of the agile approach.  It’s so important that some people build the test before the software.  After all, proof of the pudding is in the eating and it’s useful to know you’re off course earlier rather than later.
  • Parameterize.  This is something you don’t hear too much about, but it’s something I’ll mention here because some of the healthcare.gov vendors blamed their problems on changes in Federal decision making about whether users need to register first.  I would always tell my development staff this simple rule – if the debate about whether some requirement should be X or Y will take longer to resolve than it takes to program it both ways, then program it both ways by creating a parameter that will switch the system one way or the other.  Don’t let these debates hold up progress of software development.  (By the way, if the debate is that hot, there is good reason to expect the decision to change in the future, which will cost more money in future programming.  So parameterize and let the decision makers argue and change their minds as much as they want.)
  • Gradual scaling – don’t roll out a big new piece of software to the whole world at once.  (Do we really need to say this?)  If the scale of deployment is expected to be a possible problem, why not minimize the problem by taking it in several steps and, again, learning what needs to be improved.  Even experienced Broadway veterans try out the show on the road first.
  • Simplify deployments by using a scalable infrastructure.  There’s much discussion about “the cloud”, which is really just a good marketing term for the vast scale of computing resources available over the Internet.  Use it instead of trying to reinvent this vast scale, which is impossible for any organization, no matter big.  Many Internet businesses you’ve dealt with use these resources to handle peak demand or initial rollouts. 

I could go on, but these guidelines are normally enough to keep your next big systems project out of the headlines.

© 2013 Norman Jacknis

[http://njacknis.tumblr.com/post/65612237318/isnt-there-a-better-way-to-build-government-software]

Can The CIO And The CMO Work Together?

Tuesday of this week, I participated in the annual CIO Executive Leadership Summit held in Greenwich, CT. This year’s focus was “Game-Changing Leadership Strategies & Business Models for Market Advantage.”  (Note: I’m Chairman Emeritus of the regional chapter of SIM, which sponsors the meeting.)

I led a session on the relationship between the Chief Information Officer (CIO) and the Chief Marketing Officer (CMO).  The two guest panelists were the successful team at Ogilvy and Mather Worldwide of Yuri Aguiar, Senior Partner & CIO, and Lauren Crampsie, Worldwide Chief Marketing Officer.

For many in the audience – mostly technology leaders in their organizations – there was a bit of unease about the growing role of the CMO in technology decisions.

Part of that unease is driven by headlines such as these:

 

While trend varies and every organization has a different mix of reasons for giving the CMO this new role, the common causes are:

  • CIOs who focus just on the back-office operations – merely “keeping the trains running on time” – and shy away from playing a more strategic executive role.
  • CIOs who spend most of their money on maintenance and thus fail to deliver new technology solutions that are needed by others in the company.
  • CIOs who are less familiar with the newer technologies, such as social media, data analytics, mobile software design, marketing technology, etc., thus forcing the CMOs to look elsewhere for what they need.

 

So the tensions between CIOs and CMOs have revolved around who gets to spend the money and who gets to control and enforce technology standards.

With this background, it was a pleasure to hear a CIO and CMO who have learned to team with each other. Their experience has lessons for many other CIOs and CMOs.

They start out as equals, both reporting to the CEO, yet they have clearly developed a mutual respect and a relationship built on intense communications – and a willingness to see things from the other person’s viewpoint. 

Then together, these two present capital budget requests for new technologies that will help Ogilvy to grow its business.

Lauren pointed out the various ways that Yuri had taught her about technology.  But the learning went in the other direction too.  With the increased importance of user experience in a world dominated by the consumerization of technology, CIOs can learn from their colleagues who specialize in creating positive user experiences – the CMOs. 

Together the relationship can be not a source of tension, but of mutual advancement for both the CIO and CMO – and, of course, for the company as a whole.

© 2013 Norman Jacknis

[http://njacknis.tumblr.com/post/64954921798/can-the-cio-and-the-cmo-work-together]

Does Your Website Talk To People The Way They Think?

(This blog post is a broadening of the recent post on gamification.)

Almost all governments have some kind of website.  Aside from when these sites just don’t work because of bad links or insufficient computer resources to meet demand, they mostly feel like an electronic version of old style government whose employees were often accused of treating other people as “just a number”. These websites talk at people in a kind of monotone, not having a conversation or interaction.

Yet, most of us realize that people have different interests, personalities, cognitive styles and ways of interacting with others.  Thus, to be most effective,  a website should change to reflect who is interacting with it.  

Unfortunately, the only variability that exists in most websites – public or private sector – is usually based on purchasing patterns, such as the different web pages and pricing that appear on Amazon’s website, depending upon your past consumer behavior or perhaps by providing languages other than English.

Glen Urban, who is a marketing professor at MIT’s Sloan School of Management, calls this the “empathetic Web”.  (See the article, “Morph the Web To Build Empathy, Trust and Sales” by him and his colleagues at http://sloanreview.mit.edu/article/morph-the-web-to-build-empathy-trust-and-sales/)

As their summary states:

We’ve long been able to personalize what information the Internet tells us — but now comes “Web site morphing,” and an Internet that personalizes how we like to be told. For companies, it means that communicating — and selling — will never be the same.

The authors distinguish between people on the basis of two pairs of cognitive preferences (visual vs. verbal and analytic vs. holistic).  At the very least, a website should reflect these cognitive differences.  

But it is also worth thinking about other differences. For example, many people prefer a conversational style to the completion of a long form.  The widespread use of smart phones to access the Internet has increased the need to have a more conversational style on the web since the screen is too small to do otherwise.  (That’s why games are a useful model to consider.)  

As the authors note, this is not just a matter of making a website more convenient, but also is essential in building trust, which helps a private company increase sales – and is an absolute requirement for any public official.

© 2013 Norman Jacknis

[http://njacknis.tumblr.com/post/64296674666/does-your-website-talk-to-people-the-way-they-think]

Games As The New Model For Business Software?

For most of the last couple of decades, business software has been pretty much the same – a series of forms that essentially automated the company procedure manuals, which preceded the days of computers.   Yes, with Windows and the Mac, those forms became prettier, but they’re usually still some kind of form.  And, aside from down lists of things like the list of countries or states, there isn’t much intelligence behind those forms.

It’s time to change that approach and learn from enormously popular digital games.  Learn what exactly?

For too many people, games are all about vicarious shoot-em-up scenes or, at best, fantasy adventures.   Business software designers could have some fun applying those techniques – imagine a “killer sales” app :-). But there’s a deeper level of interaction with technology that game designers have discovered.  

Game software does three things well.   First it motivates people to continue to play the game.  Second, it’s conversational, offering frequent bite-sized interactions with users.  Third, it adjusts to the user’s behavior, indeed learns from what the user does – while the user is also learning.

Compare that to typical business software.  The motivation to use it is mostly external – your paycheck or your desire to get something from an unfeeling bureaucracy.  The form is big and long, like a lecture or sermon, not a conversation.  And the course of the interaction varies little from person to person; there’s little learning on either side of the interaction.

Is it any wonder that game players feel so much more engaged than users of business software?

But the three aspects of good game software can easily be adapted to the business world and anyone undertaking a major development of business software today should learn from those techniques.

Three additional observations about this:

  • Motivation is not just about how many points you can rack up compared to others.  The best game designers provide support for the range of human motivations in order to help the many different kinds of players.  So, for some, the motivation is very much about winning the competition.  For others, social approval in the form of likes and other recognition is more important.  For others, getting it 100% right is the goal.  
  • More generally, it’s important to realize that there is a sophisticated use of this tool and also a simplistic use.  Indeed, not every game that’s sold is a good example of the value of gamification.
  • The funny thing is that many of the people I meet who have some control over the development of software in their organizations are avid game players.  Yet they ignore the lessons of their personal life when planning what will happen in the business.  Does that make sense?

© 2013 Norman Jacknis

[http://njacknis.tumblr.com/post/62900227376/games-as-the-new-model-for-business-software]