Enterprise transformationadvancement

1. Restoring humanity to work
   There is a renaissance in the ways we work and manage, the like of which we haven't seen since the introduction of management as a discipline, except perhaps the ideas of flow after WW2.
   The flagship is the Agile movement, which has escaped IT and is now transforming organisations, government and society. But Agile is too narrow a portmanteau, so we call the movement as a whole Human Systems Agility, to embrace all the concepts involved.
   The most important part is the first one: we are restoring humanity to work. We are going beyond the cold inhumanity of scientific management to reunite science, ethics and aesthetics - truth, goodness, and beauty.
   We see this everywhere: in the rejection of shareholder value as an ethical compass; in the need for higher cause and real values at work; in the desire to bring our whole authentic self to the workplace. We are happier when work is true, good, and fine.
   It starts with the individual and the team, and it grows with leadership commitment.
   We build on an assumption of goodness, of adult professionalism, and we authorise people to do work. We care about the values as much as the value. We create a workplace where people can flourish and be their best.
   At a time when the world is spiralling into corruption, greed, and fascism, this movement to new ways of Human Systems Agility is a ray of hope for the future.

   Attendees will gain a quick overview of the field, pointers to the deeper domains (and this goes deep!), and practical ideas of how to start a personal and an organisational advancement journey to more humane work.

2. Enterprise Agile
   Agile thinking is transforming IT, enterprises, government, and society. Its impact is far reaching enough to talk of it as a renaissance in thinking, a refresh or step change that comes only once or twice a century. This is not an exaggeration. It is leading to New Ways Of Working: iterative, incremental, experimenting, exploring complex systems. These are displacing the ideas of big-bang projects; zero risk; certainty and accuracy; plan once execute perfectly; failure is not an option.

   "Velocity through quality" is the New Way Of Working. At its heart, the agile way is about going faster by being better. We build this culture through attention to leadership, happiness, space, empowerment, community, and communications.

   At least as important, though, is New Ways Of Managing. Too often, management views the transformation to New Ways as something done to improve the practitioner workforce, not to management. This can't be. For an organisation to change, the management must change. So we combine the two into the phrase New Ways Of Working And Managing™, NWOWAM™. It is cumbersome but we leave it like that to make a point. This is one of the biggest issues facing organisations moving to agile ways of working. Managers must understand and focus on empowerment, collaboration, agility, and flow. More...

3. New Ways Of Managing™: The Agile Manager
   In order for an organisation to change the leaders need to change. There are major underpinning Agile/DevOps/Lean principles that managers need to grasp, to manage or govern the transformation to a new way of working. This equips agile managers to understand, make, and approve decisions on new ways of working: all about the “why”, none of the “what” or “how”.
   We will go through ten major principles (and more principles associated with them)
   • More important to improve work than to do work
   • Work must be sustainable
   • You can’t fix a complex system
   • Navigate uncertainty and ambiguity
   • Trust people
   • Success is achieved through failure
   • Product not project
   • Shift quality left, bake it in
   • Get out of the way of the flow of value
   • Do less to do more
   Most people from conventional IT are challenged by at least one of these ideas. Without these principles, managers are prone to think your people are crazy, "on drugs", and they may obstruct change (and look silly). Even managers who think they get it, haven't actually internalised these concepts. We talk about what these principles mean for the ways that we manage. More...

   IT transformationadvancement

4. Messing With Your Head: how DevOps changes everything.
   My favourite presentation. This presentation looks at how DevOps turns some fundamental principles of IT and ITSM on their heads, with new concepts such as high velocity change, fail fast, infrastructure as code, people over process, servers as cattle, and empowered developers. DevOps is a strong leading indicator of our IT future: sooner or later we will all need to make the lateral shift in mindset required by these challenging concepts.Your IT fundamental axioms will be challenged.

5. the IT Renaissance . Cloud, Agile, DevOps, Shadow IT, BYOD, mobile apps, user forums, cultural change, humane IT… are all surface manifestations of something deeper and more fundamental – a single shift in the way the world thinks about IT.
   This is the IT Renaissance. It is a tectonic shift, a gradual change in the way we think, liberating people from process and technology; the understanding that people deserve to be respected and empowered; the shift from control to facilitation. It brings a new emphasis to the rest of IT, beyond those standardized areas we can control within a defined process. It means liberation from constraint, from rigidity, from cumbersome complexity. It means a focus on the humanity of IT, on behavior and culture, on beliefs.
   Our IT world is changing like it never did before. We look at the big picture and its implications. More...

