Search

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?"

Editable process for when you have a high-impact situation that requires managerial oversight and organisation-wide communication. This digital summary outlines the Major Incident Process, a structured approach for responding to and managing major IT incidents within an organisation. Purpose of the Major Incident Process The Major Incident Process serves as a guideline for IT teams and stakeholders to coordinate their efforts in restoring disrupted services as swiftly as possible. It provides a set of defined activities, roles, and responsibilities to ensure effective communication and action during a crisis situation. Where and When to Use the Major Incident Process The Major Incident Process is activated when a significant incident occurs that affects critical systems and services. It is applicable across various departments within the organisation, including the Helpdesk, technical teams, and upper management. Major Incident Process Steps Investigate: Initial 1-hour investigation period by the receiving team to potentially resolve the issue. Contact Major Incident Manager: Engage MI Manager if the service is not restored within 1 hour. Assess Criteria for Major Incident: MI Manager evaluates if the situation qualifies as a major incident. Investigate & Escalate: Continued investigation and escalation by the technical team. Manage Recovery & Comms: MI Manager oversees recovery and communications. Investigation Review Meetings: Crisis meetings may be convened by the MI Manager. Update Stakeholders: MI Manager communicates updates to stakeholders. Communicate Resolution: Final communication once the service is restored. Produce an MI Report: A detailed report is produced and circulated within 24 hours. Close Incident: Formal closure of the major incident record. Roles & Responsibilities Helpdesk Staff: Responsible for initial identification, logging, and escalation. Investigating Technical Teams: Implement fixes and update the incident management system. Major Incident Manager: Coordinates overall response and communication, and produces the Major Incident Report. Why Use the Major Incident Process? Streamlined Response: Ensures a standardised, swift, and effective response to major incidents. Accountability: Clearly defined roles and responsibilities make it easier to hold parties accountable. Risk Mitigation: The systematic approach aids in reducing the impact of the incident. Transparency: Helps in maintaining open and consistent communication with all stakeholders. Continuous Improvement: Facilitates post-incident reviews to identify areas for improvement. Additional Information The Major Incident Process acts as a blueprint for organisations aiming to achieve a coordinated and effective response to severe incidents. It is instrumental for governance and compliance, making it a critical component of a robust IT management strategy.

Navigate Change With Ease Introduction Welcome to our ITIL Change Management product page! In today's rapidly evolving IT landscape, changes are inevitable. Managing those changes efficiently is crucial for your project's success and organisational resilience. Our ITIL Change Management Process offers you a standardised, adaptable framework for controlling changes in the most effective way possible. What is the Purpose of ITIL Change Management? Our ITIL Change Management Process aims to: Control Risks: Safeguard your projects and operations from the chaotic impact of unplanned changes. Improve Efficiency: Streamline the change process to save time and resources. Enhance Accountability: Define clear roles and responsibilities for change management. Ensure Compliance: Align changes with organisational goals and governance policies. Boost Reliability: Make your IT services more reliable and high-performing. Where and When to Use ITIL Change Management? Ideal For: IT Service Management Governance Protocols Security Upgrades Infrastructure Changes When to Use: Implementing new IT projects Introducing software updates Modifying governance frameworks During any change affecting IT services or processes What's Inside? The ITIL Change Management package includes: Standard Change Management Process: A step-by-step guide adaptable to your specific needs. Roles & Responsibilities: A comprehensive page outlining the duties and expectations for each team member involved in the change process. Additional Information Adaptability: Our process is designed to be flexible, meeting the unique demands of your organisation. Compliance: Our guidelines adhere to industry standards, ensuring you're always in line with best practices. Typical Roles & Responsibilities We offer a dedicated page detailing the roles involved in the ITIL Change Management Process: Change Manager: Oversees the entire change process. Change Advisory Board (CAB): Reviews and approves change proposals. Change Initiator: Proposes the change. Change Implementer: Executes the approved changes. Change Owner: Holds overall accountability for the change. Why Choose Our ITIL Change Management Process? Our ITIL Change Management Process is not just a product; it's a game-changing asset for your IT governance. With a balance of flexibility and structure, it's designed to take the uncertainty out of change, making your IT services more reliable and your life easier. Feel free to modify this content to align with your brand's voice and particular services. I trust this helps you effectively present your ITIL Change Management Process!

