Search

Capture the team's competencies and training needs. Great for defining training development plans and determining who should have access rights based on training. Welcome to our IT Skills Training Matrix template. This template is designed to help you identify and document the current skill levels of your team members across various IT-related domains. The easy-to-use format provides a simple yet effective way to capture, track, and analyse competencies within your team. What is the Purpose of the IT Skills Training Matrix Template? The primary purpose of this template is to offer an organised way to record the skill sets of your IT team. It aids in identifying training gaps, recognising skills discrepancies, and determining the security rights and administrative privileges for each team member. This facilitates targeted training, effective team deployment, and operational excellence. Where and When to Use the IT Skills Training Matrix Template? Performance Reviews: As a tool to be used during periodic performance evaluations to identify areas of improvement. Training Programs: When planning training sessions to know who needs training in which domain. Team Audits: In case of internal or external audits to demonstrate skill levels and required competencies. Resource Allocation: To make informed decisions about delegating tasks based on competencies. What's Inside? The template covers various competencies including but not limited to: General software applications (e.g., Office 365) Network troubleshooting SQL query support VPN set-up and maintenance User creation and removal Laptop setups It includes fields for: Team Member Job Title Date of Last Review Various Skills Each skill can be marked as 'Complete', 'In Progress', or 'Not Started', providing a quick overview of each individual's skill level. Why Choose Our IT Skills Training Matrix Template? Comprehensive: It covers a wide range of IT skills. User-Friendly: Simple format, easy to fill in. Versatile: Suitable for teams of any size or skill level. Actionable Insights: Quickly identify gaps and take appropriate action. Time-Saving: Streamlines the process of skills evaluation and training needs analysis. Download our IT Skills Training Matrix template today to take your team's skills evaluation to the next level.

My top reasons for why OKRs fail; Overcomplication, especially in the early days Not having the right tools for visibility and tracking Lack of managerial support and buy-in Mutation of the OKR method I make no bones about the fact that I love Objectives and Key Results (OKRs), and champion them as a tool for change. They are, in my opinion, awesome tools for projects and organisations that seek to implement change. I’ve used them to great effect several times now. But that is not how my first rollout of OKRs went. Not at all. My introduction to OKRs was through a recommendation from a senior manager (who then promptly exited the organisation, taking his support with him). A couple of us had warmed quickly to the concept and devoured videos, books and discussions, attempting to absorb the enthusiasm and learnings of others. When it came to launch, we looked to the official ‘OKR’ way and tried to apply it like zealots from day one, seeking to convert the rest of the management team to our newly found secret to success. Big mistake. I'll dig into why in a moment, but I winged it as best I could and searched for answers to my questions about implementation, which seemed pretty fundamental, but I was disappointed not to be able to find the guidance I desperately needed. So, here it is. How I suggest overcoming troubles of implementing OKRs. What are OKRs? Noob eh? Ok, no problem; here is a quick summary: OKR stands for Objectives and Key Results. It's a framework popularised by Google that thousands of organisations now use to define and track objectives alongside measurable ‘key results’ needed to achieve them. The objective is the overall goal, while key results are specific, quantifiable metrics that gauge progress. Here’s an example; Objective: Increase customer retention in Q4. Key Results: Reduce customer churn rate by 15%. Increase customer satisfaction scores to at least 90%. Implement a loyalty programme with a 25% adoption rate among existing customers. The objective sets a clear goal, and the key results offer specific, measurable targets to gauge progress. I’ve written more about what OKRs are here, and here. Problems With OKR Implementation Overcomplication of OKRs OKRs are simplicity itself. They are designed to be easy to communicate, understand and implement. Let’s take a look at the typical cycle, which comes from Whatmatters.com Here, you’ll see the nested, quarterly approach to OKRs, with Annual OKRs setting activities kicking it all off. Within each quarter, you have company-wide OKRs, Team OKRs, and Employee OKRs. That is a LOT of objective setting and alignment in a short period. Most organisations are going to struggle with implementing that many objectives throughout an organisation annually, let alone quarterly. If you’re not careful, all anyone feels they are doing is setting objectives, and you might not agree on them before you even exit the quarter. Certainly, that is what happened to us. We (as a management team) got tied in knots trying to agree and align on OKRs. There were constant iterations and reviews of objectives at every level, and frankly, a lot of resistance to committing to stretch targets. And we had consciously chosen not to implement employee OKRs at that point. Now, I’m not saying it can’t be done, and I’m not saying it shouldn’t be done. I recognise that OKRs are a top-down and bottom-up method so that you can simultaneously set key results at the company and the employee levels, adjusting as they meet in the middle. What I am saying is that if I went back to square one to implement OKRs all over again, I’d keep it as simple as possible for the first quarter; just one set of objectives at the highest level, with ownership of the key results clearly defined. To clarify; if I’m working with a department, I focus on the OKRs for the department, each with a team lead taking ownership of key results. If I’m working at a company level, I’d set them only at the company level at that point, and each key result would be assigned to a department. For the first few cycles, I would keep it simple and go no deeper than that. People need to get used to the system. The leadership need to learn how to communicate. Everyone needs to learn how to write and measure OKRs robustly. Doing it at multiple levels in the organisation on day one is a recipe for failure. That said, it’s never an entirely smooth process, nor should it be. So, in order to maintain simplicity, we should look for the things we aren’t going to do, not to add things in, which leads us to two key questions. Should We Set Annual OKRs? Yes, but cadence (quarterly, yearly, etc) depends upon your circumstances. In 2019, Google broke the conventional wisdom and started to focus on annual rather than quarterly OKR setting but looked for quarterly progress reports instead. CEO Sundar Pichai saw the quarterly process as potentially too short and onerous. And that’s okay for an organisation like Google that is well embedded and thinks strategically many years ahead. Still, it might not be right for a smaller startup organisation or an organisation in a difficult situation where it needs to pivot and adapt a lot to changing circumstances. In these cases, I’d focus on the quarterly objectives. But the truth is, as John Doerr says in his OKR bible Measure What Matters, the organisation should define the cadence. Should We Abandon Quarterly OKRs? No. And Yes. Use whatever works for your circumstances. If a lot of short-term action is needed, I would set them quarterly to build momentum. In my most recent use of OKRs, I’ve set annual objectives but quarterly key results. Here’s an example; So, here's I've set an annual objective to target £3.5 NNARR, but backed it up with 4 key results just for Q1. As Q2 approaches, then I'd keep the objective, but update the key results. Not having the right tools for visibility and tracking The enduring saying, "the right tool for the right job," holds particular significance when managing OKRs. While Jira is a stalwart in the software development and task management realms, its intricacies make it less than ideal for those unfamiliar with its specific features, particularly in the context of OKR management. Spreadsheets are another commonly used tool for OKR tracking. While cost-effective and straightforward, they can quickly become unwieldy as you attempt to add layers of complexity—such as detailed notes, comments, or tags. Although real-time collaboration is possible in spreadsheets, it often feels tacked on rather than seamlessly integrated. However, for those on a limited budget, spreadsheets can be a practical, albeit not optimal, solution. Many cloud-based tools can do the job well. And effectively, they only need to do a few things; Allow for parent & child task management (or sub-tasks); The parent is the objective, and the children are the key results. Assign ownership Track progress Give visibility to all In my experience, Monday.com is a user-friendly platform designed explicitly for project and objective management (disclaimer: no affiliation). Its features range from status updates and document linking to the tagging of objectives and key results, making it a robust choice for OKR tracking. The low learning curve further increases its appeal, particularly for those less technically inclined. An example screenshot from Monday.com - For more see this article. Other worthy contenders in this space include Asana and Trello, which offer varying degrees of customization and integration capabilities. Trello's card-based interface offers a more visual approach. Trello Asana provides excellent project management features that can be adapted for OKR tracking. Asana Then there's ClickUp, which provides a comprehensive suite of productivity tools that can be customised to suit your specific OKR needs. The crux of successful OKR implementation, regardless of your tool choice, lies in transparency. Ensure that the platform you select fosters visibility among all team members. OKRs should not be viewed as mere bureaucratic formalities; they should serve as the navigational compass for projects and strategic deliveries. As such, they should be front and centre in team meetings, updates, and strategic dialogues, effectively becoming ingrained in your operational DNA. By judiciously selecting the right tool and committing to complete transparency, you lay the groundwork for a team that is not just engaged and informed but also considerably more productive. Lack of Managerial Support and Buy-in When I first dipped my toes into the OKR pond, a handful of us were brimming with enthusiasm but faced a void in terms of managerial endorsement. This absence of top-down support relegated us to the role of OKR evangelists within the organisation. We were fervent in our advocacy, climbing proverbial soapboxes to proclaim the virtues of the "OKR methodology." We led educational sessions, distributed copies of the seminal book "Measure What Matters," and even went the extra mile to develop comprehensive training guides. However, ingraining OKRs into the organisational fabric proved elusive. Now, allow me to transition into a closely related issue—what I term the "watering-down" of OKRs. The tepid commitment from our senior leaders was a significant roadblock. Their ambivalence, whether overt or subtle, set a tone that dampened wider organisational uptake. It was only when the CEO finally took the reins, visibly endorsing and participating in the OKR process, that the broader team began to take the initiative seriously. Based on my experience, OKR success is closely tied to unequivocal, top-down support from senior management. This isn't just about token nods of approval; it's about active engagement in every phase of the OKR cycle—from rigorous critique during the initial setting of objectives and key results to ongoing, diligent progress monitoring. When senior leaders provide that level of comprehensive involvement, it acts as a catalyst, setting the stage for an organisational culture that accepts and thrives on OKRs. Therefore, if you find yourself mired in an OKR initiative that lacks managerial support, consider this a critical action item. Address it head-on with your leadership team. Advocate for their active participation, stressing that OKRs aren't just another fad but a strategic tool capable of driving measurable improvements across the board. When you've secured unequivocal backing from the top echelons of your organisation, you've effectively cleared one of the most formidable hurdles in successful OKR implementation: resistance. Mutation of the OKR Method In our initial zeal to secure buy-in for the OKR approach, we—the self-appointed evangelists—began to make considerable concessions that led to a significant dilution of the methodology's core principles. To appease key stakeholders, we allowed a level of mutation to the OKR framework that was not just suboptimal but counterproductive. The result was a version of OKRs that was anything but streamlined. Issues included; Too many objectives and key results. Always try to aim for 3 to 5 of each. Poorly worded OKRs that deliberately allowed people to be noncommittal about deliveries. OKRs that teams didn’t buy into, but had thrust upon them. What we ended up with were OKRs that were bloated and cumbersome, burdened by an excessive number of objectives that rendered the entire system unwieldy. This was contrary to the essence of OKRs, which are intended to be concise, focused, and actionable. The excess baggage we added to placate stakeholders made it increasingly difficult to track progress, much less achieve the objectives meaningfully. This raises a crucial point: the temptation to alter the OKR method to fit pre-existing notions or appease various factions can be a slippery slope. Such dilutions, while perhaps well-intentioned, often result in a Frankenstein's monster of a system that serves neither the team nor the broader organisational goals effectively. The compromises we made, thinking we were gaining ground, actually undermined the very objectives we aimed to achieve. Therefore, it’s essential to be vigilant about maintaining the integrity of the OKR framework. I should have pushed harder in the early days for an external OKR coach. They didn’t have to be great, nor time-consuming, but someone who had more experience and objectivity could have helped guide us much better than the blind leading the blind scenario that we ended in. Education and advocacy play a vital role. One must not only introduce the methodology but also equip the team with the understanding and tools to implement it effectively. This includes pushing back against unwarranted modifications that compromise its efficacy. Furthermore, it underscores the need for clear guidelines and ongoing training. As the methodology gains traction within your organisation, it’s imperative to continually reassess and recalibrate to ensure that the original tenets of OKRs are upheld. In Summary: Overcoming Troubles of Implementing OKRS Heed the advice of someone who's felt the heat yet remains an ardent advocate: OKRs are an invaluable tool. They've fundamentally changed the way I approach objectives, and though I wouldn’t say the road has been entirely smooth, there are certain lessons I wish I'd grasped sooner. Firstly, simplicity is key. Tailor the OKR cadence to match your organisation's rhythm, but don't let them become a cumbersome chore. Choose an appropriate tool for tracking that aligns with your team's capabilities and workflow—this is more crucial than you might initially think. Secondly, even the best-laid OKRs can flounder without robust support from senior leadership. Top-down enthusiasm and engagement are not just desirable; they're essential for the OKRs to make a meaningful impact. Lastly, while customising the OKR framework to fit your needs can be beneficial, exercise caution. Make sure any modifications enhance, not undermine, the fundamental goals you're striving to achieve. By approaching OKRs with these guidelines, you're setting yourself up for a more streamlined, focused, and, ultimately, more successful journey towards reaching your organisational objectives. Good luck!