6. The Lizard Brain. This presentation looks at the often overlooked instinctual levels of human behaviour in the context of IT transformational change driven by DevOps. Culture change doesn't happen unless we cater for the primitive subconscious needs of humans to interact, communicate and bond. The ideas presented are simple starting points for building a human community of trust and collaboration to make DevOps happen. They will give you a new lens to examine the things you do to ensure they succeed.
7. Experiment: explore new ways of working. Establish an Experiment programme to encourage all individual teams to experiment with new DevOps ideas and techniques. This is an important initiative to invigorate the interest, energy, and enthusiasm around DevOps across the IT organisation, and to expand its uptake. Experiments seek to see if the ideas will work, to generate proof points, and to develop awareness and experience. The experiments should have a purpose and testable conditions. There are boundaries around experiment including decisions as to what success will “look like” and when it will be done. Experiment can be done with subsets of innovation, ideation, etc.
8. Reinventing IT: Changing Roles. People, leadership, and organisations need to reinvent.
9. The Toolsmiths: the changing role of IT Operations. As DevOps becomes business as usual over the coming years, the function of IT Operations moves from building and managing Prod to building and managing the automation tools so that others (Build teams) can build and manage Prod. This creates several career directions for us.
10. Technology Process People System: the maturing of the IT industry. Over the decades, our industry has evolved from being technology-centric to process-centric (the blossoming of ITIL), to lately being people-centric (culture, leadership, teaming, roles, skills, empowerment...). Lean and DevOps point us to the emerging next (final?) level: systems thinking.

11. Enterprise DevOps: what DevOps looks like for a horse. This presentation looks at the implications for DevOps in an established enterprise with legacy IT: the clash of cultures, of practices, of lifecycles. It looks at how we can resolve these issues and what the benefits will be to the enterprise, and to established ITSM. DevOps in an enterprise is a different thing to DevOps in a unicorn startup: horses don't grow horns. More...
12. He Tangata, People in IT: the importance of cultural change. Without it all IT initiatives will fail. More...
13. Changing Their Minds: Real Service Improvement. All service improvement is about changing people's behaviour. We have several decades of not doing very well at getting people to do IT better. Why is that and what can we do to effect real change in Real IT? Here is a model and a set of techniques to address cultural change at different levels.
14. DevOps 101: an Introduction to DevOps. Much talked about, less clearly defined. This presentation introduces the huge field of DevOps in less than an hour.

    IT governance and strategy

15. The impact of DevOps on Governance and Controls. DevOps (and Agile) changes the operating model for IT and as a result drives a change in the way IT participates in the organisation. As a result all sorts of models are driven and will be further driven to change, such as portfolios, funding, projects, change, design, delivery, compliance, and audit.
    This presentation will look at the shifts happening in product portfolios, definitions of value, engagement of IT, how IT is funded and accounted for, how systems are delivered, and what the impact is on testing, compliance, and controls.

16. Owning DevOps: The ten fundamental principles. Ten underpinning Agile/DevOps principles that managers need to know to manage or govern the transformation to a new way of working. It produces agile managers who can understand, make, and approve decisions on new ways of working. You don't need to know how to do DevOps or Agile, but you need to understand they're not crazy.

17. Elevate the control, Getting Controls Out Of The Way Of Flow. One of the principles of DevOps is "get out of the way": if you are a supporting function ("necessary non-value work") then make sure you are not a constraint to flow of value. Controls are a particular issue; we have to have them in order to minimise risk and ensure compliance. But, they often accrete unnecessary ceremony over time, and optimise to the governor not the value worker. Rob presents a dozen tactics for minimising the impact on flow of value from Require to Deploy. More...

