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".
  • Role definition Archives - CTO/CIO Perspectives
    CIO Paradox Battling the Contradictions of IT Leadership Tweet It s a universal trait it seems we all want to be understood want the world to see things through our eyes want to watch the aha light go on when people finally realize just how tough we have it and how magnificently we still prevail IT people and senior technology executives in particular are anything but exceptions to this longing In fact it seems that very few other disciplines have to put up with a constant stream of articles and books questioning our very existence approaches purpose and worth Does IT Matter the death of the CIO etc Even the acronym CIO is commonly and gleefully referred to as standing for Career Is Over And you want a downer Just try googling average tenure of the CIO A person could downright get a complex here No one seems to get it No one understands how tough a job this is No one seems to perceive the damned if we do damned if we don t intrinsic nature of our role I present this syndrome with all due humor against the assault of laughter nothing can stand said Mark Twain but I also mean it is it utter masochism that leads us to choose this whipping boy kind of career at this level That s why it s so welcome when a book comes along that effectively presents insight and understanding into the big picture struggles of today s CIO even combined with empathy and warmth Martha Heller s The CIO Paradox Battling the Contradictions of IT Leadership just out late last year brims with been there seen that deep insight into many of the standard CIO predicaments Read more Tweet Filed Under Book reviews Industry trends Overview Recommended reading Role definition By Peter Kretzman Leave a Comment Novels of IT The Phoenix Project Tweet Nerd alert it s an exciting day for me when someone releases a new novel of IT I ve made it my mission to find and review several of these now four over the past couple of years and I may be one of the few people out there who has read and reviewed all of them To recap what do I mean by a novel of IT It s a term I coined to describe a fictionalized depiction of life in a corporate IT environment usually bearing a number of intended lessons in tow about IT best practices approaches pitfalls They re generally not works of serious fiction their audience is usually the lot of IT professionals rather than the broad public For example I don t include in this category two fine and recommended works that in fact aspire more to literature than to IT didacticism Douglas Coupland s Microserfs and Ellen Ullman s The Bug As I ve traveled through the fictional scenarios depicted in these four books I ve evolved criteria for what makes them successful or not in my eyes In

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

  • The case against #NoEstimates, part 1: introduction and common sense - CTO/CIO Perspectives
    and how they might help make better decisions However it seems to boil down to a virulent and unshakable base conviction that estimates are utterly horrible for all the reasons stated above and more Using estimates allegedly leads to chronic abuse of developers by management cements inflexibility into projects and disturbs developer flow The sole alternative to estimates that the NoEstimates advocates clearly identify however seems to simply restate the age old Agile principles of small teams user stories sliced into doable chunks use of drip funding so as to achieve a predictable fixed cost and software delivery early and often They point out that software project scope tends to change drastically and frequently during such frequent delivery and argue that this scope variability allows projects to be declared as done and successful long before and without ever having actually delivered all the upfront identified desired functionality Over the next two blog posts I ll first lay out the reasons to see considerable value in a software development estimating process and its outcomes and then respond to the myriad NoEstimates complaints that are levied against estimates as used for software development But we ll start here as an intro just with invoking basic common sense about life and business Every day in life spoken and unspoken estimates drive what we do Can I make it to the dry cleaners and to the grocery store to get some milk before I have to pick up my child from school Can I cross the street without being hit by the car I can see approaching I need to get more done on that key task is it worth getting someone to help me or should I just do it on my own As in life so too in business pretty much everything we do involves us formulating and weighing implicit estimates what will this take Will we make it in time Will it be worth it And so on The only thing up for debate is when and how much we formalize them i e write them down The extent we tend to formalize a given estimate depends on the issue the stakes the team the time frame etc There s no single fits all answer Whenever there is any manner of management business scrutiny and there always is estimates in some usually more explicit form are part of the landscape In fact pretty much all proposals to senior management will cover or evoke these specific questions in some way How much will this cost When can we have it What s our expected benefit I ve never seen these questions not get asked by the boards the CEO COO and CFO of even smallish companies They re the most natural questions in the world when undertaking to have anyone do work of any substantial size in any domain In fact a board or CEO that didn t ask these questions about a major pending project would be guilty of dereliction of

    Original URL path: http://www.peterkretzman.com/2014/09/24/the-case-against-noestimates-part-1-introduction-and-common-sense/ (2016-04-28)
    Open archived version from archive

  • The case against #NoEstimates, part 2: why estimates matter - CTO/CIO Perspectives
    interim milestones that are needed to accommodate other elements in the organization and their tasks on the overall project Then you re not ready to play strategically in the business arena Estimates help us make collective reasonable commitments A willingness to make reasonable commitments leads to a culture of accountability which leads to high performance when facing a goal I ve argued elsewhere that this is fundamental human nature Without going into detail about goal setting theory I ll just say it flatly concrete goals are key to success Specifically studies involving specific and challenging goals led to higher performance than did easy or no goals Of course if unchecked the combination of unrealistic goals fiat driven commitments and subsequent constantly looming and seemingly arbitrary deadlines could turn into the proverbial death march But let s focus on avoiding those kinds of bad practices rather than letting our working processes get defined entirely by the possibility of them occurring Rather let s build a culture of accountability where people understand that in the course of ordinary business commitments need to be set and that they need to be agreed upon in collaboration A culture of collaboratively making and reliably delivering on commitments is an enormous positive and it should never be automatically equated with a culture of fear Does it make you too nervous to set a schedule and make a reasonable commitment without perfect information Then you re not ready to play strategically in the business arena Estimates provide a reference point a line in the sand When a work item runs over estimate it can provide a useful indicator that something is awry or that related assumptions need to be revisited Without such a reference point after all who s to say that anything has gone awry at all As George Dinwiddie wrote Estimates are based on assumptions and using them as a hypothesis can provide early notice that those assumptions might be incorrect when actuals differ from the estimate In short the process of estimating in and of itself has by products and benefits far beyond the sheer number or other indicator of sizing that emerges at the end Here s a great summary of similar points on the multiple benefits of estimates translated from a blog post in German Estimates are important so that requirements can be clarified so that misunderstandings can be resolved at an early stage so that there is transparency about deadlines and targets so that task prerequisites and open issues can be clarified so that all parties can arrive at a common commitment In summary let s harken back to common sense once again given these positive aspects and effects that a rational estimating process can provide exactly why would anyone state that a desirable goal is to push forward into limiting estimates down to zero where possible Frankly as is probably obvious I don t think there s a good answer to that question But in my next post I ll

    Original URL path: http://www.peterkretzman.com/2014/10/02/the-case-against-noestimates-part-2-why-estimates-matter/ (2016-04-28)
    Open archived version from archive

  • The case against #NoEstimates, part 3: NoEstimates arguments and their weaknesses - CTO/CIO Perspectives
    get bias out explicitly on the table through open declaration and active group scrutiny of estimates than to have it enter through the backdoor silently Estimates make it harder to change the plan Estimation up front makes it harder for us to change the plan because as we define the plan in detail we commit ourselves to following it mentally and emotionally Why would that possibly be the case Don t let that happen Estimates should be getting recalibrated constantly feeding in any new information and quite possibly changing the approach the timeline the staffing the scope of your overall effort As new information arises any plan can be changed assuming that there s a sober evaluation of the pros and cons of doing so Note that there s always a healthy tension between adhering to a game plan vs panicking entirely and ditching the plan as soon as the first obstacle rears its head Part of the role of a skilled product manager and of management in general is treading that narrow line deciding when and how to react and regroup NoEstimates advocates often paint their critics as inflexible big design up front oriented waterfall obsessed dinosaurs That s a straw man Analogy if you re taking a trip there s a very happy medium between we ll head east and completely wing it as we go vs we ll plan every stopover to the nearest second up front In other words you plan the trip to the degree you deem appropriate for your needs and you adjust appropriately as new information hits your radar Some plans will need to be changed in major ways others will absorb the inevitable minor variances and be broadly speaking just fine as initially defined Estimates take too much time Estimates are expensive to gather It depends It s always easy to trot out egregious straw man examples don t spend more time estimating etc than doing work one NoEstimates advocate has been known to tweet as if that s a common scenario Of course it isn t time spent planning needs to be weighed as with everything in business from a cost benefit perspective if I m about to spend 10 million on a software project it s worth spending six figures constructing estimates and a workable plan against which progress can be measured Align the time and expense of estimating with your value at risk in other words This again should be common sense Estimates are not required to deliver software Many companies and practitioners are doing it This may be the weakest NoEstimates argument of all Of course estimates are not required A driver s license isn t strictly required to physically drive a car a sterile environment isn t required to operate on a patient having a referee isn t required to play a game of soccer Equally doing upfront planning or even using common tools like bug tracking or source code control aren t required to deliver software I ve unfortunately often seen teams go without such things But just like a reasonable level of planning and the use of appropriate tools like source code control rational use of an estimating process can indeed contribute meaningfully to overall high quality timely delivery of software capabilities for an enterprise Pointing out that estimates aren t required in order to code as if anyone had been claiming they were seems quite intentionally to miss the point There are better ways OK no this is the weakest argument because it s not a bona fide argument at all I really wish I could cite the specific better ways that NoEstimates advocates have proposed in lieu of estimates but the declaration is usually formulated as above vaguely with nothing behind it The only concrete better way that seems to get cited consists of drip funding for the team you can pull the plug whenever you want story slicing of whatever piece of work is mysteriously judged as most important frequent delivery of software and then iterate refactor The need for estimates then disappears or so claim the NoEstimates advocates None of that is intrinsically a bad idea for some development circumstances but it s most certainly not universally applicable And it doesn t answer the up front questions that don t go away what will be the likely total investment we re making to get the full capability we need And when will we get that capability We re not ditching estimates Despite this now oft repeated claim the key NoEstimates advocates have yet to name any concrete examples of when estimates in their view actually are appropriate As a result NoEstimate s claim not to be ditching estimates comes off as defensive disingenuous and insincere considering the intensity of the diatribes they ve delivered against estimating In truth NoEstimates advocates appear to acquiesce to doing estimates only in cases where they are basically forced to do so by unreasonable and or unenlightened management But this kind of grudging acceptance of the need to do estimates while metaphorically holding one s nose estimates are a smell of possible decision making dysfunctionality is no way to win the understanding of or promote a strong collaboration with business people who have to grapple with uncertainty in their own areas every day In fact such a clearly insincere pro forma acquiescence is also likely to fail to incorporate all the positive elements and outcomes that a high quality estimating process would bring to the table So there you have it the principal arguments raised by NoEstimates in support of their case One last installment will be forthcoming in this series giving my bottom line assessment of estimates vs NoEstimates Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Estimating General Industry trends Process Comments Glen B Alleman says October 9 2014 at 3 03 pm Just figured something out The statement of Ron Even with clear

    Original URL path: http://www.peterkretzman.com/2014/10/08/the-case-against-noestimates-part-3-noestimates-arguments-and-their-weaknesses/ (2016-04-28)
    Open archived version from archive

  • Financial metrics for IT: the holy grail of ROI, and how it misses the point: Part 1 - CTO/CIO Perspectives
    you want to get to the point where you can reliably calculate present and make project choices based on such concrete metrics For detailed explanations of the meaning and suggested interpretation of each of these financial metrics please see some of the references contained in the Lagniappe section at the bottom of this post NOTE the spreadsheet itself is supplied in a link at the bottom of Part Two of this post here In this day of spreadsheets and canned financial functions though the basic calculation of all those metrics is almost too easy really just a few formulas away My belief is that metrics are hugely important for decision making but that the data that goes into calculating the metric is what matters most of all Specifically what are the assumptions What s the analysis behind the numbers Are you taking all the project factors into account Have you brainstormed through all the costs and hammered on what benefits are truly achievable The point is to get as complete a picture as possible by soberly laying out the costs and the benefits over time taking everything into account This is what I ve seen few organizations do at all and even fewer do well In fact many organizations will simply spout that we base all project selection on demonstrated ROI without actually having a rigorous process in place for ensuring that they capture all the costs and all the benefits that go into calculating that ROI A nice looking ROI number comes out of the process but the assumptions behind it aren t well thought out so it s fairly meaningless So as I discuss ROI NPV and other Should we metrics I want to deemphasize the metrics themselves and focus on what should be meticulously and methodically gathered in terms of those core assumptions Hard benefits tend to boil down to two major categories increased revenue decreased costs less personnel required hardware or software that can be decommissioned etc Similarly costs boil down to two categories One time costs cost for acquisition of software and or hardware implementation costs Recurring costs annual maintenance fees dedicated personnel needed for support etc Each of these major areas should be the topic of intense devil s advocate brainstorming with your team and with business stakeholders as appropriate What really are the prospects for additional revenue Are you perhaps fooling yourselves and being overoptimistic Is the business stakeholder willing to stand behind these estimates on the record And if you think you can reduce costs and or increase productivity would you actually be willing to have those dollars removed from your budget at a defined point once the project is implemented A dose of conservatism should reign here What really are all the costs both one time and recurring Have you thought of everything Are you counting in costs such as shipping or sales tax on equipment or software an instant 8 8 budget jolt depending on what state you re in

    Original URL path: http://www.peterkretzman.com/2008/03/19/financial-metrics-for-it-the-holy-grail-of-roi-and-how-it-misses-the-point-part-1/ (2016-04-28)
    Open archived version from archive

  • tanstaafl: An Introduction to IT Portfolio Management - CTO/CIO Perspectives
    the level of effort and time line required That approach requires a systematic examination at regular intervals of all projects in the immediate pipeline and a determination of what will get worked on and what won t Quick recipe after you ve done initial level of effort estimates for each and every project under consideration schedule a major quarterly planning session including all key stakeholders where you weigh potential projects against factory capacity the sum total of the work units that the factory can produce in the coming quarter The outcome of this meeting needs to be the approved set of projects that at least according to your estimates however flawed they may be appear achievable in that time frame and within the current capacity of your factory Then as the quarter progresses hold a high profile weekly recap the primary purpose of which is report on progress and to fend off unnecessary changes Your stakeholders will need to be educated again and again on the impact of changes to the plan it s common for these to be underestimated even by your own IT resources Above all remind your stakeholders again and again that scheduling resources and project planning is essentially a zero sum game Resources people s time allocated to one project means you need to accept the opportunity costs of not having them work on another project As economists and libertarians love to say TANSTAAFL there ain t no such thing as a free lunch Lagniappe Jeannette Cabanis Brewin Project Portfolio Management is Your Friend Bruce Miller Linking Corporate Strategy to Project Priority and Selection Jim Pennypacker and Patrick Sepate Project Portfolio Management and the Strategic Project Office Debbie Bigelow Want to Ensure Quality Think Portfolio Management Jim Pennypacker editor Project Portfolio Management Maturity A Benchmark of Current Business Practices Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Process Comments Kathleen Kostuck says May 14 2012 at 12 03 pm Peter since maintenance continues after a project is implemented do you include level of effort estimates for maintenance for each project when looking at capacity Peter Kretzman says May 20 2012 at 11 07 am Great question Kathleen and actually one that needs a whole blog post or several in response In a nutshell I m a big believer that maintenance work has to be scheduled and planned separately and with different resources wherever possible from project work It s a huge drain on a department in general to have maintenance work as always unpredictable in nature impacting project work or sometimes the other way around when project timelines get tight So it s a separate endeavor altogether to determine and then plan for the necessary additional resource load that is likely on that maintenance group once the project has been delivered But the gist of your question is quite right often that planning is completely ignored in the blithe assumption that the necessary

    Original URL path: http://www.peterkretzman.com/2007/08/13/tanstaaflan-introduction-to-it-portfolio-management/ (2016-04-28)
    Open archived version from archive

  • CTO/CIO Perspectives - Page 2 of 15 - Intensely practical tips on information technology management, by Peter Kretzman
    both sides of the argument Not interested Read more Tweet Filed Under Estimating General Industry trends Process Recommended reading Stakeholders By Peter Kretzman 5 Comments IT does the moonwalk our endless search for absolutes Tweet Scene I was CTO at a high traffic social networking site circa ten years ago It was one of those times when our site got crushed by unexpected sudden volume due to being mentioned in an article in a prominent newspaper My infrastructure manager walked into my office the next morning ashen faced We re gonna get killed tomorrow unless we add ten front end servers to our prod environment he proclaimed A fairly common IT reaction absolute adamant ominous Ten new servers That was a nice round pulled from thin air number obviously and by the time we talked through it we actually found other more practical more feasible ways first to estimate and then handle the increased load But to the infrastructure guy as he walked in the situation was both dire and absolute and he saw only one solution that should even be considered So now let s look at another data point on IT psychology Take the latest iPhone brouhaha the quick cracking of the iPhone 5s Touch ID fingerprint scanning technology Amazingly Touch ID has turned out to be less than perfect Someone with 1 000 of equipment plus lots of time motivation and patience could conceivably fool the scanner Meanwhile what gets lost in the outrage over this turn of events is the notion that the technology might indeed be good enough or better than the alternative We forget the simple fact that the technology is primarily oriented to people who currently don t use passcodes at all and that it vastly improves general security for those sorts of users As one article pointed out The point of any security system isn t to be unbreakable there s no such thing but to be fit for purpose My larger point if there s a problem or a difficulty or even a nuance to a particular approach s applicability a common IT practitioner s instant reaction is that the approach or practice is absolute junk and should be completely avoided Similarly we often reject fundamental improvements to a situation simply because they are not perfect We let best get in the way of better On this general theme an amusing tweet crossed my screen the other day rands wrote I find when an engineer says Less than ideal they often mean Complete fucking catastrophe I laughed at this of course but partly because I ve more often experienced that scenario in reverse an engineer deciding and then loudly and profanely proclaiming that a situation was nothing short of a complete disaster simply because it was less than ideal Read more Tweet Filed Under Anecdotes General Overview By Peter Kretzman 2 Comments Starting points for the quantitative CIO downloadable basic tools Tweet Much as in any field IT executives constantly have to seek a balance between idealism and pragmatism Given a particular problem and the range of possible solutions do we insist on doing it right or do we buckle down and just get it done even with gaps There s obviously no single right answer which is what makes IT consistently so fun and frustrating at the same time Over time though my own approach has typically been to focus on the continuous improvement aspect of doing it right whenever possible get something going as a start then hone it over time as you learn more about the problem and your situation Using spreadsheets as a management tool definitely falls on the just get it done side of this spectrum of approaches Spreadsheets are seductively easy omnipresent and usable by people with a variety of skill sets and technical savvy But there s a host of downsides spreadsheets are frail creatures Errors can creep in fairly easily even for experienced users as data and circumstances change and spreadsheets are especially prone to the incursion of silent errors and omissions when undergoing revision And once implemented in all their imperfection spreadsheet based solutions can broaden and become large scale long term systems I ve seen this happen again and again Yet I feel that every technology executive should be maximally fluent in spreadsheeting simple tracking analyzing modeling alternatives understanding costs and risks The technology provides a readily available easy way to knock out quick and dirty models that can clarify one s thinking and approach enormously They work well as long as you keep in mind that the spreadsheet is usually a stop gap for those times when you are faced with a glaring need and you don t have time budget or staff to implement anything deeper right away In an early blog post I listed the seven areas where a quantitative approach is especially necessary for the technology executive Read more Tweet Filed Under Financial Metrics Process Role definition Tools By Peter Kretzman Leave a Comment CMO outspending the CIO on technology so what Here s what Tweet Rarely do I write targeted responses to specific blog posts but last week a CMO related article crossed my screen that I think is both representative of many people s attitudes and enormously flawed in its assumptions logic and conclusions Esmeralda Swartz writing for ReadWrite com titularly opines the following So What If Chief Marketing Officers Outspend CIOs On Enterprise Tech Even more grandiosely the post s subtitle is Isn t it possible that a technology buying process driven by marketers instead of technologists will make things better Well I suppose I should allow that anything might be possible but no not by the unconvincing yet not atypical line of argument Swartz pursues and not when you consider standard business realities Here are a few representative quotes related to the backbone of her argument namely that buying technology is like buying a new car Let s look at an everyday example

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

  • CTO/CIO Perspectives - Page 3 of 15 - Intensely practical tips on information technology management, by Peter Kretzman
    to remember that rather than expressing categorical disagreement let alone outrage it s far more useful to look first for common ground then aim to identify the areas of contention or difference in perspective That struck me recently when I read Todd Williams BackFromRed recent blog post with the title Stop All IT Projects and recalled that another esteemed colleague Steve Romero itgEvangelist has expressed views along the same lines Todd and Steve are both smart experienced IT professionals whom I highly respect In Todd s case we ve met in person in Steve s we ve exchanged numerous emails and blog posts over recent years Both of them unquestionably get it when it comes to IT matters I generally agree with what they post or tweet they ve each written books that I recommend to others In fact I even agree with much of what Todd writes in this particular post But still with consummate respect I think these colleagues and others are picking the wrong battle when they insist so staunchly on no IT projects Here s why Read more Tweet Filed Under Pillars of Purview Process Projects Stakeholders By Peter Kretzman 2 Comments Valuable vs fun learning to love IT Asset Management Tweet My attitude is that if you push me towards something that you think is a weakness then I will turn that perceived weakness into a strength Michael Jordan As with so much in life so it goes with IT the parts that are fun aren t always valuable and the parts that are valuable aren t always fun Let s talk about a hugely valuable side of IT that isn t really much fun at all And when it s not fun that means that it s often neglected and thus turns into a great weakness IT assets hardware software systems services represent a major investment for most firms today For new economy companies in particular the cost of such resources both bringing them on board and maintaining them as corporate assets often exceeds expenditures in any area other than wages and benefits It s astonishing then that firms not to mention IT management specifically don t always embrace the ongoing hard work required to maximize the value of those expenditures and minimize the corporate risks involved All too often I see IT asset management ITAM neglected by IT executives because well it involves a discouraging amount of drudgery to do it right especially over the long haul This neglect occurs even more often when an executive succumbs to the latest faddish push for IT to focus on strategy and innovation to the detriment of fundamentals Read more Tweet Filed Under Anecdotes Book reviews Financial Process Recommended reading Vendor management By Peter Kretzman 1 Comment More timeless still relevant information technology jokes Tweet One of my most visited blog posts noted that certain IT jokes tend to come up again and again That post covered four such familiar jokes along with what I felt

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



  •