1. Introduction to ISO 27001 Brief history and purpose ISO 27001, officially known as ISO/IEC 27001, is part of a growing family of ISO/IEC Information Security Management Systems (ISMS) standards. It is a framework that helps organisations keep information assets secure. The international standard was first published in October 2005, derived from the British Standard BS 7799-2, and has since undergone revisions, the most notable in 2013 to better reflect the changes in information security threats and technologies. The purpose of ISO 27001 is to help organisations establish, implement, maintain, and continuously improve an information security management system (ISMS). By adopting the standard, organisations can manage the security of assets such as financial information, intellectual property, employee details, or information entrusted by third parties. Importance of information security In the digital age, information is amongst the most valuable assets that an organisation can have. As such, the security of this information becomes paramount. Information security is not just about antivirus software, implementing the latest firewall, or locking down your data in physical safes. It is about ensuring the confidentiality, integrity, and availability of data. Information security breaches can lead to significant financial losses, damage to an organisation’s reputation, and legal penalties. Implementing a robust information security management system is critical to safeguarding data from various threats, including cyber attacks, data leaks, and theft. Overview of the standard ISO 27001 is designed to be comprehensive in scope, allowing all types of organisations—regardless of their size, nature, or complexity—to apply the standard when managing their information security. The standard adopts a process approach for establishing, implementing, operating, monitoring, maintaining, and improving the ISMS, emphasising the importance of continuous improvement. The standard requires organisations to assess their information security risks, taking account of the threats, vulnerabilities, and impacts. It specifies requirements for the establishment, implementation, maintenance, and continual improvement of an ISMS within the context of the organisation’s overall business risks. 27001 aims to ensure the selection of adequate and proportionate security controls that protect information assets and give confidence to interested parties, particularly customers. Annex A, which lists 114 information security controls, plays a crucial role in implementing and maintaining an ISMS. ISO 27001 provides a trusted framework that any organisation can use to build a secure ISMS. It facilitates a systematic approach to managing and protecting company-held information through risk management. By aligning with ISO 27001, organisations can demonstrate to stakeholders, customers, and partners their commitment to securing information. 2. Key Components of ISO 27001 ISO 27001, a comprehensive framework for managing and protecting information assets, hinges on several fundamental components that combine to ensure robust information security within an organisation. Understanding these components is essential for implementing an Information Security Management System (ISMS) that conforms to the ISO 27001 standard. Information Security Management System (ISMS) At the heart of ISO 27001 is the Information Security Management System (ISMS), a systematic approach to managing sensitive company information. The ISMS encompasses people, processes, and IT systems by applying a risk management process. It helps organisations safeguard their information in a way that is efficient, consistent, and cost-effective. Establishing an ISMS is crucial for organisations aiming to protect their intellectual property, financial data, employee details, or any information entrusted to them by third parties. Risk Assessment and Treatment Information security risk management forms the cornerstone of an effective ISMS, providing guidelines for performing risk assessment and risk treatment. ISO 27001 requires organisations to perform regular assessments to identify the information security risks associated with their information assets. These risks are then analysed and evaluated to determine how they affect the confidentiality, integrity, and availability of the information. Following the risk assessment, an organisation must apply appropriate treatments to mitigate, transfer, accept, or avoid the risks. Documenting these risks and their treatments is vital for demonstrating compliance with ISO 27001. Statement of Applicability (SoA) The Statement of Applicability (SoA) is a critical document that outlines the control objectives and controls that are relevant to the organisation’s ISMS. The SoA serves as a declaration of which of the standard’s 114 controls from Annex A have been selected and applied within the organisation. It also provides justification for inclusion or exclusion of these controls, reflecting how each decision supports the management of information security risks. The SoA ensures that all stakeholders are aware of which controls are implemented and provides evidence of the organisation’s commitment to information security. Continuous Improvement ISO 27001 emphasises the importance of continuous improvement through the Plan-Do-Check-Act (PDCA) cycle. An iterative process ensures the ISMS remains effective and responsive to internal and external changes. By continually monitoring and reviewing the system’s performance, organisations can identify areas for improvement and take corrective actions. This not only enhances the efficiency and effectiveness of the ISMS but also aligns the organisation’s information security management practices with its evolving security landscape. In conclusion, the key components of ISO 27001 – ISMS, risk assessment and treatment, SoA, and continuous improvement – are integral to establishing, implementing, maintaining, and continually improving an ISMS. These components enable organisations to effectively manage and protect their information assets in the face of changing risks and challenges. 3. Structure of ISO 27001 ISO 27001 is meticulously structured to provide a robust framework for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It comprises several clauses, each focusing on different aspects essential for information security. Understanding these clauses and their significance is crucial for any organisation aiming to achieve compliance with the standard. Below, we delve into the key clauses of ISO 27001 and explain their roles in the framework. Clauses and their significance Context of the organisation This clause requires organisations to define the external and internal issues that can influence their information security objectives and determine what needs to be addressed in their ISMS. It emphasises understanding the needs and expectations of interested parties, thereby ensuring that the ISMS is aligned with the strategic direction of the organisation. Identifying and understanding the organisational context lays the foundation for an effective ISMS, as it guides the scope and implementation strategy of information security policies. Leadership Leadership focus is on the pivotal role leaders and top management play in the effectiveness of the ISMS. It mandates the commitment of top management towards the information security management system, requiring them to establish a security policy, define roles and responsibilities, and embed information security into organisational processes. Leadership ensures the integration of the ISMS into the organisation’s processes and that the necessary resources are available for its implementation and maintenance. Planning Planning pertains to the assessment and treatment of information security risks. Organisations are required to perform risk assessments to identify security threats, vulnerabilities and impacts. Based on this assessment, they must then decide on appropriate risk treatment options, whether it be avoiding, transferring, mitigating, or accepting the risk. This clause ensures that the organisation sets clear information security objectives and makes informed decisions to treat risks according to their severity and potential impact on the business. Support The support clause covers the resources, competence, awareness, communication, and documentation vital for the ISMS. It highlights the necessity of providing sufficient resources, training, and awareness for employees, ensuring effective internal and external communication about information security, and managing documented information required by the standard. Support ensures the smooth operation of the ISMS through adequate resources and communication. Operation This clause is about executing the plans and processes necessary to meet information security objectives. It involves the actual implementation of risk treatment plans, managing changes, and ensuring the security of processes. The operation phase is where an organisation puts into action its policies, controls, and procedures to mitigate and manage information security risks effectively. This phase includes implementing controls for various aspects of information security, such as access control, cryptography, and physical security. Performance Evaluation Performance evaluation focuses on monitoring, measurement, analysis, and evaluation of the security performance and the effectiveness of the ISMS. It includes monitoring and managing security incidents to minimise their impact. It involves regular reviews of information security performance, audits, and management reviews to ensure objectives are being met and continuous improvement is achieved. This clause helps in identifying opportunities for improvement and making necessary adjustments to the ISMS. Improvement The final clause stresses the importance of continual improvement of the ISMS. Based on the outputs from performance evaluation, organisations are required to act upon opportunities for improvement and address nonconformities with corrective actions. This ensures that the information security management system remains effective and resilient over time, adapting to changes in both internal and external contexts. Understanding the structure and significance of these clauses is the first step in implementing an effective ISMS aligned with ISO 27001. Each clause contributes to a comprehensive approach to information security, from understanding the organisational context and ensuring leadership commitment to planning, supporting, operating, evaluating, and improving the ISMS. 4. Benefits of ISO 27001 Certification Implementing ISO 27001 and achieving certification offers a myriad of advantages for organisations, ensuring the secure handling of information amidst an era where data breaches are unfortunately common. Here, we delve into the principal benefits derived from ISO 27001 and how they elevate an organisation’s information security and overall reputation. Enhanced Security of Information At its core, ISO 27001 is designed to protect three aspects of information: confidentiality, integrity, and availability. By adhering to the structured framework of ISO 27001, organisations can significantly improve their security measures, safeguarding sensitive data against unauthorised access and breaches. This rigorous protection extends across all data formats, including digital, paper-based, and cloud-stored data, ensuring comprehensive security coverage. Compliance with Legal and Regulatory Requirements The landscape of information security is heavily regulated by laws and standards, which can vary greatly across different jurisdictions. ISO 27001 Certification aids organisations in navigating these complex legal and regulatory requirements. It ensures that they are not only compliant with current legislation but are also well-prepared for future changes in data protection laws. This proactive compliance reduces the risk of legal penalties and the damaging repercussions that can follow non-compliance. Improved Risk Management A pivotal component of the ISO 27001 standard is its emphasis on risk assessment and management. By identifying potential risks to information security and implementing appropriate controls to mitigate these risks, organisations can preemptively counter threats and vulnerabilities. This forward-thinking approach enables companies to adapt to new risks as they emerge, maintaining the integrity and security of their information systems. Customer Trust and Confidence Customers are increasingly aware of the risks associated with the handling of their personal data. ISO 27001 Certification serves as a testament to an organisation’s commitment to information security, engendering trust and confidence among clients and stakeholders. This trust is invaluable for maintaining existing relationships and for cultivating new ones, as customers are more likely to engage with businesses they perceive as secure and responsible. Competitive Advantage In competitive markets, differentiation is key to standing out. ISO 27001 Certification provides a distinct advantage by demonstrating a verifiable commitment to information security. It acts as a mark of quality and reliability, distinguishing certified organisations from their competitors. This advantage is especially significant when tendering for contracts or expanding into new markets, where demonstrating compliance with international standards can be a prerequisite. In conclusion, ISO 27001 Certification bestows numerous benefits on organisations, from bolstering information security and ensuring legal compliance to enhancing customer trust and providing a competitive edge. These advantages collectively contribute to a robust information security posture, positioning certified organisations as leaders in their field. 5. The Certification Process The certification process for ISO 27001 is a sequential journey that corroborates an organisation’s adherence to best practices in information security. This process ensures that the established Information Security Management System (ISMS) is not only in place but is also efficacious and continuously improving. Here’s a detailed exploration of the steps involved in the certification process: Preparation and Gap Analysis Before diving into the certification process, an essential step is to conduct a comprehensive gap analysis. This preliminary stage involves a meticulous assessment of the current information security practices against the ISO 27001 standard’s requirements. It helps identify areas that require enhancement or complete restructuring, thereby setting the groundwork for implementing an ISMS tailored to the organisation’s specific needs. Implementing ISMS Post gap analysis, the next stride is the implementation of the ISMS. This phase is pivotal and requires developing policies, procedures, and controls dictated by the outcomes of the risk assessment and treatment plan. It encompasses the broader frameworks of information security goals, risk management strategies, and compliance measures. The implementation phase is iterative, demanding continuous feedback and modification to align with the organisational context and objectives. Internal Audit and Management Review Upon implementation, an internal audit is imperative to verify the effectiveness of the ISMS. This includes checking the compliance of processes with the standard’s requirements and evaluating the controls’ efficiency in mitigating information security risks. The internal audit fosters an understanding of how the ISMS operates in real-time scenarios. Following the internal audit, a management review is conducted. This step involves the senior management team reviewing the audit findings and ensuring that the ISMS remains suitable, adequate, and effective in safeguarding information assets while supporting the organisation’s strategic directives. Certification Audit Stages The certification audit is conducted by an accredited certification body and is bifurcated into two stages: Stage 1 (Documentation Review) This initial audit reviews the ISMS documentation, including policies, procedures, and the Statement of Applicability (SoA). The goal is to ascertain if the ISMS is designed conforming to the ISO 27001 standards before observing its operation in the workplace. Stage 2 (Main Audit): This involves a detailed, on-site audit to verify that the ISMS is effectively implemented and practiced across the organisation. It includes interviewing staff, reviewing operational practices, and assessing compliance with the ISMS requirements. Maintaining Certification Achieving ISO 27001 certification is not the culmination but rather a milestone in the ongoing journey of information security excellence. To maintain certification, organisations are required to conduct regular internal audits, engage in continuous improvement processes, and undergo surveillance audits by the certification body usually once a year. This ensures the ISMS’s persistent alignment with the changing information security landscape and organisational dynamics. In summary, the ISO 27001 certification process is comprehensive, demanding careful planning, commitment across the organisation, and an ingrained culture of continuous improvement. It’s a testament to an organisation’s dedication to maintaining the highest standards of information security. 7. Conclusion In recapitulating the essence and advantages of ISO 27001, it becomes apparent that in our increasingly digital world, the protection of information is not just a necessity but a responsibility. The standard serves as a robust framework for organisations to not only shield themselves against the myriad threats inherent in the digital landscape but also to structure their information security management processes in a systematic and comprehensive way. ISO 27001 certification empowers organisations with a competitive edge, enhancing customer trust and fulfilment of regulatory compliance. Its emphasis on continual improvement ensures that the management system evolves in lockstep with both the external environment and the internal growth of the organisation. By adhering to ISO 27001, companies affirm their commitment to safeguarding their most precious commodities—their information assets. Critical to the successful implementation of ISO 27001 is the understanding that information security is not a one-off project but a perennial journey. This journey demands ongoing vigilance, regular risk assessments, and a culture that prioritises security across all levels of the organisation. The challenges along this path are manifold, yet they are not insurmountable with a strategic approach grounded in best practices and learning from peers who have successfully navigated similar challenges. As we look towards the future, it’s clear that the digital landscape will continue to evolve at a breakneck pace, bringing forth new challenges and threats to information security. In this context, ISO 27001 stands as a beacon guiding organisations in their quest to protect their information assets in an ever-changing world. Its principles of risk management, continuous improvement, and leadership involvement remain pivotal. By embedding these principles into their operational ethos, organisations can anticipate, respond to, and mitigatively navigate the complexities of information security in our digital age. In conclusion, ISO 27001 is more than a standard; it is a commitment to excellence, a tool for transformation, and a blueprint for building a resilient and secure information ecosystem. Embracing ISO 27001 is, therefore, imperative for any organisation that aims to excel in today’s global digital economy while ensuring the security and integrity of its information assets.

The Sunk Cost Fallacy I watched "The Walking Dead" until it finished in Season 11. It lost its way as a show, and I was 'hate watching' it from about season 6 onwards. I watched approximately 110 episodes of a show I no longer loved because I'd invested time and effort in it and always hoped it'd get better (it didn't). This, in a nutshell, is the 'Sunk Cost Fallacy'. What is the Sunk Cost Fallacy? The sunk cost fallacy refers to a cognitive bias that compels individuals to continue an endeavour, investing in a project, activity, or decision based on the amount of resources (time, money, effort) they have already committed rather than on a rational assessment of the current and future costs and benefits of continuing the investment. How does it impact decision-making? Apart from making us watch TV shows much longer than we should (Smallville, I'm also looking at you), it makes us hold onto our investments of time, money, and other resources because of the resources we've already pumped into them. We continue beyond the point of reason because we've put so much into something. This fallacy affects various aspects of life: A project that should have stopped keeps going because of the level of investment. A losing betting run is continued as someone hopes to recover their losses. A career path that no longer fulfils you but you continue with because of the time you put into it. A TV show that keeps going long after its creative mojo has evaporated. Why do we do it? Humans tend to demonstrate a cognitive bias called 'loss aversion'. We hate writing off a loss. Studies have shown that we'd much rather avoid a $1 loss than make a $1 gain. The emotional energy invested in these decisions often clouds our judgment. Groups can fall into the trap even more so than individuals. I wrote an article on "groupthink" that touches on it. Still, sometimes peer pressure and shared responsibilities can lead to less individual accountability, and projects push well beyond tolerances, which should have otherwise stopped them because no single member feels the personal responsibility for the decision to stop. That, frankly, is a reason why you see so much hate and war in this world; people feel that they've invested so much over so many generations into something that they cannot stop and let go despite the harm it does to them. The Concorde Remember when we had a passenger plane that travelled faster than the speed of sound? No? Then you're probably relatively young. In 1976, the British and French governments saw the first flight of their joint venture, 'Concorde'. It could fly from London to New York in 3 hours. Compare this to the fastest flight today of about 5 hours. Well, despite being a technological achievement, early budgets of £70m started to be evident that would not be enough, and the project would not be commercially viable due to high operating costs and limited market demand; both governments continued to invest massive amounts of money over several decades to the tune of more than £1bn. The desire to recoup the substantial sunk costs and achieve the project's ambitious goals led to continued investment long after it was apparent that the project was unlikely to turn a profit. While Concorde made a nice profit for British Airways later in life, the investment by the British and French governments was far more than their original intent, and the taxpayers picked up that bill. How to Avoid the Sunk Cost Fallacy Avoiding the sunk cost fallacy requires a mixture of self-awareness, discipline, and a willingness to make tough decisions based on the present and future rather than being anchored to the past. And, of course, knowing when a TV show has 'jumped the shark'. Here's how you can sidestep this psychological trap: Acknowledge the Fallacy First, it is crucial to recognise that the sunk cost fallacy exists and understand how it can cloud judgment. By being aware of this bias, you're better prepared to identify when you're making decisions influenced by sunk costs rather than logical assessments. Evaluate Decisions Objectively When faced with a decision, objectively evaluate the current situation and prospects. Ask yourself, "What are the benefits and costs of continuing this investment?" and "If I were not already involved in this project, would I still enter it today based on the current information and prospects?" Seek External Opinions Sometimes, we're too close to a project or decision to see it clearly, so seeking external opinions can provide a fresh perspective. Friends, colleagues, or mentors might offer insights you hadn't considered, helping counteract biases towards continuing an unprofitable course of action. But be careful, they bring their own biases with them! Establish Predefined Criteria Setting predefined criteria for a project or investment can help. These should include clear goals, budgets, and timelines. If the project exceeds these parameters, it might be time to reassess its viability. This approach helps to remove emotion from the decision-making process, focusing instead on predefined benchmarks. Embrace Failure as a Learning Opportunity Changing our perspective on failure can also mitigate the sunk cost fallacy. I nstead of viewing failed investments of time, money, or effort as losses to be avoided, consider them as learning opportunities. Each "failure" can provide valuable insights and experience that contribute to personal and professional growth. Know When to Cut Losses The most challenging aspect of avoiding the sunk cost fallacy is knowing when to cut losses. It's a lot easier said than done. It requires courage to admit that continuing an investment is no longer justified. Remember, resources spent on unprofitable endeavours could be allocated to more promising opportunities. Implement Incremental Decision Making Break down decisions into smaller, incremental steps. This approach allows for regular reassessment of a project's or decision's viability, making it easier to pivot or abandon based on current realities rather than past investments.

Projects can and do go horribly wrong. Before we explore how to avoid the pitfalls, here are some sobering statistics. Statistics from https://www.projectmanagementworks.co.uk/project-failure-statistics/ We use tried and tested project management techniques and tools to tip the balance between success and failure in our favour (which is 'success', to be on the clear side). What is a Project? I'm sorry to have to do this, but let's quickly start at the beginning because I'm always surprised by how many people get confused about what a project actually is. A project is a temporary endeavour to create a unique result. Unlike routine 'business as usual' operations, projects have a defined beginning, specific objectives to fulfil, and completion criteria. It's important to understand that a project has a definable end, after which it closes. So, if you find yourself in a project that doesn't know its destination, ask serious questions. Projects also tend to draw from across functional teams in an organisation. So, they often involve people who infrequently work with each other. Finally, projects are typically fraught with pitfalls because they are risk-laden adventures into the unknown. The degree of risk is unique to each project, but if you know in detail what you are doing and have done it many times before, it's not a project; it's a standard operating procedure. That said, you can have templated projects, like building a house. Overview of Project Management Project management methodologies and practices have evolved over the years, adapting to changing industry landscapes (such as software development) and increasing project complexity (such as software development). Traditional methodologies, like the Waterfall model, follow a linear and sequential approach, going step-by-step from requirements to delivery. It's a nice, ordered, logical approach but not very adaptable to change. Newer, more flexible and adaptive frameworks like Agile, Scrum, and Lean are designed to deliver more iterative and incremental results, enabling teams to respond quickly to changes in requirements and stakeholder feedback. The approaches deliver a little bit, check if it's okay with the stakeholder, do a bit more, rinse, and repeat until done. The choice of methodology depends on the project's nature, objectives, and specific requirements. No single approach works for every delivery, and no approach is exclusive – you can mix and match them to suit your needs. The following guide is designed more around the waterfall approach, but it doesn't mean that Agile practices can't be added to the execution phases. The Project Life Cycle The project life cycle describes the phases of a project from initiation to closure. These phases are: Initiation: Defining the project at a broad level and establishing its feasibility. Planning: Detailing the scope, defining the objectives, and developing the project management plan to achieve those objectives. Executing: Implementing the project plan and executing the tasks to deliver the project's outputs. Monitoring and Controlling: Tracking progress, managing changes, and ensuring project objectives are met within the defined scope, time, and cost. Closing: Finalising all activities across all project management process groups to formally close the project or phase. We'll explore these in more detail as we go. The Project Management Triangle There are three main constraints that all projects are trying to control: scope, time and cost. The project management triangle, also known as the 'triple constraint,' is a model that demonstrates these constraints, their interrelationship, and how changes in one factor can impact the others. Here's a brief overview of each: Scope: This refers to the size of the project, the goals to be achieved, and the requirements to meet those goals. It defines what will be delivered as the project outcome, including the tasks, features, and functions. Time: This encompasses the schedule or timeline for completing the project. It involves determining the project phases, key milestones, and final deadlines. Cost: Also known as the budget, this pertains to the financial resources available for the project. It includes all expenses such as labour, materials, tools, and other costs needed to deliver the project. The principle behind the triangle is that if any of these constraints change, it will impact the other two. For instance, if the project scope expands (more features are added), it will likely take more time and increase costs. Similarly, reducing the timeline might increase costs (due to the need for more resources to work faster) or reduce the scope (fewer features can be realistically completed in a shortened time). This is an essential concept because it demonstrates how a small impact in one of the constraints can significantly impact the others. Project managers must walk a tightrope; allowing the project to lean a little too much in one direction unchecked can lead to catastrophic outcomes. Importance and Benefits of Effective Project Management By adhering to established project management principles, organisations can achieve their strategic objectives within the allocated time and budget, ensuring the efficient utilisation of resources (or at least doing much better than without it). The following sections summarise some of the main advantages of employing sound project management practices. Enhanced Efficiency and Productivity A structured project provides a roadmap that leads to project completion. By defining clear objectives, milestones, and deadlines, project managers can oversee the systematic progression of tasks, leading to an uptick in efficiency and productivity. So, it's critical to bring clarity and control to a project, and guess who is central to that? You. You ensure the project knows where it is, what it's doing, and where it's going. Improved Risk Management Risk management is a crucial part of any project manager's responsibilities. By foreseeing potential pitfalls and planning accordingly, project managers can minimise the impact of risks when they turn into realities. A proactive stance on risk management helps safeguard the project and ensures it stays on track regarding its budget and timeline. It's impossible to see or prevent every risk that might happen, but you can, at the very least, think about the big ticket ones you can predict and ensure you have a plan. Enhanced Customer Satisfaction The ultimate goal of any project is to fulfil the client's requirements - delight the customer. Delivering what you think they want rather than what they need is a recipe for disaster. Effective project management ensures that projects deliver 'the right thing right', increasing customer satisfaction, happiness and karma. Satisfied clients are more likely to engage in repeat business and provide positive referrals, which is imperative for an organisation's (or project manager's) reputation and long-term success. Optimal Resource Allocation Resource allocation is a critical aspect of project management, involving the efficient distribution of tasks and the judicious use of time, budget, and human resources. Let's face it: all teams are stretched, and resources need to be carefully aligned so that they can deliver the most significant benefit to the organisation. Effective project management ensures that resources are allocated optimally - avoiding people sitting around doing nothing or stretched too thinly. It also ensures you get the biggest bang for your buck, thus maximising the project's return on investment (ROI). Improved Team Coordination and Communication Project management fosters a cohesive team environment by promoting transparent and consistent communication. A project manager can ensure that everyone works towards a common goal by keeping all team members informed about project objectives, progress, and changes. Without this kind of roadmap, chaos seeps into the project, little by little, until everyone walks their path, expecting different outcomes and benefits from the project. An American colleague once referred to this as the 'Goat Rodeo', which made me smile and is now a metaphor I often refer to. This is perhaps the most critical aspect of project management to me. Without this kind of unification and agreement on goals, tasks, dependencies and commonality, the project will go off the rails. If you can keep the communication going in all directions, you'll increase your chances of project success exponentially. That's so important, I will put it in a box. So, that's the basic part done, let's look next at the project phases in a little more detail. Key Terms and Concepts Let's tick off some terms I may have thrown around and not explained fully. Stakeholder A stakeholder is any individual, group, or organisation that may affect, be affected by, or perceive themselves to be affected by a project's decision, activity, or outcome. Stakeholders can directly or indirectly influence the project and its success. Scope The scope of a project refers to the detailed set of deliverables or features of a project. It includes all the work required to complete the project successfully. Managing scope is crucial as it prevents 'scope creep', which is the project's expansion beyond its initial objectives, often causing budget and time overruns. It's always important to clarify what is out of scope as much as within the project's scope. Work Breakdown Structure (WBS) A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. WBS is a key project deliverable that organises the team's work into manageable sections. Gantt Chart A Gantt chart is a type of bar chart that illustrates a project schedule. It shows the start and finish dates of the various elements and a summary of the relationships between the elements of a project. Gantt charts help plan and schedule projects and track project components' progress. Senior managers love looking at a Gannt Chart. It provides them with a level of false confidence that their project is delivering. Critical Path The Critical Path is the longest path/sequence of tasks that must be executed to reach the end of a project. The tasks on the critical path are called critical activities because if they're delayed, the project itself will be delayed. Image from https://acqnotes.com/acqnote/tasks/critical-path-critical-path-method?utm_content=cmp-true Risk Management Risk Management involves identifying, assessing, and responding to project risks to minimise their impact on project objectives. It includes risk identification, analysis, response planning, monitoring, and control. Prince2 PRINCE2 (Projects IN Controlled Environments) is a structured project management method and practitioner certification programme primarily used in the UK, which emphasises dividing projects into manageable and controllable stages. It is a process-based approach that guides a project's high-level management, control, and organisation.