18. Multi-Speed IT . Enterprises are wrestling with the conflicting needs to chase competitiveness in a world of new tech, whilst still remaining mindful and careful. In IT we are caught in the same bind. By embracing Agile, DevOps, BYOD and other "liberation" approaches, and integrating them into our ITSM, risk, and governance practices, we can create an IT environment with a better chance of responding at the speed of business, whatever the business chooses that speed to be. This presentation proposes a more nuanced approach to two-speed or “bi-modal” IT, where each lifecycle implementation is a blend of the two "speeds: Conservative and Nimble. Any one project or development team can have some nuanced mix of the two depending on the business's needs. We may end up with three or more lifecycle structures in the organisation, as needed. Some teams will work within a standard lifecycle and other teams will be empowered to create their own. It's an infinitely-variable Multi-Speed IT Capability model we need. More...
19. Slow IT. Here is a new wave I see emerging in IT. We had Slow Food decades ago. Now we are seeing Slow Business, and I hope we will see Slow IT. The key point I want to make is that there are absolute limits on how fast IT can go. The governors or executive or customers or users can rant all they want about how IT "must" deliver faster, but we are approaching rates that simply are not humanly possible. The limits are with humans and systems: there appear to be no technical asymptotes.
    The onus is on the organisation and the customer to understand (or at least listen to) the limits of IT, and to manage that risk responsibly. It's not happening much. More...

20. To Protect and Serve. The motto "to protect and serve" is a good one for IT. There seems to be this expectation that IT exists only to create new IT in response to the demands of the business. It's not true.
    The Finance department doesn't exist solely to find the money for whatever the business needs ("serve"). The Finance department also exists to look after the health and safety of the organisation's wealth ("protect"). Sometimes the Finance department will resist new initiatives simply because the organisation can't afford them. This then becomes a decision escalated to the Executive or the governors (the Board) to decide whether to proceed against the advice of the CFO.
    In exactly the same way, the Information Technology department exists to protect the IT interests of the owners of the organisation whilst also serving IT's customers and users. The two don't always align.
    IT is entrusted with custody of the organisation's IT assets. Sometimes it is not in the best interests of the organisation to abandon those investments or to increase the risks to the confidentiality, integrity and availability of the information, in order to meet demands for new IT from the customers.
    Put another way, IT's role is to balance extracting maximum value from existing investments against facilitating the generation of value from new investments. Protect and serve: it's a tough gig and sometimes a thankless one. More...
21. Organisations have failed their IT like bad parents: The world has really messed up owning IT (Information Technology), like a bad parent messing up a child's upbringing, letting them develop bad habits. We need to do better. We can do better. We need to do it soon, as modern IT requirements become ever more complex. IT is in bad shape, struggling to meet escalating demands for more complex automation, more data, more complex technology, and dispersed control (internet, Cloud, Agile, mobile, social media BYOD…). This isn’t entirely IT’s fault. They have been left to make their own way with insufficient guidance, support and resources. If this continues, more IT departments will fail to enable their organisation to remain effective and competitive. We must help them out, and soon. Those who run and govern organisations have an accountability and responsibility to manage and govern IT, just as they do every other aspect of the enterprise. This is true in the public and private sectors alike. It is not a new message but only now is it catching on. More...
22. The Cult of the Customer: Examine your assumptions around "customer first". Often but not always. There is such a thing as over-servicing the customer. Who is paying and what do THEY want? More...
23. What Governance Isn't (and thereby better understanding what it is, including ISO/IEC 38500)
    Often the easiest way to understand something is to define what it is not. The philosophers among us will remind that “what something is not” is an infinite topic. This presentation looks at “what governance isn’t but people sometimes try to make it”. It considers seven interrelated areas often confused with governance.
    In theory the practice of governance is simple, though in practice not so. The definition of governance is simple: policy making and monitoring. But the vendors will make governance mean what they sell; the analysts will make it mean something new and oh so clever; and many writers will make it whatever they think it means. This presentation’s quest is probably futile: the word “governance” is doomed just like “partner” and “paradigm” and “legacy” and “virtual” before it. Maybe there is still a chance. You will make this presenter happy if just once you say “that’s not governance”. More...