In the ever-evolving world of project management, staying up-to-date with the latest methodologies, strategies, and tools is crucial for success. Project management books are vital in providing professionals with the knowledge they need to excel in their careers. But with countless books available, how do you choose the best ones to read? Worry not! We have curated a list of the top 9 project management books for 2023, ranging from beginner to advanced levels and covering various methodologies and approaches. These books offer invaluable guidance, tips, and techniques to help you become a better project manager and lead your teams to success. So, let’s dive in and explore these must-read books! Key Takeaways This ultimate guide provides the top 9 project management books for 2023, including essential reads and best for beginners. It also covers the Agile approach, Scrum success, leadership focus, advanced techniques and a comprehensive overview of topics related to project management. It includes tips on choosing the proper certification & utilising PM software, implementing the knowledge gained from books & exploring additional resources. Top 9 Project Management Books for 2023 Project management books offer proven frameworks and experienced guidance for successful project management. These manuals divide operations into straightforward components, assisting you to remain organized and manage timely results for successful projects. Our selection of the top 9 project management books for 2023 is based on ranking, relevancy, and customer feedback. From beginners to seasoned professionals, these books have something for everyone. Whether you want to learn the basics of project management, explore Agile methodologies, or hone your leadership skills, our curated list has got you covered. Therefore, let’s explore the top 9 project management books for 2023 and see how they can assist in improving your project management skills. Essential Read: A Guide to the Project Management Body of Knowledge (PMBOK Guide) The PMBOK Guide is a comprehensive resource for project management principles and practices, catering to professionals across all levels. This comprehensive guide, published by the Project Management Institute, encompasses 12 project management principles around eight project performance domains. With its thorough coverage of project management principles and practices, the PMBOK Guide is essential for professionals seeking to enhance their skills and knowledge. The most recent edition of the PMBOK Guide is the seventh edition, comprising 250 pages. A notable quote from the guide highlights the need for project managers to capitalise on cultural differences and promote working together interdependently in a climate of mutual trust. Available on Amazon.com, the PMBOK Guide should be on every project manager’s bookshelf. Best for Beginners: Project Management Absolute Beginner's Guide The Project Management Absolute Beginner’s Guide is the perfect companion when starting your journey in the project management field. This introduction to project management provides an in-depth look into: Essential qualities of successful project leaders Common missteps that first-time project managers can make Comprehensive guidance on how to manage various tasks Not only does this book cover the fundamentals of project management, but it also offers updated insights regarding: Agile project management approaches. Security and privacy policies Leading remote and virtual teams Project Management Institute standards This guide equips beginners with the necessary knowledge and confidence for mastering project management and starting their journey in this field. Agile Approach: Doing Agile Right Agile project management has taken the world by storm, and Doing Agile Right by Darrell Rigby, Sarah Elk, and Steve Berez is the perfect resource to help you understand and implement this approach. The book debunks myths about Agile, such as it being only for software development or a one-size-fits-all solution. According to Doing Agile Right, balance is the key to implementing Agile effectively. This book gives project managers insights into the Agile methodology and strategies for successful implementation within their organisations. Don’t miss this opportunity to enhance your Agile management skills and elevate your projects. Scrum Success: Scrum: The Art of Doing Twice the Work in Half the Time Scrum, a popular Agile framework, has revolutionised how teams work on complex projects. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland provides an in-depth exploration of the Scrum methodology and its various applications. The fundamental belief of Scrum is that customers may modify their requirements, necessitating product teams to be agile and adjust their strategies to deliver solutions promptly. With a notable quote stating that unnecessary heroic effort should be seen as a sign of inadequate planning, this book is a must-read for anyone looking to master the Scrum framework and improve their project management skills. Leadership Focus: Project Management for the Unofficial Project Manager Leadership skills are critical for project managers, even those without formal titles, as they are indispensable for successful project management and effectively managing projects. The book Project Management for the Unofficial Project Manager examines project management strategies for those without formal project management experience, emphasising the significance of leadership capabilities. This book teaches readers how to effectively lead a team, motivate them, and accomplish objectives. Focusing on the significance of leadership empowers project managers to realise their potential and lead their teams towards success. Don’t miss the opportunity to enhance your leadership skills and become a more effective, experienced project manager, avoiding the pitfalls of a lazy project manager. Advanced Techniques: Strategic Project Management Made Simple For experienced project managers looking to level up their skills, Strategic Project Management Made Simple by Terry Schmidt is an excellent resource. This book delves into advanced project management strategies and techniques, providing guidance on tackling projects with a strategic viewpoint and adequately addressing a project's overarching rationale. The revised edition of this book includes: An expanded section on transforming ideas, problems, and opportunities into projects A new chapter for attaining project excellence New case studies to assist businesses in meeting evolving needs with successful project delivery This project management book allows experienced professionals to develop their expertise further and stay updated in the dynamic field of project management. Comprehensive Overview: The Fast Forward MBA in Project Management The Fast Forward MBA in Project Management by Eric Verzuh, PMP, offers a complete guide to project management, including practical solutions, tips, and case studies. The sixth edition of this book covers topics such as: Project Quality Digital project management Prioritising leadership Current practices in change management In addition to the main content, this book includes a section dedicated to PMP Exam preparation and a selection of downloadable forms. With a notable quote stating that the best project managers are also excellent leaders, The Fast Forward MBA in Project Management is a must-read for anyone looking to enhance their project management skills and knowledge. Real-World Wisdom: Making Things Happen Practical advice and real-world experiences are invaluable for project managers trying to define, lead, and manage projects effectively. Making Things Happen by Scott Berkun provides precisely that, sharing insights into strategies for effectively managing initiatives and leading teams. The content in Making Things Happen is divided into Plans, Skills, and Management. This book enables project managers to comprehend the potential real-world challenges and offers strategies to tackle them. A notable quote from the book states that even on our projects, we should avoid the tendency to escape and conceal failures, emphasising the importance of learning from mistakes. Streamlined Solutions: Project Management Lite Project Management Lite by Juana Clark Craig, PMP, offers a straightforward approach to project management, suitable for non-project managers involved in or collaborating with project teams. This book includes: An overview of its purpose The initial steps to take The necessary steps to complete the project Simple worksheets and checklists Project Management Lite, with its simplified approach, aids non-project managers in comprehending the project management process and collaborating effectively with project teams. If you’re not a project manager but find yourself working in or with project teams, this book is an excellent resource to help you navigate the world of project management. Enhancing Your Project Management Skills Continuous learning and improvement are vital for project managers aiming to excel in their careers. Here are some ways to enhance your project management skills. Reading project management books to refresh your understanding of project management fundamentals and gain knowledge of new principles and skills. Attending workshops and conferences to learn from industry experts and network with other project managers. Utilizing project management software to streamline your processes and improve efficiency. By actively seeking opportunities for learning and improvement, you can stay ahead in your project management career. Remember, the best project management books provide you with the necessary knowledge and inspire you to put that knowledge into practice. Investing time in your professional development enhances your effectiveness as a project manager, equipping you to manage the challenges that may arise. Choosing the Right Project Management Certification Project management certifications play a crucial role in validating a professional’s capabilities and can be beneficial in distinguishing them in the job market. Consider your career objectives and the nature of projects you might deal with when choosing a certification. Investigating the different certifications available, such as the Project Management Professional (PMP), Certified Associate in Project Management (CAPM), and Agile Certified Practitioner (ACP), can help you decide which one is the most suitable for your needs. Additionally, evaluate the cost and time commitment associated with each certification. Choosing the properUtilising project management certification helps showcase your expertise, experience, and dedication to the field, distinguishing you from the competition and enhancing your career success prospects. Utilizing Project Management Software In today’s fast-paced, technology-driven world, leveraging project management software is crucial for ensuring efficient and effective project management. Project management tools provide managers with an overview of each project, enabling them to: Plan Manage tasks Collaborate with team members. Schedule Report on project progress Project managers can streamline their processes and enhance their project management skills by integrating the knowledge acquired from books with efficient project management software. Don’t underestimate the power of technology in helping you become a better project manager. Invest in project management software complements your needs and watch your projects thrive. Tips for Implementing Knowledge Gained from Books Applying the lessons learned from project management books to real-world projects and situations can be challenging. To ensure that the knowledge gained from books is retained and can be easily referred to in the future, consider highlighting significant points in the book, making notes in the margins, and summarising the main points. Start slow and maintain consistency when applying the knowledge acquired from books. Divide the knowledge into smaller components and take the time to comprehend and apply each. Setting achievable objectives and taking incremental steps towards them allows you to effectively apply the lessons from seminal books to your projects, enhancing your success as a project manager. Additional Resources for Project Managers To further enhance your project management skills and knowledge, consider exploring additional resources such as ebooks, articles, and online courses and networking with other project managers. Some best ways to find additional resources for project managers include exploring project management blogs and websites, enrolling in online courses or certifications, reading project management books and eBooks, listening to project management podcasts, and joining project management knowledge bases and online communities. Remember, the best resources may vary depending on your specific needs and interests as a project manager. Hence, investing time to find apt resources can foster your professional growth and improve your effectiveness as a project manager. Summary In conclusion, project management books are critical in helping professionals enhance their skills and knowledge in the field. By selecting the right books, attending workshops, and networking, project managers can continue to grow and stay ahead of the curve in the ever-changing world of project management. We hope that our curated list of the top project management books for 2023, along with the additional resources and tips shared in this blog post, has inspired you to take the next step towards becoming a better project manager. Remember, the journey to mastering project management is continuous – keep learning, keep growing, and keep making things happen. Frequently Asked Questions What are the six roles of a project manager? The six roles of a project manager include planning and developing the project idea, creating and leading a team, monitoring project progress and setting deadlines, solving issues that arise, managing the money, and ensuring stakeholder satisfaction. They are responsible for the day-to-day management of the project. They must be competent in managing the six aspects of a project, i.e. scope, schedule, finance, risk, quality and resources. What are the top 3 things in project management? Effective communication, strong leadership, and excellent management are the top three qualities of an effective project manager. Hiring executives prioritise these skills when looking for the ideal candidate. Is project manager a stressful job? Project management can be stressful as there are many responsibilities and deadlines to meet. Missing deadlines or over budget can lead to increased stress levels, consequently impacting productivity. Is a project manager job hard? Project management may appear to be a difficult job, but the fact is that it can be pretty straightforward, significantly, when aided by the right software. The reality of the job is that the real challenge lies in managing teams and handling client relationships. What's the best way to learn project management? Gain experience by starting with smaller projects and gradually increasing complexity, developing your style as you go. Networking with other project managers is an excellent way to enhance learning and discover new approaches.