How to Manage an ITSM System Implementation Are you seeking to transform your IT service management (ITSM) capabilities by implementing a new tool? According to a Freshworks survey, 81% of IT leaders believe ITSM can enhance employee productivity and efficiency. A Forrester Research report reveals that 59% of organisations have either implemented or plan to implement ITSM tools to improve customer experience. Getting it wrong can be easy, as there are numerous significant pitfalls. I've seen it implemented well and badly over the years, and you do not want it to be the latter. This article is independent of any ITSM service providers and will guide you through the steps to craft a successful ITSM implementation project plan. It will also provide you with some templates that have been tried and tested over 15 years of ITSM and project implementations, getting you off to the best possible start. It will help you; Create an overall project plan Define your requirements Evaluate marketplace options Select a vendor Handle data migration Customise your tool Plan your testing & training approach Document Templates Several supporting document templates that can kick-start an ITSM Implementation Project Plan are included. There are many others over in the Templates section of the site that may also help, including; Project Charter Template Project Budget Tracker ITSM Implementation Steps The following are the steps involved in the ITSM implementation process, emphasising the importance of effective communication and education: Define Requirements: Document your needs in terms of must-have / could-have requirements. Identify & Evaluate: Explore the marketplace, draft a top 5, and arrange demos. Then, seek a hands-on trial with the top 2. Select a Vendor: Make a final selection based on requirements, budget and due diligence. Plan Implementation: Define a delivery plan, potentially with the vendor's support. Effective project management is crucial in defining a clear and achievable delivery plan. Data Migration: Move any data into the system (users, legacy data, assets, etc.) Configure & Customise: Configure workflows, teams, categories, SLAs, etc. Training: Train your team on how to use the system. Ensure any administrators are confident in making changes. User Acceptance Testing: Have the team test the system to ensure it works as expected. Go-Live: Launch with communications to the organisation. Review & adapt. The service desk plays a vital role in the launch and review process. Key Recommendations - Before You Start Nothing Good Comes Easily Approach the project with the mindset of delivering iteratively. Identify where value can best be added to your processes and focus there. 48% of organisations self-assess their ITSM capabilities as "great" or "good." 27% are "getting there," indicating ongoing improvement efforts. 22% acknowledge they have "still much to improve upon" in terms of ITSM capabilities (Invgate statistics) Building something too complex and aiming for nirvana from day one is neither practical nor controlling risk and scope. Adopting an agile methodology can help in delivering iteratively. Build. Review. Iterate. Keep it simple and avoid protracted procurement processes Wrapping yourself up in a protracted procurement process is best avoided if possible. It is understandable if you have a strongly defined procurement process that requires evaluating and scoring options and business case approvals. However, the most difficult decisions are often when we are overwhelmed with choices or there are no wrong choices. I've seen teams get procurement fatigue, and the projects die just because they feel they need to get hands-on with everything or the vendors start to control the procurement process. Shortlist > Get Demos > Go hands-on with two > Make a choice. Seek management support for the investment first You don't go to buy a car for yourself before you have decided: a) you need one, and b) you have the budget. So, the same applies here. A lot of wasted time can be avoided if you know you have strong managerial support for change before evaluating solutions. If you do have that support right up front, it'll make every step much more manageable. The vendors will sit up and notice you better if they think you have budget approval. The team will engage better, too, as will other stakeholders. Step 1: Gather Your ITSM Requirements So, the first step in any procurement process is to define what you need. Even if it's relatively simple, collect your requirements. Typically, the requirements will come from multiple stakeholders, so engage them well and don't fall into the trap of telling people their requirements. If they have needs, they should express them but may require a little coaching to do so. I can't define your requirements for you, as everyone's needs are unique, but as a basic starter to get you going, here are some general areas of consideration that most would be exploring from any software evaluation. Requirement Groups Functional Requirements Core Features: The essential functionalities that the application must provide to meet your business needs, including incident management. User Experience: How intuitive and user-friendly the application is, including its learning curve and interface design. Integration: The ability of the application to integrate with other systems and platforms within your IT ecosystem. For example, do you need it to integrate with 365 or Google or Salesforce? Customisation: How easily the application can be tailored to fit specific business processes and requirements. Technical Requirements Architecture: The technical foundation of the application, including considerations for scalability, performance, and compatibility. How big could this thing get? Security: Security features and compliance with relevant standards and regulations to protect data and users. Data Management: How the application handles data input, storage, retrieval, and export, including backup and recovery processes. Portability: The ability of the application to run on various platforms or environments if necessary (e.g. laptops, tablets, mobile devices, etc) Financial Requirements Cost: The total cost of ownership, including initial purchase, implementation, training, support, and maintenance costs. Licensing: The licensing model of the application and how well it fits with your usage expectations and budget constraints. ROI Expectations: Expected return on investment, including efficiency gains, cost savings, and other financial benefits. Support and Maintenance Vendor Support: The level and quality of support provided by the vendor, including availability, response times, and support channels. Updates and Upgrades: How the application is kept current with updates and upgrades, and the associated costs and processes. Training: Availability and quality of training resources or services to ensure effective use of the application by staff. Compliance and Standards Regulatory Compliance: Compliance with relevant industry regulations and standards. Data Protection: Adherence to data protection laws and guidelines, ensuring the privacy and security of user data.  Is GDPR important in terms of user data? Vendor Viability Vendor Reputation: The reputation and stability of the vendor in the market. Customer Reviews: Feedback from current and past customers regarding their experience with the application and vendor. Future Roadmap: The vendor's commitment to the future development of the application, ensuring it will continue to meet your needs. The template below will walk you through a more detailed exploration of requirements if needed. Capabilities for Consideration Here are some initial suggestions of requirements to consider; Service Reporting & Resource Management Visualisation and analysis of the ITSM platform and integrated data for service costing, improvement, and resource utilisation, including Dashboards Historical reporting and trend analysis Predictive analytics Case Management The platform can easily be adapted to manage tasks and processes related to IT and other business operations without using a separate tool for automating business processes or a platform specifically designed for creating applications with minimal coding. Service Level Management The tool should be able to manage service-level agreements, including tracking SLA performance and generating SLA-related reports. Workflow Automation & Integration ITSM applications can make IT operations more efficient by automating repetitive tasks and connecting different actions across the ITSM platform. This is made possible with the help of a tool that lets you design and manage complex processes, coordinating various tasks and systems. Automation in ITSM implementations can minimise disruptions and take advantage of the latest technologies. So look for something that can allow you to configure processes without too much training and development. Multichannel Engagement Look to see if the ITSM system can directly provide, or integrate with other solutions, for the delivery of IT service experiences across various channels and devices, including; Mobile apps Live chat Virtual agents (AI tools), User portals for logging issues with a request catalogue Forums Knowledge base IT Support Enablement Processes, recommendations, and automation to enable IT support functions, including incident management, problem management, integrated observability, and knowledge management. A service catalog is crucial as it provides a structured list of IT services, enabling efficient and effective IT support functions. Service Configuration Management Federated system of record for relationships and performance of IT service components, enabling efficient and accurate decisions regarding IT service delivery. At the very least, you'll likely want the solution to integrate with your asset and user management systems, so that you can assign the incidents and requests to the correct people and equipment. Adaptive Change & Release Control governance and risk in production environment changes through automation, standard change models, integration with DevOps tools, and release and deployment oversight. Integrated AI Application of AI and analytics within ITSM platforms to improve staff efficiency, effectiveness, and error reduction by augmenting ITSM processes, field recommendations, proactive support, and data-driven automation. Integrations Integrating IT Service Management (ITSM) tools with existing systems is a pivotal strategy for organisations aiming to streamline their IT services and enhance operational efficiency. The following articles from Workato and Exalate provide comprehensive insights into the essence, benefits, and practical examples of ITSM integrations, shedding light on how these integrations can transform IT service delivery. ITSM, at its core, is about delivering IT services in a structured and consistent manner, ensuring that the right services are provided to the right people, at the right time, and in the right way. ITSM tools, such as ServiceNow, BMC Helix, Zendesk, and Atlassian Jira Service Management, play a crucial role in this process by offering a centralised platform for managing all aspects of service delivery. These tools facilitate a range of functions, including incident management, problem management, knowledge management, request management, asset management, change management, and configuration management. The integration of ITSM tools with other systems is a process that connects the ITSM platform with other applications using third-party tools that leverage application programming interfaces (APIs). This connection allows for the synchronisation of data and the automation of workflows across different platforms, thereby enhancing efficiency and reducing manual errors. For instance, integrating an ITSM tool with an engineer's ticket management system can expedite the resolution of technical issues by ensuring that engineers are promptly notified and can address the problems swiftly. The benefits of ITSM integration are manifold. Firstly, it eliminates data silos, making crucial information accessible across different applications and to all relevant stakeholders. This accessibility improves decision-making and operational efficiency. Secondly, ITSM integration enhances both the customer and employee experience by streamlining service delivery and onboarding processes, respectively. It also minimises human errors that can lead to costly disruptions. Lastly, ITSM integration is a stepping stone towards digital transformation, enabling organisations to implement end-to-end automations that can fundamentally change how they operate. However, implementing ITSM integration is not without its challenges. Common pitfalls include inadequate planning, selecting the wrong integration solution, and failing to engage all stakeholders effectively. To ensure a successful integration, organisations should follow best practices such as thoroughly planning the integration process, choosing a compatible and scalable integration solution, establishing clear communication channels, and continuously monitoring and adjusting the integration to meet evolving business needs. Some Suggestions Tip: Always write down your requirements. Have a version you can share with suppliers so they can respond directly in their presentations or responses to each need, and you can compare apples with apples. Most vendors will ask for this if not presented with it anyway; they'll want evidence of how much their solution fits your requirements. Tip: Know your must-have / should-have / could-have requirements and categorise them as such. Use something like the MoSCoW model to define your priorities. Tip: If possible, draft a 3-year plan Where do you want this product to go? How will the business change in that period? What external or internal factors might change? Would you require future integrations with other services? Would you expand into other service areas, such as Change or Inventory management? Tip: Know your budget, and don't allow yourself to be pulled in by vendors Early discussion about budget ranges and what you can afford may significantly influence which solutions you evaluate. There's no point walking into a Rolls-Royce showroom if you only have a few thousand dollars to spend. Vendors will often be reluctant to share pricing with you at the start of the journey, so if pricing is going to be a significant issue, ask for rough budgetary order of magnitude figures from them right up front or look for organisations which are transparent and publish their pricing on their websites. Step 2: Evaluating ITSM Vendors Broadly ITSM solutions will fit into the following categories; free/open source mid-range premium The table below is a summary of the options and significant differences. However, overlap will always exist as these categories have no hard lines. Marketplace Options Stepping into the ITSM marketplace can be overwhelming. There are so many options, and they all claim to be best for you. It's crucial to consider vendor management when evaluating these marketplace options to ensure you choose the right solution for your needs. The following are not recommendations or endorsements but simply some starting points of the most well-known solutions on the market. They are not affiliated / advertising links. Free / Open Source Options Investigating and understanding what you are and are not getting with these solutions is crucial. For example, some have advertising within them, some have limited functionality, and others are without backup solutions. Mid-Range Options These are widely used and solid choices, with years of product evolution, supporting materials and configuration options available. Premium Options These market-leading options have the broadest range of features and customisation choices. Guidance To Help Evaluate ITSM Vendors Use resources such as 'Gartner's Magic Quadrant for ITSM' Many vendors offer the report for free if it reflects well on them Be careful of any websites that claim to compare solutions for you. They may position themselves as independent, but on closer examination can be found to be application vendors themselves. That said, here are some commonly used sites that collect software reviews that may be helpful. Consider the configuration and onboarding carefully Some organisations have thought through the entire customer journey and have onboarding resources dedicated to making implementation successful. Others will throw the software at you. Evaluate your needs and options here carefully. Success often lies not in the functionality but in the implementation. Change control plays a crucial role in ensuring successful configuration and onboarding. Give any existing solution a fair evaluation It may be that you 100% know the limitations of any current solution if you already have one and are keen to move away from it. However, don't throw the baby out with the bathwater; ensure you have thoroughly exhausted your existing solution by exploring the requirements you have drafted with the incumbent vendor. You'll avoid a lot of egg on your face and unnecessary costs if you evaluate your existing tools carefully and give them a fair shake of the stick. Step 3: Select a Final Vendor In this step, you'll select the most suitable vendor based on the evaluation process conducted in Step 2. How you select your ITSM solution will be done to a host of parameters unique to your circumstances and requirements that you need to evaluate, but make sure you are doing this consistently and fairly for each option. For example, if you don't see a feature in one solution that appears in another, ask the vendor if it exists; don't just make assumptions. Ultimately, it would be best if you had just two or three options that it comes down to. However, if you are privileged to know which solution is right for you without too much deliberation, I recommend just going for it, especially if its in the Gartner magic quadrant. Always follow internal procurement guidelines and demonstrate your evaluation and recommendation in a business case. Others may need to know how the decision was reached. Review the vendor evaluations Revisit the evaluations you conducted in Step 2, 'Identify & Evaluate Vendors', noting each vendor's strengths and weaknesses. Pay special attention to their ability to fulfil your requirements and any additional features or capabilities that may add value to your help desk operations. The best way to analyse options is to put them into a matrix, such as a spreadsheet, and numerically score each solution against consistent criteria. Maybe some score more highly in certain areas that look good but are weak in the mandatory features. Compare costs Evaluate each vendor's pricing models, considering the initial setup costs, ongoing maintenance fees, and any additional costs for customisation or integrations. Factor in your budget and the potential return on investment (ROI) the tool can provide. I always recommend looking at the total cost of ownership over three years. Some suppliers will give an artificially low cost in year 1, substantially increasing the costs through years 2 and 3. They know it is tough to move once locked into their software. Vendors may be low in one area, such as licencing, but high in another, such as integrations with other applications and tools. Make sure they are being transparent and upfront with their costings. Check references and customer testimonials If you want additional confidence, contact other clients to understand their experience with the tool and the vendor's support services. It'll likely be a part of any procurement process in a larger organisation. In addition, online reviews and testimonials can provide valuable insights into the tool's performance and user satisfaction (see Gartner & Capterra in the previous section). Consider vendor stability and reputation. Research the vendor's stability, financial health, and standing in the industry. Choosing a well-established vendor with a proven track record reduces the risk of disruptions due to financial issues or lack of support. Sometimes the Finance or Procurement teams in an organisation can help here. This is especially important if you don't have much information on an organisation or they don't appear on many evaluation platforms (i.e. Gartner). You could be an early adopter of new technology, offering significant benefits and drawbacks. Assess vendor support and responsiveness. Evaluate the quality of the vendor's support services, including their response times, availability (24/7 or business hours only), and communication channels (phone, email, chat). Service level agreements (SLAs) are crucial in evaluating vendor support and responsiveness, as they define the expected service standards and response times. Selecting a vendor with reliable support services can help ensure a smooth implementation process and minimise potential issues during operation. Dig around on their website, read their help materials and get a sense of their offering. Great support can make or break a relationship. It can be very telling by evaluating how much the vendor engages with you during the early days and how much support they are willing to offer you in onboarding and migration. Someone once referred to this as the 'get out of bed index', which means if you call a vendor early one morning because you have a problem, will they jump out of bed and get to it because they value your custom, or will they treat your organisation as one among many, and roll over and go back to sleep? Service level agreements can provide insight into this level of commitment. Ensure scalability and future-proofing Consider whether the ITSM tool can scale and adapt to your organisation's future needs, such as growing user bases, additional features, or integration with other systems. Choose a vendor capable of supporting your long-term goals and growth plans. This refers to the earlier discussion on our three-year plan for the ITSM solution and any modular add-ons. Weigh the pros and cons Review all the information gathered during the evaluation process, and weigh the pros and cons of each vendor. Then, create a shortlist of the top contenders, and discuss the options with your team and stakeholders to reach a consensus. That said, while consensus is great, don't attempt to make decisions by committee. It should be no more than 2 or 3 people making a decision and a final recommendation. Decision-making owner(s) and accountability should be clearly defined from the outset. Negotiate terms and conditions Once you've chosen the preferred vendor, negotiate to secure favourable terms and conditions. This may include pricing, service level agreements (SLAs), support services, and customisation options. Generally, if the supplier publishes its licencing prices on its website transparently, it won't negotiate. However, if they keep their price book closed and are coy about pricing, you have more room for manoeuvrability. Always act keen but cool. You want the vendor to believe you are interested in their product but have options and don't have to choose them. If pricing is at the discretion of the salesperson, then they'll pressure you at month, quarter or year-end for the revenue so they can make their sales targets. This can be annoying as they pester you every five minutes, but valuable if you deliberately wait to engage them at one of these points. Terms and conditions are likely non-negotiable for larger organisations, so I wouldn't even try. However, with smaller vendors, there is always an opportunity to be more explicit about expectations around support and maintenance. Critical contract considerations to allow you to select a vendor Important things to always review in any contract, whether you can negotiate them or not, are; Payment terms Be clear on how invoicing will work. There can be a significant difference for a CFO in paying everything up-front rather than quarterly or monthly. Most small or medium organisations like to smooth their cash flow to regular payments rather than sudden annual spikes. Termination terms Understand clearly how and when you can terminate your licence agreement. For example, if you are committed to the vendor for a period, you need to know for how long and under what circumstances (i.e. poor performance) you can terminate early and what that process looks like. Also, check the terms about exporting your data. Some organisations may charge extra to help you migrate or may not even let you take your data. It's worth knowing the boundaries. Warranties/service credits If the performance is poor, how does the vendor experience that pain? Do they have service credits or a money-back scheme? What motivation do they have for providing excellent service? Step 4: Planning The ITSM Implementation Process This implementation project plan will help guide your team through the process and ensure a smooth transition. Project planning is a skill that requires a whole training course just for the subject, but these guidelines provide a generic implementation plan, which you can adopt and adapt to help you plan out your implementation. Establish objectives and success criteria. Begin by defining success criteria and key performance indicators (KPIs) to measure the project's progress and outcomes. These should come directly from your objectives as outlined in your requirements document from Step 1, "Document Your Requirements". Performance metrics play a crucial role in defining success criteria, as they provide quantifiable data to assess whether the project meets its goals. Create a project timeline. Develop a realistic project timeline outlining the key milestones, tasks, and deadlines for each phase of the implementation process. This should include planning, data migration, configuration, customisation, training, user acceptance testing (UAT), and go-live. A template is provided at the end of the chapter for a suggested approach, but it is only a starting point, and many other things need consideration. Assemble the project team. Form a cross-functional project team with representatives from IT, the help desk, and other relevant departments. Assign roles and responsibilities, such as project manager, implementation lead, training coordinator, and system administrator. Engage with your stakeholders! Any significant groups impacted by the change should be brought into the project to help shape it and make it a success. Even if your team is small, and the decision-making sits with you, engage the wider team(s) and ensure they buy into the vision and new direction. If you don't, they will likely feel excluded, and that change is being made to them rather than them playing a part in it. I firmly believe in finding your most prominent critics or most likely resisters and bringing them close. Develop a communication plan Create a plan to keep stakeholders informed and engaged throughout the implementation process. This may include regular status updates, progress reports, and project meetings. A template is provided for creating such a plan in the templates section. Define system architecture and infrastructure Work with the vendor and your internal IT team to determine the appropriate system architecture and infrastructure for the new ITSM solution, considering scalability, performance, and security factors. Of course, this will entirely depend upon your hosting options and other parameters, but make sure you are engaging with any technical teams as early on in the process as possible. I've seen simple implementations prohibited from progressing because infrastructure and security teams are involved too late, and fundamental considerations were not addressed. Plan for data migration Develop a data migration plan to transfer relevant data from your current helpdesk system (if it exists) or other tools into the new ITSM solution. This may include user accounts, historical tickets, knowledge base articles, and configuration items. Again, this is difficult to specify in detail, but you will want to identify your data stores, transfer method and the cutover point when the previous solution is no longer needed. More information about data migration is in the lesson Step 5 - Data Migration. Plan for configuration and customisation Identify any necessary system configurations and customisations to align the new ITSM solution with your organisation's processes, policies, and branding. This may involve configuring workflows, fields, forms, and notifications and integrating them with existing systems. More information is in Step 5 - Configuration & Customisation. It's a suggestion, but accept out-of-the-box configuration options wherever possible. While it might sound counter-intuitive, most systems will have tried and tested processes based on best practices ready to run with much less configuration needed than adapting to tool to meet your complex existing processes. Modifying your rules to meet the tool's default configuration is often a better approach. Again, I recognise that it's counter-intuitive but worth strong consideration. Develop a training plan Create a training plan to ensure all helpdesk staff and relevant stakeholders are familiar with the new ITSM solution's features and functionality. This may include vendor-provided training, in-house sessions, and self-guided resources. Training is discussed more fully in Step 7 - Training. Plan for user acceptance testing (UAT) Develop a UAT plan to validate that the new ITSM solution meets your organisation's requirements and success criteria. This should involve representative users who will test the system, provide feedback, and sign off on the final implementation. Dropping in an untested solution over the top of existing business processes could cause disruption and demotivate the team. Step 8: User Acceptance Testing, explores UAT. Prepare for go-live Plan the go-live process, including the steps to transition from the old helpdesk system to the new ITSM solution, such as data cutover, system activation, and user onboarding. Develop a contingency plan to address any potential issues during the go-live process. By following these guidelines and creating a thorough implementation plan, you'll be better prepared to manage the complexities of implementing your new helpdesk ITSM solution and achieving your project objectives. See Step 9 "Go Live" for more information. Step 5: Considering Data Migration Planning Successful data migration ensures the new system is accurate, functional and delivers the expected business benefits. This section will explore considerations to remember if you want to bring data over from a legacy system. Identify the data to be migrated be migrated to the new system and why. Prioritise business-critical data and consider removing or archiving obsolete, redundant, or low-quality data to minimise complexity and ensure a clean start in the new system. It can be beneficial to draw a line under the old system and only bring across a few bits of critical data, or even none at all. Perhaps the old system can be maintained as a legacy system for reference if necessary, or everything could be exported to PDF documents and filed. There may be ways in which data migration can be minimised or even avoided. If you can avoid it, it will make your life easier. Robustly challenge why you must migrate data and who needs it for what purposes. It could save you a big headache. Select the data migration approach Choose a data migration approach that best aligns with your organisation's goals, resources, and the data's complexity. Common approaches include: Big bang: migrating all data at once, typically during a scheduled downtime Phased: migrating data in smaller chunks over time Parallel: running both old and new systems concurrently for a period while gradually transitioning data Develop a contingency plan Plan for the possibility of unexpected issues or setbacks during the migration process. Develop a contingency plan that outlines steps to mitigate risks, address potential data loss or corruption, and ensure business continuity. Always be in a position where if the migration steps don't work as expected, you can always go back and try again later. Test, validate, and monitor the migration process Test the data migration process before going live. I'm just going to repeat that. Test the data migration process before going live. I watched a project I was not directly involved in crash and burn spectacularly because the data migration exercise was an afterthought. Validate the migrated data to confirm the accuracy and monitor the process closely to identify and address any issues promptly. Post-migration support and optimisation After the migration, monitor the new ITSM solution and address any issues or gaps. Use this opportunity to optimise processes and workflows, refine the system configuration, and implement continuous improvement initiatives. Suggested Steps For A Data Migration Plan Data assessment & inventory Identify data sources and types, assess data quality, and create a data inventory. Data mapping & transformation rules Define the mapping between source and target systems, and specify any required data transformation rules. ETL testing & data validation Test the process in a non-production environment, validate data integrity, and fix any issues. Data cleansing & migration Clean and migrate helpdesk tickets, user data, historical incident records, documents, and IT asset data. Data reconciliation & cleanup Reconcile migrated data, identify discrepancies, and clean up residual data or differences. Post-migration monitoring & support Monitor the system after migration, and provide support to address any migration-related issues. Step 6: Configuring & Customising the Tool Configuring and customising an ITSM tool to the organisation's unique requirements and aligning it with its processes and workflows is crucial. Understand the out-of-the-box capabilities. Before starting the customisation process, gain a thorough understanding of the out-of-the-box features and capabilities of the ITSM solution. As previously mentioned, there is great value in leveraging these features as much as possible to reduce the need for extensive customisation, which can increase complexity and hinder system updates and upgrades. Adhere to best practices and vendor guidelines for configuring and customising the ITSM solution. This minimises the risk of issues, ensures optimal performance, and simplifies future upgrades. Determine required customisations Identify the gaps between your organisation's requirements and the ITSM solution's out-of-the-box capabilities. Then, determine which customisations are necessary and prioritise them based on their impact on achieving your needs. Balance customisation with simplicity. While customisations may be necessary to meet unique requirements, strive to maintain simplicity in the system configuration. Excessive customisation can complicate the system, increase maintenance costs, and make upgrades more challenging. Document configuration and customisation Maintain detailed documentation of all configurations and customisations, including their rationale and expected outcomes. This documentation is crucial for reference, troubleshooting, and future system upgrades. Test and validate configurations and customisations. Thoroughly test and validate all configurations and customisations to ensure they meet the organisation's requirements and function as expected. Include key stakeholders in the testing process to gather valuable feedback and identify potential issues early on. Tasks To Configure an ITSM Tool Define and configure incident management processes and workflows Set up incident categories and subcategories Establish and configure priority levels, impact, and urgency definitions Define and set up escalation points and rules Create and configure service level agreements (SLAs) for incident resolution Configure automated notifications and alerts for incidents Customise incident forms and fields to capture the required information Set up incident assignment rules (e.g., based on categories, skills, and availability) Configure and customise user roles and access permissions for incident management Integrate incident management with email, chat, and other collaboration tools Set up incident reporting templates and analytics to track performance metrics Configure knowledge base integration for incident resolution (e.g., auto-suggest articles) Establish procedures for major incident management,, including communication channels and stakeholder involvement Step 7: Staff Training The successful implementation of an IT Service Management solution hinges on practical training, as it empowers staff members to harness the system efficiently and deliver optimal benefits. If activity is ad-hoc or poor materials are provided, the project will likely crash or be poorly responded to. Here, we'll explore essential advice and considerations for crafting a dynamic, results-driven ITSM training plan. Gauge Training Requirements Assess your helpdesk staff's skill sets, current knowledge, and roles. Pinpoint the skills and competencies required to proficiently use the new ITSM solution and address any knowledge gaps through targeted training initiatives. Collaborate with key stakeholders across various departments, such as IT, helpdesk, and other relevant business units. Their input and support will help tailor training content to organisational goals and requirements. For example, there will be different types of users of your system, including. Help Desk / Technical Analysts People needing to create dashboards & reports (likely management or team leaders) Those that need to configure the workflows and system options Those that support the infrastructure and database needs. Of course, depending upon the organisation, these could be one or many people, but by grouping the roles and defining their needs, you plan more effectively. Craft an Engaging Training Plan Develop a comprehensive, immersive training plan detailing objectives, content, delivery methods, schedules, and necessary resources. Customise the plan to cater to staff members' needs, including new hires, experienced personnel, and managerial roles. Employ a mix of training formats, including instructor-led sessions, online courses, workshops, and hands-on exercises, to accommodate diverse learning styles and preferences. This strategy will enhance the learning experience and bolster knowledge retention. Integrate hands-on exercises and simulations that allow staff members to navigate the new ITSM solution in a controlled environment. This approach will instil confidence, reinforce learning, and deepen comprehension of the system's features and workflows. Create explicit, concise, compelling training materials like guides, tutorials, and cheat sheets to supplement learning. Ensure these resources are easily accessible and updated regularly to stay current with system or process changes. Foster Knowledge Sharing Cultivate a culture of knowledge sharing by inspiring staff members to exchange experiences, tips, and best practices related to the ITSM solution. Facilitate this through discussion forums, team meetings, or mentorship programs. Commit to Continuous Training and Support Acknowledge that training is an ongoing process, offering continuous learning opportunities for staff members. Provide refresher courses, advanced training sessions, and access to relevant resources to keep staff abreast of system updates and best practices. I've witnessed teams implement solutions only to have team members leave. Then the team is now in a position whereby it no longer knows how to administrate its software, paying for costly consultancy to reverse engineer workflows and other parts of the configuration. Ensure Training is Before UAT For those contributing to the User Acceptance Testing of workflows and other configuration or integration settings, ensure the users have had sufficient training on the system before or as part of their UAT Testing tasks. Suggested Training Plan Step 8: ITSM User Acceptance Testing ITSM User Acceptance Testing (UAT) verifies that the new system fulfils your needs, functions as intended, and yields the anticipated benefits. In this section, we'll delve into the essential considerations during the UAT stage of an ITSM implementation. You should engage stakeholders from various departments, including the help desk, the wider IT team, and other pertinent business units. In addition, involving end-users is crucial, as their feedback and insights help ensure the system aligns with their needs and expectations. You only need to test those parts you have configured or customised. Let's assume the vendor has thoroughly tested their product. Design realistic test scenarios, use cases & acceptance criteria Craft test scenarios and use cases that mirror real-world situations and challenges helpdesk staff might face to get the most out of testing. These scenarios should encompass the entire processes and workflows. Here are some examples; Incident submission and categorisation: A user encounters an issue with their email client and submits an incident ticket through the self-service portal. The test case should verify that the ITSM tool correctly captures the incident details, categorises it under the appropriate service (e.g. software - email), and assigns it an initial priority level based on the issue's impact and urgency. Incident routing and assignment: An incident ticket is created for a software bug affecting multiple users. The test case should ensure that the ITSM tool routes the ticket to the appropriate support team or technician based on predefined assignment rules, such as team expertise, workload balance, or location. SLA enforcement and escalation: A high-priority incident with a strict SLA that requires a resolution within four hours is logged. The test case should verify that the ITSM tool effectively tracks the time spent on the incident, sends notifications to relevant parties when the deadline is approaching, and automatically escalates the issue to higher-level support or management if the SLA is breached. Major Incident test: A complex major incident requires collaboration between multiple support teams, such as networking and software development. The test case should ensure that the ITSM tool enables seamless communication, knowledge sharing, and status updates between all involved parties and provides a clear record of the incident's resolution process for future reference. Incident closure and user feedback: A helpdesk technician resolves an incident, and the ITSM tool marks it as resolved, sending an automatic notification to the user. The test case should verify that the user can confirm the resolution, provide feedback on the service quality through a satisfaction survey, and access a knowledge base article for future reference or self-help, if applicable. The ITSM tool should also automatically update the incident status to closed and document the resolution details for reporting and analysis purposes. Allocate adequate time and resources. Ensure ample time and resources are dedicated to the UAT stage. Hastily conducting UAT or scrimping on resources can lead to insufficient testing, resulting in undetected issues and a system that falls short. Testing needs to balance the risk and complexity of the implementation. It's for you to assess and decide what is right. One of the primary factors contributing to this underestimation is the lack of understanding and appreciation for the complexity and scope of the testing process. Many projects may assume that testing is straightforward and primarily involves identifying and resolving bugs. However, they may fail to recognise the intricacies of creating comprehensive test scenarios, ensuring adequate test coverage, and managing the time and resources required for thorough testing. Another reason is the optimism bias. Teams may have an overly optimistic outlook on the project's progress and assume the implementation will proceed smoothly, with few issues or bugs to address during the testing phase. This mindset can lead to inadequate allocation of time and resources for testing, ultimately resulting in a rushed and ineffective testing process. Moreover, the pressure to meet deadlines and budget constraints can also influence teams to cut corners regarding testing. Monitor and prioritise issues Keep a log of issues identified during UAT and prioritise them based on their impact on the system's functionality, user experience, and help desk goals. Then, swiftly address high-priority issues and iteratively fine-tune the system as required. I recommend using a basic scale of 'must do' / 'should do' / 'could do' / 'won't do' to prioritise issues for remediation. Everything defined as s 'must' has to be fixed by go-live. Anything categorised as 'should' comes next and, if possible, is resolved. 'Could' items can be tolerated, and 'Won't do' things speak for themselves. After addressing issues, validate and verify the solutions to ensure they have been effectively handled and don't introduce new problems (in the test biz, we call this 'regression testing'). Finally, re-test affected functionality and workflows to confirm the system satisfies the acceptance criteria. Once UAT is completed, obtain sign-off from key stakeholders and end-users to confirm that the ITSM solution fulfils the organisation's requirements and is prepared for deployment. Example UAT Plan Step 9: ITSM Go-Live Planning The go-live stage marks the transition from implementation to operational use. Ensuring a successful go-live and maintaining the system's performance beyond this stage is crucial for realising the full benefits of the ITSM solution. This section on ITSM go-live planning will discuss advice and considerations for going live and beyond. Craft an impeccable go-live plan I know it's the old 'insert a small miracle here' part, but from experience, having an all-encompassing go-live plan meticulously outlines the steps, timelines, resources, and roles is a pillar of a smooth transition. It should read as an instruction manual of who is doing what and when so that there is no ambiguity left during the go-live phase and everyone is clear on their responsibilities. Conduct a rigorous pre-launch assessment Before taking the plunge, perform an in-depth review of the ITSM solution to verify that all aspects, from configuration and customisation to data migration and training, have been met. Then, double-check that all issues identified during UAT have been resolved and that the system is primed for deployment. It is often valuable to have your go-live plan in two parts; 1. Acceptance / Readiness Plan This outlines everything necessary for the various stakeholders to issue 'green flags' for the project to proceed with the implementation. It forms a kind of checklist of criteria that you can review as a final step before the launch. Before launch, you confirm that all green flags are raised. 2. Customer Implementation Plan This summarises how you will communicate and engage with your customers. What do they need to know? What is the plan for communicating with them? Is it a series of more minor communications or more extensive training sessions? Will you release a new customer portal on day one or after a few weeks? Go live with minimal ripples To keep disruptions at bay, consider scheduling the go-live during a period of low help desk activity, like after-hours or weekends. Communicate the transition plan and potential downtime to help desk staff and end-users, ensuring they're in the loop. Deploy a robust support system Establish a strong support structure during the initial go-live period to assist help desk staff and end-users. This could be a dedicated support team ready to tackle questions, concerns, or any issues during the transition. Be ready to swiftly address any issues or concerns during the go-live process and beyond. Establish a streamlined process for logging, prioritising, and resolving problems while informing all stakeholders about progress and resolutions. And After... Keep a watchful eye on performance and adoption Monitor the ITSM solution's performance and user adoption diligently during the go-live phase and beyond. Keep track of crucial metrics, such as system response times, user satisfaction, and incident resolution times, guaranteeing that the system delivers on its promises. Cultivate a culture of continuous improvement I've found that fostering a culture of continuous improvement, where helpdesk staff and end-users are encouraged to provide feedback and suggestions for system enhancements, can work wonders in refining the ITSM solution to better align with organisational needs and objectives. Offer unwavering training and support Training and support are ongoing endeavours. Continue to provide helpdesk staff and end-users access to resources, refresher courses, and advanced training opportunities, ensuring they remain proficient with the ITSM solution and can adapt to any changes or updates. ITSM Go Live Planning Activities Go-Live Preparation Activities The following summarises the tasks needed before sign-off from the Project Sponsor to approve the production release. Review the overall project status and confirm all key milestones have been met Confirm completion of data migration, system configuration, customisation, and integrations. Conduct a final review of the system setup, including roles, permissions, and workflows Verify that all required documentation (user guides, technical manuals, etc.) is available Confirm completion of user training and ensure all users have the necessary knowledge to use the system Perform final User Acceptance Testing (UAT) to validate system functionality Review and address any open issues or concerns raised during UAT Develop a detailed go-live schedule, including a cutover plan and rollback plan (if needed) Communicate the go-live schedule and expectations to all stakeholders Prepare the IT support team for handling potential issues during the go-live phase Confirm availability of resources to monitor system performance and address issues post go-live Obtain final sign-off from relevant stakeholders to proceed with go-live Go-Live Activities The following tasks will be triggered when approval to implement the solution has been finalised in the previous step and scheduled through the change management process. Execute the cutover plan, switching from the old ITSM system to the new one Monitor system performance and connectivity during the transition Verify that all data, customisations, and integrations are working as expected Confirm that users can successfully access and use the new system Establish communication channels for users to report issues or seek assistance Communicate the successful go-live to all stakeholders Decommission the old ITSM system, if necessary Post-Go-Live Monitoring and Snagging Following implementation, we will monitor the solution for one week through the following actions. Monitor system performance, response times, and overall stability Track and address user-reported issues, questions, or concerns Review system logs for any unexpected errors or performance issues Hold regular status meetings to discuss system performance, user feedback, and open issues Implement any required system updates or patches Optimise system configurations based on actual usage patterns and user feedback Perform a post-implementation review to assess the success of the project Identify and prioritise areas for further improvement or enhancements Embracing Continuous Improvement in ITSM Implementation A successful ITSM implementation doesn't end with the deployment of tools and processes; it evolves into a continuous journey of improvement and adaptation. As highlighted by Cask NX, LLC, and Info-Tech Research Group, the dynamic nature of IT services and the ever-changing demands of businesses necessitate an ongoing commitment to refine and enhance ITSM practices. Monitoring for Ongoing Improvements Post-implementation, it's crucial to establish a robust monitoring system that tracks the performance of your ITSM processes against predefined key performance indicators (KPIs). Cask NX, LLC emphasizes the importance of identifying and evaluating essential success metrics to adapt business processes as ITSM progresses. This proactive approach ensures that ITSM services remain aligned with business objectives and user expectations, facilitating a smoother digital transformation journey. Feedback Loops and Iterative Enhancements Incorporating feedback mechanisms is vital for capturing insights from IT staff, end-users, and stakeholders. This feedback should be quantitative and accurately reflect costs, business effects, and the overall customer experience. As suggested by Info-Tech Research Group, creating a feedback loop augments implementation progress according to end-user feedback, enabling iterative enhancements. Regularly reviewing feedback helps identify areas for improvement, ensuring that ITSM tools and processes continuously evolve to meet the organisation's needs. Applying DevOps as an ITSM Best Practice Adopting DevOps principles within your ITSM strategy, aligns with the continuous improvement methodology. This approach involves incremental changes in development, feature testing, release, and deployment, fostering a culture of continuous delivery and quality assurance. By outlining the ITSM implementation project's endgame and measuring vital success criteria regularly, organizations can enhance service quality and reduce waste, thereby achieving operational excellence. Case Study Background In an SME organisation, the fragmentation of support systems across various teams presented significant operational challenges; Teams utilised disparate systems for logging and tracking incidents, changes, bugs, and knowledge, leading to inefficiencies and communication barriers. This setup necessitated multiple logins for users and manual case transfers between systems, complicating the incident resolution process and knowledge sharing. Problem Statement The lack of a unified system led to several critical issues: Multiple Logins: Users were burdened with navigating multiple systems, complicating their workflows. Manual Case Transfers: The absence of integration necessitated manual transfers, increasing the risk of errors and delays. Visibility and Traceability Issues: It was challenging to track incidents and locate knowledge across different systems. License Duplication: Financial resources were wasted on duplicating licenses for different systems. Lost Tickets: The disjointed system led to tickets being overlooked or lost, hindering timely action. Change Management: Without a central register or forward schedule of change, the organisation reacted to changes rather than proactively managing them. Solution After evaluating various solutions, the organisation decided to implement Monday.com, despite it not being a dedicated ITSM tool. The decision was based on its: Flexibility: Monday.com offered the adaptability needed to tailor workflows to the organisation's specific needs. Intuitive Workflow Configuration: The platform's user-friendly interface facilitated easy setup and management of workflows. Broad Applicability: Beyond ITSM, Monday.com could be utilised for project management and other business workflows, offering a versatile solution. Implementation The implementation process was meticulously project-managed, with a focus on collaboration with Monday.com's onboarding team to tailor the platform to the organisation's needs. Key steps included: Workflow Development: Team leads, with minimal support, could develop most workflows themselves thanks to the platform's intuitive design. Data Migration: A selective migration strategy was employed, transferring some historical data via spreadsheets and utilising an easy import facility. Training: Adopting a 'train-the-trainer' approach, key business leads were equipped to disseminate knowledge within their teams, fostering a culture of advocacy for the new system. Testing: An informal yet critical phase of UAT allowed for the refinement of process flows before full deployment. Go-Live and Beyond: The initial success of the go-live was amplified by subsequent evangelist-led sessions, comprehensive training materials, and continuous feedback loops with both internal stakeholders and the supplier. Outcomes The transition to Monday.com significantly improved operational efficiency by: Consolidating Systems: Reducing the need for multiple logins and manual case transfers. Enhancing Visibility: Facilitating easier tracking of incidents and access to knowledge. Optimising Resources: Eliminating license duplication and ensuring resources were utilised effectively. Improving Change Management: Establishing a proactive approach to change management with a central register and forward schedule. Conclusion The organisation's strategic decision to adopt Monday.com as a unified platform for support systems marked a pivotal shift towards streamlined operations. The careful planning, inclusive training approach, and ongoing engagement with the platform have cultivated a more efficient, proactive, and collaborative work environment. This case study exemplifies the transformative potential of flexible, user-friendly technology solutions in addressing complex operational challenges. About the Author: Alan Parker is a seasoned IT professional with over 30 years of experience in the industry. He holds a Degree in Information Systems and is certified in ITIL and PRINCE2. Alan has managed diverse IT teams, implemented key processes, and delivered successful projects across various organisations. Since 2016, he has been a sought-after consultant in IT governance and project management. Alan excels in simplifying complex problems and avoiding common pitfalls in IT management. Learn more about his journey and expertise here.

