{"id":1198,"date":"2006-08-29T10:35:21","date_gmt":"2006-08-29T17:35:21","guid":{"rendered":"http:\/\/gillin.com\/blog\/?p=1198"},"modified":"2009-10-25T14:39:02","modified_gmt":"2009-10-25T21:39:02","slug":"reshape-it-via-new-models-like-software-as-a-service","status":"publish","type":"post","link":"https:\/\/gillin.com\/blog\/2006\/08\/reshape-it-via-new-models-like-software-as-a-service\/","title":{"rendered":"Reshape IT Via New Models Like Software-as-a-Service"},"content":{"rendered":"<p><em>From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission.<\/em><\/p>\n<p>IT should embrace SaaS enthusiastically, as it can save a whole lot of headaches building prototypes that users reject.<\/p>\n<p>Anyone who\u2019s been in IT for more than a few years knows the dirty little secret of the profession: many IT projects (in fact, <em>most <\/em>of them, in my experience) fail. That\u2019s been the story as long as I can remember. Why, after so many years, are we still so frustrated by failure?<\/p>\n<p>There are three main reasons I\u2019ve observed<ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">:<\/ins><del datetime=\"2006-08-30T00:57\" cite=\"mailto:%20\"> <\/del><\/p>\n<ul>\n<li>In too many companies, IT is an island that is      organizationally and even physically removed from the business it serves.<\/li>\n<li>Too many users suffer from throw-it-over-the-wall      syndrome, which leads to projects that fail to match the needs that exist      at delivery.<\/li>\n<li>Turnover and organizational change undermine too many      projects, making them irrelevant by the time they\u2019re delivered.<\/li>\n<\/ul>\n<p>Let\u2019s look at how you can approach each problem.<\/p>\n<p><strong>IT is an island<\/strong> \u2013 IT people themselves are often too willing to accept a balkanized structure that isolates them from the business. There is a bad idea for so many reasons, but the insular, often introverted nature of technical professionals lets them rationalize this situation. They don\u2019t communicate well with the business side, so they settle for separation.<\/p>\n<p>You can\u2019t change people\u2019s personalities<ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">,<\/ins> and you can\u2019t force people to work in situations that make them uncomfortable. But you can make sure that IT project leaders have the capacity to work productively with business end-users. That means not talking down or clamming up, but rather showing tolerance, acceptance<ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">,<\/ins> and humor. Your project managers are ambassadors. You need to select people with strong diplomatic skills.<\/p>\n<p>With the right ambassadors in place, you can afford to set the rest of your IT organization apart to some degree. The project leaders should serve as both diplomat and translator, buffering the relationship with the business side while speaking both languages fluently.<\/p>\n<p><strong>Customer accountability \u2013 <\/strong>The throw-it-over-the-wall problem begins with the user sponsor<ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">,<\/ins> and is perpetuated by gullible IT organizations. Often, the perpetrator is a senior business-side executive, a \u201cbig idea\u201d type who conceives of a grand vision and then hands off half-baked requirements to an IT group that often doesn\u2019t fully understand what it\u2019s supposed to deliver. Six months later, IT comes back with a prototype, by which time either the requirements have changed, the user has moved on<ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">,<\/ins> or he or she has forgotten about the whole thing.<\/p>\n<p>Let\u2019s face it: no one likes creating spec documents or sitting through progress report meetings. They\u2019re tedious and boring. But they are absolutely essential if a project is to remain on track. The CIO needs to be the bad guy here. He or she must insist upon project management discipline and review meetings at least once a quarter to make sure the project is still relevant. The CIO needs the backing of a top company executive in taking this approach. Otherwise, IT will be buffeted by constant changes in the business environment. Which leads to the final problem.<\/p>\n<p><strong>Organizational change <\/strong>\u2013 How many managers can you name in your organization who have been in the same job for more than two years? In many companies today, half the leadership has taken on a new assignment in that time. So why do we still start IT projects that have deliverables scheduled a year or more down the road?<\/p>\n<p>The business environment is too changeable these days to permit that kind of scheduling. Projects must be componentized, with deliverables scheduled every few months. If you can\u2019t decompose a project like that these days, it probably isn\u2019t a very good idea in the first place.<\/p>\n<p>Technology may be riding to the rescue. The rise of the so-called \u201csoftware as a service\u201d (SaaS) business \u2013 epitomized by Salesforce.com <ins datetime=\"2006-08-30T00:57\" cite=\"mailto:Comparison\">\u2013<\/ins><del datetime=\"2006-08-30T00:57\" cite=\"mailto:%20\">&#8211;<\/del> is enabling users to try applications before they commit to them. SaaS delivers applications over the Internet, and users can often achieve results in a matter of days. In some cases, users may find that a SaaS solution is all they need. But even if they don\u2019t, SaaS is a heckuva way to prototype different approaches and solutions. A lot of IT organizations are approaching SaaS warily, worried that they will lose control. Instead, they should be embracing the model enthusiastically. It can save them a whole lot of headaches building prototypes that users reject.<\/p>\n<p><strong><em><br \/>\n<\/em><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission. IT should embrace SaaS enthusiastically, as it can save a whole lot of headaches building prototypes that users reject. Anyone who\u2019s been in IT for &hellip; <a href=\"https:\/\/gillin.com\/blog\/2006\/08\/reshape-it-via-new-models-like-software-as-a-service\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[143],"tags":[162,163,98,170],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pTy95-jk","_links":{"self":[{"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/posts\/1198"}],"collection":[{"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/comments?post=1198"}],"version-history":[{"count":7,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/posts\/1198\/revisions"}],"predecessor-version":[{"id":1732,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/posts\/1198\/revisions\/1732"}],"wp:attachment":[{"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/media?parent=1198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/categories?post=1198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gillin.com\/blog\/wp-json\/wp\/v2\/tags?post=1198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}