Helps summarise the way in which incidents can be categorised. This downloadable template is a vital tool for IT professionals, service managers, and consultants focusing on incident management in IT settings. It serves as a foundational framework for categorising incidents, thereby facilitating trend analysis and data-driven decision-making. What is the Purpose an Incident Management Categories List? The Incident Management Categories List Template aims to standardise the way incidents are categorised. This enables better configuration of incident management tools and offers a systematic approach to trend analysis. Where and When to Use this Template? This template can be employed in various situations such as: Initial setup or reconfiguration of an incident management tool. Periodic review of incident categories and subcategories. Quality assurance and governance in IT settings. What's Inside? Contained in the template are the following fields: Category: For providing a clear name for each category of incident (e.g., Network Issue, Software Bug). Subcategory: Allows for further detailing of the type of incident within a category (e.g., Connection Loss, Authentication Failure). 'Other' Subcategory: Always included to cover incidents that don't fit easily into predefined categories. Additional Information Flexibility: The template is designed to be adaptable to various IT environments and can be customised as needed. Instructions: It includes guidance on how to fill in each field effectively for better data analysis and reporting. Why Choose Our Template? Efficiency: It simplifies the process of incident classification, saving time during incident resolution. Clarity: Using a standardised list ensures that staff across different roles and departments speak the same 'language' when discussing incidents. Analytical Value: Designed with trend analysis in mind, this template facilitates deeper insights into the incident landscape. Quality Control: Helps maintain consistency and quality in how incidents are managed and analysed. This Incident Management Categories List Template is your key to a more organised, insightful, and effective incident management process.