Project management is an intricate discipline, and project complexity plays a significant role in the success or failure of a project. In this ever-evolving landscape of project management, it is crucial to understand and manage the complexity of projects effectively. One such tool that has gained traction among project managers is the project complexity matrix. This post unravels the concept of project complexity matrix, its components, and various tools and techniques to manage project complexity successfully, and provides a few tools and templates to help out. Key Takeaways Project Complexity Matrix is a tool used to assess the complexity of projects by evaluating external, internal, technological and environmental factors. Projects can be categorized into three levels based on organizational, operational & technological factors as well as individual resource communication team stress and role factors. Tools such as project management software, communication strategies & resource allocation techniques are essential for successful project results. Defining Project Complexity Matrix Project complexity refers to the totality of all factors that may influence the ultimate result of a project. Recognizing and appraising the hazards associated with a project, along with devising tactics to reduce those risks, entails determining project complexity. One of the project management tools that helps in determining project complexity is the project complexity matrix, which comprises the following factors: External factors Internal factors Technological factors Environmental factors A project manager can ascertain the complexity of a project using various tools and techniques, such as the Darnall-Preston Complexity Index (DPCI). The DPCI evaluates complexity across four categories: External complexity Internal complexity Technological complexity Environmental complexity These categories contribute to evaluating project complexity, helping to determine project complexity. Purpose of Project Complexity Matrix The project complexity matrix assists project managers in assessing risks, allocating resources, and making informed decisions for the attainment of successful project results, which may require further research and analysis. The advantages of utilizing a project complexity matrix in project management include enhanced comprehension of project complexity, suitable management approach, augmented decision-making, improved project planning and control, and augmented project success rate, all of which can be assessed using a complexity score. A Project Complexity Matrix aids risk evaluation by providing a structure to gauge a project’s complexity level, taking into account factors such as funding, budget, size, and number of stakeholders. It also assists in resource allocation in project management by classifying projects according to their complexity, which can be divided into three categories: simple, moderately complex, and highly complex. This categorization contributes to successful project outcomes through decision making by determining project rigor, providing executive oversight, guiding planning and control, and aiding in resource allocation, all of which require a high degree of understanding and management. Components of Project Complexity Matrix The project complexity matrix encompasses diverse factors including resources, goals, risks, integration, communication channels, roles, and stress levels that add to project complexity. Team size and composition, project duration, schedule, cost and scope flexibility, clarity of the problem and solution, stability of requirements, strategic importance, degree of organizational change, inter-project dependencies, political sensitivity, and utilization of unproven technology are some of the factors which affect the complexity of a project. The way these factors are handled play a crucial role in making the project successful. In the project complexity matrix, the following elements determine a project’s complexity: Resources: The quantity required, their accessibility, and the level of coordination and communication between them. Goals: The degree of project rigor required to successfully finish the project and attain the desired goals. Risks: Introducing uncertainty and potential difficulties that can influence the project in various ways. Assessing Project Complexity Using a Matrix Approach The matrix approach in assessing project complexity is a methodology that utilises a matrix or tool to evaluate and categorise the complexity of a project. It involves the identification and analysis of various indicators or descriptors to determine the level of complexity associated with the project. The matrix provides a framework for project teams to assess and comprehend the complexity of a project, which can assist in making informed decisions and implementing appropriate risk management and assurance measures. Identifying key factors in project complexity using a matrix approach involves steps such as determining the project lifecycle size, evaluating project duration, assessing organizational complexity, scrutinizing project requirements, assessing technology readiness, and considering resource availability. Examples of a project complexity matrix may vary depending on the approach or framework employed, but common factors generally considered include structural complexity, people resources, governance and lifecycle requirements, organizational factors, and operational and technological factors. Identifying Key Factors Factors that contribute to project complexity include: Team size Project duration Schedule Cost Scope flexibility Clarity of problem/solution Stability of requirements Strategic importance Organizational change Inter-project dependencies Political sensitivity Unproven technology These factors need to be kept in mind while undertaking any project. For instance, team size can contribute to project complexity in several ways, such as larger teams having more communication channels, which can increase the complexity of coordinating and managing the project. Project duration significantly influences project complexity; as the duration lengthens, complexity grows due to the involvement of more tasks, dependencies, and stakeholders, thus making the project intricately challenging to manage. The project schedule also plays a vital role in a project’s complexity, as a stringent and inflexible schedule may augment the complexity, whereas a pliable schedule allows for modifications and can decrease complexity by accommodating unforeseen changes and uncertainties. Rating Project Complexity Rating project complexity requires assigning scores to each factor and employing tools like the Darnall-Preston Complexity Index to ascertain the overall complexity level. The Darnall-Preston Complexity Index (DPCI) is a project profiling technique that evaluates the complexity of a project based on various attributes including: External factors Internal factors Technological factors Environmental factors When assessing a project’s complexity, factors such as: Size of the project Objective scoring criteria Level of rigor required in initiating the project Main factors influencing project complexity Factors that influence at least 80% of a project’s complexity Environmental complexity are taken into account. Several tools can assist in assigning scores to each factor of project complexity, including the Project Complexity Assessment and Management (PCAM) Tool and Scoring models, which provide a structured approach to evaluating and ranking the various factors of complexity, thereby aiding project managers in effectively managing project complexity. Categorizing Projects Based on Complexity Projects can be categorized into three complexity levels: Simple: These projects have straightforward requirements and resource needs. Moderately complex: These projects involve some level of complexity in terms of organizational, operational, and technological factors. Highly complex: These projects have high levels of complexity, involving multiple factors such as individual, resource, communication, team stress, and role factors. An important factor plays a role in determining the complexity of a project. The requirements and resource needs for different types of projects vary: Simple projects have straightforward requirements and resource needs. Moderately complex projects necessitate a more diverse set of skills and resources. Highly complex projects entail extensive requirements and resource needs, often requiring specialized expertise, advanced technology, and a substantial investment of time and resources to manage and execute successfully. Simple Projects Simple projects are characterized by having clearly defined objectives, minimal potential risks, and requiring fewer resources and communication channels. Some examples of simple projects may include organizing a fundraiser or conducting a home renovation project. Resource allocation in simple projects is typically managed by: Identifying the available resources, such as labor, materials, and equipment Assigning them to specific project tasks Strategically planning and scheduling the resources to ensure they are utilized efficiently and effectively in order to achieve the desired outcome. Moderately Complex Projects Moderately complex projects involve more resources, higher risks, and increased communication channels; however, they still maintain manageable objectives and requirements. Examples of moderately complex projects could encompass innovating an everyday process improvement or consolidating a business office. The primary difficulties encountered in managing moderately complex projects include budgetary matters, establishing explicit goals and objectives, communication, a lack of responsibility, and unrealistic deadlines and expectations. Highly Complex Projects Highly complex projects typically possess multiple objectives, present high risks, necessitate numerous communication channels, and necessitate significant resources and coordination. Examples of highly complex projects include designing a portfolio management office or implementing a financial system. It is common to experience issues such as inadequate communication, absence of explicit goals and objectives, expansion of scope, insufficient skills and resources, and selection of an inappropriate methodology when carrying out highly intricate projects. Tools and Techniques for Managing Project Complexity A variety of tools and techniques can be employed to effectively manage project complexity. These include: Project management software Communication strategies Resource allocation techniques Insights from past experiences By utilizing these tools and techniques, project managers can tackle the challenges posed by complex projects and enhance the success rate of their projects. Project management software streamlines the organization of tasks, monitoring of progress, and proficient management of resources. Clear and effective communication is essential for managing project complexity, as it facilitates the establishment of clear communication channels and protocols, encourages stakeholder engagement, promotes transparency, and enhances collaboration and teamwork. Resource allocation techniques for managing project complexity include utilizing a project management software to track resources, constructing a resource plan, and employing a resource leveling technique. Project Management Software Project management software tools facilitate the organization of tasks by providing a centralized platform wherein tasks can be generated, delegated, and monitored. These tools enable users to form task lists, set due dates, delegate duties, and track progress. Additionally, they offer features such as task dependencies, task prioritization, and task visualization, which aid in the organization and management of tasks efficiently. With project management software tools, teams can cooperate, communicate, and remain organized, guaranteeing that tasks are accomplished on schedule and within budget. Project management software facilitates tracking project progress by supplying tools and features that enable project managers to observe and analyze project tasks, collaborate and communicate, establish milestones and deadlines, and create reports and visualizations. The most suitable project management software for managing complex projects includes GanttPRO, ClickUp, Asana, Celoxis, Wrike, HoneyBook, WorkOtter, Flowlu, GitHub, and Trello. Communication Strategies Effective communication strategies are essential for ensuring seamless coordination among team members and stakeholders. Examples of effective communication strategies include regular meetings, clear communication of expectations, and open dialogue between team members and stakeholders. By employing these strategies, project managers can ensure smooth coordination among team members and stakeholders, thereby reducing complexity and risks associated with project management. Resource Allocation Techniques Resource allocation techniques optimize the use of resources, minimize stress levels, and ensure project success. The most effective resource allocation techniques for highly complex projects include: Critical path analysis Critical chain method Resource leveling Resource smoothing Software that supports resource allocation in project management includes Mavenlink, ProjectManager, ClickUp, Monday.com, Runn, Nifty, Teamdeck.io, Float, Forecast, and eResource Scheduler. Results and Lessons Learned Analysis of results and leveraging past experiences are crucial for boosting the management of complex projects in the future. Lessons learned contribute to the enhancement of project complexity management by averting the recurrence of errors, disseminating optimal practices, and encouraging a culture of perpetual advancement. Examining and applying lessons learned assists project teams to detect inventive approaches and work practices that can be employed to manage complex projects more proficiently. Summary In summary, understanding and managing project complexity is crucial for project managers to ensure the success of their projects. This blog post has provided insights into the concept of the project complexity matrix, its components, and various tools and techniques to manage project complexity effectively. By employing these tools and techniques, project managers can tackle the challenges posed by complex projects and enhance the success rate of their projects. Remember, a well-managed project is a successful project. Frequently Asked Questions What are the 4 types of project complexity? Project management experts Remington and Pollack identify four types of complexity that influence project selection: structural, technical, temporal, and directional. What is the complexity matrix in project management? The Project Complexity Matrix is a tool which helps project teams identify the risk and assurance requirements and appropriate tools sets relative to the complexity of the project, allowing for better informed decisions. How do you calculate project complexity? Project complexity is calculated by considering the number of resources involved in the project, as well as other factors such as design complexity, integration of legacy code, type of content management used and geographical distribution. These elements help to measure the scope of a project and determine its overall complexity. What is the patient complexity score? The patient complexity score ranges from 0 (no complication or comorbidity) to 4 (very severe complication or comorbidity), calculated using a complex algorithm for each treatment episode. What are the three levels of project complexity? Project complexity can be divided into three levels: simple, moderately complex, and highly complex, depending on the resources needed and the project requirements.

