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".
  • Vendor management Archives - CTO/CIO Perspectives
    sometimes lead a shop away from that and into tightly coupled handoffs because those seem faster and easier You don t have the time to do it right so you end up using a lot of time doing it over My argument is that just as it is with object oriented architectures it s worth slightly less efficiency in the small if certain sacrifices in the hand off arena can help you attain efficiency in the large As I wrote in my previous post referring to the constant business driven pressure to put eight pounds of manure into a five pound bag when it comes to delivering technology projects The main insight here is that finding a viable way to outsource some projects is your ticket to expanding the bag I m not even talking about offshoring here simply about being able to take a chunk of your project load and hand it to an outside entity to get done If everything could be done that way then you d be constrained in your project load only by available money Sadly in many shops almost nothing can be done that way due to too much interdependency of systems too much background lore required and no processes in place to allow for external entities delivering changes into current production environments My position here is that it s a key part of your job to change that situation to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively Read more Tweet Filed Under General Projects Vendor management By Peter Kretzman 4 Comments Offshore development aim for it even if you never go there Tweet As I wrote last time a large part of my reason for opposing offshoring is because I ve rarely if ever worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option Let s go into that in more detail now I ve observed before that managing the incoming flow of projects is often reminiscent of trying to stuff eight pounds of manure into a five pound bag In other words you have more to do than you could ever get done You will constantly be challenged and should be challenging yourself to find ways out of that dilemma either how can you become a better stuffer so to speak or how can you expand the size of the bag itself I assume that you re doing everything you can to maximize the effective allocation of your resources so that you are more efficiently stuffing the bag So what about increasing the size of the bag Well additional internal headcount is usually hard to come by and it also takes a fair amount of management overhead to scale a department prudently The push is usually for short term delivery of a project increasing your own headcount can work in the long run but almost

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

  • Simple, more practical approaches to actual resource allocation - CTO/CIO Perspectives
    as installed packages On a larger scale becomes a huge business change management project to implement Large packages CA s Clarity Changepoint etc PPM Pros enterprise class high level of functionality and integration Cons high implementation cost in dollars time and resource commitment up front and ongoing Here s an example of an approximating spreadsheet where resources are roughly allocated day by day to any of nine simultaneous projects numbered 1 9 and each color coded Note that this is a quick and dirty planning working document meant to do coarse allocation planning at the start of a month with actual assignments and microadjustments made as the month progresses Its principal advantage beside pure simplicity is that it quickly forces the planners to confront the ever present NUTS problem where there are too many projects underway at once for the available resources I ve had great success with the approximating spreadsheet approach in a bang for the buck sense in smaller less than 100 people in IT organizations Once you wrap your brain around it being just an approximation tool it gets you 80 90 of the way there without having to devote a large portion of your staff s time to the constant and intense administrivia often necessitated by one of the bigger project management packages The example spreadsheet itself is available to download for free in a link in the Lagniappe section at the end of this post But those packages do have their place In short though here s the key ongoing challenge for project management software adopters and of course vendors how do you obtain the necessary functionality across the vast spectrum of functionality without turning everyone into a project data entry monkey Your project management software needs to be a tool not a torture device not a time sink My argument is that your key goal in a cross project sense is to roughly allocate your resources so that you avoid major contention and or taking on too much And you want to focus on this with the minimum amount of overhead you can because at an extreme it will suck up virtually all your time So I m hardly arguing for seat of the pants resource allocation but I also tend to shy away from the Unified Field Theory approaches as well I ve been there and I ve seen them consume organizations Lagniappe Added as of December 2015 Tomac Emily Sue and Govani Grishma Top 10 Project Management Software Wikipedia C omparison of project management software Gartner Group Magic Quadrant for IT Project and Portfolio Management Wikipedia Project Management Wikipedia Program Management Wikipedia Project Portfolio Management SearchCIO PPM From Efficiency to Enlightenment Downloadable sample allocation spreadsheet shown above Resource Planning Tool EXAMPLE V2 2 by Peter Kretzman Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Projects Tools Top 25 posts Tagged With approximating balance complexity PPM program management project management simple Comments Kris Kelso says February 17 2010 at 7 08 am Good article Peter I think one of the biggest hurdles is that highly technical people have a difficult time accepting a system of loose estimates and always want to drive towards more precision and perfection Even for the people who can learn to view less than 100 accuracy as acceptable they each draw the line of necessary accuracy at a slightly different point and end up arguing about how complex the approximating spreadsheet needs to be The debate itself becomes an ongoing resource drain Senior leaders don t like to get into resource management they want to leave that to their managers But I believe that in order for this to work a senior leader CIO must at a minimum define and articulate the level of accuracy he she expects so that the directors and managers who implement and manage the system can get on the same page about what the goals are jfbauer says February 17 2010 at 7 49 am Another great post Having worked both in large 2000 person IT shops and small 20 person IT shops I can safely say I ve seen a gamut of project management approaches PMO office lead enterprise deployments of large packages never seemed to get past time entry yielding financials and high level run rates but no practical use by project managers and leads Thus PMs and PLs were forced to come up with their own tactical solutions which differed and weren t easy to mash together to see any real cross project resource views Honestly and I ve commented as such in my blog posts in the past here using your approximating spreadsheet was the most effective way to do light weight capacity planning that had tremendous buy in and support from the next level of management due to its simple uncomplicated analysis representation Steve Romero IT Governance Evangelist says February 17 2010 at 8 47 am Great post Peter I am glad you are tackling the machinations of this key challenge because frankly it gives me a headache And I think this headache aspect contributes greatly to the thirst for the silver bullet you rightfully state does not exist I suggest organizations should first have an acute understanding of the decisions they are making and then determine the data required to ensure the decision is reasoned and rationale This decision mapping exercise helps illuminate which of the many alternatives you identify is best suited to fulfill providing said data to said decision makers The only other thing I will add is in regard to your Large Package cons The high implementation costs can be significantly reduced if the enterprise goes the SaaS route in those instance when it is offered such as Clarity Steve Romero IT Governance Evangelist http community ca com blogs theitgovernanceevangelist Roger Sessions says February 17 2010 at 8 59 am Great post as always And as always I disagree on a few of your points The first is not a point you make but one that people might easily misinterpret from your post Anyone ever tell you that a simpler approach can often work better than a more complex one Whoever it was it probably wasn t a project management software vendor I totally agree that a simpler approach will rarely work better than a more complex approach but an approach focusing on the simplicity of the end product will almost always deliver a better product than one that ignores the complexity of the end product So I agree that we shouldn t be looking for simple methodologies But we should be looking for simple deliveries The other point on which I disagree is Project management is relatively easy in other words The hard part is PROJECTS management I understand what you are saying here but let me express my concern I believe that a substantial overall simplification in a system occurs when you break down a single monolithic project into a number of smaller autonomous projects Doing so creates numerous projects from one project Your statement will lead some to believe that you have increased the overall project complexity in doing this In fact if you do a good job if I may be so bold to suggest if you follow my guidelines for doing this then you will end up with N projects to manage each of which is much less complex than 1 N Even when throwing in the extra overhead for the coordination management you still end up with a large savings in overall management complexity Let s say for example that the original single project had 100 000 Standard Complexity Units SCUs If you do a good job of splitting this up into five smaller projects it is likely that none of the smaller projects will exceed 10 000 SCUs Adding them together gives 50 000 SCUS Throw in another 10 000 SCUs for the project coordination still only brings the project up to 60 000 SCUs yielding an overall savings of 40 000 SCUs Since SCU s I believe translate directly to cost and chance of success you have also reduced the overall project cost by 40 and increased the chances of success by almost 60 So it isn t that I disagree with anything you say more than I caution readers in extrapolating from what you have said Thanks Roger Sessions Peter Kretzman says February 17 2010 at 9 33 am Thanks for commenting Roger I think my post caused some misunderstanding in an attempt to clear this up I added a sentence at the end of my first paragraph making it clear that the post actually argues FOR a simpler approach than the Unified Field Theory embrace all approach of the larger project management PPM software packages And nowhere did I intend to imply that I specifically advocated breaking down a single monolithic project into smaller ones in an effort to simplify and I definitely didn t argue that doing that sort of breakdown actually makes things more complex I think that your strong involvement and outstanding work on this kind of issue may have influenced your reading of my point here Rather I m saying that multiple projects are just a reality in today s IT world and allocating resources across those projects avoiding contention skirting the danger of overcommitment etc is a thorny problem no matter how you slice it Peter Kretzman says February 18 2010 at 9 38 am Thanks John The blog post of yours that you reference above was a good one I would point out though that I distinguish between general capacity planning also done in an approximating style and then actual resource allocation which is more granular The first was covered in my post on The Practical CIO Difficulties in project prioritization selection part 2 There you re just trying to get a general idea if all the envisioned projects can fit roughly within the factory capacity you have available Here in this post I dive into ways to actually allocate the resources again with an approximating approach but more granular than the capacity planning model The more formal PM packages will push you even further down into granularity 20 of Bob s time on project A 80 on project B etc and my point is that this is often meaningless precision and or changes so often as to make the estimation process a serious time sink Peter Kretzman says February 18 2010 at 9 14 am Thanks for commenting Steve Yes all other things being equal the SaaS route is looking better and better lately That said my other main point is that the approach itself the Unified Field Theory is costly and time consuming in and of itself and requires a good deal of organizational change management and commitment The mapping exercise you suggest is one way of eliciting confirming that commitment which of course needs to be ongoing Peter Kretzman says February 18 2010 at 9 16 am VERY perceptive comment Kris Yes that debate about how complex the approximation needs to be can be a drain And it s the leadership of the CIO that needs to set the standard and expectations for it Pankaj says February 22 2010 at 1 30 am Great article Peter Web 2 0 tools could fill the gap of simple yet robust tools for project management They re part of the shifting paradigm where software is designed for end users rather than IT Change management shouldn t be a very big issue at least in small companies since adoption is usually bottom up needs of local teams driving adoption rather than a top down corporate initiative An approximation spreadsheet has the downside it mainly only a project manager s tool with no inputs from the team Peter Kretzman says February 22 2010 at 7 30 am I don t think the nature of the tool SaaS or otherwise has much to do with the inherent complexity involved in a multi department rollout of a PPM package I ve witnessed clients struggle with exactly that despite their platform being a Web 2 0 tool Not only was the tool less user friendly than it could be although certainly better than some traditional packages but all the typical problems communication acceptance custom tweaks etc reared their heads A tool or approach that works acceptably in a bottom up mode doesn t necessarily scale to a larger top down view otherwise people could simply use MS Project on their own and everything would be fine The whole point is cross project resource allocation and simplicity There s actually nothing about an approximating spreadsheet which says you get no input from the team In fact it s critical that team members participate in the resource allocation not just a single manager It s a top down approximating upfront approach meaning it requires close knowledge of what people both are currently working on and what they need to work on Thanks for commenting Ron Rosenhead says February 25 2010 at 6 41 am Good post Peter I have long since argued for pragmatic project management and I like this approach It gets people going and you can amend it as you go along Incidentally I think project management is relatively easy especially with your suggestion however it s the people that make it more difficult Ron Rosenhead Ajay says March 5 2010 at 3 01 pm Good post Peter My PPM experience is mirrors some of the ones you have mentioned in the article As interesting issue I once faced with a client was that the PMO director of a 100 person shop would not consider a spreadsheet based solution lest the CxOs think that the PMO is not serious about PPM They went ahead and spent the money to get a more robust solution with training et al go figure As usual sometimes the people aspect triumphs rational thinking Peter Kretzman says March 5 2010 at 5 18 pm Yes I ve seen this kind of tunnel vision as well And of course it s the people aspect of implementing PPM that s the hard part no matter what level of tool you use I ve chosen to put the time and effort behind evangelizing the need for PPM as an approach rather than touting the advantages that a specific tool will bring Cynthia West says September 30 2010 at 6 34 am Great article Peter I am always telling my customers and prospective customers that purchasing a software solution alone will not work The team must have people process and product By people I mean leadership of the management team You can t simply buy a product or solution and throw it out there without good leadership which includes a thoughtful communication plan etc By process of course I mean deciding how you will use the software In our case there are multiple ways of performing functions so it s a good idea to have your process written down and explained to all By product you must have the right tool for the job Buying a high end system when your team has a CMM ranking of 1 won t be a good fit Thanks for providing rational advice Pankaj Kumar says October 12 2010 at 2 23 pm Hi Peter Nice article I was looking for a Allocation approach Vs Assignment approach and came across this article I am evaluating whether I should just care about overall allocation at project level and loosely coupled resources so that then can use their effort for more than one task or should tightly coupled them with the task project is large and needs around 200 resources The trade off for first approach is I need to let go individual allocation and forcasting If I will stick with tightly coupled then I need to allocate 200 resources for task that they might not be working sometimes also I am trying to figure out if I can use simple allocation method Peter Kretzman says October 12 2010 at 8 32 pm Thanks for the question Pankaj I think this largely depends on your organization and the answer also depends based on whether you re talking about task level allocation or project level allocation With 200 resources coupling them tightly to a project can seem limiting but I ve also seen that reduce dependencies that are otherwise too hard to assess and juggle I ve generally seen at a TASK level that it s important to have a resource assigned and dedicated to just one task at a time read no more than one per day if at all possible assuming that the tasks are not too granularly defined My other point is that someone somewhere does need to be assigning each resource their tasks at that level no matter what you re doing at a higher level in terms of resource allocation My article basically came down on the side of using simple allocation whenever possible rather than getting tied up in contorted knots trying to split and juggle resources in other words be able to know that you ll have THIS resource working on THIS task for THIS day Again if the tasks are appropriately defined and meaty that shouldn t involve too much not working sometimes which of course is always a valid concern jacopo says May 12 2011 at 12 28 am Great post very inspiring now I am not looking for a free meal but I am just not a XLS guru Would you be able to suggest where to look for if we want to try a spreadsheet likes yours is there any template available around thank you Peter Kretzman says May 13 2011 at 5 12 am Well as my post said using a spreadsheet to do simple squint across your thumb resource allocation will definitely require someone

    Original URL path: http://www.peterkretzman.com/2010/02/16/simple-more-practical-approaches-to-actual-resource-allocation/ (2016-04-28)
    Open archived version from archive

  • "No IT projects"? A practical take
    re going to the well too often The metaphors may be running away from me here like bulls in Pamplona but my point is that business involvement can t be molded into a one size fits all approach For me No IT projects is fine when it serves to underscore how all projects need to have business value firmly in mind But overemphasizing the slogan swings the pendulum back too far the other way The slogan s main genesis seems to be the perceived ongoing need to fight an old battle worrying about techies run amok in other words that may indeed still be lingering around the edges of our industry but on which there is little real disagreement Yet when it becomes a constant battle cry with its usual accompanying assertion that business people must drive all projects it dismisses basic business realities about the reluctance and ability of non IT business folks to engage in many IT intensive projects at a level of detail that is akin to mixing oil and water Ask the business they ll typically tell you they want some things just handled correctly and swiftly without them always needing to be deeply involved throughout It makes a lot more sense to go for targeted effective participation in selected projects than to insist on it across the board In other words the practical view is that IT needs to both know its place and yet set the pace for the company in IT related areas instead of reflexively pushing for direct business participation in all areas This practical view recognizes and accepts that IT has a twofold deep responsibility and obligation generally doing the right business focused thing no arbitrary hallway robots in other words for a business constituency that has its own full time areas of intense focus and making sure to get the right kind of help and buy in from that constituency when it matters most In the end I believe that my colleagues Todd and Steve probably know all this We simply choose to emphasize different aspects for them it s about always getting the necessary business buy in and participation above all Steve for example argues forcefully and cogently and quite correctly for how important it is for business to step up to its fundamental obligation to spearhead IT governance All three of us would doubtlessly and easily agree that as Todd writes the project s goal is value value which comes from delivering a product that meets the customer s needs So back to my comparison with current events flatly put silly season shouldn t apply here Even though I disagree with them on this one issue I m confident that neither Todd nor Steve will now assume in any way that I ve therefore thrown in my lot with what Todd called the whims and desires of the techno bigots Indeed I think we all value the same basic world of IT business collaboration with the same fundamental goals but merely through different lenses and perspectives And there s nothing silly about that Lagniappe Mark McDonald There are no IT projects only business projects July 17 2011 Mark McDonald Managing the returns on non business projects July 16 2009 Bob Lewis Bad news for traditional techies There are no IT projects July 6 2011 Project Pre Check There are no IT Projects September 7 2011 Colin Beveridge Biggest IT Myth of all time Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Process Projects Stakeholders Comments Charles Betz says August 16 2012 at 6 32 pm Amen Peter A project to implement a large scale VMWare farm capable of replacing 500 obsolete servers is an IT project Of course it is also a business project and should be held accountable for ROI execution but it is markedly different from a new CRM system deployment The latter requires ongoing participation of business thought leadership The former not so much Charlie Gene Hughson says August 16 2012 at 6 35 pm Great article While hyperbole can be memorable ultimately it smacks of salesmanship A sober balanced approach will inspire more confidence in the long run Involving business units in dial tone projects apart from the budgeting process will likely only lead to annoyance As you say pick your battles and save your demands on their time for those things that directly impact the business Roger Sessions says August 16 2012 at 6 43 pm I think you raise some valid issues The way IT is done today there are certainly going to be projects the business doesn t care about One example might be a corporate wide database The Business doesn t have any particular opinion on how this should be done However I think we are seeing a shift in projects from large to small from complex to simple and horizontal in focus to vertical in focus At the same time the Cloud is slowly removing infrastructure issues With these shifts it becomes more practical to see each project as a business initiative And if the business doesn t care enough about the project to lead it then we may well ask why bother Peter Kretzman says August 16 2012 at 8 09 pm Roger You make a very telling point I agree that much of this may be shifting in the manner you describe and the role of the cloud certainly reduces although doesn t utterly eliminate counter to some claims the specific projects spawned to address infrastructure issues So yes many more projects will fall under the umbrella of business affecting which is should be the goal after all But as I indicated there will always likely remain certain roof projects that are both crucial to the firm s overall success but which evoke nothing but yawns on the part of non IT folks At one site we changed out the underlying database technology used

    Original URL path: http://www.peterkretzman.com/2012/08/16/no-it-projects-a-practical-take/ (2016-04-28)
    Open archived version from archive

  • Hiring and firing: an example of a stellar employee - CTO/CIO Perspectives
    seldom encountered such a persistent and articulate individual and as I reflected on what I most wanted in the individual who would fill the open position I decided that those characteristics counted and counted a lot I was anything but wrong In my subsequent experiences with Harry as an employee I found out that he exemplified all those traits and more including the following Ability to create order out of chaos taking on sometimes vaguely formulated assignments defining meaningfully what was really needed and then delivering it beyond my expectations Ability to reason thinking out all the angles Ability to forge consensus and even while pushing hard on people to get things accomplished still be well liked even by my extremely ornery sysadmins and DBAs Versatility ability to be a quick study taking on tasks where he initially had zero background A solid work ethic This was an individual who showed up organized his tasks and simply got things done Ability to accept feedback and coaching adjusting his work as a result Ability to hang in at an organization through ups and downs Self educating reading 1 2 business related books a month In short this was an exemplary employee exactly the profile that I wish I could hire each and every time in terms of basic raw ability and attitude alone And his actual output once he had the job Harry exceeded my expectations every single time Interestingly I ve actually hung on to some sample documents that Harry created not so much for their specific content as for their overall quality and ability to serve as a compelling example as I push to get the best from my current employees Give me something like this I tell them If I currently had a suitable position available in my organization you can be sure that I d be trying to hire Harry myself because his presence strengthens any company Lagniappe I recommend nearly any book by Joel Spolsky as I do with anything by Steve McConnell as well This book is a sterling little gem with tons of wisdom and specific actionable examples Smart and Gets Things Done Joel Spolsky s Concise Guide to Finding the Best Technical Talent Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under People Pillars of Purview 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 1cb48697374dbd3df3dee2ae1f6773db Contact information for Peter Kretzman Ph 425 835 3487 Email peter dot kretzman at gmail dot com Social media Blog post categories Anecdotes 21 Book reviews 7 Communication 23 Education 6 Estimating 9 Ethics 1 Financial 7 General 31 Humor 7 Industry trends 23 Metrics

    Original URL path: http://www.peterkretzman.com/2007/10/07/hiring-and-firing-an-example-of-a-stellar-employee/ (2016-04-28)
    Open archived version from archive

  • The CIO and the fine art of vendor negotiation - CTO/CIO Perspectives
    is generally pretty efficient that way Your goal in the negotiation process is to see where you can find wiggle room on each alternative s components price terms features that will ultimately make one of those choices outshine the other on balance In other words you are looking to unsettle the equilibrium you ve achieved in 1 so that one choice comes out on top And here s another key let each vendor know and remind them frequently that this is what you re doing Usually there s no need or benefit in letting the participating vendors know exactly what your list of alternatives consists of but it will suffice that they know that you know that you have choices Miscellaneous tips and observations Negotiation in general is not simply about money although that s certainly a key dimension that can make one of your viable alternatives rise above the others Any facet of the deal should be open to scrutiny and discussion cost terms rights to upgrade SLAs warranty etc You don t always automatically choose the least expensive option nor do you always choose the most featureful Don t ever tell vendors and believe me they ll ask again and again what your budget is for this project They don t tell you what deals they ve cut when they ve sold their product to other customers do they Again the fact that you are actively pursuing other alternatives needs to speak the loudest Remember though that your goal is not to hammer down the price so far that the vendor won t make any money on the deal You can do that at times but it ultimately means that you ll get poorer service and less attention when you need it Where possible involve your legal counsel in the negotiations don t just bring them in at the end The best negotiations for me in terms of viable outcome were where I had a tight bond and common approach with my legal counsel In the end it s all about getting a viable solution for your need at a reasonable price and beneficial terms for all It s not really about winning it s about choosing Give yourself choices and in the end you and your organization do win Lagniappe Ward Keever Ten Keys to Successful Negotiations Martin Ewing 5 Can t Miss Vendor Negotiation Tips Michael Krigsman Negotiation Tips for CIOs Peter Kretzman More tips for dealing with IT vendors Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Pillars of Purview Process Role definition Vendor management Tagged With balance choice choosing cost gamesmanship money negotiation SLA tricks vendor Comments jfbauer says December 11 2009 at 8 01 am I found this post to be a great perspective on the balance of low price against the other critical aspects of the vendor relationship It may be rewarding to know you drove down the price but two months

    Original URL path: http://www.peterkretzman.com/2009/12/10/the-cio-and-the-fine-art-of-vendor-negotiation/ (2016-04-28)
    Open archived version from archive

  • The title issue: CTO vs CIO, and why it's the wrong question - CTO/CIO Perspectives
    hours a day every day letting the requisite APIs seep into your skull until they become second nature and ooze out your fingertips almost by themselves The best coders hate meetings not just out of dispositional crankiness but because meetings really do slow their cranial momentum Read Tom DeMarco s PeopleWare In short it s next to impossible I know of only one case where I ve seen it happen successfully to maintain one s deep involvement in the software nuts and bolts while also dealing satisfactorily with the mélange of executive and administrative duties required of a CTO duties that are absolutely essential to ensuring that a company s technology will scale as the company grows Once you re beyond at most 30 people the mentality of wanting such a super coder cum executive just doesn t cut it High level project and program management operational concerns frankly often just an annoyance to even seasoned developers ever increasing negotiation time with internal stakeholders marketing sales support and the care and feeding of upper management consume a huge percentage of time The savvy CTO is forced to become a generalist in technology itself delegating the intensely technical aspects to his or her team Many simply cannot or will not make the jump and you see people in this position clinging to low level development tasks or given to odd activities such as logging into routers on the side to handle configuration tasks I can t let everyone else have all the fun I ve had people tell me Companies that go too long during their maturation lifecycle without a senior technology executive at the helm tend to not even suspect what s happening After all software seems to be getting written product released Perhaps there aren t obvious problems Yet Later what inevitably comes to light are chaotic or non existent contracts bizarre and untenable operational workarounds gross overexpenditure or underexpenditure on infrastructure and often near total lock in to unscalable technology and practices So that s my summary take on the CTO CIO title question it doesn t matter what you call it but the it had better be a position that concentrates on shepherding technology systems and strategy from a high level viewpoint throughout your company Does that mean anyone can do the job No not at all Just asking the right questions anticipating the pitfalls requires years of having sweltered in the IT trenches with working code due Friday or an implausibly broken production system at 3 in the morning What it does mean is that someone who still has working code due on Friday won t be up to the full job required of this senior executive Lagniappe Follow up post on CTO CIO Perspectives The title issue revisited CTO vs CIO August 30 2009 CIO Magazine CTO A Dangerous Title Peopleware Productive Projects and Teams CTO VS CIO WHO S THE BOSS CITO The wave of the future ComputerWorld The CTO IT s chameleon Tweet

    Original URL path: http://www.peterkretzman.com/2007/07/10/the-title-issue-cto-vs-cio-and-why-its-the-wrong-question/ (2016-04-28)
    Open archived version from archive

  • Some timeless IT/tech jokes, and why they're still relevant - CTO/CIO Perspectives
    prior to the completion of UPS repairs Rackspace s incident report is an amazingly bad example of jargon laden un customer oriented IT communication There s no discussion of real root cause the breaker tripped but why or specified action plan just a bunch of seemingly nervous technobabble that lets no one understand what really happened why it happened and what they re doing to ensure that it won t happen again In other words everything in their report is technically correct but it s no use to anyone Sure they were still in the throes of diagnosis but that doesn t excuse the plethora of excess detail and their failure to address what customers really are interested in This kind of approach inspires negative confidence among one s customers needless to say 4 Difference between a methodologist and a terrorist This joke has also been around for decades I stopped telling it for a few years after 9 11 but it continues to make a needed point What s the difference between a methodologist and a terrorist Answer you can negotiate with a terrorist I ve frequently noted that some IT folks latch onto a particular methodology Rational Agile Lean whatever and come to see it and it alone as representing pure unvarnished guidance and truth If not brought back to earth they can drift into a discipleship attitude that there s really only one true way of approaching systems and projects If confronted with a failure in a project using their one true way they re quick to claim that the methodology wasn t fully or correctly implemented If it doesn t work you aren t doing it right This one trick pony perspective a sort of tunnel vision that lacks introspection creates a rigidity that s almost always detrimental In fact it tends to put you into situations where joke 1 is relevant Lagniappe Follow on post More timeless still relevant information technology jokes Tweet Share this Twitter Google Facebook Email Print Previous Post in Category Next Post in Category Filed Under Anecdotes Humor Top 25 posts Comments Arun Manansingh says September 8 2009 at 4 45 am Peter Very funny and so true I forgot about 4 But it is still relevant Thanks for sharing John Bauer says September 23 2009 at 11 55 am Number 4 caused me to recall a past employer where a few years back a technology group jump on Agile and completely fulfilled your discipleship description Needless to say they burned bright but quickly faded What ultimately caused them the most challenge was agilely developing their infrastructure you can t keep swapping OS s and application server platforms as business requirements change with taking on huge costs and delays Paul LaFave says September 2 2010 at 4 03 am IT IS et al have always been their own worst detractors In my 35 years of IS T Leadership I have fought the notion and impression that IS T are a bunch

    Original URL path: http://www.peterkretzman.com/2009/09/06/some-timeless-ittech-jokes-and-why-theyre-still-relevant/ (2016-04-28)
    Open archived version from archive

  • The IT project failure dilemma: how to get early warnings - CTO/CIO Perspectives
    Assuret s groundbreaking tool I agree it is a thoughtful and thorough approach to addressing project failures mkrigsman has taken years of experience and insights and codified it into something special I am glad you had a chance to see it and write this great post Steve Romero IT Governance Evangelist http community ca com blogs theitgovernanceevangelist Michael Krigsman says March 26 2010 at 9 17 am Peter Thank you for the insightful comments on these important issue and also on how Asuret handles them As an independent third party observer with no ties whatsoever to Asuret your review is particularly valuable and represents an impartial view Mike Jones says March 29 2010 at 4 39 pm I have not had a chance to check out the Asuret tool but it sounds interesting The one thing you did not address is no matter how people respond to questions there is nothing like getting them to respond to the working code When you do this you get real insight into where your project sits Thus we have found the only way to reduct risk of project failure is to embrace change and iterative agile development This is the sure way to identify mis matches in expectations and keep your project moving in the right direction David Chassels says March 31 2010 at 1 27 am I think the title CTO CIO highlights the core issue The CTO is about delivery technologies CIO is about creation and use of business information They are quite different skill sets The business application working with people who create all source information is about business logic This is where historically the tools have largely failed to deliver as they were componentized and designed to be used by technical people who are often remote from users so the disconnect does indeed loom large But business logic never really changes unlike the delivery mechanisms think of the pony express is now the internet With this in mind a UK company Procession set about trying to solve the IT problem which would remove the need for programmers to build custom applications reflecting exactly what the business user wanted and supporting constant change In 2008 Bill Gates said Most code that s written today is procedural code And there s been this holy grail of development forever which is that you shouldn t have to write so much code Gates said We re investing very heavily to say that customization of applications the dream the quest we call it should take a tenth as much code as it takes today You should be able to do things on a declarative basis We re not here yet saying that a declarative language has happened and you should write a ton less procedural code but that s the direction the industry is going Gates said And despite the fact that it s taken longer than people expected we really believe in it It s something that will change software development Gates is right and it is exactly what Procession delivered some 10 years earlier Using such advanced tools is the real answer to closing that disconnect and eliminating business software failure Good methodologies in project management can reduce risk of failure but no substitute for using such tools as described by Gates and now available Peter Kretzman says April 3 2010 at 10 42 am Well thanks for commenting Dave but much of what you write is along the lines of Things I Fundamentally Disagree With I ve written recently about how there are No Silver Bullets and the kind of claims made by Procession are precisely to promise it as a silver bullet to wit There is now no need to custom code any applications or buy inflexible off the shelf software which rarely solve specific business problems I m sorry but this is a patently non credible claim one that at best can be viewed as vastly overstating its case If Procession which I m sure is a fine company with an interesting product albeit one I ve never heard of in any context had indeed delivered this holy grail ten years ago as you say it d be considerably better known As for CTO and CIO being completely different roles this again is something I ve written at length about and I disagree entirely with your statement I d point again to what one actually sees in the real world where the two terms are used quite often interchangeably And no the CTO is not and must never be about simply the delivery of technologies even in companies that strongly differentiate between the two roles David Chassels says April 4 2010 at 5 37 am Peter Well it is true a real third alternative to COTS or coded custom build the ultimate flexible packaged application where the core code never changes No code generation no compiling to build any business driven requirement recognising people are the source of all information When you get right back to basics what people need to support them in their daily work there are less than 13 work tasks human and system including the important user interface that can address any business issue So make them configurable objects build flexible links put into contained data centric environment put a graphical interface at build and a whole new world opens up in just one unified tool Think about it what are we doing in the 21st century coding and recoding over and over business logic that never changes people doing something to achieve the individual and collective outputs That s what we recognised as a core issue and our unique design philosophy addresses In effect we have separated business logic from the delivery technologies Someone had to do it This has been a long journey lead by business thinking We were 10 year ahead of our time and face huge vested interests You may have heard of the innovators dilemma which applies to the dominant

    Original URL path: http://www.peterkretzman.com/2010/03/25/the-it-project-failure-dilemma-how-to-get-early-warnings/ (2016-04-28)
    Open archived version from archive



  •