Understanding the Stakeholder Engagement Plan Introduction Effective stakeholder management is crucial for the success of any project, whether it's a small internal initiative or a large-scale external implementation. The Stakeholder Engagement Plan is a strategic document that outlines how to identify, analyse, and communicate with stakeholders to ensure that project objectives are met efficiently. Here is a summary of the core components and essential elements contained in the Stakeholder Engagement Plan. Purpose of the Plan The primary objective of the stakeholder engagement plan is to establish a structured methodology for stakeholder identification, analysis, and engagement. It serves as a roadmap to ensure that all parties involved in the project are well-informed and actively participating in its successful execution. Identifying Stakeholders The plan starts by listing all stakeholders, internal and external, who have an interest or role in the project. Stakeholders can range from executive sponsors and project team members to clients, end-users, and even regulatory bodies. Stakeholder Analysis The document moves on to a detailed stakeholder analysis, which breaks down the stakeholders' roles, interests, and influence levels. This section also covers their preferred methods of communication. For instance: Executive Sponsors Project Team Members Legal Team Client End-Users External Vendors Financial Stakeholders Regulatory Bodies Engagement Strategy The plan then outlines engagement methods and frequencies, segmented by stakeholders' interest and influence levels: High Interest/High Influence Stakeholders Moderate Interest/Moderate Influence Stakeholders Low Interest/Low Influence Stakeholders Communication Plan This section offers a blueprint for communications, identifying the types of messages to be delivered, the channels through which they'll be disseminated, and the frequency of these communications. For example, high-level project updates are sent to the executive sponsor via email and discussed in quarterly meetings, whereas task assignments are communicated to project team members through Slack on a weekly basis. Milestones and Reviews Key milestones such as kick-off meetings, first stakeholder reviews, and project completion reviews are scheduled to keep stakeholders informed and to facilitate necessary adjustments to the project strategy. Approvals Lastly, the document outlines approval mechanisms for critical stakeholders, often including signatures or other methods to confirm agreement with the plan. Conclusion The Stakeholder Engagement Plan serves as an invaluable tool for effective stakeholder management, laying the groundwork for transparent communication and active involvement of all parties. Understanding and implementing the elements of this plan will go a long way in ensuring the successful outcome of any project. Would you like to delve deeper into any specific section or require further clarification? Feel free to ask.