Introduction Purpose The primary aim of infrastructure and platform management is to ensure that an organisation’s technological base, comprising hardware, software, networks, and facilities, is robust, efficient, and capable of meeting current and future needs. Infrastructure and Platform Management practice is crucial for monitoring, managing, and supporting IT services, facilitating effective service delivery that aligns with the business's strategic objectives. Scope The infrastructure and platform management scope spans the entire lifecycle of infrastructure solutions, from the initial planning and design phase to deployment, operation, and eventual retirement. This comprehensive approach includes the management of both physical and virtual infrastructure components, ensuring that they are optimally configured, maintained, and upgraded as needed to support organisational operations and objectives. Key Benefits Implementing adequate infrastructure and platform management yields several significant benefits, including: Enhanced Efficiency: Streamlined processes and improved resource allocation reduce waste and increase productivity. Strategic Alignment: Ensuring the IT infrastructure aligns with business goals facilitates more targeted and practical support for organisational objectives. Improved Service Delivery: A well-managed IT infrastructure supports high-quality, reliable service delivery, enhancing user satisfaction and trust in IT services. Basic Concepts of Infrastructure & Platform Management Below are the primary definitions and explanations: IT infrastructure encompasses all hardware, software, networks, and facilities required to develop, test, deliver, monitor, manage, and support IT services. It is the physical and virtual components that form an organisation's technological backbone. Service Value System (SVS): An overarching model that illustrates how all an organisation's components and activities work together to facilitate value creation through IT services. Infrastructure management is an integral part of the SVS, ensuring the operational integrity and performance of IT services. Technology Planning involves strategically aligning technology solutions with business needs, encompassing activities from understanding organisational requirements to deploying and managing IT infrastructure. An effective technology plan ensures the IT infrastructure can adapt to and support business strategies and changes. Processes The infrastructure and platform management practice involves a series of processes that ensure effective management throughout the lifecycle of IT infrastructure. These processes are categorised into three main areas: Technology Planning, Product Development, and Technology Operations. Technology Planning Technology planning is crucial for aligning IT infrastructure with business objectives and ensuring the organisation's technological foundation supports its strategic direction. It includes: Analysing the organisational strategy and architecture to determine infrastructure needs. Developing and agreeing on infrastructure and platform management includes defining the scope, sourcing strategies, and methodologies. Reviewing the management approach periodically to adapt to changing business needs and technological advancements. Product Development This process focuses on designing and implementing infrastructure solutions that meet specific organisational requirements. It involves: Creating basic and detailed solution designs that align with organisational standards and goals. Sourcing, developing, and configuring components as per the designed solution. Validating and testing the solutions to ensure they meet the required specifications before deployment. Supporting deployment and release into the live environment, ensuring seamless integration with existing systems. Technology Operations Once the infrastructure solutions are deployed, technology operations ensure their ongoing performance and reliability. This includes: Managing queries and events involves addressing incidents and problems to maintain service levels. Performing scheduled tasks such as backups, system updates, and maintenance to ensure system integrity and security. Patching and updating systems to address security vulnerabilities and improve system performance. Relationship with Other Practices Infrastructure and platform management is not isolated but is deeply interconnected with several other ITIL practices, enhancing its effectiveness and integration within the overall IT service management framework. Here are key relationships with other practices: Architecture Management Infrastructure management works closely with architecture management to ensure that all infrastructure solutions are aligned with the organisational policies and standards. This alignment supports the efficient delivery of robust, scalable, and secure IT services. Service Design and Business Analysis The integration with service design and business analysis ensures that infrastructure solutions are designed and implemented to meet the business's specific needs. This collaboration helps in translating business requirements into technical specifications that guide the infrastructure development process. Risk Management and Information Security Management Collaboration with risk management and information security management is critical to safeguarding the IT infrastructure's e integrity, availability, and confidentiality. These practices help identify, evaluate, and mitigate risks associated with the infrastructure, ensuring that security considerations are embedded from the outset. Capacity and Performance Management Infrastructure management must be supported by capacity and performance management to ensure that IT services meet their current and future demands. This practice involves planning for adequate resource allocation and performance tuning to maintain service levels. Incident and Problem Management The relationship between incident and problem management practices is vital for swiftly addressing and resolving infrastructure failures and disruptions. These practices ensure that issues are systematically addressed, root causes are identified, and corrective measures are implemented to prevent future occurrences. Roles & Responsibilities Effective infrastructure and platform management relies on clearly defined roles and responsibilities to ensure that all processes are executed efficiently and align with the organisation's. Here are key roles typically involved in this practice: Infrastructure Specialist Infrastructure specialists are the backbone of the practice and are responsible for managing IT infrastructure components. They ensure that all hardware, software, networks, and facilities are optimised and effectively support service delivery and business operations. Site Reliability Engineer (SRE) Site reliability engineers focus on automating the infrastructure processes to enhance reliability and performance. They apply software engineering principles to resolve operational problems and manage the systems' scalability and efficiency. Architects and Business Analysts Architects design the overall infrastructure architecture that aligns with the business's strategic needs. Business analysts work alongside them to ensure that the technical solutions meet the precise business requirements and contribute effectively to business goals. Product Owners In infrastructure management, product ownership is crucial in defining the vision for infrastructure projects, prioritising tasks, and ensuring that developments align with the business objectives and stakeholders' expectations. Technical and Operations Administrators These roles involve monitoring, maintaining, and supporting IT infrastructure to ensure its optimal performance and availability. They are crucial in implementing changes and updates without disrupting business processes. Implementation Advice Implementing adequate infrastructure and platform management practices requires thoughtful planning and execution. Here are some key metrics and things to avoid that can guide you in establishing and maintaining a robust practice. Key Metrics To measure the success and efficiency of infrastructure and platform management, consider the following key performance indicators (KPIs): System Uptime: Measures the availability of the IT infrastructure, aiming for the highest possible uptime percentage. Incident Response Time: The time during which infrastructure issues are addressed and resolved. Capacity Utilisation: Ensures that IT resources are used efficiently, neither underutilised nor overtaxed. Change Success Rate: Gauges the success of changes implemented in the infrastructure, aiming for a high percentage of successful updates without causing system disruptions. These metrics provide tangible targets to strive for and can help continuously improve management practices. Things to Avoid While implementing infrastructure and platform management, some common pitfalls should be avoided: Over-Complexity: Avoid creating overly complex systems that are difficult to manage and maintain. Simplicity should be a key goal in design and operational processes. Siloed Operations: Do not allow infrastructure management to become isolated from other IT practices. Integration and collaboration across practices enhance effectiveness and responsiveness. Neglecting Documentation: It is crucial to adequately document infrastructure changes, configurations, and processes; otherwise, it can lead to significant challenges in maintenance and troubleshooting. Ignoring Stakeholder Feedback: Listening to feedback from users and stakeholders involved with or affected by the infrastructure is crucial. Their insights can lead to significant improvements in service delivery. Frequently Asked Questions To aid in understanding and implementing infrastructure and platform management, here are responses to some commonly asked questions about this practice: What is the importance of infrastructure and platform management in an organisation? How does infrastructure management relate to IT service management? Infrastructure management is a core component of IT service management (ITSM). It ensures that the IT infrastructure can support the service delivery processes, aligning with ITSM's broader goal of providing value to the business through IT services. What should be considered when planning infrastructure improvements? When planning improvements, consider current and future business requirements, technological advancements, and potential risks. Planning should also involve stakeholders from various departments to ensure the infrastructure aligns with the overall business needs and IT strategy. How can we measure the success of infrastructure and platform management? Success can be measured using system uptime, incident response times, capacity utilisation and user satisfaction rates. Regularly reviewing these metrics will provide insights into the effectiveness of infrastructure management practices. What are some common challenges in infrastructure and platform management? Common challenges include managing the complexity of modern IT environments, ensuring security across infrastructure layers, integrating new technologies, and aligning IT infrastructure with rapid changes in business requirements. About the Author: Alan Parker is a seasoned IT professional with over 30 years of experience in the industry. He holds a Degree in Information Systems and is certified in ITIL and PRINCE2. Alan has managed diverse IT teams, implemented key processes, and delivered successful projects across various organizations. Since 2016, he has been a sought-after consultant in IT governance and project management. Alan excels in simplifying complex problems and avoiding common pitfalls in IT management. For more details, you can view his journey and expertise here.

