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".
  • Business impact and transparency: expressing system availability - CTO/CIO Perspectives
    total dollars for a given period but it also provided a ready way of analyzing up front the specific cost of a planned outage Using that as a tool management could much more effectively assess alternatives and opportunity costs when system interventions to address various problems were being considered Here s a snapshot of the model s inputs in yellow and its outputs slightly altered for presentation From here it s a small step to logging and tracking these total estimated costs across a given time period such as a month You should anticipate by the way that disclosure of the total dollar cost of outages will tend to invoke far more attention and commentary than the old style percentage figure ever did Transparency brings scrutiny This is a good thing Yes estimates and aggregations were necessary in coming up with these approximate costs it s just a model after all with all sorts of incorporated assumptions And the estimates will never be utterly perfect But still they ll be a far cry better at helping you express the approximate business impact of your downtime than just proudly declaring that the system was 99 83 available last month Lagniappe Publicly visible major SaaS system availability pages Amazon Web Services Salesforce OpenDNS Intuit Quickbase Clickability Google App Engine Evan L Marcus The myth of the nines September 1 2003 Continuity Central Five Nines Chasing the Dream Paul Beckford Calculating Server Uptime February 13 2010 Lenny Rachitsky Transparent Uptime blog George Ritchie Serio Ltd Introducing ITIL Availability Management Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Metrics Performance Pillars of Purview Top 25 posts Comments jfbauer says December 8 2010 at 11 31 am Another side benefit of this lost revenue based model is providing a more realistic context to the irrational business product team and subsequent IT management reaction Some readers will identify with the product owner that blasts out inflammatory emails demanding that heads need to roll in IT for the slightest blip in service The inflammatory email sends IT management into a root cause analysis frenzy followed by irrational costing proposals to avoid future blips in service that will most likely never get implemented If the outage blip cost 1 877 in lost revenue but the FTE burn to do exhaustive root cause and compose hastily proposed yet impractical solutions costs 10k not to mention the negative impact on the parallel in flight projects should this overreaction even be warranted Peter Kretzman says December 8 2010 at 8 29 pm Agreed John but I usually see it go the other way In other words when real dollars rather than an abstract and high sounding uptime percentage are attached to outages people start to PAY ATTENTION But yes part of discussing uptime for the CIO is helping to educate his or her peers on the cost of high availability redundancy etc On the positive side I ve seen the disclosure

    Original URL path: http://www.peterkretzman.com/2010/12/08/business-impact-and-transparency-expressing-system-availability/ (2016-04-28)
    Open archived version from archive

  • The title issue revisited: CTO vs. CIO - CTO/CIO Perspectives
    definition for the company and who can ensure that the day to day decisions in information technology will be made accordingly In other words companies need to recognize that business projects can fail equally through technology tunnel vision or through too little attention to core technology matters by executives who spend their time elsewhere on matters they deem more strategic In fact if there is no or the wrong kind of executive in charge of technology one sees effects such as the following technical and applications architecture tends to grow haphazardly becoming increasingly inflexible and unwieldy no metrics are gathered much less used for continuous improvement open season reigns for vendors who then deal primarily with lower level buyers who often lack the big picture financially and strategically the dev guru phenomenon appears where the company is dependent on one or two individuals and there s insufficient cross training no delivery commitments are made or commitments are made with no factual basis silos appear in Ops QA Dev PM often at cross purposes with each other Multiple points of entry into IT abound for business folks What gets worked on depends on personality not corporate exigency little process improvement is considered or exercised IT sourcing groups emerge that become sheer order takers for stakeholders who ve been swayed by a vendor demo For further examples consider the points I made in a recent post Canaries in the coal mine Why your IT department may be in worse shape than you think To avoid these and other examples of IT failure companies need to place at the helm of information technology an active savvy executive serving as a peer of the senior executives in the company and they must look to that individual for leadership guidance and day to day influence Should that person have the title of CIO or CTO That s not the right question because it doesn t matter Related posts Yes we can yes we must the ongoing case for IT Business alignment Countering a disturbing bandwagon rich vs poor IT organization s Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Role definition Top 25 posts Comments Scott Booher says August 31 2009 at 6 26 am Peter a good post thanks You correctly point out the apparent swinging of the pendulum on the title role issue My own sense is that many of the posts on this topic along with much of material on best practices tend to fall into binary either or extremes that are not in any way representative of the real world we live in Those binary headlines garner page views but not much else It s not likely that a mature CIO would show up to the Board room promoting either of these extremes rather they would judiciously calculate WHAT IS NEEDED for their company at its level of maturity considering the individuals involved customers C team where the staff is etc This is after all what the organization is paying for pragmatic leadership not blind obedience to whatever new leadership extreme is promoted in the trade rags that week Nathan Torrence says August 31 2009 at 10 50 am Interesting post It seems as though there are many CTOs CIOs who have this pendulum effect going on While there are plenty that consistently fall in one camp or the other CIO vs CTO I imagine that most find themselves trying to strike the balance you speak of but fall in to the trap of swinging from one side to the other Instead of making decisions from a balanced perspective its more moving from a period of strategy based decisions to a period of technology based decisions hi says January 1 2010 at 7 56 am Should that person have the title of CIO or CTO This is a valid question Words matter The fact that you had to revisit this issue based on observed trends is evidence I am not sure why strategy is attached to CIO The I stands for information which is transformed from data and translated to wisdom when that person does her his job well Allow me to use your words CFO a senior executive who is part of the strategic definition for the company and who can ensure that the day to day decisions in will be made accordingly CHRO a senior executive who is part of the strategic definition for the company and who can ensure that the day to day decisions in will be made accordingly COO a senior executive who is part of the strategic definition for the company and who can ensure that the day to day decisions in will be made accordingly I believe a person with balanced skill sets is key too It is key for any C level position Let s devise an acronym for the C level information technology leader to be more succinct while realizing that words culminating to clear definitions or points matter How about CITO I am serious I am not trying to be funny Peter Kretzman says January 1 2010 at 10 09 pm Thanks for the comment hi I actually think the CTO CIO is a different species of problem titling wise from the COO CFO et al The other execs you name tend to be already part of the strategic decision maker body with the frequent exception of the HR exec And no one says for example that the CFO shouldn t concern himself or herself with the specifics of the accounting system and just set financial direction for the company They expect that person to do both It seems to me that only with IT does the dichotomy seem to arise people tend to feel that the chief technology executive should be EITHER mainly strategic or purely tactical And that dichotomy that either or mentality is what I reject I personally like the CBTO title that s been proposed since it

    Original URL path: http://www.peterkretzman.com/2009/08/30/the-title-issue-revisited-cto-vs-cio/ (2016-04-28)
    Open archived version from archive

  • Can a CIO be successful without IT experience? Define your terms! - CTO/CIO Perspectives
    has built an expensive cost center based empire is finding survival difficult Business is sick of the tired old pipe dreams about ROI and payback Too often CIOs do not understand how to integrate IT operations INTO the business The successful CIO of tomorrow MUST and I mean ABSOLUTELY MUST integrate their IT organizations into and become part of the extended business operations For more info on how TOMORROW s SUCCESSFUL CIO will finally make it please see this four part series starting here What is the Proper Relationship for the CIO CEO and CFO http www r3now com what is the proper relationship for the cio ceo and cfo The bottom of that page has links and executive summaries of each of the posts Bill Wood President R3Now Consulting R3Now com SAP from the Customer Point of View Teresa Cottam says January 18 2011 at 1 01 am While I applaud your search for the essence of a great CIO I must say that often as in beauty it is subjective and in the eye of the beholder A CIO can be fantastic in one context but then unable to peform in another Three great qualities I often see in successful CIOs however are scepticism the ability to ask great questions and most importantly a sense of humour Peter Kretzman says January 18 2011 at 6 30 am Mark thanks for your excellent point on the possible varying agendas of a CIO s lieutenants vendors etc It s another great reason for rejecting the notion that all an inexperienced CIO needs is a great team In truth having a great team might mask for a while many of the ill effects caused by an inexperienced leader but sooner or later those effects will hit The leader is there for a reason arindam chattopadhyay says January 28 2011 at 11 19 pm As per me CIO has two major roles 1 Operational excellence CIO should able to deliver business requirements within schedule and budget Cost optimization and reuse of the components is must This requires IT Technical skill I think the skill to learn fast is a Must Have skill I was a very good C programmer but did not code for last 10 years On the other hand I need to learn lot about IT IS infrastructure while preparing a business case for BCP for RCOM I think my technical background helped me a lot in learning those technology 2 Second role is helping and working with business to create a proper enterprise architecture In this role CIO should help CEO and business leaders in continuous service improvements This is a role of taking a strategic initiatives and decision This is all about Risk management most efficiently CIO also need to be well connected to overcome all political hurdles CIO can come from any background S he should able to meet business requirements with less budget and quicker TTM and that requires technical understanding Machteld Meijer says December 3 2011 at 6 23 am I only found your column today I agree that definitions are very important For instance what is IT In our country it stands for software and hardware not for all of the activities a business needs to perform to be able to define what information they need to support their business I see many organizations I don t mean IT organizations but Business Governmental where the CIO is the head of the IT department Therefore the head of one of the service providers to the business I think that is not the best solution The CIO has to be part of the business organization and has to decide on which information the business really needs and how to obtain that Does he need to have a technical background No Does he have to have IT experience Not in the sense of having worked within IT Yes in the sense of having worked with IT and having participated in large IT projects from the demand side point of view Supported by more technical skilled staff I am sure he can make good decisions There it comes to the main qualification he should have being prepared to listen to more technical people not being priggish being able to handle political sensitive situations being able to handle much information being able to communicate on many levels and of course knowing very much of the business process and the business needs Peter Kretzman says December 5 2011 at 11 46 am Thanks for commenting Machteld Not sure whether you and I fully agree or disagree though Your last sentence is inarguable to my mind but I also fall more in the camp as expressed above in a comment from Chris Curran that those who haven t worked IN an IT organization don t have a good enough understanding of the business function its approaches cultural quirks levers etc There can indeed be outliers but to my mind those are extremely unusual I also reject as stated in my post the not uncommon notion that all a CIO needs is a technically skilled team As I wrote You d better be in position not to be easily swayed by a slick vendor or even a convincing pitch from one of your senior lieutenants part of your job is to know when to push back Machteld Meijer says December 6 2011 at 3 56 am Thanks for your reaction The sentence you quote from Chris Curran is a sentence I possibly don t understand correctly those who haven t worked IN an IT organization don t have a good enough understanding of the business function its approaches cultural quirks levers etc My idea is that those who have ONLY worked IN an IT organization only have a very small understanding of the business function Because this is completely contrary to your opinion and we agree on many other things maybe the cause of this apparent different point of view arises from

    Original URL path: http://www.peterkretzman.com/2011/01/16/can-a-cio-be-successful-without-it-experience-define-your-terms/ (2016-04-28)
    Open archived version from archive

  • Astounding IT sayings
    milestones or readiness criteria Instead a verbal vote On a scale of 1 to 10 with 1 being completely unready What ensued was actually what one would tend to expect of a group of middle managers in front of the new and powerful key executive with no one wanting to come across as negative Oh I think we re at a 7 the first person opined I d say an 8 piped up his neighbor We went around the table with nearly all the votes falling in the range of 6 to 9 I was among the last to speak We re at a 1 in my view completely unready and here s why I said to a chorus of gasps I explained that we actually shouldn t be voting but should instead be nailing down facts based criteria on which we d base our launch decision I pointed out that we d gotten precisely zero transactions successfully through the system end to end OK said Mr Key Exec Looks like maybe we re not ready Everyone is going to work the weekend This meeting was on a Friday We ll meet again on Monday and reexamine where we are And that we did Lots of hard work lots of late night pizza and diet Coke We gathered together in the same room around noon on Monday To my amazement this is what I heard OK let s see where we are Why don t we go around the table again and everyone give me your impression of our launch readiness on a scale of 1 to 10 And that s what we did Oh I m up to a 9 now We really made progress this weekend I m at an 8 but I was at a 6 on Friday And round and round When it came to me I again quietly restated my 1 pointing out that despite hard work and progress we had yet to see a single successful transaction I said that judging from experience and based on where we were at this point my prediction was that we wouldn t really be ready to launch for another three months The website launched about three months later The key takeaway should be obvious no matter what the pressures don t ever base a major operations decision on a vote where such voting would serve to substitute for a sober evaluation of facts based criteria Launch readiness is way too important to leave up to pure gut instinct and mass optimism Create your metrics and your criteria up front collect them and look at what they tell you Then act accordingly That way you ll end up with results rather than astounding sayings Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Anecdotes Personal Top 25 posts Comments Rick S says May 7 2008 at 2 43 pm Amusing stories Thanks for both the entertainment and the moral

    Original URL path: http://www.peterkretzman.com/2008/05/05/astounding-it-sayings-the-inaugural-post/ (2016-04-28)
    Open archived version from archive

  • Complexity isn’t simple: multiple causes of IT failure - CTO/CIO Perspectives
    on this Paula As I wrote on that other blog I m afraid that this line of thinking is so far outside the mainstream of what the IEEE calls generally accepted knowledge so utterly extreme that it just can t be taken seriously and no one should spend a lot of cycles trying to refute it That s blunt and harsh but it s accurate David I believe you commented on that thread as well To my mind requirements gathering understanding is simply a critical success factor In fact projects that tend to fail are often projects that haven t bothered with or have shortcut the requirements phase I don t think this is the best place to debate this very non mainstream stance of yours Paula I d suggest you blog about it at greater length and let us know Jon H Ayre The Enterprising Architect says November 19 2009 at 6 41 am A couple of additions 1 I do not feel my position is lacking in compassion There is nothing compassionate about keeping someone in an activity that they are ill suited to and find stressful and unrewarding The true leader will examine the strength of those who are failing in their current role help them to find their true calling and assist them in making the transition It is also compassionate to those who are good at something to free them from the stress and anxiety created by those who negate their good work and make their daily lives a misery rather than a joy Compassion requires action not inaction and it requires inventive thinking not blind observance of the status quo 2 Regarding the requirements issue No amount of extra work on requirements up front will overcome bad implementation Try handing detailed requirements for the redecorating of your lounge to a group of five year olds and see if the added detail improves the result extreme analogy I know but I feel it illustrates the spirit of the problem Regarding Paula s position I would say that development of requirements as a standalone pre design pre implementation activity is unfair on those of whom you are demanding the detailed requirements A more holistic approach that embraces prototyping refactoring and direct involvement in the process from start to finish will allow the requirements to evolve over time in a controlled way without the label of scope creep being attached to this Scope is a different thing to requirements and this needs to be recognised Regards The Enterprising Architect David W Wright says November 19 2009 at 8 53 am Peter thanks for the reminder Back to this topic how do we get the leadership that is needed I don t want to besmirch anyone but management tends to respond and act based on how they are measured and rewarded How do we make it worth their while Rotkapchen says November 19 2009 at 2 14 pm Pay attention to what Jon said Requirements are relevant when you re actually ENGINEERING something Software is not engineering except when it s controlling the launch of the space shuttle or when it s part of firmware The bottom line here is that businesses need to adapt constantly The methods that presume that there are things called requirements that can be locked down for releases is the stuff of denial Yes you can create some next to meaningless elements for the sake of being able to do testing don t get me started on that arcane practice but only for technical purposes Testers should have no say over or test for any UI function that s all part of UX and usability and is specified by design criteria not requirements Peter Kretzman says November 19 2009 at 6 10 pm Again Paula this really isn t a good place to argue against well accepted tenets of IT project management such as requirements gathering and testing You re certainly entitled to hold your views but I d suggest with all due respect that you recognize that they re quite unusual and far out of the mainstream of acceptance The burden of proof argument is very much on you therefore As such blog comments aren t a suitable venue to casually drop what come across as lofty ex cathedra dismissals of these fundamental approaches providing no backup I suggest again that you write a lengthy and well researched blog post on your views which I ll be happy to read Meanwhile let s stop throwing around phrases like stuff of denial and meaningless about approaches that nearly all IT practitioners embrace as necessary and beneficial Peter Kretzman says November 19 2009 at 6 31 pm Well David there s no quick easy answer to that question because it requires enlightenment on the part of people who hire and incent that management all the way up the chain I m doing my best here on this blog to discuss at length the reasons why leadership needs to focus on certain things over others and to point out the ramifications when they don t Otherwise I expect change and learning in this arena to take place slowly I ve witnessed more than my share of CEOs who fail at one company yet pop up with the same approach do it all now at their next company Rotkapchen says November 19 2009 at 9 23 pm well accepted tenets of IT project management such as requirements gathering and testing I thought the topic here was failure THESE ARE THE REASONS FOR THE FAILURE Roger Sessions says November 20 2009 at 6 49 am I disagree with Jon that the basic problem is staff mediocrity I do believe that there is a problem with staff motivation but this is another side effect of complexity Systems with high complexity are characterized by convoluted relationships When systems have convoluted relationships it is hard to make changes since each change has global ramifications that are difficult to predict This is highly frustrating and demotivating to a creative soul who sees new ideas and wants to implement them but can t because of the fragility of the system Simple systems in contrast are characterized by high degrees of autonomy This means that local changes do not percolate out to the larger system and because of this it is much easier to incorporate new ideas For the creative soul this is highly motivating probably even more motivating that traditional motivators such as money and recognition Mark points out there is a lot of pressure to estimate project completion times I point out that any estimate is only as good as the input data If the input data has a lot of uncertainty any estimates based on that data will have low accuracy The uncertainty of cost estimation data is highly dependent on the complexity of the system being estimated The higher the complexity of the system the higher the uncertainty of the cost estimation data and the lower the value of the estimate The best way to do quality cost estimates on a large complex system is to first go through the simplification process to break the system apart into small simple systems and then do the cost estimates on those small simple systems Paula doesn t like requirements I actually agree with her in a way One s ability to confidently gather requirements is highly dependent on the complexity of the system for which you are gathering those requirements Once a system reaches a certain level of complexity say more than a few 100K the confidence level in the requirements drops dramatically The answer to Paula s concerns is not to eliminate requirements gathering which I m not sure she is suggesting It is to first deal with the complexity of the system by breaking it into small simple systems and then going through a formal requirements gathering on those smaller simple systems Now it is not at all unusual when doing requirements gathering on those smaller simple systems that you will find that some of the partitioning of the original large complex system into smaller simple systems needs to be adjusted That s okay The whole process should be iterative anyway Since I have used the word simple a number of times in this discussion let me define the word as I use it A system S that solves a problem P is simple if and only if it is the least complex system possible that solves P So simple does not mean that a system S has no complexity only that it has the minimum complexity necessary to do its job To look at simple another way every problem P has a set of possible solutions s1 s2 s3 For non trivial problems the set is very large Each element in the set has a complexity measure The simple solution is the element in the set with the lowest complexity measure Thanks Peter for hosting this discussion Roger Sessions says November 20 2009 at 9 32 am Now that I have looked in more detail at Paula s ideas on requirements gathering I think I better understand what she is saying I believe she is saying that requirements gathering can only tell you what people think they want And the best systems are those that redefine what people want A good example is Twitter Had that group done any kind of formal requirements gathering it is hard to know what they would have developed but it certainly wouldn t have been anything close to Twitter And almost certainly wouldn t have been anyplace near as successful Twitter is evolving not by gathering new requirements on what people think Twitter should do but by watching how people actually use Twitter and then adapting Twitter to those uses Paula is this getting at what you are saying I can t resist pointing out that one of the reasons Twitter is so successful is its simplicity It has clearly carved out a small piece of functionality a subset of the partition in SIP terminology and does that functionality well Very similar to Google David W Wright says November 20 2009 at 10 56 am Roger good requirements practice includes defining scope and then decomposing it as needed to processes and activities at a level where requirements can be elicited This indeed helps in reducing something big and complex to many smaller understandable components The question becomes does doing this lead to less complex designs that support useful but manageable amounts of functionality My experience is yes but that would still be anecdotal I am sure it is possible to take good requirements and still produce complex designs and un factored code but I would like to think it would less likely to happen I am thinking this could be a spin off topic for some investigation what do working designers developers want from Requirements that helps them design less complex and more effective systems If anyone can suggest a good meeting place or portal for developers I would appreciate There are many so some suggestions would help A side bar the Twitter example I freely admit that what I do in Requirements work is aimed delivering information systems for business govt or non profit organizations That presents a wide range of numerous opportunities but it does leave out things like real time systems for guided missiles or video games or disruptive technologies like a Twitter or Facebook Now information systems have seen new and unforseen developments over the decades like DBMS online systems to new stuff like BPMN and BRMS even the Web could be see seen as resulting from the initial military and research need for distributed but connected resources But some things will still come from bright ideas and unexpected convergences of people and resources no doubt What IS can do is normalize or standardize some of this so the bright minds can move on to the next big thing If I can t be as creative as others my spouse is always saying how come you couldn t invent that then I can be useful Or as Red Green says If you can t be handsome be handy Rotkapchen says November 20 2009 at 2 42 pm Roger Thanks for helping clarify something that has so much to it that a discussion like this can hardly do it justice You ve clarified a couple of critical angles both of your posts are extremely relevant There are many others 1 We have to consider the continuity of this stuff We tend to treat mainly because of funding such efforts as 1 offs and do not create persistent artifacts and architectures that puts what s being done into a larger context artifacts noted here http www fastforwardblog com 2008 07 07 transparent and explicit Every initiative starts from scratch There is no shared learning 2 Design Thinking helps us to see that we start with leveraging some of these artifacts as a means by which to challenge assumptions there are often many critical and fundamental assumptions that have been held for so long in companies that everyone believes that they re true Bringing these assumptions out to be challenged is critical the visual artifacts and discussions around them help And as we uncover facts to challenge assumptions we need to create a persistent sharable collection of these findings for a continuous business context to inform new efforts http www fastforwardblog com 2009 07 31 the context of intent 3 The whole argument of requirements testing having been long established is of no consequence when it becomes clear that they help cement reliability but do nothing to balance it with validity http www fastforwardblog com 2009 08 07 reliability vs validity Yes if we re building rockets reliability is of greater significance but most of what s happening in business today requires a greater focus on validity which is where the challenge of assumptions becomes so critical The current methods and models are still on a path to lock down reliability This is fundamentally flawed for most of the business problems we are addressing today as Roger noted not to say that there aren t scenarios that still require it 4 The SDLC is fundamentally flawed The design phase is a sub design phase There s a larger architectural design that should feed individual initiatives similar to the model engaged by commercial construction Individual projects should be trades responding to a general contractor as part of a larger initiative with defined blueprints and specifications http www fastforwardblog com 2007 09 20 crossing the chasm Any requirements that the sub contractor want to provide are for their own purpose of fulfilling their response to the larger initiative the business at large IT fails at understanding true architecture They even behave as sub contractors seeing only their piece of the overall construction effort e g landscaping is the center of the project and everything else revolves around it Peter Kretzman says November 20 2009 at 5 17 pm It s possible I suppose that we re not fundamentally in disagreement about requirements since Design Research per Paula s link of http www peachpit com articles printerfriendly aspx p 1389669 to me sounds an awful lot like what I call requirements gathering Perhaps my quarrel is with disrespectful and dismissive tone as much as anything requirements gathering doesn t work stuff of denial etc But that s my point I m a practical CIO I ve gone in both as an employee and as a consultant to quite a few turnaround situations IT departments and projects in serious crisis and I can attest that the number one thing I hear from the business stakeholders about the delivery to date is they IT don t even ask us what we need And then they just give us something that doesn t do what we need it to We all know that a key IT focus over the last decade has been the need for increased business IT alignment There s room for lots of disagreement on the hows and whats involved there but the answer is simply not we ll figure out what you need and give it to you Trust us If any one attitude approach is a veritable recipe for IT failure it d be that In short it s lofty arrogant and usually plain dead WRONG to say we ll redefine what you want On the other hand you can work with stakeholders to achieve a mutual redefinition of what s needed That astonishingly is called requirements gathering as David pointed out Of course you can point at examples where a unilateral redefinition approach has worked although I don t think Twitter is a particularly good one with its issues in every conceivable area performance UI design functionality business model Apple iPod iPhone is perhaps a better thing to point to But mainstream business systems Seldom But I think we ve been sidetracked as this is a fringe issue as I ve stated above Roger your reply earlier that related directly to my post has again focused on architecture application partitioning etc as if that s perhaps not the only thing but certainly the main thing in your eyes when it comes to complexity My blog post argued that it s not Do you continue to disagree I was hoping I suppose to have moved the needle Rotkapchen says November 20 2009 at 5 33 pm Peter I d agree with you except for one basic fact for over 30 years in company after company I cannnot work with the requirements people at all They refuse to budge in their close minded approach to what they re doing And they refuse to admit that there s a possibility that there are other ways to approach their discipline Roger Sessions says November 20 2009 at 6 04 pm Sorry Peter I didn t

    Original URL path: http://www.peterkretzman.com/2009/11/16/complexity-isn%e2%80%99t-simple-multiple-causes-of-it-failure/ (2016-04-28)
    Open archived version from archive

  • Career tips for the CTO/CIO path - CTO/CIO Perspectives
    out how other people have filled their own similar gaps Find someone Ask for advice feedback tips on next steps Get religion So to speak of course Absorb the basic truth that IT itself needs to be the main service oriented architecture metaphorically speaking That s service in a business sense to the rest of the organization This obvious and incontrovertible fact seems to be lost on at least half of the IT people I ve known Get involved in customer related and business related projects Interface with internal users in formal and informal ways Get to know their concerns their problems their way of looking at things Get savvy financially A long time ago I read a magnificent slim volume now sadly out of print called Understanding a Company s Finances A Graphic Approach by W R Purcell and received a college course s equivalent of an education in finance If you also have gaps in this area find the equivalent see below for some ideas and study up Follow your company s communications on financial results read the annual reports and regular SEC filings Get the word out Communication as an ingrained ethic is one of the largest gaps quite typically in IT and you ll need to get good and frequent at it Always be publishable I learned this marvelous apothegm from someone who worked for me By this he meant always have readily at hand the basic elements as in the Five Pillars actually that show how things are going so that you could for example generate a status report at the drop of a hat Get altruistic Focus on your own people s career growth It ll come back around Thinking about others benefits you Keep up technically It s a fire hose out there trained at your eyeball Pick and choose the key technologies and get more than a dilettante s familiarity with them Yes I realize that this seems to contradict the get away point above Live with it Part of ascending to the CIO CTO role will entail exactly that kind of ambiguity in your life Lagniappe Tom Peters strategies for pursuing good luck Note that I don t necessarily agree with many of these but they re definitely worth a read Managing by the Numbers A Commonsense Guide to Understanding and Using Your Company s Financials An Essential Resource for Growing Businesses Financial Intelligence A Manager s Guide to Knowing What the Numbers Really Mean Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under People Role definition Top 25 posts 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 to this post please write this code along with your comment b744397c8d4803098aa6e5604990fa32 Contact information

    Original URL path: http://www.peterkretzman.com/2007/10/02/career-tips-for-the-ctocio-path/ (2016-04-28)
    Open archived version from archive

  • One CIO’s “lessons learned” in managing others - CTO/CIO Perspectives
    solely for three basic things to set the fundamental direction to allocate resources appropriately and to make the tough decisions that others won t or can t People are looking to you to do those specific things reliably and well Don t let them down Give people a lot of rope whenever you can Particularly when they have passion and excitement Find ways to say yes to their approaches and initiative to every reasonable degree Embrace and exemplify continuous improvement as a philosophy and approach to all things Celebrate successes Guide people past their failures and make those into positive learning experiences as much as you can This one sounds easy but was among the hardest for me to absorb Managing upwards and sideways peers CEO board is every bit as important as managing your team But it s not an either or Depending on the circumstances there will be times when you focus more on one than the other both are equally deserving of your energy Admit your mistakes Don t stonewall or rewrite history about them Speak positively of your team members of peers of management of vendors When you don t people notice and they extrapolate Did this list strike any nerve Did any specific examples come to mind where you ve seen executives or other managers fall down on some of these items I thought so The list could easily be longer of course and I look forward to the comments that will almost certainly mention a few areas I ve neglected to cover Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Anecdotes People Personal Pillars of Purview Role definition Top 25 posts Comments Vicki Mains says November 18 2010 at 6 35 am I whole heartedly agree wih you I believe it is all about respect in all directions This is something that is earned not just given And finally laugh now and then Give the team opportunities to share a laugh now and then and celebrate their accomplishments It is so fast paced every now and then it is good to acknowledge what has been accomplished recently Chris P Intel says November 19 2010 at 12 17 pm Great article Even Better Advice I love how common sense prevails in these matters Exceptional Leadership seems to alway go back to basics Back to Basics was a core theme emphasized by Intel s CIO at our IT Leaders Conference this past January Chris Sridhar says November 24 2010 at 8 40 am Peter This list is a fine distillation of the art of leadership Items 2 4 and 5 are where the great leaders separate themselves from the good ones Once you reach a certain position there should not be any insecurity in you having that forces you unconsciously to do things that leaves a trust debt with your team Value adding is one of the most insidious things that happen to every leader which

    Original URL path: http://www.peterkretzman.com/2010/11/17/one-cio%e2%80%99s-%e2%80%9clessons-learned%e2%80%9d-in-managing-others/ (2016-04-28)
    Open archived version from archive

  • Nuts: the biggest trap of all for IT stakeholders - CTO/CIO Perspectives
    of saying Too often despite having gotten this careful full disclosure approach in advance I ve seen executives panic about a third of the way into a major project simply because the project was costing so much in time and treasure even though those costs were actually completely in line with the planned expenses To be fair this kind of chronic Boy and the Nuts behavior at such companies often isn t limited to dealing with IT matters it usually ripples into product development sales office expansion splintered and ultimately wasteful marketing initiatives and other areas It s well meant of course with the idea being to do as much as possible and get big fast as the mantra of the Internet once had it Well we all need to be a voice not so much for get big fast but for get realistic soon Otherwise we ll all go well NUTS Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Process Stakeholders Top 25 posts Comments Steve Romero IT Governance Evangelist says November 3 2009 at 11 09 am Awesome post Peter Project and Portfolio Management PPM is the KEY to grabbing just the right amount of nuts Steve Romero IT Governance Evangelist http community ca com blogs theitgovernanceevangelist Mark W Schumann says November 3 2009 at 11 43 am The seductive thing about quoting software projects is that software is infintely malleable and it takes practically no time to go from blueprint source code to finished product deliverable So the question of how long will it take to develop feature X feels like very nearly the same thing as how fast can you figure out problem X Since software developers are selected and self selected for problem solving skills and confidence in same it is so so so easy to give a Yes We Can kind of answer no matter the size of the request In fields where you manipulate physical things in which delays are built in not so much So first you ve got I T Development with its built in optimism Then you ve got Management looking for some way to condense the time and money required to achieve corporate goals and every other department is up against hard limits personnel shipping time regulations the tax calendar whatever And Development s got nothing but soft limits so that s what gets pushed It s not surprising that the software people get overscheduled Mark W Schumann says November 4 2009 at 10 35 am Peter I thought a little more about the too many nuts problem recast it as the single nut too big problem from the developers point of view and blogged about it this morning at http blog criticalresults com 2009 11 04 optimism death march Thanks for the prompt Peter Kretzman says November 4 2009 at 3 27 pm Yes your blog post is excellent The amusing part that came to mind as I

    Original URL path: http://www.peterkretzman.com/2008/04/28/nuts-the-biggest-trap-of-them-all/ (2016-04-28)
    Open archived version from archive