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".
  • Process Archives - Page 5 of 5 - CTO/CIO Perspectives
    amount of pressure emerges to reduce these quickly Unfortunately the quickly part of that last sentence just isn t realistic A lot of IT expenditures can t be turned off or down at a moment s notice In many or even most cases the company has already signed and paid for maintenance agreements with hardware and software providers that typically last a year if not longer Read more Tweet Filed Under Financial Pillars of Purview Process By Peter Kretzman 1 Comment Rock and a hard place why estimating turns into a squeeze play Tweet I wasn t ever a very good bridge player and it s been decades since I played Hence using this analogy may be stretching matters but as is typical I took away some key metaphors from my time with the game One is the squeeze play where you force your opponent to discard a vital card It s similar in a way to what s called Zugzwang in chess which describes a situation where one player is put at a disadvantage because he has to make a move and by doing so any move in other words will force himself into a weaker position How does all this relate to CTOs and CIOs Consider the case of having to estimate how long a specific project will take particularly early on usually before any kind of detailed requirements are even remotely fathomed Note that this kind of estimating is among the most critical activities that you and your organization will do because it feeds into the organization s whole prioritization and costing process as a whole Unfortunately it gets you into exactly this kind of squeeze situation If you say a project is going to take what s considered to be too long you ll get beaten down about why you can t do it faster If you blithely sign up for doing it too fast say as fast as they want it there s a huge risk that you won t be able to deliver Read more Tweet Filed Under Estimating Pillars of Purview Process By Peter Kretzman Leave a Comment A team oriented approach to making good hires Tweet I made two really bad hiring decisions in a row a few years back and I have to admit that it shook me for a while I won t go into details about why these two hires were horrendous although I should note that the problem was not because the requisite technical skills were lacking but the most important thing I can say about them is that both hires happened when with all good intentions I departed from the general hiring process and practice that I ve evolved to over the years This process doesn t always work out exactly as described below for scheduling reasons but here s what I strive for and what I ve found tends to get great results Read more Tweet Filed Under People Pillars of Purview Process By Peter Kretzman

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


  • Mending Wall: Matches and mismatches in IT stakeholder expectations - CTO/CIO Perspectives
    discipline is remembering what you really want In short it s really a tug of war for the stakeholders themselves a battle between their natural immediate wants and their long term real underlying desires The answer to this perennial standoff Well quite literally there isn t one by which I mean that there isn t one single answer Instead there are several to be exercised simultaneously And more than any single other entity in a corporation success here depends on the adroit senior IT executive to bring off an appropriate balance Be flexible Your SDLC is important but it can t become absolute or wall like And while you re being flexible within reason of course recognize the downsides of doing so It means there will be some rework There will be interproject conflicts that could have been prevented had there been better planning and preparation Roller derby is not ice ballet Being scrappy will get you scraps and scrapes more often than not but that s just sometimes how the game needs to be played Educate as the opportunity presents The flip side of Frost s something there is that doesn t love a wall is good fences make good neighbors Your stakeholders don t automatically see the value in various IT processes and practices only targeted discussion will help them do so Having metering lights on freeway on ramps seems to slow things down but it actually speeds things up Recognizing that isn t intuitive Talk them through why your project may need the equivalent of metering lights Emphasize collaboration and teamwork In Frost s poem it can be argued the actual process of working on the wall together rather than the wall itself is what makes for good neighbors Figure out together what processes add real value Constantly look for ways to de couple your work so that chunks projects can be done in parallel Serial thinking can often become an easy out a lazy excuse You ll note that at least three of the points in the stakeholder list that led off this post have to do with conducting work in parallel Lead Without proactive engaged senior leadership that constantly and effectively reminds everyone of the less visible goals polls them on their reactions and then reframes the discussion the stakeholder requirements list rapidly starts to include things that are frankly akin to wanting M Ms for breakfast Leadership brings balance and perspective Make no mistake about it mending walls is hard Doing just one or two of the above approaches will cause you to fail as surely as if you did none of them And in my experience absence of the appropriate balance almost always causes a company to devolve into systems chaos Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under General Process Stakeholders Comments jfbauer says January 3 2011 at 6 33 am Sage advice as always really enjoyed the post The IT individuals

    Original URL path: http://www.peterkretzman.com/2010/12/28/mending-wall-matches-and-mismatches-in-it-stakeholder-expectations/ (2016-04-28)
    Open archived version from archive

  • More Peterisms: lessons learned on IT practices - CTO/CIO Perspectives
    the perfect is the enemy of the good The reasonable man adapts himself to the world the unreasonable man persists in trying to adapt the world to himself Therefore all progress depends on the unreasonable man George Bernard Shaw Aside from the now dated gender specificity of the above quote it s a gem Being too reasonable and adaptive can lead to complacency and failure to push the envelope Too much unreasonableness however and you re not going to be successful your expectations like the above mentioned Apple fans will be so high that you ll push all chances for success out the window Note the contradiction of this saying with the previous one however Don t make pie crust promises easily made easily broken Mary Poppins A classic way that IT often shoots itself in the foot is to overpromise usually in response to fervent desires needs and hopes or perhaps a little of Shaw s unreasonable man behavior on the part of stakeholders Here s one that I see time and again OK we ll get that feature into the very next release just a week after launch usually offered up as a negotiating concession with stakeholders when there s a late breaking requirement or the need to descope things to hit a launch deadline Of course at that point the very next release hasn t truly been planned yet and there are probably dozens of features and fixes vying for inclusion none of which have been soberly prioritized against one another by stakeholders To promise anyone anything specific on feature inclusion much less to state a specific short term time frame is almost a guaranteed way of disappointing people There s no substitute for planning even amidst the kind of heated discussion that usually happens late in a project So there s a common theme to these i e they all pertain to the negotiations process on projects but there s no single common answer that they collectively provide other than to underscore that it s important to look at things from both IT and shareholder perspectives be unreasonable in pushing for progress yet don t let a desire for perfection get in the way of generally improving things and for heaven s sake make sure you don t overpromise It s a mixed world out there and that will never change Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Communication Personal Peterisms Comments Carl Butz says April 8 2008 at 1 20 pm Hey there Peter Over many years I ve wondered how your bright star would progress Today I decided to Google you thinking you d certainly have an e mail address listed I m glad I checked and I ll be back at your blog for More Peterisms Carl Trackbacks Start simple a corporate desktop laptop refresh model says May 29 2008 at 7 10 am Don t be paralyzed by not having chosen

    Original URL path: http://www.peterkretzman.com/2008/03/09/more-peterisms-lessons-learned-on-it-practices/ (2016-04-28)
    Open archived version from archive

  • No silver bullets. Really! - CTO/CIO Perspectives
    exploded Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Industry trends Top 25 posts Tagged With agile cloud computing design thinking fads governance hype itil lean mythical man month project portfolio management ruby scrum soa theory of constraints Comments jfbauer says December 17 2009 at 6 13 am Getting IT delivery right requires leadership detail oriented personnel skillful practitioners I couldn t agree more with the pragmatic view that cuts through the bright shinny new methodological approaches to curing IT proverbial cancer But there sure seems to be money to be made building the next bandwagon and jumping on early great article Eric D Brown says December 17 2009 at 7 14 am Great job Peter I ve been known to fall into the trap of if we could only do X with X being whatever the new approach is we d be more successful I usually catch myself before getting too far along this path of thinking but still the fact that I let the new approach or new technology catch my interest as a panacea irks me Great stuff here and a great reminder that the right approach is different for everyone and may involved many approaches combine Mark W Schumann says December 17 2009 at 7 15 am Peter you write insightful stuff so often that there is now a Kretzman tag on my blog No seriously I started a really long comment here but it turned into its own entry on my own blog To prevent my comment from being nothing but an endeavor in blog shilling let me say here that my favorite insight of Brooks s paper is the distinction between accidental and essential complexity Brooks argued in 1987 that accidental complexity was nearly a thing of the past It s true As a developer you hardly ever have to mess around with peripheral stuff that simply gets in the way and doesn t work not like a logistics manager who deals with warehouse people calling in sick or like a construction supervisor who gets stuck with a batch of substandard materials Software is a really clean industry that way If something doesn t work it s probably because that s the job not a distraction from the job As a result everything we do is problem solving which is inherently unpredictable I adore your closing paragraph Rose says December 17 2009 at 2 03 pm There isn t a silver bullet and people do go crazy trying to find that one magical solution Metrics and ROI are key Here is an interesting article discussing the fuzzy ness of seeing the ROI with SOA and Enterprise 2 0 http www itbusinessedge com cm blogs lawson the human condition causes metric problems for soa enterprise 20 cs 38139 Peter Kretzman says December 18 2009 at 10 06 pm Thanks to all for your insightful comments Rose I ve actually already written about ROI fairly extensively

    Original URL path: http://www.peterkretzman.com/2009/12/16/no-silver-bullets-really/ (2016-04-28)
    Open archived version from archive

  • Executive questions, IT answers, pizza parlors, and speed chess - CTO/CIO Perspectives
    important issues to resolve before he will be able to zero in on a plausible target date It was thus kind of a stupid question on my part but exactly how stupid it really was depends on my attitude towards the exactness of the answer I get I need to be utterly aware that any answer I get this early on is going to be a wild stab at best an approximation and that it may indeed be completely wrong In essence I m asking a question akin to how long is a piece of string But it s actually only an unreasonable question if I have unreasonably lofty expectations as to the accuracy of the answer As we all know CEOs and other executives do ask those kinds of questions in fact they need to unless they want to just operate day to day and see what happens One can t completely avoid answering them and moreover one shouldn t I ve written before about this something I call the impedance mismatch between IT mentalities and executive mentalities It leads to the situation I ve described where you don t really know anywhere near enough to estimate early on say during annual budget season thinking about what you ll do in the second half of next year but you have to estimate anyway What s the answer Play speed chess This is my frequently cited metaphor for pushing IT people into making judgments and estimates without full information and in depth analysis Speed chess is where you aren t given a lot of time to think through your moves and their implications And if you don t move fast enough you lose the game Equally a group of knowledgeable experienced IT middle level managers can relatively quickly give you SWAG estimates on even high level descriptions of projects if you push them into it They ll naturally be reluctant to do so but the way to overcome that reluctance is to insist that the basic rule of the game is that these are estimates without penalties They ll do their professional best to come up with reasonable estimates neither padded nor overly optimistic but everyone in the game executives and technologists alike has to clearly understand that these estimates will be wildly wrong at least 30 of the time because they re based on limited information and a lot of implicit assumptions Play speed chess intoned repeatedly as a slogan can help both the executives and the technologists remember that now and down the road So maybe I can get Gunner to put some chess boards and time clocks into his new pizza parlor I ll have to ask him for an estimate on when that ll happen Lagniappe Malcolm Gladwell Blink The Power of Thinking Without Thinking Update Gunner opened his pizza parlor About two and a half years after I wrote this post And so far it s a smashing success As I expected Tweet Share this

    Original URL path: http://www.peterkretzman.com/2008/05/24/executive-questions-it-answers-pizza-parlors-and-speed-chess/ (2016-04-28)
    Open archived version from archive

  • Industry trends Archives - Page 3 of 3 - CTO/CIO Perspectives
    t get the new order Read more Tweet Filed Under General Industry trends Strategy By Peter Kretzman 16 Comments No silver bullets Really Tweet Fred Brooks wrote a seminal essay in 1986 No Silver Bullet Essence and Accidents of Software Engineering a model of clear and cogent thinking that I consider to be required regular reading for anyone involved in information technology Despite the essay s brilliance and despite its wide promulgation and deserved fame the phenomenon it describes seems to have only broadened in the last twenty three years Brooks argues as follows with bolding added The familiar software project at least as seen by the nontechnical manager has something of this character it is usually innocent and straightforward but is capable of becoming a monster of missed schedules blown budgets and flawed products So we hear desperate cries for a silver bullet something to make software costs drop as rapidly as computer hardware costs do There is no single development in either technology or in management technique that by itself promises even one order of magnitude improvement in productivity in reliability in simplicity So this basic tenet has been convincingly articulated by a leading IT thinker for almost a quarter century Yet the trend continues new technologies pop up every couple of years and the hype cycle begins Evidently hope springs eternal Read more Tweet Filed Under Industry trends Top 25 posts Tagged With agile cloud computing design thinking fads governance hype itil lean mythical man month project portfolio management ruby scrum soa theory of constraints By Peter Kretzman 11 Comments Cloud computing misunderstood but really not that complicated a concept Tweet Consider these statements Baseball is a game where the pitcher throws to the catcher An iPhone is a device that lets you call anywhere in the world The Grand Canyon is a tourist attraction in Arizona You ll have noticed that these statements aren t wrong per se But they still take you aback don t they They miss the point miss the magic neglect the important differentiators By explaining too little defining the subject too narrowly they explain nothing that s really useful Here s another Cloud computing is where you have a lot of intelligence in the network and it s available from wherever you need to get to it A distressing portion of mainstream media covering cloud computing has decided that the best way to explain the phenomenon is first to make hand waving general statements such as the above example from BusinessWeek and then cite a few consumer understandable examples such as in this piece from NPR Do you have a Yahoo e mail account Maybe a Gmail account Do you put up pictures on Flickr Perhaps you ve started keeping your schedule online If so then you are using cloud computing that s what tech companies call it when people work and store information on the Internet Flickr Gmail and Facebook are great services but declaring that they represent the burgeoning

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

  • The One True Way syndrome exemplified: the overstated case against code comments - CTO/CIO Perspectives
    deadlines exist My Own Descent Into One True Way ism Here s a personal illustrative example from a slightly different domain I don t use spell checkers basically ever I find them annoying and much too prone to alerting on false positives Instead I proofread my material carefully and find the errors That happens to be a particular albeit admittedly societally useless strong skill of mine honed through years of activity in both software development where typos count and journalism And I ve noted that people who rely on spell checkers often miss really obvious painful errors their two busy too sea um Or they do things such as correct alot by which they mean a lot to allot just because the hapless spell checker suggested it as the fix Given that errors can be missed or even created by relying on a spell checker and my lack of need for a spell checker myself should I now recommend that people do the hard work and learn to do as I do proofread their text carefully on their own Of course not That would be very idealistic of me but it would also be quite misguided Most people out there aren t as dogged or adept at proofreading as I happen to be so using a spell checker actually does help them catch a lot of mistakes that would otherwise go unnoticed Some errors don t get caught that way perhaps but on balance the result in most cases is better To eliminate the use of spell checkers altogether simply because they can be misused or imperfect would be throwing the baby out with the bathwater based on a very faulty assumption that everyone should be able to catch their own typos the way I happen to be able to Comments and clean code not an either or But back to comments I ve been programming now for longer than I like to admit decades Since I don t code every day anymore I m particularly motivated to use many clean code precepts as a self defense mechanism revisiting my own code even a few short months after I ve worked on it can be a nightmare if the code itself is not as as clear and maintainable and yes self explanatory as possible And for the very same reason I comment my code even if it feels a little redundant at the time Whenever I ve had to maintain code whether by me or someone else I remember how profoundly grateful I ve been when the code has also contained bread crumbs in the form of appropriate useful comments that let me easily revisit why particular choices were made or which explain the deeper context of the immediate chunk Clean code and useful commenting really doesn t have to be an either or and it makes no sense to insist that it is Moreover what is often missed in this debate is acknowledgment of the kind of chilling effect that influential books and blog posts and tweets create when they so categorically state that comments are harmful In particular the less experienced less idealistic developers will take away the work easing aspect of that i e don t bother to spend time commenting without necessarily absorbing and implementing the true precepts of clean code as a prerequisite In truth not everyone will be as committed to clean code as the clean code proponents imagine for a number of the practical reasons I ve cited above When you rely on having made code self explanatory and you shun comments altogether because of that assumption you miss the obvious and common situation one person s self explanatory code may look to a future maintainer more like a big ball of mud than the author can possibly imagine when he himself is knee deep into creating it There s nothing wrong with judicious and targeted comments that provide the beneficial sort of bread crumbs that help out later maintainers So here s the thing for solid and laudable reasons software craftsmen start out warning folks to be cautious and targeted about when they use comments but they then take that stance to extremes embracing an impractical blindered fringe view that pigeonholes all comments as signs of failure At its most extreme part of that stance even seems to turn into accusing the other side of not having a true zeal for excellence or being too willing to make compromises on quality A balanced view should prevail It s much more sensible to take a balanced view as does Steve McConnell in his book Code Complete noting that done poorly commenting is a waste of time and sometimes harmful Done well commenting is worthwhile That s quite different from pronouncing all comments to be failures as did my Twitter conversationalists and as does Robert C Martin in his otherwise excellent and useful book Clean Code in which he writes Comments are always failures We must have them because we cannot always figure out how to express ourselves without them Again then I return to the practical side of things and strongly counsel against advice even from consummate craftsmen that smacks of an absolutist One True Way approach and which contradicts common sense Claims like our approach will solve all your IT failure problems and the claim that all comments are failures avoid using them are cut from the same cloth Don t buy it Lagniappe Jani Hartikainen Is Commenting Your Code Useless October 15 2009 James Carr Code Comments The Lowest Form of Communication October 15 2009 Danny Tuppeny Writing comments in code is NOT a waste of time March 26 2011 Jeff Atwood Coding without comments July 24 2008 Sammy Larbi Common Excuses Used To Comment Code and What To Do About Them June 18 2008 Brian Kotek Don t Comment Your Code June 5 2008 Ben Nadel Not Commenting and the Tipping Point of Poor Programming June 5 2008 Robert C

    Original URL path: http://www.peterkretzman.com/2012/10/23/the-one-true-way-syndrome-exemplified-the-overstated-case-against-code-comments/ (2016-04-28)
    Open archived version from archive

  • Countering a disturbing bandwagon: rich vs. poor IT organizations - CTO/CIO Perspectives
    and IT I can t agree though with your Project Portfolio Truth as stated The causes of project failure are actually myriad intertwined and often fraught with politics They are usually anything but simple I wrote a whole post about this in fact Complexity Isn t Simple Multiple Causes of IT Failure See http www peterkretzman com 2009 11 16 complexity isn E2 80 99t simple multiple causes of it failure jfbauer says August 8 2010 at 5 48 pm Extremely pragmatic post as always Though not a CIO myself I can t help but equate these seemingly ethereal goals for rich CIOs with the way of architect astronauts around the middle of this past decade I would imagine a CIO would be on his or her way out if he or she were pontificating on richness while production systems were crashing and budget was vanishing on last minute ill negotiated licensing deals etc Peter Kretzman says August 8 2010 at 7 26 pm Thanks John as you know I completely agree As I ve written before excellence in tactical delivery is the ante that gets you to the strategic table And thanks for the reminder about architecture astronauts a classic Joel Spolsky meme that everyone should review http www joelonsoftware com articles fog0000000018 html He writes That s one sure tip off to the fact that you re being assaulted by an Architecture Astronaut the incredible amount of bombast the heroic utopian grandiloquence the boastfulness the complete lack of reality And people buy it The business press goes wild In other words the comparison you make here is quite apt Frank Scavo says August 9 2010 at 12 56 pm I m trying to think of another functional area where neglect of day to day operational excellence would be promoted as a qualification for higher corporate office Can you imagine It s always easier to teach a business person engineering than an engineer business Or Running the finance department is not a valuable use of the CFO s time talents and energy Rather I think this sort of thinking should lead to a pink slip Peter Kretzman says August 9 2010 at 1 28 pm Frank To play devil s advocate a bit I actually think that the people I was writing about would object to being depicted as proposing neglect of day to day operational excellence Instead they simply believe that that responsibility should be delegated downward and that focusing on it too much distracts away from a CIO s higher calling to strategy essentially That said I still vehemently disagree with them Operational excellence is important enough and elusive enough in most companies to merit strong attention from C level management not a shoulder shrug and delegation to junior lieutenants So I m objecting primarily to the dismissiveness and trivializing that I see going on here because I think it s harmful in the end to strategy Strategy and operational excellence do both Don t pick one or the other Thanks for commenting Mark McDonald says August 30 2010 at 8 39 pm Peter I would like to thank you for your comments on the Forbes interview I went back through the interview and could not find where I say that IT management was no longer necessary or that it did not matter The obvious implication that you ascribe to me is not one that I believe I made or hinted at because it s not what I believe If talking about the changes needed to create more business results is as you say an abandonment of common long standing lessons in IT That is not the point I tried to make it clear that IT organizations that concentrate and focus their efforts on creating business value are more effective or richer than others The rich vs poor characterization is an unfortunate but clear differentiation Rich and poor organizations alike need strong IT management and execution Rich IT organizations do not throw caution to the wind and management discipline out the door in fact they build on it The interview pointed out that One of the things that has been very surprising out of the economic crisis is that effective leaders and good management no matter where they came from are getting a chance to shine through I believe that does more than imply that solid management matters and is important to everyone I did imply is that delivering on time on budget and on schedule is no longer enough in the face of volatility the need for results etc If you adopt a view where you re not responsible for results but you can prove that you have lower total cost of ownership that s a handicap That is a characteristic of what the interview called poor organizations That is a difference requires rather than absolves companies from effective IT management These are differences based on survey work not my hubris or any other motivation The survey work started three years ago and involves more than 1 500 CIOs each year We looked at differences between enterprise and IT effectiveness The result was simplified into the idea of rich and poor for the interview but its based on data not FUD or a desire to muddy the waters Regarding the issue of it being easier to teach business people technology that observation comes from CIOs and IT executives When I ask them why they feel that way they point out that having a technical understanding of how the business works is not the same as knowing the business You can point out that many business managers share that same situation I agree that this is an old saw argument and it was not the focus of the interview The interview mentioned Growing up in technology does not preclude you from running a rich organization though They re a little more prevalent than people give them credit for I agree that sounds dismissive to technologists That was

    Original URL path: http://www.peterkretzman.com/2010/08/06/countering-a-disturbing-bandwagon-rich-vs-poor-it-organizations/ (2016-04-28)
    Open archived version from archive



  •