Introduction to RAG Status Reporting In project management, understanding a project’s status is crucial. Utilizing project management tools, such as software and dashboards, is a great way to visually represent this with the RAG system: (R)ed, (A)mber, and (G)reen, commonly referred to as RAG reporting. This method assesses and communicates the status of a project using color categorization to indicate progress and potential issues. Effectively, you use colour coding of status for items in your project management reports to bring attention to certain points. In your report, you might have a summary of deliverables, such as the following; The RAG status reporting is pivotal in communicating the overall project status, identifying areas that need attention, and determining corrective action. This article is a comprehensive guide to RAG status, which delves into the critical aspects of RAG ratings, from the basic rag status definitions to their application in project reports. A free download of the Project Status / Highlight Report Template What is a RAG Rating? RAG stands for Red, Amber, Green—the traffic light system used to indicate the health of various elements within a project, often referred to as a RAG status; indicators which offer a quick, subjective assessment of a project’s health based on clearly defined criteria. Project management tools are often used to implement RAG status reporting, aiding in project reporting, portfolio management, and visual RAG status reports for project health and decision-making. RAG reporting involves defining the status criteria, such as what constitutes red, amber, or green, and interpreting these colors to communicate project status effectively. A RAG status reporting system is thus a widely used tool for project managers (PMs), senior management, and project sponsors. Red Status Red status signifies that serious issues are jeopardising the project delivery. If a project is in the red status, it’s a red flag for project managers to alert senior management. Project management tools can help identify and manage issues that lead to a red status by providing dashboards, project collaboration tools, and visual RAG status reports. These issues might relate to project budget overruns, poor project performance, or significant slippages in the project schedule. It’s really important that PMs define clearly what ‘Red’ means because it’s such a controversial thing to flag on a report. It’s highly visible (by design) and is making a bold statement. So, I recommend that you define each status on your reports and with your major stakeholders so that you all have a common understanding. For example, a while back, I put a status item on the report as red, meaning it was behind schedule and holding things up. I wrote alongside the commentary that we expected to resolve the issue in the next week and catch up. The CEO, however (and quite rightly) said, “I only want to see red on the report if the executive team need to intervene to ensure the project’s success”. I’ve run with that over the years, and it has served me well. However, one of the disadvantages of RAG reporting is the potential lack of trust in the reported status and the tendency to play it safe by reporting projects as green instead of amber or red. Amber Status An amber status is a cautionary sign. The project isn’t failing, but it’s not running smoothly either. Managers of projects should pay particular attention to amber projects, as they can quickly devolve into red projects if the underlying problems are not addressed. It’s a cardinal sin in some organisations to progress from Green to Red without going via Amber on status reports. Amber allows you to do something about a situation. It’s a way of highlighting that things aren’t going to plan but that you can take action to correct it. In short, I always explain amber as “We have an issue, but the project team can control it”. Green Status A green status indicates that the project is on track. All elements, from the project budget to the project schedule, proceed as planned. A green project requires less immediate management attention but should still be monitored to maintain its positive trajectory. Green is good. The Project Status Report A project status report (also known as a ‘highlight report’) is a document that provides a snapshot of the current progress and health of a project. Project management tools are often used to create and manage these project status reports. Project reports serve as a key communication tool between the project team and stakeholders, ensuring everyone is aligned and informed about the project’s trajectory. The primary purpose of a status report is to highlight completed tasks, ongoing activities, and upcoming milestones. It also identifies any issues, risks, or challenges that could potentially impact the project’s timeline or deliverables. By regularly updating and distributing this report, project managers can facilitate transparency, foster accountability, and enable timely decision-making. A typical project highlight report includes several critical components. Firstly, it provides a high-level overview of the project, including its objectives, scope, and key deliverables. It then details the project’s progress by comparing planned versus actual accomplishments, often illustrated through metrics such as percentage completion, timelines, and budget adherence. The report also outlines any significant changes or deviations from the original plan, along with their implications. Additionally, it contains a risk assessment section that identifies potential issues, their impact, and mitigation strategies. Lastly, the report summarises the next steps, upcoming tasks, and critical milestones, offering a clear roadmap for future activities. This structured approach ensures that all stakeholders have a thorough understanding of the project’s status and are prepared for the next phases. The typical contents will vary between projects, but would typically include; Status Update Current project status (e.g., on track, delayed, ahead of schedule) Progress Against Milestones Completed milestones Upcoming milestones Any delays or accelerations Major Risks / Issues Identified risks and their potential impact Current issues and their impact Mitigation strategies Outstanding Decisions Key decisions pending Required actions and responsible parties Deadlines for decisions Why Should Project Managers Use RAG Status? Project managers employ RAG status reporting for several compelling reasons. First, the colour coding in RAG status reports provides a visual representation of project health, making it easier for the project team and senior managers to understand the project status at a glance. RAG status reports also play a crucial role in project report submissions, helping the project board and organizational leadership make informed decisions. Finally, using RAG status in your project status reports aids in catching issues before they become insurmountable, thus increasing the business benefits of the project. RAG status reporting is a tool that is used in project management tools everywhere now. Look at the screenshot below from Monday.com. It’s a great example of a project management tool that does great visual rag status reports, too. How to Implement RAG Status Reporting To use a status reporting effectively, a project manager should consider the following steps: Define Criteria Before starting with RAG status reporting, you must clearly define the red, amber, or green status criteria. APM and PMI bodies offer guidelines that can be adapted to fit your project’s unique needs. There are two different methods for this. My preference is for the first because it is the simplest (and simple = good) but here they are; The RAG Scale This approach simply gives each status and what it means. Sometimes, some status review is needed to align stakeholders, but you agree at a high level. RAG Rating Validation Sheet The other, slightly more complex approach is to break down the RAG status by tolerances for each area. So, a tolerance is where you have a +/- percentage that the project manager can manage within. When a value deviates from the agreed limits, it changes the RAG status. You might think this is overkill, and in most circumstances, it is, but it is explicit and is useful for some projects to define the tolerances that are acceptable to the project sponsor(s) and gives the project manager a much clearer path to manage within. Incorporate into Project Status Reports Integrate RAG reporting into your project status reports and progress reports. Project management tools can be used to integrate RAG reporting into project status reports. This ensures that the RAG status reporting system is systematically followed across the project’s lifecycle. Status reports can take many forms. Above, I’ve given two examples of reports (Monday.com and a Template from www.iseoblue.com/products). But there are others out there. Here’s another good example from Asana. Senior Management and Steering Committee Involvement The importance of involving senior management, project managers, and the project’s steering committee in reports cannot be overstated. Their experience often provides insights into how to turn a red or amber project back on track. If an item is red, or the project’s rag status will likely turn red, then I strongly suggest that any project managers get out there and speak to their key stakeholders (sponsors, execs) and let them know personally that bad news is on the horizon. Nothing upsets a manager like being told news after the event, especially if they could have in some way potentially affected the outcome with action. Also, always, always, always make sure that the status is agreed with any person who is responsible for that part of the delivery or risk before putting it out there. If they follow up your report with an email saying, “Hey! I didn’t know we were red on this. I disagree…” then the project manager will end up red-faced. Regular Updates Statuses should be updated regularly. One project manager might opt for weekly updates, while another might find that a bi-weekly update better suits the project’s pace. Whatever the right cadence is for you, ensure it’s right for the stakeholders for whom the report is generated. Also, ensure that as a project manager, you are rag status reporting when you said you would, like clockwork. Challenges and Pitfalls of RAG Status Reporting Status reporting is widely accepted and employed across project management landscapes. However, this “traffic light” system has its pitfalls and challenges. Understanding these can enable project managers to utilise the system more effectively. Subjectivity One of the most significant challenges is the subjective assessment that project managers often face when assigning a RAG status. RAG reporting aims to ensure consistency and reliability in the assessment tool, but project managers may have different interpretations of what each colour signifies, leading to inconsistencies. As discussed, consider using a Validation Sheet with clearly defined criteria to make the RAG statuses as objective as possible. This ensures that everyone has the same understanding of what each colour means in the context of the whole project itself. Over-Simplification RAG statuses can sometimes oversimplify complex issues. A ‘Green’ status may give the impression that everything is fine, when in reality, there might be underlying problems that are not adequately captured. Complement RAG statuses with detailed progress reports or status reports that delve into the specifics. Ensure senior management and the project board are aware that Green does not necessarily mean “no action needed.” Optimism Bias There’s a natural tendency in project management to want to report good news, potentially leading to an Amber or even Red status being reported as Green. This could mask poor project performance and delay crucial intervention. Create a culture of transparency and accountability. Make it clear that it’s more beneficial to have an accurate Red or Amber status early on than a false Green that leads to bigger issues later. Inadequate Senior Management Attention Often, senior managers might only pay attention to the ‘Red’ projects in a RAG status, ignoring the ‘Amber’ and ‘Green’ ones. This can lead to missed opportunities for corrective action before an Amber turns into a serious Red project. Regular project status reporting meetings should be in place, where even ‘Green’ and ‘Amber’ projects are given due management attention. This allows for proactive measures to be taken. Ignoring Trends If a project stays at ‘Amber’ for an extended period, that’s a trend that needs attention. It’s not just the current RAG status but the history that’s important. Use historical RAG data to spot trends over time. An ‘Amber’ that’s been stable for a while could indicate a more significant issue that needs to be addressed. Lack of Action Assigning a status is only beneficial if it leads to action. A Red status that isn’t followed by corrective action is just a colour. Each RAG status should be linked with a recovery plan via a set of pre-defined corrective actions. Senior management and the project team should be aware of these and act accordingly. Status RAG Conclusion RAG status ratings are indispensable in modern project management. They offer a simple yet effective way to monitor a project's status, keep stakeholders informed, and enable corrective action. Understanding RAG status definitions and their proper implementation can make a significant difference in the successful delivery of a project. Whether you’re a project manager, part of a project team, or a member of senior management, the RAG system offers invaluable insights into the state of your project. Give yourself a green light to give it a go. About the Author: Alan Parker is a seasoned IT professional with over 30 years of experience in the industry. He holds a Degree in Information Systems and is certified in ITIL and PRINCE2. Alan has managed diverse IT teams, implemented key processes, and delivered successful projects across various organisations. Since 2016, he has been a sought-after consultant in IT governance and project management. Alan excels in simplifying complex problems and avoiding common pitfalls in IT management. Learn more about his journey and expertise here.

