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".
  • Pillars of Purview Archives - Page 8 of 8 - CTO/CIO Perspectives
    is especially new or difficult but they don t always seem to come intuitively to IT folks When presenting a problem and or proposal to upper management keep in mind the following Read more Tweet Filed Under Communication People By Peter Kretzman 6 Comments tanstaafl An Introduction to IT Portfolio Management Tweet I ve already written about how the most important task of management is the proper allocation of resources By that I don t just mean figuring out that Joe and Bob need to work on Project X this week At a higher macro level the issue of resource assignment deals with how the company as a whole plans and spawns its suite of projects Much of what I ll have to say in this post will perhaps seem to be intuitive even obvious Yet once again for all its obviousness it has been astonishingly controversial at many companies Better said these concepts seem to be intellectually understood and accepted yet then resisted perhaps due to the old adage of everyone wants to get into heaven but no one wants to do what it ll take to get there What does it take to get there then You need to plan and schedule projects holistically not one by one This approach is commonly known as Project Portfolio Management PPM although that term often is used more to describe the aspect of selecting and prioritizing IT Projects based upon corporate strategic and tactical objectives and then optimizing the whole set to ensure maximum utility All of that is both valid and critical of course I ll have more to say about project selection criteria later and in the meantime would point you to some of the references contained in my Lagniappe section Read more Tweet Filed Under Pillars of Purview Process By Peter Kretzman Leave a Comment Guest appearance on E commerce Consulting blog Tweet Sally McKenzie with whom I worked when I was CTO at Classmates Online writes a fine e commerce oriented blog that I read regularly So I was especially pleased when Sally asked me to guest contribute via a back and forth interview format on the subject of how IT folks and Marketing people can work better together Not only is this topic especially close to my heart but Sally s also one of the sharpest executives I ve worked with She especially stands out in her ability to collaborate forge agreements and foster teamwork at senior executive levels so this was a great conversation Check it out here Tweet Filed Under People Pillars of Purview By Peter Kretzman Leave a Comment The Pillars of Purview of the Successful CTO CIO Tweet So as we ve now discussed you the CTO or CIO brought in to oversee the technology areas of your company are paradoxically not really there predominantly for technology Even if you like to think of yourself as a technogeek and most of us do frankly if you want to be effective in the

    Original URL path: http://www.peterkretzman.com/category/pillars-of-purview/page/8/ (2016-04-28)
    Open archived version from archive


  • Hot stove lessons in IT, part I
    double entry bookkeeping what a waste of time to enter everything twice eh If we outsource a lot of things then we can do a lot more as an organization However people embracing this myth seldom show a good understanding of what it takes resource wise as well as the hit to organizational focus to select and manage all this outsourced work much less integrate its results Many IT organizations don t even have the necessary technical foundation infrastructure in place to allow outsourcing to happen effectively at all Outsourcing is indeed a worthy goal and a fine choice when chosen and planned for prudently but it doesn t come for free and tradeoffs must be discussed and understood up front when these choices are made If there are bugs in the software it s because QA didn t do their job well Bugs however are a fact of life in software development Mitigating them in quantity and impact and risk is the issue not eliminating them Almost always it tends to be schedule pressure and or resource constraints both caused typically by management impatience and or inadequate understanding of cause and effect that have facilitated the inclusion of an unacceptable level of bugs in the released product IT should work on everything that the users say they need the truly necessary stuff will sift to the top There s no real need for messy and time consuming prioritization efforts This may be the most dangerous myth and need to learn lesson of all these management related items Prioritization needs to happen on purpose not by accident or by mere dint of IT championship It s the most important thing that an organization does at least the organizations that manage to avoid hopeless fragmentation of resources and effort Purposeful portfolio management with heavy stakeholder participation and sponsorship is the only really effective way of dealing with the firehose that is constantly trained at IT s eyeball Tying this to the items at the top consider that if you want to do more one very viable approach is to take on less and to make sure that what you actually take on are truly the top priorities the vital few for the company One tiny anecdote to frame this discussion I saw one company where literally dozens of IT contractors were brought in at short notice and with little planning due to the unfortunately entrenched belief that adding more resources would of course result in faster delivery of badly needed product After only a month or two of having these workers on board the short term operational results of the company caused budgets to suddenly tighten and all the contractors were let go Due to ramp up and inadequate knowledge transfer almost no value was gained to the company from what equated to several person years of cost effort See the first two lessons myths above People s fingers came away badly burned on that one you can be sure So

    Original URL path: http://www.peterkretzman.com/2008/08/27/hot-stove-lessons-in-it-part-i/ (2016-04-28)
    Open archived version from archive

  • "Refuse to lose": how executive pressure contributes to IT failure
    be a number of months not weeks before the product could be successfully launched I remember him sputtering that s unacceptable and pressuring me on what I could do to yes bring off a launch in six weeks Cutting to the end of the story we launched successfully nine months later In this case a mixture of testosterone and probably some job on the line aspects were driving this CEO to ignore facts and look for ways to bull through to success despite obvious counter indicators The tragedy of the space shuttle Challenger has become almost cliché along these lines a combination of executives feeling pressure and ignoring communication from lower ranks about major problems They also disregarded warnings from engineers about the dangers of launching posed by the cold temperatures of that morning and had failed to adequately report these technical concerns to their superiors For whatever reasons NASA management gave the green light for launch despite the adverse weather conditions In essence they refused to lose and by doing that they lost in a major way Takeaways Don t let your executives turn you and don t let them become riverboat gamblers where failure is a strong possibility through a premature launch The company culture must be shaped so that it views a spectacularly failed launch as much more onerous than a delayed launch Don t let groupthink settle in where your people are afraid to speak up Any and every member of the team should have a chance to pull the emergency brake Especially holding a formal go no go meeting is essential where any stakeholder or project participant can voice concerns and point out facts that speak against readiness That said do be careful of the pessimist amid your ranks who typically voices dire predictions on every project and who sooner or later will be proved right Insist on facts not Eeyore ism Let your team watchwords for these situations become the following candor and facts Bring both to the meetings or go home The best way to avoid letting pressure drive a premature launch establish your launch criteria clearly and openly with quantitative measurements way in advance If you don t have legitimate facts based ways to tell if you re ready i e not just the launch date arriving and not your testosterone level that morning well then you re not ready Without a doubt refuse to lose can be a great attitude up to a point No executive no team should ever become blasé about missing a target But refuse to lose can t ever be allowed to become refuse to face facts When it does you don t just lose face you just plain lose Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Anecdotes Pillars of Purview Projects Comments jfbauer says October 28 2009 at 6 56 pm Great perspective on the pressures on IT projects and over pressure before truly being

    Original URL path: http://www.peterkretzman.com/2009/10/28/refuse-to-lose-how-executives-contribute-to-it-failure/ (2016-04-28)
    Open archived version from archive

  • Projects Archives - Page 3 of 3 - CTO/CIO Perspectives
    inherited a team that wasn t doing In fact the team wasn t saying either Astonishing as it may seem they had been allowed by company management to fall into the pattern of making no commitments for delivery in anything other than the vaguest of possible terms most of which had to do with stating noble intentions of working hard In other words they weren t really putting themselves on the line A major part of my approach there was to emphasize the importance of making and then meeting specific commitments for delivery Commit Deliver Track Communicate became the simply stated three pronged get well plan in that situation Easily stated not so easy to achieve but that s a story for a different posting someday My major point here though and an important part of project delivery doing what you say you will do that occasionally gets lost is declaring victory when the project is successfully launched This declaration should be a relatively formal executive penned announcement of the launch usually delivered via a broadly disseminated e mail Insisting on declaring victory has a number of important purposes Read more Tweet Filed Under Communication Pillars of Purview Projects Previous Page 1 2 3 Contact information for Peter Kretzman Ph 425 835 3487 Email peter dot kretzman at gmail dot com Social media Blog post categories Anecdotes 21 Book reviews 7 Communication 23 Education 6 Estimating 9 Ethics 1 Financial 7 General 31 Humor 7 Industry trends 23 Metrics 5 Overview 10 People 12 Performance 1 Personal 20 Personal R D 2 Peterisms 4 Pillars of Purview 43 Process 38 Projects 17 Recommended reading 8 Role definition 29 Stakeholders 15 Strategy 9 Tools 6 Top 25 posts 25 Vendor management 10 Blogroll 10x Software Development Steve McConnell s blog Archimedius

    Original URL path: http://www.peterkretzman.com/category/pillars-of-purview/projects/page/3/ (2016-04-28)
    Open archived version from archive

  • Top 25 posts Archives - Page 3 of 4 - CTO/CIO Perspectives
    population of desktops and laptops e g how many are more than a year old Don t relate the actual handling of the asset e g replacement after three years to the financial handling e g spreading the capital expense over three years from an accounting perspective Replacement tends to be demand driven meaning usually crisis driven Don t have a solid process or any process for decommissioning a machine that is past its useful life Don t have the ability to tell a given employee when his or her machine will be replaced Read more Tweet Filed Under Pillars of Purview Process Tools Top 25 posts By Peter Kretzman 4 Comments Astounding IT sayings the inaugural post Tweet I haven t given myself the luxury of telling an IT anecdote or two here recently so it s about time here are two with moral of the story observations for each Note these are true stories I may have changed some of the facts lightly to make them less identifiable They re also always at least several years in the past to provide a healthy amount of distance for everyone I d actually like to make this post the first in a recurring motif a series that I ll call Astounding IT Sayings for what I hope are obvious reasons The saying that I consider to be astounding in its context will be highlighted for you below in bold Read more Tweet Filed Under Anecdotes Personal Top 25 posts By Peter Kretzman 12 Comments Nuts the biggest trap of all for IT stakeholders Tweet As I promised last time there s one more key way the biggest way of all not to get what you want from your IT organization This is in fact the trap I have seen virtually every entity I ve ever worked for fall into to some degree some to the point of actually destroying the company The trap is perhaps best communicated first via parable no religious implications here mind you and then I ll give some concrete examples and some brief advice on how to avoid or at least mitigate it Few people realize how well many of Aesop s Fables apply to IT situations after all as Apollonius of Tyana noted Aesop made use of humble incidents to teach great truths One of my favorites along these lines is Aesop s fable about the boy and the nuts in the jar Read more Tweet Filed Under Process Stakeholders Top 25 posts By Peter Kretzman 3 Comments Using feedback loops to improve IT department service Tweet As I ve written here before I strongly advocate thinking of IT in general as a service organization to the rest of the business Any service organization needs one or more forms of feedback loop to be able to gauge whether it is successfully accomplishing its mission However I ve observed relatively few IT organizations that actively seek to implement such feedback loops on a regular basis At

    Original URL path: http://www.peterkretzman.com/category/top-25-post/page/3/ (2016-04-28)
    Open archived version from archive

  • Top 25 posts Archives - Page 4 of 4 - CTO/CIO Perspectives
    in ComputerWorld pointed out ask what a CTO does and you re likely to get a variety of responses In some companies the CTO heads research and development In other companies the CTO is just like a CIO In still others the CIO reports to the CTO And there are also CTOs who work in IT departments and report to the CIO I m going to reveal my bias here up front it doesn t matter really what you call the position The important part is to recognize two conflicting truths technology is all important in many leading and bleeding edge companies today technology itself however cannot be the sole or even the main focus and purview of the senior technology executive Read more Tweet Filed Under Role definition Top 25 posts Previous Page 1 2 3 4 Contact information for Peter Kretzman Ph 425 835 3487 Email peter dot kretzman at gmail dot com Social media Blog post categories Anecdotes 21 Book reviews 7 Communication 23 Education 6 Estimating 9 Ethics 1 Financial 7 General 31 Humor 7 Industry trends 23 Metrics 5 Overview 10 People 12 Performance 1 Personal 20 Personal R D 2 Peterisms 4 Pillars of Purview 43 Process 38 Projects 17 Recommended reading 8 Role definition 29 Stakeholders 15 Strategy 9 Tools 6 Top 25 posts 25 Vendor management 10 Blogroll 10x Software Development Steve McConnell s blog Archimedius Greg Ness always interesting blogs on networking security and virtualization Bridging the Gap Bridging the Gap between Business and IT Laura Brandenburg s excellent blog on crafting business analyst practices to solve business problems CIO Dashboard Chris Curran blogs on IT management issues CTOvision com Bob Gourley s excellent blog looking at things from a lens of enterprise technology E commerce Wisdom Sally McKenzie is a

    Original URL path: http://www.peterkretzman.com/category/top-25-post/page/4/ (2016-04-28)
    Open archived version from archive

  • choice Archives - CTO/CIO Perspectives
    new car because of the thrill of haggling with the salesperson But I ve learned over the years how negotiations can best be structured for the optimal outcome Like cryptography where greater obscurity isn t equivalent to greater security successful negotiation isn t dependent on tricks or subterfuge I m quite content to tell any vendor or salesman how I go about negotiating because doing so doesn t provide them any kind of advantage If anything it s beneficial to me and my company that all parties in the negotiation understand clearly the basic principles and approach that I m using it cuts a lot of the normal gamesmanship out of the equation Read more Tweet Filed Under Pillars of Purview Process Role definition Vendor management Tagged With balance choice choosing cost gamesmanship money negotiation SLA tricks vendor Contact information for Peter Kretzman Ph 425 835 3487 Email peter dot kretzman at gmail dot com Social media Blog post categories Anecdotes 21 Book reviews 7 Communication 23 Education 6 Estimating 9 Ethics 1 Financial 7 General 31 Humor 7 Industry trends 23 Metrics 5 Overview 10 People 12 Performance 1 Personal 20 Personal R D 2 Peterisms 4 Pillars of Purview 43 Process 38 Projects 17 Recommended reading 8 Role definition 29 Stakeholders 15 Strategy 9 Tools 6 Top 25 posts 25 Vendor management 10 Blogroll 10x Software Development Steve McConnell s blog Archimedius Greg Ness always interesting blogs on networking security and virtualization Bridging the Gap Bridging the Gap between Business and IT Laura Brandenburg s excellent blog on crafting business analyst practices to solve business problems CIO Dashboard Chris Curran blogs on IT management issues CTOvision com Bob Gourley s excellent blog looking at things from a lens of enterprise technology E commerce Wisdom Sally McKenzie is a

    Original URL path: http://www.peterkretzman.com/tag/choice/ (2016-04-28)
    Open archived version from archive

  • A case study of "going to the cloud" (SaaS) - CTO/CIO Perspectives
    countered these roadblocks via several approaches We surveyed all users in the company for their views of the system and tolerance for change in this area and fed this feedback into the resulting action plan We constructed a thorough cost analysis of the status quo how much the current solution was costing the company in both hard and soft costs I used this analysis to obtain executive buy in and to specify in detail what the cost and effort would be to fix it We made sure that both junior and senior staff were involved in the methodical evaluation of alternative approaches including the alternative of keeping the status quo This helped achieve staff buy in We brought our short list vendors in for week long user proof of concept trial periods getting both staff and user feedback thus defusing a lot of the loss of control type of uncertainty regarding the change We negotiated hard with our short list vendors to obtain a good deal for the company We worked hand in hand with our excellent legal staff to make sure we were well protected in terms of vendor SLAs security etc We constructed and followed a careful user communication plan keeping everyone informed of the rollout schedule via FAQ style emails The rollout of the chosen solution went fairly smoothly We failed to identify two key risk areas or areas of concern clearly enough though Users were much more concerned about calendar migration old appointments and their attachments than we had anticipated and somehow this didn t come out in surveys etc before the implementation we responded not by migrating the old items expensive and difficult but by keeping the old system running for a period of time after system rollout of the new solution and that seemed to be satisfactory Users had great difficulty adapting to a 250MB email space limitation since they had effectively had no limit albeit poor performance and terrible stability under the old system Even though we had discussed that limit in advance done benchmarking across similar companies about their space limits and gotten clear user buy in it still might have been better to consider a higher limit and hence more cost as we sought expenditure approval Now just three years or so later I d do several things differently obviously anticipate and avoid the mistakes itemized above consider using Google s business email offering we ruled it out since it was brand new as of the time of the implementation but it offers a much greater storage limit than any other provider I m aware of and finally implement sooner rather than later Why sooner The implementation and system was such a success that despite the bumps and concerns I just named there was no more constant hallway conversation about the email system It had ceased to become a concern and also ceased to become an excuse And bottom line for the company besides those productivity benefits The total cost of

    Original URL path: http://www.peterkretzman.com/2009/08/20/a-case-study-of-going-to-the-cloud-saas/ (2016-04-28)
    Open archived version from archive



  •