archive-com.com » COM » P » PETERKRETZMAN.COM

Total: 193

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Get multiple arrows for that quiver: selective and competitive outsourcing - CTO/CIO Perspectives
    to allow for external entities delivering changes into current production environments My position here is that it s a key part of your job to change that situation to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively Let me focus in this post on the important role that outside help can and should play in your development portfolio Specifically I recommend that you find several I suggest three to five vendors who can take on well defined development projects and deliver them relatively independently of your current core development staff Pay no attention to the natural sales technique that each vendor will use e g we want to be your sole provider because that s principally in their interest not yours Each vendor will have different skill sets different availability even slightly different approaches Not to mention pricing when a provider knows that they won t win every job by definition that keeps everyone on their toes in terms of both maximizing quality and minimizing the cost of delivery Here are a few key aspects to strive for when embarking on this sort of selective outsourcing Make sure the vendor can and will work within the software delivery approaches that you ve carefully established You ll find that a lot of independent vendors actually aren t accustomed to the idea of formal handoffs and loose coupling Educate them and move forward with the ones who get it Work closely with your company s legal department to understand clearly what data you can hand off to external entities and what protection mechanisms need to be in place Design or redesign all of your development processes so that it will be relatively painless to keep your vendors working with current builds data and necessary interfaces into your key systems Otherwise you ll face a nightmare of integration testing once they deliver Don t tolerate lack of collaboration i e with other vendors or with your internal staff which happens more than you probably suspect or information hiding Everyone needs to be part of the team with all behavior above board Make sure everyone the vendors and your in house staff understands that delivery is defined as full delivery not just working code That includes acceptance testing user and operations both knowledge transfer agreed upon documentation test scripts everything Do recognize that functions down the road QA operations will be impacted resource and schedule wise almost as much by an outsourced project as by an in sourced one Nothing comes for free and this is often forgotten Make sure that your internal team understands the strategy here You don t want to have jealousies or insecurities pop up simply because not all projects are being done internally Most of all the key lesson I ve learned from working with outside vendors has to be the notion of putting multiple arrows into the quiver in other words actively seeking out and using

    Original URL path: http://www.peterkretzman.com/2009/05/06/get-multiple-arrows-for-that-quiver-selective-and-competitive-outsourcing/ (2016-04-28)
    Open archived version from archive


  • Offshore development: aim for it, even if you never go there - CTO/CIO Perspectives
    ve seen a lot of internal development teams provide little more than just the last item and what s worse those shops typically have the developers install it If you focus your development team on what should be a best practice anyway for internal projects thinking about future operability documented installation steps packaging of deliverables verification testing etc and expect your operations folks to insist on formal handoffs you re paving the way for future handoffs to come potentially from points outside your department You ve then federated and expanded your development factory while keeping control over what matters maintaining a robust production environment You ve set standards and expectations in place that you can communicate to outside vendors Voilà you ve expanded the bag well at least theoretically So here s my point creating crisp handoffs per the skeleton outline above is something you absolutely must do if you ever hope to outsource But you ll find that you ll reap significant internal benefits from doing it anyway Plan to do what s necessary to lay the groundwork for outsourcing even if you never actually go down that path Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Process Vendor management Comments Val Jelinic says August 19 2009 at 7 13 am Interesting comments Peter however I still think the main point is being overlooked here Today especially in this time of financial crisis and economic recession outsourcing portions of business requirements to offshore companies is becoming more more the norm Greater investment to return ratio customised teams to perform the work without the expensive permanent staffing management and a quality control of the product service that is greatly improving this fast growing alternative is showing that what was once considered to be high risk and hard to control is fast becoming and alternative that cannot be ignored Small flexible teams operating under controlled supervision by experienced managers with cultural and technological experience is proving to be a valuable commodity Large software houses are cumbersome with in flexible internal processes and fixed overheads that must make high margin to cover costs hence their products services prices are greatly inflated One such Swiss based company recently quoted 700 man hours over 6months for development work of a web based application to the tune of CHF750 000 Something which an offshore software development company would be able to do for 1 10 of the price dependant on location and the specifications of course and possibly a shorter delivery time These savings are hard to ignore when the financial pinch is being felt everwhere For SME s and Start Ups everywhere the question is not whether or not to consider an offshore software development as an alternative to a large established software house but which alternative to choose from The market is lush with choices for an alternative and many savings to be had Worthy of further investigation no Val

    Original URL path: http://www.peterkretzman.com/2008/02/19/offshore-development-aim-for-it-even-if-you-never-go-there/ (2016-04-28)
    Open archived version from archive

  • Offshore software development: the reasons why not - CTO/CIO Perspectives
    saying that the focus when offshoring tends to be just on the delivery of working code so entropy pushes things in that direction It s also well known that the effort of reading maintaining and updating a set of code far exceeds the cost of initially building it Even aside from those concerns of quality offshoring often comes with a set of executive blinders about the other costs of taking that approach I watched one company I worked for enthusiastically and with great fanfare outsource its development to India because of the lower cost Next thing I knew we were shipping them expensive servers for development and test buying software licenses to support their work procuring bandwidth back to the US juggling source code control and seeing members of our in house staff take lengthy trips over there to monitor what was going on I won t even go into the numerous other logistics problems that arose Did anyone add up those costs Of course not Another general motto of mine Take all the costs into account Fallacious assumption 3 Staff continuity isn t a major concern This fallacy basically reflects the executive viewpoint that code development can be black boxed what matters is just getting the code which is the commodity that counts Code need to be fixed later That s simply another task to be allocated to the appropriate resource Offsetting the fallacy over the long term a cohesive team i e one with some measure of continuity will be vastly more productive than a fragmented team constant staff changes and upheaval eventually tend to show up in the balance sheet because things end up costing more The act of reading and maintaining code from scratch especially poor code is a less than trivial undertaking and always takes longer than having it handled by a team that has some measure of staff continuity By its nature offshore staffing is essentially out of your sight and it s very hard to gauge the effects of turnover And of course you re just focused on getting working code out of them anyway whether it s the same team this week as last is relatively of little concern I ve seen offshore teams have significantly greater turnover than domestic teams even during the Internet crazy years in America In summary initial coding is easy Requirements gathering and design are hard Communication is hard Maintenance is hard Staff continuity is hard So offshoring is a seductive thing it makes the easy part easier and cheaper but at the cost of making the hard parts much harder and riskier As Martin Fowler pointed out offshore development is very fashionable but it s still too early to really understand its true strengths and pitfalls Certainly anyone doing it because they think they ll get cost savings similar to the rate differences is seriously deluding themselves In my next post I plan to seemingly reverse myself somewhat and explain why you should nonetheless mold your

    Original URL path: http://www.peterkretzman.com/2008/02/14/offshore-development-the-reasons-why-not/ (2016-04-28)
    Open archived version from archive

  • The pitfalls of the implicit "buy" bias for IT systems and services - CTO/CIO Perspectives
    up your hands and absolving the company of any responsibility or involvement Make sure you or someone else at the company can be a tough and active negotiator both on price and on terms and conditions Mistakes made on either one can affect the bottom line for years In the case of one off projects as opposed to outsourcing ongoing services watch out for inadvertently creating a total ongoing interminable dependency on the entity to which you ve outsourced Keep some employee skin i e familiarity in the game It s really rare for a system or service to be truly stand alone in any company Assume that at least 30 of the total schedule will require intense participation from your internal resources carefully defining integration points clarifying requirements and ensuring knowledge transfer Try not to outsource all the most enticing projects for the sake of your internal team s interest pride and eventual continuity In fact be sure to make it clear to your team when you do outsource something why you picked that specific area or project Think about the state of your operational acceptance process If you haven t had a robust process for migrating new applications or builds into production that process needs to be crystallized before outsourcing anything is remotely viable You do not want to get into the situation of having the outsourced entity have to ship an engineer to your doorstep to install its product into your production environment If you can t succinctly state the specific hand off requirements to your vendor up front then trouble is down the road On outsourced development projects unless it truly is a stand alone project a rarity think about your integration test environments and process Where will the acceptance gates be You re not really contemplating just taking their word that everything works and won t impact your other applications are you It should be clear from the above that outsourcing entails a ton of work on your end work which can come close to balancing out the actual work you re supposedly outsourcing But here s the most important point you should be doing that preparation work anyway even for internal projects You should have acceptance gates clear hand offs careful integration testing etc If you organize and plan for that you have the ability to scale your team up internally as well as externally You can then do a kind of internal outsourcing on a project by project basis since hand offs are crisp and safety nets are in place That approach ultimately becomes the only possible meaningful answer to the recurring dilemma I ve written about before how do you stuff 8 pounds of manure into a five pound bag Bottom line if you re robust enough already in your organization about these best practice kinds of hand offs you re quite ready to shade the buy vs build equation a bit more towards the buy side If you re not you

    Original URL path: http://www.peterkretzman.com/2008/02/05/the-pitfalls-of-the-implicit-buy-bias-for-it-services/ (2016-04-28)
    Open archived version from archive

  • Buy vs. build, and why Scott McNealy thinks the CIO doesn't need a staff - CTO/CIO Perspectives
    outsourced even to his senior lieutenants It can get dangerously easy as a senior executive to reach that level of detachment It s something I advise against But that s a different topic altogether In any case my main takeaway points from the anecdote itself reflect exactly those two twin contradictory poles representing simultaneous truths The anecdote has stuck in my mind and gotten repeated to my staffs all these years precisely because both aspects of it are true Upper management can sadly often underestimate and or undervalue the amount of work and complexity entailed in both keeping the lights on and delivering new features and functions to the business IT systems and services are now actually quite often not much more than commodity items which can achieve scales of economy and efficiency through appropriate outsourcing to firms that are expert in each particular area So yes one can and frequently does farm out chunks of the existing IT work and rely on an external party to provide the associated service systems development systems operation financial systems e mail colocation facilities tech support help desk even project management For example building a custom operations center for a web site today when quality colocation facilities are readily available is fairly foolhardy and almost always unnecessary But think about it It s also the case that managing a passel of external vendors is not a walk in the park Strong horses need strong riders And in what shouldn t be a surprise companies that are created to exploit economies of scale will often push to achieve well economies of scale this means that existing customers can often be neglected unless those customers manage the relationship closely and actively All of that active management takes staff and time and knowledge Equally there are core competencies integration requirements and business specific needs less than people think more more than management would typically like that can effectively rule out the use of off the shelf commodity approaches It s all in the balance of course I ll talk further in subsequent posts about possible approaches toward striking a balance Lagniappe Notable quotes from Scott McNealy one of the more flamboyant figures in technology circles Bill Howard s retrospective view upon departing from Sun Microsystems Build vs buy background articles Build vs Buy In the 21st Century Joshua Greenbaum Intelligent Enterprise magazine Survival Guide Bob Lewis Buy Versus Build Why Companies Should Never Build Software Consider these points when making the build vs buy decision Jerry Loza Tech Republic The Death of Packaged Apps Eric Keller Sandhill com Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Vendor management Speak Your Mind Cancel reply Name Email Website you MUST enable javascript to be able to comment Notify me of follow up comments by email Notify me of new posts by email Notice It seems you have Javascript disabled in your Browser In order to submit a comment

    Original URL path: http://www.peterkretzman.com/2008/01/30/buy-vs-build-and-why-scott-mcnealy-thinks-the-cio-doesnt-need-a-staff/ (2016-04-28)
    Open archived version from archive

  • IT, the CIO, and the business need for "roof projects" - CTO/CIO Perspectives
    development architecture and test resources but it without doubt had business value Yet it was again a roof project it provided no clearly identifiable new capability other than things will be easier and the company will be at much less risk All chosen projects represent opportunity costs when you do one it means you no longer have those resources available to work on another at the same time Internal customers in these two instances had great difficulty accepting the delay of new functionality work and would have preferred that we had left the old roof in place so to speak My least favorite adage that is often heard at times like this if it ain t broke don t fix it To which I have been known to retort if the car is still running why change the oil In other words roof projects need the business to have rare long term vision to truly SEE the benefits especially if risk and or future capability is involved Business folks for understandable and solid reasons such as this quarter s all important financial results are typically pressured to favor implementing measures where the short term revenue is fairly clear By nature they aren t as interested in something that simply promises easier better less risky work down the road In a perfect world all projects would have agreement from everyone across the organization But hey the world s not perfect and everyone has their own pet areas IT tends to deal with areas that are both arcane and which involve subjective risk assessments not certainties And we in IT circles sometimes tend to imagine a world where everything is of course facts based and hence we believe that project selection will be as one professional recently tweeted to me totally simple But in the real world there are biases and politics just to name two factors that influence the selection of projects It is absolutely critical that the CIO CTO be the chief voice at the senior management table when it comes to educating and advocating the judicious undertaking of roof projects when necessary Without that active voice it s common to see the roof work continue to be deferred year after year In a future post I ll expand further on this topic talking more about the difficulties of and approaches for project prioritization in general Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Projects Comments Michael Burke says November 16 2009 at 10 54 pm Couldn t agree more There s a universal truth that any IT system is a true reflection of the process and organization that built it Complex process poor system complexity and brittleness You might be working on an insurance system where each product has slight subtle but profound variations on how it processes lapsing premium calcuations acceptance rules etc etc As you point out only strong leadership to drive simplicity cohesion

    Original URL path: http://www.peterkretzman.com/2009/07/07/it-the-cio-and-the-business-need-for-roof-projects/ (2016-04-28)
    Open archived version from archive

  • More tips for dealing with IT vendors - CTO/CIO Perspectives
    job Doing so keeps everyone including you and your staff on their toes and watchful of both cost and value and it lets you gauge what you really want features and functions from the purchase Get your legal and financial people involved as early as they will accept and usually that s pretty early Nothing is more frustrating to an in house legal counsel for example than to be brought in and told everything s all done and we really need to get this signed this week That approach is bad enough in terms of your negotiating power and it s even worse for protecting your company The vendors will want to know what your budget is Sometimes you ll have a really firm idea of what that is Don t tell them Sometimes you won t have a firm idea because it depends on the value that you re seeing and the trade offs you can make in other areas Don t tell them Within an appropriate and reasonable range of product type e g all Volkswagens as opposed to a mix of Volkswagens and Bentleys you want to focus on functionality robustness and overall value long before you start discussing particulars of price The vendors will want to know who their competition is They go crazy when they don t know whom they re up against and they will tend to ask repeatedly in various ways Don t tell them though Again it s mainly about them understanding your business and needs and about you understanding their offering Everything else is largely a part of the price negotiation After the sale is complete Have a long memory Good vendors are golden Less good ones seldom change their basic approach There are several vendors a very small set to be sure that I will never work with again under almost any circumstances Don t let your natural trust and hope go too far towards giving business relationships a second chance if you ve been seriously disappointed the first time around Don t fall out of touch with your new vendor any more than you want them to do that to you Maintain regular contact Make sure that you or a suitable delegate is in charge of the ongoing relationship this means achieving an ongoing understanding what products they have in the pipeline and how it affects what you ve purchased from them already Don t get complacent any more than allow them to become complacent Each of your vendors should earn your business each time Yes it s easier to just call up Joe for the next piece of equipment or software module but within logistical boundaries look to explore if there are viable alternatives You owe that to your business and to your bottom line Lagniappe Deborah Perelman Six Steps to Successful Vendor Management ComputerWorld Vendor Management Tips Building Relationships Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under

    Original URL path: http://www.peterkretzman.com/2007/08/21/more-tips-for-dealing-with-it-vendors/ (2016-04-28)
    Open archived version from archive

  • About Peter Kretzman - CTO/CIO Perspectives
    enterprise software He has served in CIO and CTO positions at several companies including high volume Internet sites Peter s blog covers broad topics of interest to senior executives giving the CTO CIO perspective on such things as working as a member of a company s executive team forging business IT alignment focusing product and application development enhancing and maintaining world class operations and the care and feeding of technical staff Per CIO Magazine 6 19 2009 Kretzman a 25 year IT and online veteran shares thoughts on focusing product and application development as well as enhancing and maintaining world class operations He also points out that many departments survive by hiding inefficiencies oversights and missed opportunities Peter lives in Seattle WA with his wife and children He can be contacted in German as well as English Peter Kretzman is currently available for high level IT consulting engagements and speaking engagements particularly focused on overall IT capability assessments interim CIO roles and effecting a turnaround on key projects in crisis Phone 425 835 3487 or email peter dot kretzman at gmail dot com To sign up to receive future CTO CIO Perspectives posts via email fill out this form Peter

    Original URL path: http://www.peterkretzman.com/about-peter-kretzman/?shared=email&msg=fail (2016-04-28)
    Open archived version from archive



  •