Introduction to Death March Project In project management, the term “Death March” refers to projects that are almost destined to fail from the outset. These are characterised by impossibly tight deadlines, unrealistic expectations, scarce resources, and a stubborn refusal to acknowledge the looming threat of failure. Despite their ominous nature, Death March projects are alarmingly common in many organisations, often arising from a mix of over-ambition and poor planning. The concept was popularised by Edward Yourdon in his book “Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects.” Yourdon’s work provides a comprehensive look at these doomed endeavours, shedding light on the reasons they occur and the detrimental effects they have on teams and organisations. Understanding Death March projects is crucial for anyone involved in project management. By recognising the signs early and taking proactive steps, it is possible to steer clear of these toxic ventures and instead focus on projects that are challenging yet achievable. Origins of the Term "Death March Project" The term “Death March” was coined by Edward Yourdon in his seminal book, “Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects.” Yourdon drew a stark parallel between these projects and the brutal forced marches of prisoners of war, highlighting the inevitable burnout and high failure rates associated with them. Yourdon’s definition resonated deeply within the software development community, where unrealistic deadlines and resource shortages are all too familiar. However, the concept extends far beyond the realm of software. In any field, a Death March project can emerge when leaders set out with bold objectives but fail to ground their plans in reality. These projects are often born from a mix of overzealous ambition, inadequate planning, and a lack of honest communication about the project’s feasibility. Companies spawn death marches at an alarming rate, with schedules, estimations, budgets, and resources so constrained or skewed that participants can hardly survive, much less succeed. By tracing the origins of the term, we can better understand the factors that contribute to the creation of Death March projects. This understanding is the first step towards avoiding them and fostering a healthier, more productive work environment. The Fine Line Between Ambition and Delusion Ambition is a vital driver of innovation and progress, inspiring leaders to push boundaries and achieve remarkable feats. However, there’s a thin line between ambition and delusion. When leaders cross this line, they risk initiating Death March projects, characterised by their unrealistic and often unattainable goals. Leaders' delusional ambitions can lead them to create death march projects with constrained schedules, estimations, budgets, and resources. The words of Steve Jobs, “Here’s to the crazy ones. The misfits. The rebels. The troublemakers…”, capture the spirit of ambitious leadership. Yet, these same qualities, when unchecked, can lead to projects that are doomed from the start. Leaders may envision themselves as the next Jobs or Musk, but without a grounded approach, their ambitious visions can turn into stubborn delusions. Delusional leadership often manifests in the form of overconfident planning and a refusal to adjust goals in the face of reality. This type of leadership ignores critical feedback, underestimates risks, and overestimates the team’s capacity to overcome challenges. The result is a project that, while initially filled with enthusiasm and hope, quickly becomes a grind of relentless overwork and inevitable burnout. Recognising the fine line between ambition and delusion is essential for leaders. It involves setting challenging yet realistic goals, being open to feedback, and willing to adjust plans as necessary. By doing so, leaders can inspire their teams without pushing them into the detrimental cycle of a Death March. Recognising the Signs of a Death March Project Identifying a Death March project early can save a team from immense stress and potential failure. Critical chain scheduling can help identify and manage the challenges of Death March projects by optimizing resource allocation and timelines. Here are some key signs to watch for: Unrealistic Deadlines When project timelines are set without considering the team’s capacity and the project’s complexity, it often results in deadlines that are nearly impossible to meet. This approach, known in project management as “right to left planning,” starts with a fixed end date and works backwards, frequently ignoring realistic time requirements for tasks. It is crucial to address these issues throughout the entire project lifecycle to ensure a systematic approach to managing politics, people, process, project management, and tools. Relentless Overwork A hallmark of Death March projects is an all-consuming work culture where long hours and overtime become the norm. In such environments, rest is viewed as a luxury rather than a necessity, leading to exhaustion and burnout among team members. It is crucial for the entire team to understand the project scope and upcoming tasks to streamline workload distribution and improve efficiency. Denial of Difficulties Effective leaders address problems head-on. In Death March projects, however, managers often downplay or ignore significant obstacles, fostering a culture of denial. Effective project management can help manage projects by addressing and acknowledging difficulties early on. This refusal to acknowledge and manage risks can cause small issues to escalate into major crises. Lack of Resources Constantly struggling to secure the necessary resources to complete tasks is a common feature of Death March projects. Teams may be expected to ‘make do’ with insufficient tools, personnel, or budget, hindering progress and increasing stress. Unlike perfectly organized projects that have adequate resources and planning, Death March projects often face significant challenges due to these limitations. Uncompromising Vision While ambition is valuable, it becomes problematic when it turns into stubborn inflexibility. Leaders who are unwilling to re-evaluate or adjust goals in the face of challenges contribute to the unsustainable nature of Death March projects. In these high-pressure environments, the project manager faces exceptional pressure due to compressed schedules, limited resources, and increased functionality demands, often leading to long hours and navigating numerous constraints and risks. The Human Cost of Death March Projects in Project Management The impact of Death March projects extends far beyond missed deadlines and failed objectives. The human cost can be devastating, affecting the mental, emotional, and physical well-being of the team members involved. Managing software projects, especially those characterized as Death Marches, involves navigating intense pressure, compressed schedules, constrained resources, and high levels of stress. Burnout and Exhaustion One of the most immediate consequences is burnout. The relentless overwork and constant pressure to meet unrealistic deadlines leave little room for rest and recovery. Participants in such a project face immense challenges, including relentless overwork and unrealistic deadlines. Team members often find themselves working late nights and weekends, sacrificing personal time and well-being. Over time, this leads to chronic fatigue, decreased productivity, and a significant decline in morale. Stress and Mental Health Issues The stress associated with Death March projects can also lead to severe mental health issues. Anxiety, depression, and other stress-related conditions become common as team members struggle to cope with the demands placed upon them. Such projects have a high risk of failure due to intense pressure and constrained resources. The high-stress environment fosters a sense of hopelessness and despair, as the team sees no end in sight to the relentless demands. Strained Relationships The impact of these projects is not confined to the workplace. The excessive time and energy required often strain personal relationships. Team members may find themselves disconnected from family and friends, leading to feelings of isolation and loneliness. The work-life balance becomes skewed, with work dominating their lives. To survive death march projects, it is crucial to implement strategies that help manage the high-pressure environment while maintaining personal relationships. Reduced Job Satisfaction The toxic environment of a Death March project inevitably leads to reduced job satisfaction. Team members who once felt passionate and motivated about their work become disillusioned. Addressing key issues throughout the entire project lifecycle is crucial to maintaining job satisfaction. The constant pressure and lack of resources create a sense of futility, where effort does not lead to success or recognition. High Turnover Rates The culmination of these factors often results in high staff turnover. Talented individuals leave the organisation in search of healthier work environments, taking their skills and experience with them. This turnover further destabilises the project, leading to a vicious cycle of stress and failure. Ensuring that the entire team understands the project scope and workload distribution is essential to reduce turnover rates. Recognising the human cost of Death March projects is crucial. It serves as a reminder that behind every ambitious objective are real people whose well-being should be a priority. Strategies to Avoid Death March Projects Preventing a project from becoming a Death March requires a strategic approach that prioritises realistic planning, effective communication, adequate resourcing, and flexible leadership. Here are some key strategies: Realistic Planning The foundation of any successful project is a realistic plan. This involves setting achievable goals and timelines based on a thorough understanding of the project scope and the team’s capabilities. Effective project management can help manage projects with realistic planning and achievable goals. Avoid the temptation of right to left planning; instead, develop a timeline that considers all necessary tasks and potential obstacles. Break down large projects into manageable phases, allowing for adjustments and course corrections along the way. Open Communication Transparent and open communication is vital. Leaders should foster an environment where team members feel comfortable sharing concerns and providing feedback. Critical chain scheduling can help facilitate open communication and identify potential issues early on. Regular check-ins and updates help ensure everyone is on the same page and can identify issues before they escalate. Encouraging an open dialogue about challenges and progress can lead to collaborative problem-solving and a more cohesive team effort. Adequate Resourcing Ensure that the project is adequately resourced from the outset. This includes having the right number of skilled team members, sufficient budget, and access to necessary tools and technology. Unlike perfectly organized projects that have adequate resources and planning, Death March projects often suffer from a lack of these critical elements. Under-resourcing a project is a common pitfall that leads to overwork and stress. By investing in the right resources, organisations can set their teams up for success and prevent burnout. Flexible Leadership Effective leaders must be adaptable and willing to adjust their plans in response to new information and challenges. In Death March projects, the project manager plays a crucial role in adapting to these extreme and high-pressure conditions, ensuring that the team can handle compressed schedules, reduced staff, limited budgets, and increased functionality. This means being open to revising deadlines, reallocating resources, and even re-evaluating project goals if necessary. Flexibility in leadership ensures that the project can navigate unexpected obstacles without becoming a Death March. Prioritising Well-Being Prioritising the well-being of the team is crucial. Encourage a healthy work-life balance by setting boundaries for working hours and promoting regular breaks. Recognise and reward efforts to maintain morale and motivation. Acknowledging the hard work and dedication of team members goes a long way in fostering a positive and sustainable work environment. Project managers can prioritize team well-being and maintain a healthy work-life balance by utilizing tools like BigPicture's Work Breakdown Structure and Gantt charts to create a clear understanding of upcoming tasks, monitor task status and progress, and streamline scope management. Conclusion: Striving for Success Without Sacrifice and Death Marches Ambition and innovation are the driving forces behind many of the world’s greatest achievements. However, when these qualities are not balanced with realistic planning and consideration for team well-being, they can lead to the creation of Death March projects. These projects, characterised by impossible deadlines, relentless overwork, and inadequate resources, often result in failure and significant human costs. Recognising the signs of a Death March project early on—such as unrealistic deadlines, denial of difficulties, and high staff turnover—can help organisations take corrective action before it’s too late. By implementing strategies like realistic planning, open communication, adequate resourcing, and flexible leadership, companies can prevent their ambitious projects from becoming toxic endeavours. It is crucial to develop strategies to survive death march projects and maintain team well-being throughout the entire project lifecycle. In conclusion, the key to avoiding Death March projects lies in embracing a balanced approach. Ambition should inspire and drive innovation, but it should also be tempered with realism and a genuine concern for the health and morale of the team. By fostering a work environment that values both achievement and well-being, organisations can turn potential Death Marches into Victory Parades—projects that challenge and grow their teams without pushing them to the brink. About the Author Alan Parker is a seasoned IT professional with over 30 years of experience in the industry. He holds a Degree in Information Systems and is certified in ITIL and PRINCE2. Alan has managed diverse IT teams, implemented key processes, and delivered successful projects across various organisations. Since 2016, he has been a sought-after consultant in IT governance and project management. Alan excels in simplifying complex problems and avoiding common pitfalls in IT management. Learn more about his journey and expertise here.