24. Plug and Socket: the practical application of governance to IT. What do I need to have ready when the governors come knocking?
    There is plenty of abstract information about Governance of IT (don't say "IT Governance" - Rob will explain why), but when you come to do it the lack of practical information is worrying. Lots of boxes on whiteboards, not a lot of beef in the burger. Rob England has been exploring what is out there, to build a picture of useful guidance in the implementation of IT Governance.
    When the governors (or their designates) come looking for you wanting to implement governance, what will they have with them? What will they want you to have ready? What do the plug and socket between the governors and IT actually look like in the real world? Rob will give us a clear picture of what Governance of IT is, then describe what that really means in practice.
    David Cannon said this presentation influenced part of his ITIL 2011 Service Strategy rewrite, and Rob is credited for that in the acknowledgments in Service Strategy.

25. Direct: An IT policy framework. As far as I can tell, there is no best practice IT Policy framework in existence so I am having to build one.
26. Losing the Centre: the balance between control and agility. The increasing pace of change in general - and BYOD, social media, Cloud, Agile and DevOps in particular - have implications for traditional IT Management. Decades of hard-won controls over our IT production environments are under assault from radical new forces, including Agile, DevOps, SaaS, Cloud, BYOD and social media. A new world is arriving at a remarkable pace. In that new world we will have much less control over what happens in IT. We can't control what developers do, what the business units do, what our suppliers do, what our users do. We can't even control where our servers are. We don't know where our data is, where our servers are, where our users are, what platform the users are on, where the apps are. What does the IT function within our organisation look like in that new world? What are we for? How do we protect the organisation's assets? Do we even need IT any more? As the centre of IT spirals out of control, we will see the rise of governance and assurance to complement service management.

    IT management

27. Real IT. "RealIT" (reality, get it?) is the application of information and its technology to the functioning of an organisation. I.e. never mind the businesses that sell shiny tech things or that manage other peoples information, or all the other specialist tech businesses we are so captivated and distracted by. Real IT is about using IT to execute an organisation's mission.
    When people talk about IT these days the term is - as usual - becoming debased to mean any or all of these. That's why I have started refering to RealIT: to focus on the reality of applying IT to business/enterprise/organisational outcomes; to take us away from confusing RealIT with the consumer personal digital experience (direct from manufacturer to consumer - think Apple - is NOT Real IT, the rules are different) or with the specialist industries of IT service aggregators/outsourcers/suppliers, or IT manufacturers/startups/entrepreneurs/vendors ... all of which are hijacking and distorting the "IT" conversation away from RealIT.
    The Information Technology sector is layering into interacting industries. RealIT is one layer.
    RealIT isn't always about speed; the hysterical frenzy of the startup or of the retail technology vendor. RealIT isn't always about innovation or competitiveness. RealIT isn't always about novelty and attractiveness and pandering to the desires of the users. These are viewpoints which are more important in the other parts of the value chain.
    RealIT is about balancing the conflicting duties of "To Protect and Serve": acting as custodian of the massive existing investment in information and its technology, whilst also serving the changing needs of the organisation. More...
28. Meet in the Middle (MitM): a strategic response to IT overload. The enterprise will be more inclined to respond to our appeals for Slow IT, to a more measured approach to changing our service portfolio, if IT shows a willingness to adapt by doing some "Fast IT" in return: i.e. by speeding up delivery of those changes. In other words, if they'll slow down on what they rain down on us, we'll speed up on what they do ask of us. Give us some room to breathe and we'll improve what we do. IT and the enterprise must meet in the middle. More...
29. COBIT: A Strategic View: a layman's view of COBIT and why you need to know about it. It may have started out as an audit tool but now COBIT is very much a general IT practices framework. There is no reason other than history why ITIL is the "default" choice as an IT framework. There are better ones around. In my consulting practice I use COBIT as my framework, and flesh it out with ITIL and other bodies of knowledge when necessary. I use COBIT to frame assessment, current state analysis, reviews, improvement planning, strategy, roles, and so on. It's better. More...
30. Tipu: a pragmatic approach to Continual Service Improvement. Enough theory: this is how to actually manage an improvement programme.
    Improvement changes the way people think and behave. Improving the practices and tools are secondary to changing culture. You can change software in minutes. You can change process in days. But people take much longer to change. Improvement should happen in an incremental manner: evolution not revolution. Improvement is not a project - improvement is normal behaviour for professionals: to devote a certain percentage of our time to improving the systems we work with. We should all expect that things will be better next year. We should all expect that we will make a difference and leave systems better than we found them. Improvement is business as usual.
    This presentation looks at the huge amount of potential improvement in most organisations, and how improvement goes on as part of the professional's daily work. We describe a method of breaking the task down to make it manageable, and then organising that improvement based on small increments, agile approach, empowering staff and a "relaxed" attitude - a pragmatic way of dealing with our constraints. More...
31. The Checklist Manifesto: a reading from Atul Gawande's great book The Checklist Manifesto to illustrate the critical importance of checklists in IT operations More...
32. The one top tip for IT operations and support: Checklists. We have the world of information at our finger-tips. Our operational tools get better every day. Yet things still go wrong on a regular basis. Then we take the opportunity to prove that there is no problem so bad that you can't make it worse. Why do we screw up? And why do we then screw up trying to fix it? According to Atul Gawande, author of the Checklist Manifesto, the magnitude of today’s knowledge has exceeded our ability to deliver it-safely, consistently and correctly. A simple checklist can bring about striking improvements in almost any field (think aircraft pilots). Checklists are an essential tool to minimise errors and maximise efficiency when the heat is on and you need to act. Have the checklist ready when you need it.
33. Culling: Why IT projects fail, and how to change that through service portfolio management. The reason why so many IT projects fail to deliver the expected result is that we underspend on what matters: people and process. That is not to say we overspend on technology - we do a lot of work to get that right. The overall budget for projects is too low because we underspend on process, and especially we underspend on people; consultation, testing, training, coaching, feedback... all the aspects of cultural change.
    If the project's business case doesn't stack up at this higher spend, then it was a bad idea. Because it will end up costing that much anyway to change the behaviours of the people. Or if we stick to the lower spend it will fail. Fail slowly over years or fail spectacularly, but either way it will fail because the behaviours weren't really permanently changed.
    If we spend more on projects doesn't that mean we can't do as many projects? Correct. We need to get better at killing off projects that were under-budgeted and never going to succeed. We need to cull our project portfolio. More...
34. Small business "extreme makeover": how we rebuilt the IT in a small organisation - hardware, software, practices, roles, management - from the ground up for a remarkably small fee and total cost, using existing resources, business-as-usual functions, targeted experts, SaaS, outsourcing, and COTS. This organisation sold IP, but their IT systems had no investment for years, thanks to an unsympathetic Board. The sole dedicated IT staff member left - they didn't replace him. My partners and I created architecture and management; established functions including IT Steering Committee, CAB and Service Desk; reviewed and changed their supplier value network; rebuilt the infrastructure temporarily then outsourced the lot; refreshed desktop, phones and mobile; guided and built on existing SaaS; and set them up to make a building move possible a year later.
35. The Future of IT management Regular readers know the IT Swami is the source of my peeks into the cloudy future (pun intended). He regularly updates his vision of the future of IT. More...

    Service management

36. Real Response: The Standard+Case Approach to Service Response. Standard+Case is an exciting new approach to categorising and resolving any sort of activity "tickets", such as requests (including incidents) on a service desk, problems, or changes. S+C merges our conventional "Standard" process-centric approach to responding, with Case management, a discipline well-known in some other industry sectors such as health, social work, law and policing. S+C addresses criticisms of approaches like ITIL for being too process-centric and not allowing customers and knowledge workers to be empowered. S+C does not seek to replace or change ITIL or other theory: it expands and clarifies that theory to provide a more complete description of the real world.More...
37. Crossing the Streams: DevOps and ITSM. You will see all sorts of claims on the internet of how DevOps is the end of ITIL. It ain't so, and there is as much strong argument out there for the use of both. How do DevOps and ITSM affect each other? What are the connections? How will they work together? Here is one view of where the work will be needed, and what value they offer each other.
38. Kamu: reconciling and uniting the DevOps and ITSM world-views. Thousands of intelligent IT professionals can't be totally wrong - there must be substance, there must be value worth mining. ITSM isn't a dead process-bound mainframe bureaucracy and DevOps isn't a bunch of childish whining developer cowboys trying to be exempt from sensible controls. A model exists (antifragility) that allows for a non-chaotic alternative to robustness and stability, and hence a common ground is possible between the current DevOps and ITSM world-views. Kamu is about finding it. More...
39. Hono: a Supplier Engagement Model: When establishing the relationship with an external service provider (outsourcer), why do we document a whole operating model spanning both organisations? The whole point of outsourcing is that the supplier should be a black box, with inputs, outputs and performance requirements. What we need to define is the interface between the two entities, to ensure the operating models of each one mesh properly together. Define the connecting cogs, or the plug-and-socket - choose your analogy.
    This is more efficient: we don't redundantly document processes which already exist, and are documented elsewhere. It is more effective: we focus on the gaps, specifying the requirements for change in each organisation in order to connect their operating models.
    This is pioneering stuff: there is very little published on what an engagement model should look like or how to develop and use it. Rob has built them: this presentation looks at a format, the content, and its uses.
40. The Cult of Process Maturity: Process/practice maturity is a metric that should be of little interest when deciding where to focus your improvement efforts, or for measuring the results of those efforts. And CMM process management maturity is even more useless than execution maturity. Risk and value should be the primary metrics for planning and assessing your improvement.. More...
41. Owning ITIL: what decision-makers don't get told. An antidote to the KoolAid for ITIL decision-makers and those who work for them. More...
42. Six Tactics for ITSM to Deal with Agile As far as mainstream ITSM is concerned the primary impact of Agile development method is on our carefully constructed production environment. Agile has the potential to undo decades of work building protection for the assets for which we are accountable. It's our job to control risk as well as enable value. Sometimes it seems Agile ignores the former in pursuit of the latter. Here are six tactics to help deal with that. More...
43. ITSM Crap on the Internet: cutting through the excrement in what you read online. This presentation will survey the internet ITSM information which demands critical thinking; the material which will lead you astray if you don't examine it with a skeptical mind. We will look at "Crap Factoids": misinformation spread mostly by vendors and analysts, as hunted out by Chokey the Chimp; and sky-is-falling hysteria, as pecked on by Chicken ITle (pronounced "ittle"). And you will meet The ITIL Wizard, provider of "the best ITIL advice on the internet", which isn't hard given that much of it is rubbish. We will look at characteristics of Crap Factoids and bad advice, so that you can recognise it before you step in it. More...
44. BSM: Basic Service Management. Think you know everything about Service Management? We bet you will take something away from this session no matter how experienced you are. Rob England wrote the book Basic Service Management, which compresses an introduction to "everything" about Service Management into 50 pages. In this presentation he will now compress the book into a summary of SM in forty minutes flat. Can he do it? Come and see. Note: there is zero IT content in this presentation - it is pure service management as it applies in any context. More...
45. ITIL Through the Looking Glass: What we can all learn from scaling down ITIL. Making large-organisation best practices fit in Small to Medium Enterprises takes us into an Alice-in-Wonderland world where nothing is quite the same. What loomed large has vanished and what was trivial is suddenly enormous. In Timothy Leary fashion [you kids look him up on Google] we can learn much about our everyday reality by getting outside it for a change. "Trip out" with this presentation and see your own Service Management world in a whole new way. More...
46. Achieving a Harmonious IT Environment (based on the satirical Real ITSM). A humorous view of how to operate IT to maximise the "harmony" of the work environment.
47. Framework Fiesta: There is more to ITSM than just ITIL. A review of many of the frameworks, methodologies, standards and other bodies of knowledge relevant to ITSM.

    Service management practices

48. Get Out Of the Way: moving from change control to change facilitation. Our IT world is changing - best exemplified by DevOps. We need to accommodate faster cadences of change. We need to optimise our value streams and remove constraints to flow of work. One of the bottlenecks in many organisations is IT operational change and release management. These processes need to move from being gatekeepers to being facilitators. The goal becomes ensuring as much change happens as fast as possible.
49. Dead Cat Syndrome: One of the things ITIL V3 improves is the whole development/production interface, introducing radical concepts like production readiness, acceptance, evaluation... oh and testing. Heady stuff. But something that was omitted from ITIL V3 was documentation of Dead Cat Syndrome: chucking new services across the Production fence like a dead cat.
    Operational readiness of new and improved services ensures a smooth transition from Project to Production. ITIL talks about it in a number of places, but I think Operational Readiness needs to be recognised as a practice in its own right, like any other ITIL "process". OR is not (just) about being a gatekeeper to Prod: it's about ensuring readiness throughout the lifecycle. OR provides a positive benefit for the customers, projects, development, and operations.
    Operational readiness of new services ensures a smooth transition from Project to Production. Operational acceptance should depend on: proper testing, warranty period, operational readiness assurance, operational robustness, organisational infrastructure, and liaison relationships. More requirements to worry about and a higher bar to clear might seem like the last things a project manager wants to hear. But, by meeting these criteria, a PM knows exactly what they are shooting for. Moreover, there will be minimum fuss at the end of the project and a quality product will be delivered. More...
50. A State of Emergency: Major Incident Management: A Major Incident (MI) is about abandoning the normal process and switching to different procedures. A MI is about having to invent process. So a MI is about the recognition that normal Incident and problem Management are not going to cut it. A MI is a declaration of a state of emergency. One of the enigmatic parts of ITIL is Major Incidents. These are my tips for better Major Incident Management. More...
51. Sorting out request, incident and problem: I don't agree with ITIL on how it defines request, incident and problem, and their related management processes. The definitions are muddied and misleading. Life would be simpler and things would work better if we sorted the definitions out. I've done that. Here is a far simpler, clearer and more straightforward model of request, incident and problem. The model provides better roles, responsibilities, metrics and practices, and therefore will be more effective and efficient. More...
52. A contribution mechanism for ITIL. Seven years ago The IT Skeptic designed a universal practice framework called Core Practice (CoPr, "copper"), which predictably went nowhere, like most frameworks. But I believe it maps out a mechanism that could be effectively used for the future ITIL (or other frameworks) to accept, accumulate, structure, and regulate public contribution of content.
53. The 5% Club: Why CMDB is only appropriate technology for a select few organisations: the ones that are sufficiently complex to justify the effort and sufficiently rich to be successful in the implementation. These make up about 5% of all enterprises. The other 95% will waste our always limited resources in attempting a CMDB. More...
54. Six views of service catalogue. A service catalogue is not just for customers. The data in it is used by at least six major stakeholder groups: customers, account managers, users, operations/technicians, support, and management/finance. The service catalogue is used for a wide range of different use-cases: negotiating new services, negotiating SLAs, reporting service levels, support, planning availability and continuity, monitoring live systems... Although ultimately the customers are the most important stakeholder in catalogue composition and content, it needs to be designed and built with all these scenarios in mind.More...
55. Technical service catalogue. There is an endless debate on the IT Skeptic blog over whether a Technical Service Catalogue describes the same services as a Business Service Catalogue or different ones. The IT Skeptic disagrees with ITIL and the majority of readers, but isn't backing down.More...

    Hot topics and IT current affairs

56. Dont fear the future: you can't predict it. Luddites react against technology because they lack vision. It's not their fault they can't foresee the future. Nobody can. But in every single other technology shift, entrepreneurs found a use for idle labour, and the efficiencies of technology meant there was new wealth to buy those new services. Don't fear the robot.
    I have had it up to here with those who see people and society as a passive bus-load of zombies trundling towards whatever dreadful fate they are frothing up today, whether it be rising oceans or robots doing us out of a job. We aren't helpless and we aren't mindless. We adjust, we respond, we correct, we react - as individuals and as communities and societies. The only thing mindless is the use of extrapolation to predict the future. We should do better than that. More...

57. A Skeptic's View of Automation and AI. A jaundiced view of forecasts of robots taking our jobs, automation rendering us obsolete, and AI being smarter than we are, let alone the Singularity nonsense. In his role as The IT Skeptic, Rob puts these ideas back where they belong, in science fiction. We look at how awful predictions are, the fallacies that delude us, and particularly why AI isn't happening any time soon and why robots won't take your job.
58. How I downshifted. Years ago I made a conscious decision to slow down, down-shift as they say. I dropped my six-figure corporate selling job and set up an office at home with my wife and my delightful then-six-year-old son who had seen far too little of me.
    Now I make about half what I did, but I enjoy life fifty times more.
59. The Social Media Hype Cycle: is social media creating an IT revolution or a mildly interesting extra channel?
60. Dolphin-free computing: Green IT is a conscience salve to people who can't let go of their grossly wasteful lifestyles. I can't either but I don't pretend reducing the carbon footprint of a server makes the least bit of difference to my profligacy.
61. Big Uncle: Benevolent Security and The End of Privacy. Privacy was a momentary aberration in human history - get over it.
    Big Uncle is a name for the concept of “benevolent security”. Privacy is a dated concept, disappearing fast. People get all tied in a knot over this, but the consequences are only as bad as we let them be. Like any technology, there will be evil applications and there will be good ones. There are upsides: Big Uncle not Big Brother.
    Who controls which one we get? The people who work in IT: we make either one happen, we are the troops. More...
62. The Geeks are not Inheriting Anything: caring for your career and your staff by moving beyond geekdom
63. IT Teachers Suck: what we need to know to train adults properly
64. A History of the IT Skeptic: controversy, dirty deeds and crap factoids