“Groupthink” is a term coined by psychologist Irving Janis in 1972 to describe a situation where the desire for group harmony overrides rational decision-making. Essentially, it happens when people in a group value consensus over the quality of the outcome, leading to less-than-optimal decisions. Or, to put it another way, a group can value an easy-to-digest self-told lie more than a hard-earned truth. The psychological phenomenon can lead to poor decision-making, stifled innovation, and ultimately, sabotage a team’s success. Janis suggested there were eight main forms of groupthink; The Illusion of Invulnerability: Members of the group have an overconfident belief that their decisions are beyond reproach, leading to excessive optimism and risk-taking. Collective Rationalisation: Group members ignore warnings and do not reconsider their assumptions, rationalising away any challenges to their shared beliefs. Belief in Inherent Morality: Group members believe in the inherent morality of their group and its decisions, ignoring the ethical or moral consequences of their actions. Stereotyped Views of Out-Groups: Those who oppose the group's decisions are labelled as outsiders and assumed to be incapable of making useful contributions. Direct Pressure on Dissenters: Group members apply direct pressure on anyone who questions the validity of the arguments supporting the group’s decisions, causing most members to remain silent or to change their views to align with the group. Self-Censorship: Members withhold their dissenting opinions and counterarguments due to fear of rejection or ridicule, leading to a loss of individual creativity and independent thinking. Illusion of Unanimity: Silence is interpreted as agreement, leading to the erroneous belief that everyone in the group is in agreement. Mindguards: Some members take on the role of protecting the group from dissenting opinions or from information that might disrupt the consensus. Recently, I’ve witnessed a public organisation (not one I’ve worked with, so don’t panic!) fall into the groupthink trap. It was so pronounced, absolute, and catastrophic as an example of group decision-making that I wanted to tackle the concept here because I see it all the time in all kinds of forms, in all aspects of life. This article aims to provide an in-depth understanding of groupthink, explain its psychological underpinnings, and explore its detrimental effects on businesses. Moreover, it will offer actionable steps for avoiding this common pitfall. So, what is Groupthink? Sometimes, we think that team cohesion is the golden ticket to success. However, that cohesion does come with its pitfalls, chief among them being the phenomena of "groupthink.". In a business context, groupthink manifests in various ways. It might range from disregarding risky strategies due to the fear of failure to rubber-stamping a proposal simply because it comes from senior management. Later, I’ll explore some high-profile examples, but let’s look at the mind cogs. The Psychology Behind Groupthink The psychological mechanisms driving groupthink are deeply rooted in our need for social cohesion to belong to a harmonious collective. It feels like it's unravelling bit by bit every day, but generally, it's what we desire: to be part of the wider group and be accepted. With that in mind, here are a few root causes that can lead us down a path of conforming to group thinking. Conformity One primary factor is conformity, where individuals align their beliefs and actions with those of the majority, often due to social pressure. It’s that ‘what is everyone else thinking’ first mentality. In a study by Solomon Asch in 1951, participants were asked to match line lengths. Approximately 75% of participants conformed at least once to a clearly incorrect majority opinion. This pressure is especially potent in a corporate setting where job security and career progression are at stake. These are the meetings when we see everyone looking around the table and looking to see what the CEO’s opinion is before we offer one ourselves. Do keep in mind that most CEOs are looking for decision-making support, so just looking at them before giving a viewpoint is not great for fostering a good image of yourself in that environment. Harmony Another driver is the human desire for harmony and the avoidance of conflict. Most of us don't want conflict or drama, so we take steps to avoid it. I experience this every night when cooking several different meals for the family. But, within a working team, this can manifest as suppressing dissenting opinions or criticism out of fear of rocking the boat. This aversion to conflict can turn constructive debate into an echo chamber of agreement. That is to say, the group will kid itself into a particular course of action. We’ve all seen it, maybe even gone along with it. We know people in a group have voiced strong opinions in private, but when it comes to the crunch, they say nothing. That’s the avoidance of conflict kicking in right there. Cognitive Bias Our old friend cognitive bias also plays a role, such as confirmation bias, where we tend to favour information that confirms our existing beliefs and ignore data that challenges them. This bias can lead to overconfidence in the chosen course of action in a group setting, often without proper vetting or scrutiny. The Dangers of Groupthink in Business The adverse effects of groupthink are not limited to mere suboptimal decisions; they can have far-reaching implications for businesses that extend beyond the meeting room. Let’s look at some of the more critical dangers of groupthink. Ineffective Decision-Making When a team prioritises consensus over critical analysis, they risk overlooking viable alternatives or disregarding potential pitfalls. Such lack of scrutiny inevitably leads to decisions that may not stand the test of time or reality. For example, several times now, I’ve seen scenarios whereby organisations have launched new products without adequate market research first, resulting in significant financial losses and a major impact on staff morale. So, they had the consensus but didn’t have the data to support their decisions. We talk a lot about ‘data driven decisions’, but the reality is that its rarely actually done. Lack of Critical Thinking A culture that encourages groupthink stunts individual cognitive processes. It suppresses the ability to question, challenge, or even think outside the box. Without these capabilities, a business risks remaining stagnant and unresponsive to market changes. Thus, it becomes more susceptible to being outmanoeuvred by more innovative competitors. This is particularly a problem for mid-sized organisations, in my experience. Smaller ones have shorter decision-making paths, fewer decision owners, and fewer stakeholders seeking to ‘add value’ (do you note how I added apostrophes there to show I didn’t mean that they add value?) So, as organisations get larger, the decision-making framework usually becomes less clear about who is empowered to make the decisions, and people start looking for democratic decision-making, which I’ve written about in an upcoming article for the Project Management Institute. Ignoring Alternatives In a group environment, members tend to zero in on a single course of action, often neglecting to explore other avenues. This blinkered view can lead to missed opportunities and potentially better solutions. In more severe cases, it can even mean overlooking critical ethical considerations, thereby compromising the integrity of the business. This isn’t necessarily tied to only groups; we do it as individuals as well, but it IS noticeable that in groups, we can look more widely at options because we have different minds coming together to solve a problem, yet we fall into a trap that we should be able to avoid. Overconfidence in Choices One of the most treacherous aspects of groupthink is the false sense of security it imparts. When everyone agrees, it can be easy to assume that the decision is sound. This overconfidence can be perilous, particularly when it leads to inadequate risk assessment or failure to anticipate market responses. We’ll dig into some meaty examples of this in a moment with historical examples. Stifled Creativity and Innovation In a groupthink scenario, homogenisation (like the word?) of ideas is almost a given. Creative and unconventional solutions are often suppressed, as they could disrupt the harmony within the group. This is particularly detrimental in industries where innovation is key to staying ahead of the competition. A company bound by groupthink will likely be a laggard rather than a leader in its field. The other day, during a radio debate about the role of freedom of speech in relation to journalism and truth, the UK broadcaster Nick Robinson was saying how he felt that if there was an unconscious bias in the established UK mainstream media, it was in this area that they accepted the conventional wisdom too readily, and sometimes that wisdom changes as a society or organisation matures. What he was alluding to was the mainstream media typically does try to be impartial (you may scoff, and fair enough) but is biased in its impartiality towards the accepted social belief rather than seeking to dig in and challenge it factually. Ethical Risks The desire for unanimity can sometimes overshadow ethical considerations. When everyone is aligned, and dissent is frowned upon, decisions that compromise integrity can slip through the cracks. This negligence of social responsibility can manifest in various forms, from poor environmental practices to exploitative labour policies. Reputational Damage The implications of groupthink extend to how a business is perceived externally. Public relations disasters stemming from poor decision-making (Coca-Cola, I’m coming back to you) can lead to significant backlash. Whether it's consumer boycotts or tarnished relationships with stakeholders, the long-term harm to brand value can be incalculable. Case Studies: Groupthink Gone Wrong In order to better understand the destructive power of groupthink, let's delve into some historical examples where this psychological phenomenon has led to disastrous outcomes in the business world. The Fall of Enron Perhaps one of the most notorious instances of groupthink leading to catastrophic failure is the case of Enron. Enron Corporation, founded in 1985, was an American energy company headquartered in Houston, Texas. It rapidly became one of the world's leading electricity, natural gas, and communications companies. However, behind the scenes, Enron hid massive debts and losses through complex accounting loopholes. By the late 1990s, a culture of excessive risk-taking and an absence of internal checks and balances led the company to increasingly dubious financial practices. It wasn't until 2001 that whistleblowers and investigative journalists began to expose the financial irregularities, leading to a sharp decline in stock prices and, eventually, bankruptcy in December 2001. The energy company's high-risk accounting practices were not questioned due to a culture discouraging dissent. Even as red flags began appearing, employees and the board ignored the warning signs. They included wildly fluctuating financial statements, complicated and opaque accounting methods, and a series of off-the-books partnerships designed to hide debt. Skilling and Fastow, key figures in the scandal, implemented financial tactics to keep massive debt off Enron's balance sheet, thereby misleading investors and regulators. External auditors, who were supposed to act as gatekeepers, did not question the company’s accounting practices. Furthermore, whistleblowers were largely dismissed or ignored, stifling internal dissent. These ignored warning signs collectively contributed to the blind approval of high-risk accounting and investment practices, leading to the eventual implosion of the company. The fall of Enron resulted in an estimated loss of $74 billion for shareholders, thousands of employees losing their jobs and savings, and stricter financial regulations, including the Sarbanes-Oxley Act of 2002. Source: McLean, B., & Elkind, P. (2003). The Smartest Guys in the Room. The New Coke Debacle In the mid-1980s, Coca-Cola faced stiff competition from its arch-rival, Pepsi (my personal favourite. Go team Pepsi!). Market research seemed to suggest that consumers preferred a sweeter taste, similar to that of Pepsi. To counter this trend and rejuvenate its brand, Coca-Cola executives decided to reformulate their century-old beverage. Then-CEO Roberto Goizueta championed the initiative and it was internally dubbed "Project Kansas." After conducting blind taste tests, which they believed confirmed their hypothesis, the executives were convinced that the new formula would be a hit. However, this is where groupthink reared its ugly head. The decision to change the formula was met with unanimous approval within the company, despite significant historical brand loyalty from consumers and the fact that the taste tests were flawed in not considering the emotional and cultural attachment to the original formula. Several red flags were overlooked in the process: The taste tests did not account for consumers' sentimental value attached to the original Coca-Cola. There was a glaring absence of market research exploring the potential backlash from changing a century-old, beloved formula. Internal concerns or questions about the move were suppressed, and a general atmosphere discouraged dissent. The new formula was launched in April 1985 amid much fanfare but was met with immediate public outcry. Consumers stockpiled the original Coke and protested outside the company headquarters. The public’s emotional attachment to the original recipe was grossly underestimated, and the groupthink within Coca-Cola had blinded them to potential pitfalls. Within a few months, the company made an about-turn, reintroducing the original formula as "Coca-Cola Classic." The New Coke debacle remains one of the most striking examples of how groupthink can lead to a costly, embarrassing, and completely avoidable business failure. Source: Oliver, T. (1986). The Real Coke, the Real Story. Each of these cases serves as a cautionary tale, underscoring the dire consequences of groupthink in a corporate setting. They emphasise the importance of encouraging dissent and diversity of thought to foster a more resilient and adaptable business environment. How to Mitigate Groupthink While the dangers of groupthink are apparent, the good news is that its detrimental effects can be mitigated through various strategies designed to foster open dialogue and critical thinking. Encourage Dissent One effective way to combat groupthink is to encourage dissent within the team actively. I’ve sometimes heard of it as ‘bear pitting’, whereby an idea is deliberately explored from contentious angles to prove it has legs. It’s a process that can explore the validity and reasoning behind something. In a similar manner, you could alternatively appoint a 'devil’s advocate', where one team member is tasked with challenging prevailing assumptions and presenting alternative viewpoints. Both approaches disrupt the comfort zone of unanimity and force the group to examine the issue more thoroughly. Anonymous Feedback Mechanisms Anonymity can embolden team members to voice their genuine thoughts without fear of reprisal. Twitter is proof of that. Anonymous surveys or suggestion boxes can be useful for gathering diverse opinions, especially when dealing with sensitive or controversial topics. I’m not suggesting, for one moment, that you do this with a team, but you can do this with stakeholders and those impacted by a decision to see if there are aspects of the decision that need further exploration. The problem can be, that if you wait until too late in the decision-making process, the group will have effectively made its mind already, and then it becomes just a task, the outcome of which cannot change the groupthink. So, ultimately pointless. Promote Diversity Diversity is not just a buzzword; it’s an essential component for avoiding groupthink. Teams of individuals with varied backgrounds, experiences, and perspectives are less prone to falling into the groupthink trap. Foster an inclusive culture that values different viewpoints, as this can enrich the decision-making process. Leadership Styles The role of leadership cannot be underestimated in combating groupthink. Adopting an open-door policy and actively listening to team members can go a long way in promoting an open and healthy dialogue. Leaders should aim to facilitate rather than dictate discussions, making it clear that dissenting opinions are not just tolerated but are actively encouraged. A 2009 study by Elizabeth A. Mannix and Margaret A. Neale found that leaders who encourage debate and dissent were more likely to avoid groupthink and make better decisions. In Conclusion Groupthink is a pervasive and often insidious challenge that can hamper a business's ability to make sound decisions, innovate, and maintain ethical standards. The risks range from poor decision-making and stifled creativity to ethical lapses and severe reputational damage. Fortunately, understanding the psychological mechanisms behind groupthink and recognising its symptoms can pave the way for effective mitigation strategies. Promoting an environment that values dissent, diversity, and open dialogue is crucial. Leadership also plays an especially significant role in setting the environment's tone. By being vigilant and proactive, businesses can avoid the groupthink trap and instead harness the collective intelligence and diverse perspectives of their teams to drive success. The dangers of groupthink cannot be ignored or underestimated, making it essential for companies to take active steps to counteract its effects. After all, the strength of a group should lie in the diversity of its members' thoughts, not in the uniformity of their agreement.

Introduction It's estimated that 70% of projects globally fail. Seriously. Google it. I believe cognitive biases are the silent killers of many of these projects if not all of them. Even projects that deliver rarely do so smoothly (shock, horror). And why would they? The very definition of a project is something that has not been done before and, therefore, is a path laid from the stones of 'unknowns'. Typically, they are fraught with decisions, risks, assumptions, and uncertainty. Throw into this mix funding limitations, scope changes and quality problems, and you are creating a stewing pot of problems. Bad thinking seeps in, subtly influencing the decision-making processes and often leading to terrible outcomes. In project management, detecting and avoiding common cognitive biases is crucial in detecting and avoiding precision and accuracy. Talking about our successes in projects and deliveries is all well and good, but is that where the real learnings come from? I don't think so. We learn far, far more from our failures and hurdles. In my experience, project problems are virtually always down to some form of human decision-making failure (and I'm really trying to think here... I want to say ‘exclusively’). In a series of articles, I want to explore what causes projects to crash, if not fatally, then in some significant aspect, they will go wrong. What is a cognitive bias? Well, it's 'bad thinking' in a nutshell. It's mental shortcuts that we can all take, based upon all sorts of factors, but for example, generalisations, that lead us to a bad place, but born from our biases, be they overt or subtle. Common Cognitive Biases Affecting Projects Confirmation Bias So, let's start with confirmation bias, the tendency to filter and interpret new information that aligns with our existing beliefs or theories. It's about more than just agreeing with information that complements our ideas; it also involves considering alternative viewpoints less. Imagine a scenario whereby you have a friend and they believe strongly in a particular brand (or politician, nudge, wink) beyond any evidence that might demonstrate the contrary. Their bias disregards the evidence that doesn't fit their view, regardless of its pedigree. So, despite contradictory data, someone holds onto their pre-existing beliefs. In fact, A study published in the Journal of Personality and Social Psychology found that people are twice as likely to seek information that confirms their beliefs compared to information that contradicts them. In fact, some people fall deeper into their beliefs the more they are challenged with contradictory evidence. This can be incredibly dangerous and sometimes amusing (reference: Loch Ness Monster). In project management terms, you'll have individuals or teams doggedly clinging to conclusions, regardless of the evidence available. Examples of Confirmation Bias in Projects Ignoring Red Flags If a project starts to ignore or dismiss issues or risk flags (likely actually amber) and downplay them over a period of time, then you probably have confirmation bias at work. For example, if we start to get the sense that something isn't going to be delivered on time, and each week we get an update from the responsible manager that they, “Hope to pick up the slack,” and downplay it, we may continually allow that to slip because we like and trust that person, but the reality is, the data probably isn't supporting that confidence. Some data might, such as previous experiences, but the data in the moment is pointing to another conclusion. So, we need to be data-driven and try to remove our bias as much as possible from the equation. This could take the shape of 'burndown charts' or other metrics that give us a factual overview of the situation. We also need to put a line in the sand and say, 'If this situation hasn't changed by X, we must...' Making Decisions Confirmation bias can also limit the range of options considered, leading to poor decision-making. Managers might be biased towards a particular technology or a supplier that isn't suited to the job. They ignore signs or expert advice that another solution is more effective. Several years ago, I worked on a £1m+ project evaluating suppliers to walk them through a rather complex technology delivery. One of the managers decided they wanted an organisation they’d worked with previously to deliver it, despite the fact they had never undertaken a delivery of this nature. The evidence all pointed to a more expensive but experienced option being the right way through, but it was pushed to one side with counterarguments about 'lower cost' and 'flexibility' of working with a partner that hadn't done it before. I'll let you guess how the project outcome went. According to Irving Janis, who coined the term, “groupthink”, in 70% of cases when decision-making groups work together, they fail to consider all available options. That’s sobering. The bias can also affect how resources are allocated. Those with an undue preference for specific tasks may funnel more resources into them to the detriment of other critical activities. Overconfidence Bias Ah, so this is a biggy. When we are new to something, we tend to have an overconfidence bias, believing that whatever task is in front of us is much easier to accomplish than it is. I suffer this on virtually every DIY job I do around the house. So, a manager might overestimate her team's abilities or the complexity of a task. A particular form of overconfidence bias, known as the Dunning-Kruger effect, leads individuals to overestimate their capabilities, thinking of themselves as experts in a subject where they are not. Here's an example from the Decision Lab; When a survey was sent out to software engineers at a company, 42% predicted they would be ranked in the top 5%. Well, you don't need me to help you with the maths there.... What can you do? Simply put, seek expert guidance. Talk to people who have been there and done it before (there's always someone). They'll help you see the pitfalls and reset expectations. Or, if no expert is available, have a proof of concept or investigation phase in your project, where you are specifically looking at the feasibility of those aspects you are unfamiliar with. The Sunk Cost Fallacy This is one I've seen time and again. You can witness it in all parts of life as well. When a project faces challenges, it tends to keep investing in it due to the time, effort, and resources already committed. This can lead to a cascade of bad decisions, amplifying the scale of failure rather than mitigating it (Arkes & Blumer, 1985). It speaks to loss aversion and that people will continue with nonsensical investments into things to avoid a loss. Studies suggest that people are twice as motivated to avoid a loss than to make a gain; people are more motivated to save a $2 loss than make a $1 gain. A few years ago, I wanted to kill an in-flight project (I know, imagine a project manager suggesting it, the heresy!) I thought the business case was only valid for a while, and it was turning out much harder and longer than anyone anticipated. I voiced my unpopular opinion and was shot down pretty quickly. The reason given? You guessed it. The cliche was spoken; "We've invested too much into this now to turn back". So, we kept throwing good money after bad, doubling down on the mistake, and pushing on with the delivery. In the end, while the project did deliver, be it overdue and over budget, it didn't have the business benefits anticipated. It wasn't just frustrating for me but soul-destroying for those who sunk their efforts into the delivery, and here I'm particularly thinking devs, QA and Product team. Mitigating Cognitive Biases So, we know that everyone can be fallible to cognitive biases, and we know that they can destroy projects, but how do we avoid them? Self-Awareness and Training Like any pitfall, awareness of these biases is the first step in mitigating their impact. Training programmes are available, specifically focusing on good decision-making practices and avoiding cognitive biases, which can equip team members with the tools to identify and counteract these mental pitfalls. But are these actually practical solutions? I'd say not really. Training a team one week will end up with that knowledge lost, dispersed or forgotten about within a few months. Training yourself is the better approach. Constantly asking yourself, 'Is this bad thinking?’, ‘What is my evidence?' and ‘How can I test my assumption?’ (note: NOT 'How can I confirm my assumption? That's a bias right there, but you know that because you’ve been reading this). Be mindful. Keep your mind open. Challenge everything. Call out bad thinking as just that, but present the evidence. Find allies to make your voice louder. One evangelical voice is easily dismissed, but if you can find others, you can likely create momentum. Checkpoints and Reviews Incorporating unbiased checkpoints and reviews can offer a reality check for the project status. I think of it as the rules of drinking. When sober, I set myself a rule of not using my phone to text people to save me any embarrassment the next day (less of an issue these days, but it served me well in my younger days). I follow the rule specifically when I'm not doing my best thinking. So, in this instance, I'm a big believer that a project should set its review points, the questions it needs to answer, and the metrics it needs to evidence well in advance of reaching the checkpoint because when it gets there, it might not be thinking clearly. Having an external consultant or a different team assess the project at various stages can also provide an impartial view. I provided this kind of assessment on an ERP implementation. The assessment uncovered some major project issues with undefined scope, no sequenced deliveries, and a lack of expertise within the team to deliver. I submitted my report, expressed my concerns and the biases took over within the executive team. They couldn’t accept the evidence presented. They couldn’t accept that all their work was leading to disaster. A few months later the project collapsed and needed to be refactored from the ground up. Eventually, it delivered, but not with the same scope, programme manager or project lead, and in a vastly different manner. Decision-Making Frameworks Structured decision-making frameworks can help avoid cognitive biases by encouraging a systematic approach to problem-solving. Orchestras have known this for years, and many have adopted 'blind auditions' whereby applicants to join an orchestra are evaluated without being seen (either by demo tapes or other methods) because the bias of those recruiting in the past led to a significant lack of diversity. Here's a common example in projects: using scoring criteria for supplier selection, such as 'cost', 'capability', 'payment terms' etc. Weight those more important items to you, and score the suppliers on an even 'apples for apples' comparison as possible. It's all too easy to get influenced by a good sales team, or someone you click with. But its much more important to be making decisions based on facts. Tools like decision trees or the Pugh matrix can assist in evaluating options more objectively. Here's a simple example of a Pugh Matrix for selecting a tool within a project. Assume the baseline tool is "Tool A", and we are comparing it against "Tool B" and "Tool C": In this matrix: "0" indicates that the alternative tool performs the same as the baseline for the criterion. "+1" indicates that the alternative tool performs better than the baseline. "-1" indicates that the alternative tool performs worse than the baseline. Conclusion What have we learnt? Well, cognitive biases, if left unchecked, can stealthily derail projects. They can infest every aspect of decision-making and at every level. Biases impact judgments and influence decisions, often without us even being aware of their influence. By understanding and addressing these biases, project managers can improve the likelihood of successful outcomes in complex IT projects, especially in areas like governance and security. As you engage with situations going forward, ask yourself: "Is the decision-making based on balanced evidence, or is it based on a preference?"