Search

I've got a well-thumbed copy of a book called "Waltzing with Bears" by Timothy Lister and Tom DeMarco, which shaped my approach to risk management many years ago. If you've ever dipped your toes into the turbulent waters of project management or tried to navigate the maze of software development, this book may resonate with you too. What has always fascinated me is the compelling concept of risk accumulation. Risk, to me, is a layered entity, stacking up in a manner that's as unpredictable as it is inevitable. Imagine that you have one risk with a 5% likelihood of occurrence, another at 5%, and another at 5%. Sounds manageable, right? But here's the rub: it's not a simple addition. This combination doesn't mean you've got a nice, tidy 15% chance of facing a hiccup. Instead, you've got a festering pot of risks where the overall likelihood of something going awry is becoming more of a 'when' than an 'if.' It's a dance with probability, and too many people are ready to roll the dice with key decisions around it. Imagine for a moment that you're a juggler. Each risk is a flaming torch you're attempting to keep airborne. But here's the kicker: the torches aren't all the same size. Some are mere sparklers compared to others. The real trick to successful juggling and successful project management is recognising which torches demand the most attention. And this is where "Waltzing with Bears" really hits home. It teaches us to focus on the recurring risks, the ones that don't just spark but threaten to become raging bonfires. Overly optimistic timeframes? That's a bonfire. Quality issues due to rushed QA? That's another one. Underestimation of complexity? You've got it, another big one. And let's not forget the blissfully naive optimism that blankets the start of every project... However, my key learning over the years has to be the emphasis on avoiding false economy. Trying to do things on the cheap, especially when they're way outside our expertise, is the equivalent of waltzing blindfolded with a bear. My advice? Find someone who's already danced that waltz. Be it a partnering organisation or an experienced leader, they've been there, done it, and have the claw marks to prove it. As we approach the finale of our dance, let's clear the floor of one major misunderstanding: risk management is not a one-and-done event. It's about more than compiling a risk log, tucking it away in a drawer, and hoping that by some magic, the risks will manage themselves or disappear if they aren't looked at. Risk management is a living, breathing project element that demands active engagement. It's about constant communication, ensuring stakeholders, and most critically, the top-tier executives, are well-informed about the risks at play. This dance requires a lead, so every risk should have an owner who can guide it, manage it, and see it through its lifecycle. As we move towards the project's end, it's important to keep our eyes on the changing landscape of risks, regularly reviewing and updating our risk log. After all, a well-managed risk reduces as we approach the project's conclusion (the "glide path", as the book above refers to it). But remember, the earlier we spot a risk, the better our chance of addressing it before it spirals out of control. Let's make honesty our dance partner here. We must create an environment where raising risks and concerns is encouraged, not stifled. A project team should never be a place where risks are met with passive aggression, dismissal, or accusations of exaggeration. Because let's face it: questioning a risk-raiser's loyalty or team spirit is unfair and detrimental to the project's success. In conclusion, remember that "Waltzing with Bears" is more than a dance with risk; it's a dance with honesty, responsibility, and proactive management. So, let's keep those feet moving, those risks under control, and most importantly, keep the dialogue open because every dance becomes more fluid with clear, honest communication.

Control project risks using this template Introduction Our Risk Log Template is a structured document designed to help you identify, assess, and manage risks across various projects. Tailored for project managers, team leaders, and stakeholders, this template helps streamline the risk management process by offering an easy-to-follow format. What is the Purpose of the Risk Log Template? The Risk Log Template offers a systematic way to record, assess, and track risks throughout the life cycle of a project. This helps to proactively manage potential pitfalls and seize opportunities, ensuring projects are more likely to be delivered on time and within budget. Where and When to Use the Risk Log Template? The Risk Log Template is highly versatile and can be used across a variety of scenarios: Planning stages of a new project. Ongoing risk management during project execution. Audit and review exercises for past projects. What's Inside? The Risk Log Template contains key fields tailored for effective risk management: Risk Log Entries: Detailed records of risks, including ID, description, category, probability, impact, risk score, mitigation strategy, owner, status, and last updated date. Key Definitions: A glossary section explaining terms and fields used in the log. Additional Information Customisable: Modify the template to align with specific project needs or industry standards. User-Friendly: Designed for easy use, with clear headings and simple layout. Compatibility: Suitable for various formats and software applications. Why Choose Our Risk Log Template? Comprehensive: The template is robust, covering all essential aspects of risk management. Efficiency: Save time by using a tried-and-true format, allowing focus on risk assessment rather than document setup. Standardisation: Ensures that risk management is carried out in a consistent manner across projects. Guidance: The template provides a systematic way to approach risk management, making it easier for both new and seasoned project managers. Our Risk Log Template is an indispensable tool for effective risk management, helping you navigate the uncertainties of any project.

Introduction In Information Technology Service Management (ITSM), proactively managing risks is pivotal to ensuring the reliability, efficiency, and security of IT services. Within the ITIL version 4 framework, Risk Management is a core practice designed to guide organisations in identifying, assessing, and controlling risks. This practice is not just about mitigating threats but also about recognising and seizing opportunities that align with the business's strategic objectives. The importance of Risk Management in ITIL 4 transcends traditional boundaries, influencing decision-making processes and the overall management of IT services. By embedding Risk Management into their operations, organisations can achieve a balance between minimising risks and maximising value, steering towards operational excellence and sustained growth. “Your tomorrow’s reward depends on your today’s risk management” ― Syed Quaid Ali shah (Ph.D. Scholar) Understanding Risk Management in ITIL 4 Definition of Risk Management Risk Management within the ITIL 4 framework is defined as a systematic practice to identify, evaluate, and address risks associated with IT services and operations. It encompasses a comprehensive approach to managing threats and opportunities, ensuring that strategic, compliance, operational, and financial targets are met with an acceptable level of risk. Objectives and Importance of Risk Management in ITIL Framework The primary objective of Risk Management in ITIL 4 is to protect the organisation's value-creation activities while enabling the organisation to be more responsive and resilient to risk-related events. This practice is integral to the ITIL framework for several reasons: Understanding the role and importance of Risk Management in ITIL 4 is the first step towards embedding this practice into the organisational fabric, ensuring that IT services are delivered efficiently, securely, and in alignment with business objectives. The Role of Risk Management in ITIL 4 Risk Management is intricately woven into the ITIL 4 framework, playing a pivotal role in ensuring that IT services are aligned with the business's needs and resilient to disruptions. Its role extends across various practices and processes, making it a cornerstone of the ITIL 4 service value system. Integration with Other ITIL Practices Risk Management in ITIL 4 does not operate in isolation. Instead, it integrates seamlessly with other practices such as Service Continuity Management, Information Security Management, and Change Control. Remember; it’s a general practice within ITIL, which means it is used in many places, from projects to operational risk management. This integration ensures that risk considerations are embedded in all aspects of IT service management, from planning and design to delivery and improvement. Here are some examples of how it directly integrates with some other practices; Service Continuity Management: Risk Management supports service continuity by identifying threats to IT services and ensuring that plans are in place to mitigate these risks. Information Security Management: It aligns closely with Information Security Management by assessing data security, privacy, and compliance risks and defining appropriate control measures. Change Control: In the context of Change Control, Risk Management evaluates the potential risks associated with changes to IT services, ensuring that changes do not introduce unacceptable levels of risk. Impact on IT Services The effective implementation of Risk Management profoundly impacts the quality and reliability of IT services. It enhances decision-making by clearly understanding risk exposure and its potential impact on service delivery. Moreover, it fosters a culture of risk awareness and encourages proactive risk identification and mitigation, leading to: Improved service reliability and performance. Enhanced customer satisfaction through consistent and secure service delivery. Increased agility, allowing the organisation to respond swiftly to changing risks and opportunities. In essence, the role of Risk Management in ITIL 4 is to ensure that risks are identified, assessed, and managed in a way that supports the organisation's strategic objectives, enhances service delivery, and minimises negative impacts on business operations. “Risk management is a more realistic term than safety. It implies that hazards are ever-present, that they must be identified, analyzed, evaluated and controlled or rationally accepted.” - Jerome F. Lederer The Risk Management Process in ITIL 4 Risk Management within ITIL version 4 encompasses a structured approach characterised by specific processes and activities aimed at efficiently managing risks throughout the lifecycle of IT services. This approach is detailed through three primary processes; Governance of Risk Management Risk Identification, Analysis, and Treatment Risk Monitoring and Review in ITIL 4 Governance of Risk Management in ITIL 4 Risk management governance is a critical process within ITIL 4 that establishes the foundational framework and policies for managing risks across the organisation. This process is instrumental in aligning risk management practices with the organisation's strategic objectives, culture, and regulatory requirements. The governance of the risk management process is a cyclical and iterative process that requires continuous attention and adjustment. It sets the stage for effective risk management by establishing clear guidelines and expectations, allocating resources, and ensuring organisation-wide alignment with the risk management strategy. This foundational process supports compliance and strategic alignment. It promotes a proactive and informed approach to managing risks across the organisation. Here's a detailed look at the key components of this process: Analyse the Environment The governance body begins by analysing the external and internal environments using the PESTLE framework (Political, Economic, Social, Technical, Legal, Environmental factors) alongside the competitive and threat landscapes and regulatory requirements. This comprehensive analysis helps in understanding the broader context within which the organisation operates and informs the overall strategy, including aspects related to risk management. This activity is typically conducted annually but can be triggered more frequently by significant events that might impact the organisation's strategy or operational context. Document Risk Capacity and Risk Appetite Based on the environmental analysis, the governance body establishes and documents the organisation's risk capacity (the maximum amount of risk the organisation can bear) and risk appetite (the amount of risk the organisation is willing to pursue or retain). These crucial parameters guide decision-making processes and risk management strategies throughout the organisation. Documenting risk capacity and appetite ensures that all risk management activities are aligned with the organisation's strategic goals and cultural context. I explore the issues around underestimation within risk management here. Document Risk Management Policy The risk management policy is a formal document that outlines the organisation's approach to identifying, analysing, and managing risks. It may reference specific standards and guidelines, such as ISO 31000, and includes details about the methodologies, tools, and roles involved in the risk management process. The creation of this policy requires specialist knowledge in risk management. However, the final decisions and authorisation rest with the governing body. A sufficient budget is allocated to support the activities required by the policy. Provide Direction to Management The governance body communicates the documented risk capacity, appetite, and management policy to management at all levels. This ensures that everyone involved in managing risks knows their responsibilities and the parameters within which they should operate. This direction is not specific to risk management. However, it is crucial for embedding risk management considerations into day-to-day decision-making and operational processes. Monitor the Organisation The governance body must monitor risk management practices on an ongoing basis to ensure that they are implemented according to the established policy and remain effective and relevant. This includes reviewing audit reports and monitoring significant deviations from the risk management plan. While this activity is not exclusive to risk management, it focuses on ensuring that risk management objectives are met and that adjustments are made to align with changing environments and organisational strategies. Risk Identification, Analysis, and Treatment in ITIL 4 This process is central to proactively managing risks, ensuring they are systematically identified, assessed for their potential impact and likelihood, and treated appropriately. The risk identification, analysis, and treatment process is iterative and integrated with other ITIL 4 practices. It requires collaboration across different teams and disciplines within the organisation, ensuring that risk management is embedded in all aspects of IT service management. Effective communication and documentation are crucial throughout this process, enabling informed decision-making and fostering a culture of risk awareness. Here's a detailed breakdown: Risk Identification Risk identification aims to catalogue potential risks that could affect the organisation's IT services and operations. This stage involves a broad and inclusive approach to recognising risks, employing various techniques to ensure comprehensive coverage: Sources and Techniques: Utilising previous risk registers, service portfolios, brainstorming sessions, tabletop exercises, stakeholder interviews, and external threat assessments. This wide array of sources helps in capturing both internal and external risks. Scope of Control: Risks are identified with a specific focus, such as project risks, service risks, etc., ensuring that each area of the organisation's operations is considered. Regular and Trigger-based Identification: While some risk identification activities are scheduled regularly (e.g., annually), others may be triggered by specific events like security breaches or significant changes in the operational environment. Documentation and Ownership: Each identified risk is assigned an owner responsible for managing that risk, with all risks documented in a risk register for transparency and accountability. For additional help, here's a Risk Management Log Template that I've used over the years. It allows for the simplified tracking of risks and can be adapted to your needs. Risk Analysis and Evaluation Each risk undergoes analysis following identification to assess its potential impact and likelihood. This evaluation helps in prioritising risks and determining the level of effort and resources required for their management: Qualitative and Quantitative Methods: Risks are analysed using either qualitative or quantitative methods, as specified by the organisation's risk management policy, to assess their severity and the probability of occurrence. Risk Evaluation: Based on the analysis, risks are evaluated against the organisation's risk appetite, helping decide the appropriate management strategy for each risk. Updated Risk Register: The risk analysis and evaluation findings are documented in the risk register, ensuring that information is up-to-date and accessible. Risk Treatment In the treatment phase, strategies are developed and implemented to manage identified risks in alignment with the organisation's risk appetite and capacity: Treatment Options: Options include accepting the risk, mitigating it through specific actions, transferring the risk (e.g., through insurance), or avoiding the risk altogether. Selection of Controls: Controls are selected or designed to manage the risk based on the chosen treatment strategy. This may involve adherence to specific standards and best practices or developing bespoke solutions. Implementation and Management: Implementing risk treatment plans involves various activities, including design, investment, development, testing, and deployment. The effectiveness of these measures is managed and monitored by the risk owner. Risk Monitoring and Review in ITIL 4 The Risk Monitoring and Review process ensures that risk management practices remain effective, relevant, and aligned with the organisation's evolving risk landscape and strategic objectives. This continuous process involves assessing the performance of risk management strategies, controls, and actions, and adjusting them as necessary. The process creates a feedback loop that enhances the organisation's risk management capability. Organisations can maintain a resilient and adaptive risk management framework by regularly assessing the effectiveness of risk controls and strategies and adjusting them in response to changes in the risk environment. This process supports the continuous improvement of ITIL 4 practices. It helps sustain the alignment of risk management efforts with the organisation's strategic goals. Here's a detailed examination: Control Assessment and Evaluation This activity ensures that the controls implemented to manage risks are correctly applied and effective over time. It involves assessing both the implementation and the ongoing suitability of these controls. While some controls may require daily or weekly assessments in high-risk areas, others might be reviewed less frequently. Specific events, such as security incidents or significant changes in the operational environment, can also trigger assessments. The assessment includes auditing technical implementations (e.g., verifying the installation and updating of antivirus software) and evaluating adherence to procedural controls (e.g., compliance with a clear desk policy). The results may lead to updates in the risk register, identification of needs for new or updated controls, or initiation of a risk audit. This ensures that controls remain fit for purpose and effectively manage the identified risks. Risk Audit Audits are conducted to ensure that the risk management framework and its processes continue to be appropriate and effective in the context of the organisation's changing environment. Scheduled regularly, risk audits may also be prompted by events that potentially impact the risk landscape, such as introducing new IT services or partnerships. Audits can be performed by internal teams or external parties, offering an unbiased evaluation of the risk management practices. The audit may highlight the need for new or revised controls and provide valuable feedback for the 'monitor the organisation' activity in the governance of the risk management process. Monitoring the Risk Environment Continuous Observation This involves monitoring the internal and external risk environment to detect any changes that might affect the organisation's risk profile. Adaptation and Response When significant changes are identified, the organisation may need to reassess its risk capacity, appetite, and strategies to ensure continued alignment with its objectives and operational context. Updating the Risk Register The risk register is a living document that must be updated regularly to reflect the findings from control assessments, audits, and the monitoring of the risk environment. Accountability and transparency ensure that all stakeholders are informed about the current risk status, the effectiveness of controls, and any adjustments made to the risk management approach. Implementing Risk Management in ITIL 4 Implementing Risk Management in the ITIL 4 framework is a strategic initiative that requires careful planning, execution, and ongoing management to ensure its effectiveness and alignment with organisational objectives. Here's a structured approach to implementing Risk Management in ITIL 4: 1. Establishing a Risk Management Framework Governance and Policy Begin by establishing a governance structure and a comprehensive risk management policy outlining the objectives, scope, roles and responsibilities, and risk management processes. This policy should reflect the organisation's risk appetite and capacity, as outlined in the Governance of Risk Management process. Integration with ITIL Practices Ensure the Risk Management process is integrated with other ITIL 4 practices, such as Service Continuity Management, Information Security Management, and Change Control. This integration helps embed risk considerations into all aspects of IT service management. 2. Risk Identification and Analysis Comprehensive Risk Identification Utilise various techniques and sources to identify risks comprehensively, including reviews of existing risk registers, service portfolios, and external assessments. Ensure that risk identification covers all areas of IT services and operations. Systematic Risk Analysis Analyse and evaluate identified risks using qualitative and quantitative methods. This analysis should consider risks' potential impact and likelihood, facilitating prioritisation and informed decision-making. 3. Risk Treatment and Mitigation Developing Risk Treatment Plans Based on the analysis, develop and implement risk treatment plans that align with the organisation's risk appetite. This may involve risk avoidance, mitigation, transfer, or acceptance strategies. Selection and Implementation of Controls Select appropriate controls to manage identified risks. This involves not only adopting existing controls and best practices but also designing and implementing new controls as necessary. 4. Monitoring, Review, and Continuous Improvement Ongoing Monitoring and Review Establish mechanisms for continuously monitoring and reviewing risks and the effectiveness of risk management strategies. This includes regular updates to the risk register, audits, and reviews to assess the relevance and effectiveness of controls. Continuous Improvement Leverage insights gained from monitoring and review activities to inform continuous Risk Management process improvement. This involves updating risk management policies, practices, and controls in response to changes in the organisational environment, IT services, or risk landscape. 5. Culture and Communication Fostering a Risk-aware Culture Promote a culture of risk awareness and proactive risk management throughout the organisation. This involves training and awareness programs for staff at all levels. Effective Communication Ensure clear and effective communication channels for reporting risks, sharing risk management strategies, and disseminating risk management policies and updates. Stakeholder engagement is key to successful Risk Management implementation. Implementation Challenges and Solutions Implementing Risk Management in ITIL 4 can present challenges, such as resistance to change, resource constraints, and aligning risk management practices with organisational objectives. Addressing these challenges requires strong leadership, clear communication, and the engagement of stakeholders across the organisation. Providing adequate resources, training, and support can also facilitate the smooth implementation of Risk Management practices. Challenges and Solutions in ITIL 4 Risk Management Implementing and sustaining effective Risk Management practices in alignment with ITIL 4 can present several challenges for organisations. However, with strategic planning and execution, these challenges can be overcome. Below are some common hurdles and strategies to address them. Conclusion Risk Management within the ITIL 4 framework presents a structured, strategic approach to identifying, assessing, and mitigating risks in IT service management. Through the governance of Risk Management, risk identification, analysis, and treatment, and ongoing monitoring and review, organisations can effectively manage risks, ensuring that IT services are reliable, secure, and aligned with business objectives. Implementing Risk Management according to ITIL 4 guidelines enables organisations to mitigate threats and capitalise on opportunities, thereby enhancing value creation and service excellence. However, implementing and sustaining effective Risk Management practices is challenging. Organisations must navigate issues such as resistance to change, alignment with business objectives, resource constraints, the pace of emerging risks, and measuring effectiveness. The key to overcoming these challenges lies in clear communication, strategic alignment, resource optimisation, continuous monitoring, and fostering a culture of risk awareness and proactive management. As IT environments continue to evolve and the business landscape becomes increasingly complex, the importance of effective Risk Management cannot be overstated. Organisations that successfully integrate Risk Management practices into their IT service management processes can achieve greater resilience, improved decision-making, and enhanced operational efficiency. In doing so, they position themselves to thrive in an uncertain, rapidly changing world, driving forward with confidence and strategic insight. Risk Management in ITIL 4 is a practice and a critical component of a successful IT service management strategy. As we look to the future, the principles of Risk Management will continue to evolve, reflecting new insights, technologies, and methodologies. Organisations that stay informed and adaptable leveraging the comprehensive guidance provided by ITIL 4, will be well-equipped to navigate the challenges and opportunities of the digital age. If you are interested, then I talk more about concepts within risk management here. This article discusses concepts and practices from the ITIL framework, a registered trademark of AXELOS Limited. The information provided here is based on the ITIL version 4 guidelines and is only intended for educational and informational purposes. ITIL is a comprehensive framework for IT service management, and its methodologies and best practices are designed to facilitate the effective and efficient delivery of IT services. For those interested in exploring ITIL further, we recommend consulting the official ITIL publications and resources provided by AXELOS Limited.

The advent of a new software release or a project going live is a thrilling time for any organisation. It signifies progress, innovation, and the exciting promise of enhanced operations. However, amidst the frenzy of anticipation, one critical team often gets overlooked until the eleventh hour: the help desk. From my experience, I can attest that this last-minute inclusion of the help desk can lead to many problems, from low staff morale and ineffective end-user support to products that don't function in real-world circumstances, which the help desk would have identified. I advocate for a shift in perspective, and here's why it's critical to bring the help desk to the forefront of project planning. Understanding the Product Inside Out Help desk staff must be familiar with the product to support end-users effectively. They gain deep insights into the functionality, potential issues, and workarounds when included from the onset. This makes them more competent in troubleshooting and assisting users. But when thrown in at the last moment, their understanding is superficial at best, leading to ineffective support and frustrated users. Including them early can even identify show-stopping issues. Nobody knows the pitfalls of a product and what the customer needs like the help desk. Preventing Morale Decay Being thrust into the spotlight without adequate preparation can lead to stress and low morale among help desk staff. They might feel underappreciated and sidelined, leading to decreased motivation and performance. Early inclusion gives them ample preparation time and communicates that their role is valued and crucial to the organisation's success. Shaping End-User Perception The help desk is the face of your organisation to end users. If they're well-prepared, they project competence and confidence, shaping a positive perception of your organisation. On the other hand, being unprepared can lead to an image of disorganisation and inefficiency. To address this, I propose developing a set of acceptance criteria that the help desk can use whenever they engage with a project team. These criteria outline critical information the help desk team needs before a product launch or project go-live, ensuring they're adequately prepared to support end users. Here's a glimpse of what these criteria could include: Training: Help desk staff must receive comprehensive training on the new software or project. This should be theoretical and practical to ensure a complete system understanding. Documentation: All necessary user manuals, troubleshooting guides, FAQs, and other supportive documents should be readily available. Test Environment Access: Help desk staff should have access to a test environment to familiarise themselves with the system and try their hands on troubleshooting common issues. I'd encourage them even to be part of User Acceptance Testing. Early Notification: Project teams must notify help desk staff well in advance about the impending go-live date to ensure adequate preparation time. Contact Points: Clear communication lines should be established between the help desk and the project team for any issues or queries. By implementing these acceptance criteria, we can ensure that our help desk staff are well-prepared, confident, and ready to provide excellent support from day one. Let's redefine our approach and recognise the pivotal role that our help desk plays in ensuring the success of our projects. It's time to put them at the forefront, right where they belong.

Templated communication to capture and share all key information in a digestible format for stakeholders. Keeping stakeholders informed about new software releases is more than a courtesy; it's an essential part of change management. Our Upcoming Release Notification ensures you communicate effectively, setting the stage for a successful launch. What is the Purpose of a Release Notification Template? Our Upcoming Release Notification serves to: Inform Stakeholders: Keep all relevant parties aware of upcoming changes, new features, and enhancements. Minimise Impact: Notify about potential downtime and system requirements to avoid business disruptions. Facilitate Transition: Provide resources for training and support to ease the transition to the new version. Boost Engagement: Build anticipation and excitement among users for new features and improvements. Where and When to Use an Upcoming Release Notification? Ideal For: Software Companies IT Departments Change Management Teams When to Use: Prior to releasing a software update or new version For communicating planned system outages What's Inside? The Upcoming Release Notification includes: Key Highlights: Detailed description of new features, enhancements, and bug fixes. Potential Impact: Information on downtime and any new system requirements. Training and Support: Availability of training materials and points of contact for support. Additional Information Customisable: Adapt the template to fit the specifics of your software or application. Comprehensive: Covers all bases from features to potential system impacts, ensuring stakeholders are well-informed. Why Choose Our Release Notification Template? Stay ahead in effective communication with our Release Notification template. Empower your stakeholders to make the most of your new features while minimising potential hitches. A simple yet comprehensive guide to what's new, what's changing, and what to expect.

Introduction Purpose Release management is an essential IT service management practice that focuses on the controlled deployment of IT services and infrastructure changes. It is instrumental in ensuring that enhancements and fixes are delivered efficiently without disrupting the current services and operations. Scope The practice of release management extends across various facets of IT processes and impacts numerous stakeholders, from IT professionals who design and develop the changes to end-users who rely on stable and effective IT services. Effective release management processes are critical for maintaining the integrity and reliability of IT services in a dynamic technological landscape. Key Benefits Implementing robust release management practices offers significant advantages. For service providers, it ensures that new and altered services are delivered in a controlled manner, mitigating risks and reducing downtime. For consumers, these practices enhance the overall quality and reliability of services, leading to increased satisfaction. The key benefits include: Controlled Deployment: Ensures that changes are introduced to minimise disruption to existing services. Risk Management: Reduces the potential for errors and defects while deploying new services and features. Enhanced Satisfaction: Improves the perception and effectiveness of IT services, boosting user and customer satisfaction through timely and smooth updates. Basic Concepts and Terms General Concepts Release management is the practice of managing, planning, scheduling, and controlling a software build through different stages and environments, including testing and deploying software releases. The practice ensures that the integrity of the live environment is protected and that the correct components are released. It is integral to the continuous delivery pipeline to support ongoing application changes without adverse effects. Key Terms Release: A release typically refers to the handover of new or changed software, hardware, or services to the operations team and end users. It may include multiple changes or updates bundled together to form a single release. Deployment Management vs. Release Management: While these terms are often used interchangeably, they focus on different stages of the change process. Deployment management covers the steps involved in putting new or changed hardware, software, or service components into operational use. Release management, however, encompasses the overarching process that manages developments, configurations, testing, and deployments within controlled IT environments. Release Management Processes Release Model Development and Improvement Release model development and improvement is a critical process within release management. It involves periodically assessing and enhancing release models to better suit the evolving needs of IT services and products. This process ensures release management strategies align with technological advancements and organisational goals. Continuous improvement of the release models allows for increased efficiency in managing the flow of changes and deployments, thus minimising disruptions and maximising service value. Key aspects of this process include: Assessment of Current Practices: Regularly review existing release models to identify areas of inefficiency or outdated practices. Stakeholder Feedback: Integrating feedback from users, IT staff, and business leaders to refine and improve release processes. Adoption of New Technologies: Incorporating new tools and technologies to automate and streamline release processes, thereby reducing manual errors and delays. Training and Development: Ensuring all personnel involved in the release process are well-trained and understand new or revised models. Release Planning and Coordination This process focuses on meticulously planning and coordinating each release to ensure its success. It involves defining the scope, timing, and resources required for the release and coordinating with various teams to ensure smooth execution. Effective release planning and coordination help to mitigate risks, manage stakeholder expectations, and ensure alignment with business objectives. Essential elements of this process include: Release Scheduling: Determining the optimal time for release to minimise impact on business operations. Resource Allocation: Ensuring sufficient resources, including personnel, software, and hardware, are available and adequately prepared. Risk Management: Identifying potential risks associated with the release and developing mitigation strategies. Communication: To ensure transparency and preparedness, all stakeholders should be kept informed about the release schedule, potential impacts, and expected outcomes. Relationship with Other Practices Release management does not operate in isolation within the ITIL framework. It is deeply interconnected with several other IT service management practices, ensuring that IT services are delivered efficiently and effectively. Understanding these relationships is crucial for a holistic approach to service management. Key Relationships Change Enablement: Release management works closely with change enablement to ensure that all changes are assessed, approved, and implemented in a controlled manner. Change enablement focuses on managing changes to prevent negative impact, while release management ensures these changes are released successfully into the live environment. Deployment Management: As previously noted, deployment management is closely related to release management but focuses more on the technical aspects of moving changes into production. Release management ensures these deployments align with broader business goals and compliance standards. Service Validation and Testing: This practice ensures that new or changed services meet customer expectations and operational requirements. Release management relies on service validation and testing to ensure that all releases are fit for purpose before they are made live. Configuration Management: Release management depends on accurate and up-to-date configuration data to plan and implement releases effectively. Configuration management provides the necessary information about the IT infrastructure, which helps assess releases' impact. Incident and Problem Management: Effective release management can reduce the frequency and impact of incidents and problems. Conversely, incident and problem management insights can improve release processes to prevent future issues. Roles & Responsibilities In the release management framework, several roles are pivotal in ensuring the smooth execution of releases. Each role has specific responsibilities that contribute to the overall efficiency and effectiveness of the practice. Key Roles Release Manager The release manager is central to the release management process. This role involves overseeing the planning, scheduling, controlling, and deployment of releases. Responsibilities include: Coordinating with various IT teams to ensure timely and successful release of changes. Managing risks associated with releases. Communicating release details to all stakeholders. Ensuring that the release process adheres to organisational policies and standards. Configuration Manager: Works closely with the release manager to ensure that all release components are accurately recorded and that the configuration management database (CMDB) is updated with the latest configuration information post-release. Change Manager Although primarily involved in the change enablement practice, the change manager collaborates with the release manager to ensure that all changes within a release have been approved and are ready for deployment. Service Validation and Testing Team This team is responsible for validating and testing the release to ensure it meets the required standards and functional requirements before it is deployed to the live environment. Project Managers and Development Teams These roles are involved in the earlier stages of the release lifecycle, focusing on the development and initial testing of the changes included in a release. Implementation Advice Effective release management implementation requires a strategic approach that balances the technical aspects of IT services with the organisation's business objectives. Here are some key pieces of advice to ensure successful implementation: Key Metrics Adoption Rate: Measure how quickly and effectively new or changed services are adopted within the organisation. This metric can indicate the success of a release in meeting its intended goals. Release Downtime: Monitor the amount of downtime associated with each release. Minimising downtime is crucial for maintaining business continuity and user satisfaction. Success Rate: Track the percentage of releases that meet the defined success criteria without causing subsequent issues or requiring hotfixes. Stakeholder Satisfaction: Regular feedback from users and stakeholders after each release can provide insights into how well the release met their needs and expectations. Things to Avoid Overcomplication: Avoid creating overly complex release processes that obscure understanding and hinder execution. Simplify processes wherever possible to maintain clarity and efficiency. Insufficient Testing: Under-testing a release can disrupt the live environment. Ensure comprehensive testing phases are integral to the release process. Poor Communication: Failure to communicate effectively with all stakeholders throughout the release process can lead to misunderstandings and misalignments with business needs. Establish clear and consistent communication channels. Neglecting Post-Release Review: Skipping the review phase after a release can prevent the organisation from learning and improving. Conduct thorough post-release reviews to identify lessons learned and apply these insights to future releases. Frequently Asked Questions Here are some commonly asked questions about release management, which can help clarify typical concerns and enhance understanding of the practice: What is the difference between release management and deployment? Release management is a broader practice that includes planning, scheduling, and controlling the deployment of IT services to ensure they meet the business's and users' needs. Deployment specifically refers to the technical activities required to move new or changed hardware, software, or services into production. How often should releases occur? The frequency of releases depends on the business requirements, the maturity of the IT infrastructure, and the capabilities of the development and operations teams. Some organisations opt for regularly scheduled releases, while others may adopt a continuous deployment approach where releases occur as changes are ready. What are the best practices for ensuring a successful release? Best practices include comprehensive planning and coordination, engaging with stakeholders throughout the process, conducting thorough testing to ensure functionality and compatibility, and reviewing each release to gather learnings for continuous improvement. How can release management impact user experience? Properly managed releases ensure that new or updated services are introduced smoothly and without disruptions, enhancing user satisfaction. Good release management also means that services are continually improved in response to user feedback, aligning more closely with user needs. Can automation improve the release management process? Yes, automation can significantly enhance the efficiency and reliability of release management by reducing manual errors, speeding up processes, and ensuring consistency across releases. Tools like CI/CD pipelines automate the integration and delivery process, while automated testing can ensure that releases meet quality standards before deployment.

There's been a significant paradigm shift in business process management, especially with the changing landscape of IT. While it's true that the "old ways" have brought us to where we are today, it's time to revamp our approach. One area ripe for re-evaluation is our IT help desk - that essential team resolving various technical issues, keeping operations smooth, and ensuring the team is tech-ready. What if we could elevate the help desk's role beyond just fixing issues? Could we make them an integral part of the business units they support? The answer lies in a simple yet transformative concept: the practice of help desk analysts shadowing the very business units they serve. Let's delve into how this innovative practice could strengthen our business's performance and the symbiotic relationship between help desks and the business units. Understanding the Business, First Hand Traditionally, help desk staff interact with business units only when a technical issue needs resolution. They fix the problem, and it's business as usual. However, this creates a reactionary approach rather than a proactive one. By having help desk analysts spend time shadowing business units, they gain firsthand experience of the day-to-day operations. They witness the workflow's struggles, bottlenecks, triumphs, and intricacies. This experience builds a deeper understanding of how the business functions, which feeds into a more nuanced and effective approach to supporting those functions. Empathy and Improved Relationships Empathy often takes a backseat in a world driven by numbers and bottom lines. But it is empathy that fosters understanding, appreciation, and, ultimately, stronger relationships. When help desk analysts spend time with business units, they learn the business processes and appreciate the challenges these teams face. This shared experience and mutual understanding foster better communication and respect. Consequently, business units will view help desk staff as allies rather than just problem fixers, leading to improved cooperation and more robust relationships. Identifying Opportunities for Technological Improvements When we view IT as a mere tool to fix issues, we miss the opportunity to harness its full potential in transforming our business operations. By immersing themselves in the business processes, help desk analysts can identify areas where technology could improve efficiency, speed, or ease of operations. They can suggest tools or software to automate repetitive tasks or design systems to streamline processes. This proactive approach helps optimise current operations and opens avenues for innovation and growth. The concept of help desk analysts shadowing business units is about more than just getting them out of their comfort zone. It's about empowering them to become an integral part of a business. By understanding the business operations, empathising with the challenges, and identifying opportunities for technological enhancements, our help desk staff can go beyond resolving technical issues. They can become catalysts of change, driving our business towards optimised processes, improved relationships, and, ultimately, unparalleled growth. Let's bridge the gap and usher in this transformative approach.

Overview Introduction In IT service management, the emphasis often leans heavily towards the technical aspects—infrastructure, applications, and processes. However, any successful IT service delivery model rests not just on technological prowess but also on its relationships' strength and depth. Within the ITIL v4 framework, Relationship Management emerges as a practice designed to nurture and maintain the bond between service providers, customers, and other stakeholders. For those already acquainted with ITIL v4, it's understood that the framework offers a holistic approach to IT service management, integrating principles, practices, and activities to support organisations in managing and delivering services to their customers. Relationship Management stands out among these practices, not for its direct impact on the technology stack, but for its role in aligning IT services with business needs and expectations, ensuring that technology is an enabler of value rather than a mere operational tool. The significance of Relationship Management cannot be overstated. In an environment where IT is increasingly seen as a partner in business success, the ability to establish, sustain, and enrich relationships with customers, users, and other stakeholders is paramount. This practice goes beyond customer service; it's about understanding needs, anticipating changes, and working collaboratively to co-create value. Doing so helps bridge the gap between the technical capabilities of IT services and the strategic ambitions of the business, ensuring that both are aligned in pursuit of common goals. Understanding Relationship Management At its core, Relationship Management within the ITIL v4 framework is designed to identify, analyse, and foster relationships with stakeholders to ensure that the services provided meet or exceed their expectations. This practice recognises that the value of IT services is not solely derived from their technical specifications but also from their ability to satisfy the needs and objectives of those they serve. Hence, Relationship Management is fundamental in aligning services with the business's strategic direction, ensuring that IT is a crucial success enabler. Definition and Objectives Relationship Management aims to establish and nurture the links between the service provider and its customers, users, and other stakeholders. These relationships are critical for understanding requirements, setting expectations, and facilitating effective communication. The ultimate goal is to support value co-creation through services closely aligned with business needs and user expectations. The objectives of Relationship Management can be summarised as follows: Types of Relationships In the context of ITIL v4, Relationship Management oversees various types of relationships, each critical to the service management ecosystem. Customer Relationships: These are the relationships between the service provider and the individuals or organisations with a direct interest in the services offered. User Relationships: Distinct from customers, users are those who directly interact with the service. Understanding user needs and experiences is vital for service improvement. Supplier and Partner Relationships: These relationships are with third parties that provide additional products or services necessary to deliver the IT services. Internal Relationships: Within an organisation, Relationship Management also applies to the interactions between different departments, teams, and roles that contribute to service delivery. Each of these relationships requires a tailored approach to management, considering the unique needs, expectations, and value propositions involved. By effectively managing these diverse relationships, organisations can ensure that their IT services are aligned with business objectives and flexible enough to adapt to changing stakeholder needs. Key Components of Relationship Management Relationship Management within the ITIL v4 framework encompasses several vital components for building and maintaining effective relationships between service providers and their stakeholders. Understanding and implementing these components is crucial for any organisation to enhance its service delivery and customer satisfaction. Stakeholder Identification and Analysis The first step in effective Relationship Management is identifying and understanding the stakeholders. This involves mapping out all individuals, groups, or organisations interested in or affected by the IT services provided. Stakeholder analysis helps categorise stakeholders based on their influence, interest, and needs concerning IT services. This analysis is critical for prioritising relationship-building efforts and tailoring communication strategies to different stakeholder groups. Establishing and Maintaining Relationships After identifying and analysing stakeholders, the next step is establishing and maintaining relationships with them. This involves developing strategies for engagement, setting up regular communication channels, and ensuring a clear understanding of each party's expectations. Relationship maintenance is an ongoing process that requires continuous effort and adaptation to stakeholders' needs and organisational objectives changes. Communication Strategies Effective communication is at the heart of Relationship Management. Developing and implementing a communication strategy that addresses different stakeholders' needs, preferences, and communication styles is vital. This strategy should include regular updates on service performance, changes, improvements, and mechanisms for feedback and dialogue. Clear, transparent, and timely communication fosters trust and strengthens relationships. Value Co-creation A central theme of ITIL v4 is the co-creation of value through collaborative service relationships. Relationship Management involves stakeholders in the service management process, enabling them to contribute to and influence service design, delivery, and improvement. This collaborative approach ensures that services are aligned with stakeholders' needs and expectations, leading to higher satisfaction and perceived value. Implementing these key components effectively requires a structured approach and a commitment to understanding and meeting the needs of stakeholders. By focusing on stakeholder identification and analysis, relationship establishment and maintenance, communication strategies, and value co-creation, organisations can ensure that their Relationship Management practices contribute positively to service delivery and overall business success. Service Relationship Journey The Service Relationship Journey within the ITIL v4 framework outlines the progression of interactions and engagements between service providers, service consumers, and other stakeholders. This journey is not linear but a continuous cycle of improvement and value co-creation. Understanding this journey is crucial for effective Relationship Management, as it highlights the stages where strategic and meaningful engagement can enhance service value and customer satisfaction. Explore: Understand Markets and Stakeholders The journey often begins before any formal relationship is established, with service providers and consumers exploring their needs and market opportunities. This stage involves understanding potential partners' operational context, strategic objectives, and organisational capabilities. For service providers, it's about identifying market demands and the stakeholders' specific needs. For service consumers, it's about understanding what services are available and how they might meet their needs. Engage: Foster Relationships Once potential alignments are identified, the focus shifts to fostering relationships. This stage is critical for building trust and understanding between the service provider, consumer, and stakeholders. Effective engagement involves open communication, transparency, and a willingness to understand and accommodate each other's needs and expectations. Good relationships are foundational for any successful service delivery and value co-creation. Offer: Shape Demand and Service Offerings With a foundation of trust and understanding, the next step is to shape the demand and service offerings. This involves articulating, matching, and refining the requirements and capabilities of both parties. The service provider develops and presents offerings that align with the consumer's articulated needs. This stage is crucial for ensuring that the services offered meet the demands and bring value to the service consumer. Agree: Align Expectations and Agree on Service The next critical step is to align expectations and a formal agreement on the service scope, quality, and delivery conditions. This involves planning how value will be co-created, establishing metrics for tracking performance, and agreeing on the responsibilities of each party. Clear agreements set the stage for a successful service relationship, ensuring both parties are committed to the same objectives and understand their roles in achieving them. Onboard: Get on Board or Leave the Journey Transitioning into the service involves integrating the service into the consumer's environment or, if not proceeding, parting ways amicably. Onboarding is a crucial phase where resources are allocated and processes are adjusted to facilitate the new service. Effective onboarding ensures a smooth transition and sets the foundation for successful service consumption and value co-creation. Co-create: Provide and Consume The actual provision and consumption of the service, where both parties actively engage in co-creating value based on the agreed terms. This stage involves leveraging the service provider's resources and the consumer's active participation to achieve the desired outcomes. Continuous engagement and adaptation are key to ensuring the service meets the consumer's evolving needs. Realise: Capture Value and Improve The final stage involves tracking the value created through the service, assessing performance against agreed metrics, and identifying areas for improvement. This continuous evaluation is essential for maintaining and enhancing the service's value over time. Feedback and insights gained during this stage inform future iterations of the service relationship journey, driving ongoing improvement and adaptation. Processes within Relationship Management The practice of Relationship Management in ITIL v4 encompasses structured processes and activities designed to fulfil its purpose effectively. These processes ensure that the practice not only establishes but also maintains and enhances relationships with various stakeholders through a systematic approach. Processes Overview Each practice within ITIL, including Relationship Management, may include one or more processes and activities necessary to achieve its objectives. A process is a set of interrelated or interacting activities that transform inputs into outputs, defining the sequence of actions and their dependencies. Specifically, Relationship Management focuses on two main processes: Managing a Common Approach to Relationships Managing Relationship Journeys These processes are integral to fostering and sustaining meaningful relationships with stakeholders, ensuring the organisation's relationship approach is coherent, strategic, and effectively managed across all levels. Managing a Common Approach to Relationships This process is dedicated to defining, agreeing upon, and promoting a unified organisation-wide approach to managing relationships with various stakeholders. The activities within this process include: Analysing the organisation's culture, strategy, and stakeholders: Understanding the existing relationship dynamics, organisational culture, and strategic objectives to tailor the relationship management approach. Developing and agreeing on key principles of relationships: Establishing foundational principles that will guide all stakeholder relationships, ensuring consistency and alignment with organisational values. Developing and agreeing on relationship models for key stakeholder groups: Creating tailored relationship models that address different stakeholder groups' specific needs and dynamics. Embedding effective behaviour patterns into daily work interactions: Integrating the agreed principles and models into the organisation's daily operations, fostering a culture that supports effective relationship management. Reviewing and adjusting the relationship approach and models: Continually assessing the effectiveness of the relationship management approach and making necessary adjustments to improve stakeholder engagement and satisfaction. Managing Relationship Journeys Focusing on the ongoing management of relationships according to agreed models, this process ensures that relationships evolve in a way that remains aligned with organisational objectives and stakeholder needs. Key activities include: Identifying stakeholders and selecting the appropriate relationship model: Recognising and categorising stakeholders to apply the most effective relationship model. Verifying and adjusting the relationship model to the situation: Tailoring the chosen model better to fit the specific context and dynamics of the relationship. Following the relationship model: Adhering to the established model to guide stakeholder interactions and engagements. Managing exceptions: Addressing and resolving any deviations or challenges that arise in the relationship according to the model. Reviewing the relationship: Regularly assessing the relationship to identify improvements, capture lessons learned, and initiate continual improvement initiatives. Key Metrics for Relationship Management In ITIL v4's Relationship Management practice context, measuring the effectiveness of relationship management activities is crucial for ensuring continuous improvement and alignment with business objectives. Key metrics provide actionable insights into how well relationships are managed and where there are opportunities for enhancement. Here are several important metrics that organisations can use to track the success of their Relationship Management efforts: By monitoring these key metrics, organisations can gain valuable insights into the effectiveness of their Relationship Management practices. This, in turn, enables them to identify areas of strength, uncover opportunities for improvement, and make informed decisions to enhance stakeholder relationships and service delivery. Benefits of Effective Relationship Management Effective Relationship Management, as outlined in the ITIL v4 framework, yields numerous benefits for organisations, service providers, and stakeholders. By prioritising establishing, maintaining, and enhancing relationships, organisations can significantly improve service delivery, stakeholder satisfaction, and overall business outcomes. Here are some of the key benefits of effective Relationship Management: Improved Service Delivery By fostering solid relationships with stakeholders and understanding their needs and expectations, organisations can better tailor their IT services to meet these requirements. Effective Relationship Management ensures that services align with customer needs, enhancing service quality, reliability, and performance. This alignment helps in reducing service disruptions and improving the overall user experience. Enhanced Customer Satisfaction One of the primary goals of Relationship Management is to enhance customer satisfaction. Organisations can improve customer loyalty and satisfaction levels by engaging with customers, understanding their feedback, and adapting services accordingly. Satisfied customers are likelier to continue using the services, recommend them to others, and contribute to a positive brand reputation. Increased Trust and Collaboration Effective Relationship Management builds trust between service providers and their stakeholders. Trust is the foundation for open communication, sharing of information, and collaborative problem-solving. When stakeholders trust the service provider, they are more likely to engage in co-creation activities, share insights, and work together towards common goals, leading to innovative solutions and mutual benefits. Better Alignment of IT Services with Business Needs Relationship Management helps ensure that IT services are aligned not only with customer needs but also with the business's strategic objectives. By maintaining a close relationship with business stakeholders, IT can gain insights into changing business priorities, emerging opportunities, and potential challenges. This enables IT to adapt services proactively, ensuring they continue to support business objectives effectively. Facilitates Value Co-creation The ITIL v4 framework emphasises the co-creation of value through collaborative service relationships. Effective Relationship Management facilitates this by creating an environment where service providers and consumers can work together to identify opportunities for value creation. This collaborative approach ensures that services are designed and delivered to maximise value for all parties involved. Competitive Advantage Organisations that excel in Relationship Management can achieve a competitive advantage by differentiating themselves through superior service delivery and customer engagement. By establishing strong, lasting relationships with stakeholders, organisations can secure their loyalty, attract new customers through positive word-of-mouth, and stand out in a crowded market. Implementing Relationship Management in Your Organisation Implementing effective Relationship Management within the framework of ITIL v4 requires a strategic approach that focuses on understanding stakeholder needs, fostering collaboration, and continuously improving relationships. Below are some best practices, tools, techniques for successful implementation, and advice on overcoming common challenges. Implementing Relationship Management: Best Practices Checklist Action Plan for Implementation Kick-off Meeting Organise a kick-off meeting with key stakeholders to communicate the importance of Relationship Management and outline the objectives of implementing these best practices. Assign Roles and Responsibilities Clearly define who is responsible for each action point, ensuring ownership and accountability for implementing the best practices. Develop a Timeline Create a realistic timeline for implementing each best practice, including milestones for stakeholder mapping, establishing communication channels, setting expectations, fostering a customer-centric culture, and setting up feedback mechanisms. Monitor Progress and Adapt Regularly monitor the implementation progress against the timeline and objectives. Be prepared to adapt your approach based on feedback and the changing needs of stakeholders. Celebrate Successes Recognise and celebrate achievements and milestones to maintain momentum and motivation among the team and stakeholders. Tools and Techniques for Effective Implementation CRM Systems: Customer Relationship Management (CRM) systems can be invaluable for tracking customer interactions and managing customer information. These systems help personalise the customer experience and ensure customer needs are met promptly. Collaboration Platforms: Tools like Slack, Microsoft Teams, or Asana can facilitate collaboration and communication internally and with external stakeholders. These platforms can help keep everyone informed and engaged. Social Media and Digital Communication: Utilising social media platforms and digital communication tools can help reach out to and engage with a broader audience. They offer informal yet effective ways to maintain relationships and gather feedback. Overcoming Challenges Resistance to Change: Change is often met with resistance from internal teams or external stakeholders. Address this by clearly communicating the benefits of Relationship Management practices and involving stakeholders in the change process. Resource Constraints: Implementing Relationship Management practices can be resource-intensive. Prioritise initiatives based on their potential impact and seek executive support to allocate necessary resources. Maintaining Consistency: Consistently applying Relationship Management practices across all levels of the organisation can be challenging. Develop organisational policies and training programs to ensure consistency and alignment with Relationship Management goals. Effective Relationship Management is a dynamic and ongoing process. It requires commitment across the organisation to understand and meet stakeholder needs continually. By adopting these best practices, utilising appropriate tools and techniques, and being prepared to address common challenges, organisations can significantly enhance their Relationship Management capabilities, improving service delivery, customer satisfaction, and overall business success. This article discusses concepts and practices from the ITIL framework, which is a registered trademark of AXELOS Limited. The information provided here is based on the ITIL version 4 guidelines and is intended for educational and informational purposes only. ITIL is a comprehensive framework for IT service management, and its methodologies and best practices are designed to facilitate the effective and efficient delivery of IT services. For those interested in exploring ITIL further, we recommend consulting the official ITIL publications and resources provided by AXELOS Limited.

Get yourself a coffee. This is probably my longest blog. It's been cathartic, but it might help others estimate their projects. At the heart of every project lies a set of estimations - a roadmap that guides our teams to the end goal. As we embark on a new delivery, these estimations act as signposts along an ever-evolving path. One familiar pitfall project managers face is the underestimation of the effort required. Here, I want to delve into the nature of estimation, its challenges, and strategies to mitigate related risks. As the term suggests, estimates are educated guesses about what lies ahead in the project journey. In the beginning, these guesses can be wide off the mark. However, as we venture further, the fog of uncertainty should begin to lift, making way for increasingly accurate estimations. Our estimations should mirror the "cone of uncertainty", a concept illustrated by Steve McConnell in his book, "Software Estimation: Demystifying the Black Art". As the project progresses, the cone narrows, symbolising a decrease in the estimation uncertainty. So, giving estimates within a range rather than a single figure can combat underestimation. The common practice of providing an overly optimistic figure can set unrealistic expectations and set a project up for failure. I firmly believe in tri-estimation: providing a best-case, worst-case, and most likely scenario. This method gives a holistic view of the situation, offering a reasonable buffer for uncertainties. I'd go further than this in many projects, particularly the longer ones, and say that publishing these figures clearly in your reports is crucial. I've had pushback on this over the years, with people only wanting to publish 'the most likely' estimate, which in my opinion, is dangerous as it misses context and will almost always need constant adjustment. In the early stages of a project, it's easy to get bogged down with creating perfect estimates. People often see it as handing the management team a stick to be beaten with if they fail to adhere to the early assessment. But sometimes, we must put a stake in the ground and make a 'Wild Arsed Guess (WAG)'. Many people are reluctant to give anything without analysing, workshopping, discussing, pro-types, etc. They get struck down by analysis paralysis and can't provide a rough order of magnitude (ROM) estimate. But these are often needed to understand a project's viability and likely costs during the feasibility stages. Teasing them out of teams can be painful but necessary. I'd suggest, in these instances timeboxing the duration for such estimates (e.g. having a short workshop to discuss the likely resources and time). However, it's crucial to remember not to hinge delivery upon these early, rough estimates. Senior management often interprets estimates as confirmed delivery dates, ignoring the caveats that come with them. If someone says we are tracking 6th April, that's their takeaway. That's all they hear, "6th April". Anything less will be considered overdue. When communicating estimates, it is essential to articulate the uncertainties and variables affecting the timeline. Nobody wants to be perceived as a doomsayer, but reporting overly optimistic timescales, which you then push out week by week, is the weakest form of project management. Let's talk about tools. Development estimate tools can be instrumental in tracking and predicting project progress. A well-executed tool can be a project manager's best ally. My Favourite: Burndown Charts Consider the burndown chart, a staple in agile methodologies. This simple yet powerful graph shows work left to do versus time. It visually represents progress, helping teams adjust their pace and strategies to meet their goals. Despite being associated with agile development, burndown charts can also be adapted to other projects or situations, making them a versatile tool in a project manager's toolbox. A burndown chart is a visual tool used predominantly in agile project management to illustrate the amount of work remaining in a project against time. The x-axis typically represents time (in days, weeks, or sprints), and the y-axis represents the work left to complete, usually measured in hours or story points. At the start of the project, a line is drawn from the top left corner (representing the total work to be done) down to the right, indicating the expected completion rate. As tasks are completed, they are marked off, creating a new line that 'burns down' towards the x-axis. The comparison between the actual progress and ideal lines visually represents whether the project is on track. If the project is ahead of schedule, the actual line will be below the ideal line; if it's behind schedule, it will be above. The burndown chart's real-time update capability allows teams to react and adjust their pace or strategies as necessary promptly. It does depend on getting an early estimate on epics/tasks (often in "story points") and then the pace (or 'velocity') of the team (i.e. how many story points they can get through in a period). Teams can be reluctant to do this type of estimating as it can be heavy on the effort up front. Ah, you say, "Estimating the effort of a project upfront is waterfall, not agile!" Ah, I say, "Tell me how you will estimate the delivery of the entire project then?" At some point, the estimates must move to something based on evidence and calculations. We need that. Estimate the epics (big ticket items) for the project as a whole, and then estimate the user stories for the sprint you are entering. That way, you can have a sprint burndown and a project burndown. Methods of Estimation However, just like any other tool, the effectiveness of a burndown chart lies in its execution. To accurately reflect a project's status, the data needs to be there, and it's an iterative cycle; back to the first point about the 'cone of uncertainty'. In Mike Cohn's book called 'Agile Estimating and Planning,' he gives several methods of estimation; Story Points: Cohn explains that estimating with story points is a beneficial and efficient technique. A story point is a measure of effort required to implement a user story, which is an informal description of a feature from an end-user perspective. In story point estimation, the relative size of a user story is compared to other user stories, and points are assigned accordingly. It is a comparative metric and doesn't correlate to a specific time duration, like hours or days. Ideal Days: Cohn introduces the concept of ideal days for estimation. Ideal days represent the time something would take to develop without interruptions. Thus they represent a "perfect" or "ideal" development environment. This method can be more intuitive for some teams, as it's based on time. Still, it must be adjusted according to the team's efficiency and inevitable interruptions in real-world work environments. Planning Poker: This is a consensus-based technique for estimating the effort or size of user stories in Scrum. Each team member is given a set of cards (usually online) with different numbers corresponding to the Fibonacci sequence. For each user story, team members privately select a card representing their estimated effort required and then simultaneously reveal their cards. This leads to discussion and, ultimately, consensus on an estimate. Affinity Estimating: In this technique, user stories are grouped by their similarities or 'affinities.' Teams compare a new user story with already-sized stories and place it in the appropriate group. It is handy for estimating a large number of user stories quickly. T-Shirt Sizing: Here, user stories are assigned sizes that correspond to t-shirt sizes (XS, S, M, L, XL). Alternatively, a Fibonacci sequence is used (e.g. 1,2,3,5,8). It's a less precise but quick method, often used in the early stages of a project and one I've used many times. Cohn emphasises that no estimation technique is universally better than others. The choice depends on the team's preference, the project specifics, and the level of precision required. All these techniques aim to break the complexity of tasks into manageable, estimable units. They should be refined as the project progresses and the team gains more knowledge and insights. Don't Forget The Testing While here, I want to ensure this thought is captured too. Don't underestimate the testing phase. Some industry experts propose that testing can take up 25% to 50% of the total project effort. For instance, in "The Art of Software Testing" by Glenford J. Myers, Corey Sandler, and Tom Badgett, they suggest that, in many cases, the ratio might lean more towards a 1:1 ratio for development to testing, especially for highly critical or complex systems. An Agile cycle doesn't stop the need for a thorough testing phase(s) at the project's back end. If you're outsourcing your development, you'll still need a hefty QA phase. I'm used to external development organisations shovelling crap over the fence and expecting UAT to pick up on the faults. I could write a whole article on just that. Maybe I will… Ring Fence Your Resource One final thought; estimates are for nothing if the resources aren't ring-fenced against outside interruption. Suppose your team is working on other things simultaneously, such as delivering bugs and fixes while developing new features. Your estimates will likely get blown out of the water in that case. Sometimes this is unavoidable, in which case you need to estimate the amount of time for that external 'noise', but the better approach is ring-fencing resources. The more critical the delivery, the more I'd ring-fence the resource. In conclusion, project estimation is fraught with potential pitfalls, and underestimation is a common yet dangerous misstep. By utilising a dynamic, range-based approach to estimation, recognising the value of early-stage 'WAGs', improving the communication of uncertainties, and effectively employing tools such as burndown charts, we can mitigate these risks, setting our projects up for success. Further Reading: McConnell, Steve. "Software Estimation: Demystifying the Black Art". Microsoft Press, 2006. Lederer, Albert L., and Jayesh Prasad. "Nine management guidelines for better cost estimating." Communications of the ACM, 1992. Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall Professional Technical Reference.

In the following article, I will explore some of the project management fundamentals, tools & techniques that I've reached out to use time and again as a successful project manager during project planning. There isn't going to be anything that knocks the socks off someone who has been doing project management for a while. Still, it is designed to spotlight other management techniques that might help a noob (as my kids say) or intermediate in their project management career. Let's start with the key methodologies. Project Management Life Cycle Methodologies & Standards Everything here is interchangeable and complementary. For example, a project manager can run a PRINCE2 or PMBOK project using Agile Scrum project management development cycles. They aren't mutually exclusive. I've done it many times. Agile Scrum: The Paradigm of Adaptability and Collaboration What is Agile Scrum? Agile Scrum project and change management is a vibrant, iterative methodology that fosters teamwork skills, communication and stakeholder engagement. It's designed for teams to adapt quickly to changes and work collaboratively towards a common goal. Agile methodologies like Scrum are built on flexibility, adaptability, and collaboration principles. They thrive in environments where requirements may change or evolve throughout the project. Agile assumes that the project manager and team will learn more about what is needed as the project progresses, giving them the latitude to make changes and manage projects accordingly. In Agile Scrum, work is broken down into short cycles by the project managers and team, known as "sprints," which typically last two to four weeks. A "Product Backlog" houses all the tasks, features, and requirements, which are then pulled into each sprint based on priority. The Scrum Master plays a pivotal role by facilitating Scrum ceremonies and ensuring that the team stays on schedule and accurate to the principles of Scrum. The Agile approach is about taking smaller chunks of delivery, prioritised by value and delivering it in a cycle; then you pick up the next set of features, build, test and deliver those. Here's a nice article from Paul Ross summarising Agile in more depth. Over the years, people have started using the term 'Agile' to mean anything they want it to mean, and usually incorrectly. It's worth looking for a moment at the manifesto that kick-started the whole thing (check out http://agilemanifesto.org for more). We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. If you are interested, look at the fundamental principles here: https://agilemanifesto.org/principles.html. Pros and Cons Pros: High adaptability, rapid delivery, and excellent for evolving projects where scope and requirements are defined as you go, allowing flexibility as the project develops. Cons: It can be chaotic for projects with fixed scopes or strict regulatory requirements as there becomes an overhead of constant meetings and scope review. Agile also doesn't focus on upfront planning, which can be dangerous and inefficient when determining the resources needed for the delivery. Waterfall: A Linear Approach for Well-Defined Projects What is Waterfall? The Waterfall project management methodology is often viewed as outdated, especially compared to Agile. However, this linear, step-by-step approach to the project management life cycle has its merits and needs to be more deserving of its sometimes negative reputation. In Waterfall, projects move through stages like Requirements, Design, Implementation, Testing, and Deployment, each relying on the previous one's completion. The term 'Wagile' is often used mockingly for organizations attempting to implement Agile in a Waterfall manner. While Agile advocates for rapid initiation, Waterfall focuses on thorough planning before project commencement. Both approaches have advantages and disadvantages, but Waterfall can be particularly beneficial in specific contexts. Waterfall benefits projects with well-defined, static requirements, such as those in regulated sectors like healthcare and finance, where comprehensive documentation is mandatory. Its structured nature lends itself well to large and complex projects involving multiple teams, allowing for better management and predictability. Clients and stakeholders often appreciate this predictability, as it provides a comprehensive upfront plan with clearly defined deliverables and timelines. The methodology is also conducive to specialisation; teams can zero in on specific project stages or phases where their expertise is crucial, often enhancing the quality of work. A dedicated phase for quality assurance allows more scope for rigorous testing, a key asset when each project stage builds upon the last. Lastly, it's worth noting that Agile projects often require a comprehensive end-to-end testing phase, similar to Waterfall. While Agile incorporates ongoing testing, its QA phase can also extend other phases of the project timeline, just as it would in Waterfall. Therefore, Waterfall's structured approach offers significant advantages to a project manager for projects requiring a sequential flow that can't quickly be revised. Pros and Cons Pros: Defined structure, easier management, and ideal for projects with precise requirements. Cons: Inflexible, slow to market, and changes can be expensive and disruptive. PRINCE2: A Structured, Process-Oriented Model for Project Managers What is PRINCE2? PRINCE2, short for "Projects IN Controlled Environments," is a UK-originated, process-oriented methodology famous worldwide for its structured approach to project management. Unlike broader frameworks, PRINCE2 offers a more detailed set of processes and steps. Built on seven principles, themes, and processes, it clearly outlines roles and responsibilities, making it adaptable to managing projects of any size or sector. The methodology breaks projects into manageable stages for accurate planning and control. It prioritizes business justification and continuous viability assessment, focusing on delivering value. This flexible planning approach allows project managers to only detail the phase they're currently in or about to enter, preventing unwieldy and confusing project plans. However, its structured nature might not be ideal for projects needing high flexibility or for smaller project teams where formal roles could seem excessive. But for large-scale ventures requiring meticulous planning and robust risk management, PRINCE2 remains a solid choice. The 7 Principles of Prince2 project management 1) Continued Business Justification A project must have a clear business need, customer quality expectations, and benefits that are continually assessed and justified. 2) Learn from Experience Project teams should continually seek and draw lessons from previous experiences. 3) Defined Roles and Responsibilities Every team member within the project management team needs to understand their roles and responsibilities to manage projects. 4) Manage by Stages The project scope should be broken down into manageable stages and phases to enable efficient control of resources and risk. 5) Manage by Exception Establish a clear chain of authority for making decisions when issues go beyond specific pre-defined tolerances. 6) Focus on Products The project should be output-oriented, creating a product that meets the quality, scope, and purpose. 7) Tailor to Suit the Project Environment PRINCE2 should be adapted and tailored to meet the project's specific needs. The 7 Themes of Prince 2 project management 1) Business Case Documents the justification for the project based on estimated costs against benefits. 2) Organization Defines the roles and responsibilities within the team and the scope and organization of the project management team. 3) Quality Describes what quality means regarding project performance and how it will be achieved. 4) Plans Lays out the roadmap for achieving the project objectives. 5) Risk Manages potential threats and opportunities that could impact the project. 6) Change Addresses how the project plan changes will be identified, assessed, and controlled. 7) Progress Monitors and compares actual project team achievements against those planned. The 7 Processes of Prince 2 project management 1) Starting Up a Project (SU) The initial process involves defining the project at a high level. 2) Directing a Project (DP) This phase concerns the decisions regarding project initiation, stage boundaries, and closure. 3) Initiating a Project (IP) Involves creating a Project Initiation Document that encapsulates the business case and other vital elements. 4) Controlling a Stage (CS) Managing the various stages, including assigning, monitoring, and controlling work. 5) Managing Product Delivery (MP) Ensures that the project team creates and delivers the project’s products. 6) Managing a Stage Boundary (SB) Involves planning and approvals for the project moving from one stage to the next. 7) Closing a Project (CP) Formal decommissioning of the project, handing over products to the client, and evaluating project status and performance. Pros and Cons Pros: Scalable, standardised, and excellent for large projects. Cons: It can be overly bureaucratic and may not be ideal for smaller or less formal projects. PMBOK What is PMBOK? The Project Management Body of Knowledge (PMBOK) is a guide and framework for best practices in project management and is best known and used in the United States. It is developed and maintained by the Project Management Institute (PMI), a globally recognised non-profit professional organisation for project management. The PMBOK Guide is widely considered to be the definitive resource for project management methodologies, tools, and training courses and techniques. It serves as the foundation for PMI's Project Management Professional (PMP) certification exam. Unlike some methodologies like PRINCE2 or Agile, PMBOK isn't a project management "methodology" in itself. Instead, it's a comprehensive and organized collection of processes, best practices, terminologies, and guidelines accepted as standards within the project management industry. It aims to provide a common language and framework for project management that can be adapted and applied across organizations in various industries, domains, and project sizes. The PMBOK Guide outlines a framework for change management and project management fundamentals based on five process groups and ten knowledge areas. The five process groups are Initiating, Planning, Executing, Monitoring and Controlling, and Closing. These stages guide the lifecycle of change and project management for a project from conception to completion. The ten knowledge areas in PMBOK are: Project Integration Management Project Scope Management Project Schedule Management Project Cost Management Project Quality Management Project Resource Management Project Communications Management Project Risk Management Project Procurement Management Project Stakeholder Management Each knowledge area consists of specific processes belonging to one of the five process groups. The processes within each knowledge area are typically defined in terms of their inputs, tools and techniques, and outputs (commonly referred to as ITTOs). PMBOK is a comprehensive resource project managers can consult to improve communication practices. It offers flexibility, allowing project managers to select and develop the tools, communication techniques, practices, and processes most relevant to their project rather than prescribing a one-size-fits-all methodology. Pros and Cons Pros: Extensively detailed, universally recognised, and versatile. Cons: Can be complex and overwhelming, often best suited for large-scale projects with experienced project managers at the helm. Selecting and executing an appropriate strategy and methodology is vital for the success of any project. Each methodology has its own advantages and limitations, so it's crucial to weigh these factors carefully against your project's scope, budget, time, cost, risk and quality objectives. With a solid understanding of Agile Scrum, Waterfall, PRINCE2, and PMBOK, you'll be better prepared to guide your projects to a successful outcome. Project Management Fundamentals : Tools When I refer to project management tools here under the banner of project management fundamentals, I'm not talking about project management software applications but tools that can be used regardless of the software you choose. Most project management SaaS solutions handle all of these things, but you can equally do them in Microsoft Office or Google Docs just as effectively. Gantt Charts Gantt charts are a visual scheduling and management tool that presents the project timeline in a graphical format. By displaying tasks and their respective start and end dates, project managers can see the entire project schedule, scope, and sequence. Dependency mapping within the chart can reveal critical paths and potential bottlenecks. Love them or loath them (and I've encountered a lot of people who hate them with the same passion my dog hates a bath), the value of Gantt charts lies in their ability to provide a clear and comprehensive overview of the project's progress, helping project managers both to anticipate issues and realign resources as necessary. I've yet to find a visual tool that works as effectively for project managers. It becomes about pitching it at the right level of detail for the intended audience. Kanban Boards Kanban boards are becoming increasingly crucial to project management fundamentals and are used to organise and track tasks through different project management life cycle stages. Utilising columns and cards, they visually represent the project status and progression of tasks, promoting transparency within the project management team. They're highly adaptable and can be used in various project management methodologies. For project coordinators and project managers, Kanban boards enhance team collaboration, allowing for real-time updates and flexibility, making them a valuable tool for managing workflows and maintaining efficiency. AIRAD (Actions, Issues, Risks And Decisions Log) The AIRAD (or often RAID) log is a centralised tracking tool for various project components, including actions, issues, risks, and decisions. It fosters accountability and ensures that critical elements are not overlooked. For a project manager, quickly identifying and addressing risks and issues is paramount. The AIRAD log facilitates this by providing a consolidated view, aiding the project manager in risk mitigation, and contributing to the overall smooth execution of the project. It's a valuable tool for project management fundamentals and tracking at any level. The more complex the project, the more I separate these things, but for small to medium projects, having them combined in one place can work well. At its most uncomplicated, you can create a spreadsheet in Excel and track the actions, performance issues, risks and decisions there. See my templates section for "AIRAD" to create a template. Work Breakdown Structure (WBS) A Work Breakdown Structure (WBS) is vital in project management, particularly software delivery. This organisational tool allows the project manager to break down a project into manageable tasks and sub-tasks, aiding in allocating resources, time management, and tracking progress. A WBS presents a hierarchical structure that offers transparent communication and a comprehensive view of the project, enhancing communication and collaboration among project team members and stakeholders. For a software delivery project, a WBS might be divided into categories like requirement analysis, system design, coding, testing, and deployment. These categories can be further broken down into specific tasks with detailed responsibilities and deadlines. For instance, the coding phase of a successful project may include tasks like developing individual modules, peer reviews, and integrating different components. By organising the project in this manner, a WBS helps ensure that each phase of a successful project is carefully planned and executed, contributing to the timely and successful delivery of the software product. RACI Matrix Models So, the RACI Matrix is common inside and outside of projects. The acronym RACI stands for Responsible, Accountable, Consulted, and Informed. I mention it because it is a valuable tool for any project manager, regardless of your methodology of choice, to ensure roles and responsibilities are understood. In any project, it is critical to track and document these things; there is no better, succinct way than using the RACI Matrix. A RACI matrix is a project management tool that clarifies roles and responsibilities during a project or set of tasks. The matrix is presented in a tabular form with tasks or deliverables listed in rows and project team or members listed in columns. Here's what each letter in the acronym RACI stands for: Responsible This person or role is responsible for performing the task or completing the deliverable. They are the "doers" of the work. Accountable This person or role is ultimately accountable for the correct and thorough completion of the task. There should be only one person designated as "Accountable" for each task, and they have the authority to sign off or approve the task. Consulted These stakeholders are the people or roles that need to provide input or advice before the task can be completed. They have to develop a two-way communication relationship with the task. Informed These stakeholders are the people or roles who need to be informed after the task is completed or about critical decisions related to the task. They have a one-way communication relationship with the task. Example: Let's consider a simplified example for a website development project. In this RACI matrix example: The Project Manager is Accountable for creating the Project Plan, and the Web Developer and Graphic Designer are Consulted. The Client is Informed after it's done. For the Design Mock-up, the Graphic Designer is Accountable, the Web Developer is Responsible for carrying it out, and the Project Manager is Consulted. Again, the Client is Informed. During the Coding phase, the Web Developer is Accountable and Responsible, the Project Manager is Consulted, and the Client is Informed. By clearly laying out these roles, the RACI matrix helps avoid confusion and overlap between stakeholders, ensuring that everyone knows their roles and responsibilities for each task or deliverable. The above gives you a basic overview of project management fundamentals. Every single one of these areas warrants deeper dives, especially if you are setting off on a project management career to become a successful project manager.

A template for completion to summarise progress on a project to the stakeholders. Project Status Reports (also known as "Highlight Reports") are a cornerstone in project management, offering a snapshot of a project's current state. Our Project Status Report template is designed to provide a structured framework for monitoring and reporting on project performance, budget, and risks. What is the Purpose of the Project Status Report Template? The template aims to: Centralise Information: Bring together all relevant project data in one place. Facilitate Communication: Bridge the gap between project teams and stakeholders. Enable Proactive Management: Provide early warnings for issues and risks. Where and When to Use the Project Status Report Template? Ideal For: Project Managers Team Leads Stakeholders When to Use: Regular project updates Stakeholder meetings Risk assessments What Does it Contain? The Project Status Report template includes the following sections: Project Title: Name of the project. Date & Reporting Period: When the report is prepared and the period it covers. Prepared By: Individual responsible for the report. Executive Summary: A brief overview of the project status. Key Accomplishments: Notable achievements and their details. Project Milestones: A list of milestones, their status, and comments. Issues and Challenges: Identified problems and actions taken. Risks and Mitigations: Potential risks and strategies to mitigate them. Budget Status: A breakdown of budgeted vs. actual spending. Upcoming Activities: Planned activities and those responsible. Action Items: Tasks that need immediate attention. Attachments/Appendices: Any additional documentation. Approval: An optional space for stakeholder signatures. Additional Information RAG Status: Included across multiple sections to indicate the Red-Amber-Green status for quick assessment. Comments Column: To provide additional insights or explanations. Why Choose Our Project Status Report Template? This template is not just a formality but a vital tool for effective project management. It ensures that you capture all key data points, thereby enhancing visibility and control over your project.

Helps you score a project in terms of complexity & risk against simple criteria. Summary The project scoring criteria is designed to help project managers, stakeholders, and teams evaluate the complexity of a given project. The assessment takes into account multiple facets of a project, from scope and impact to technology and resource requirements. Each category is rated on a scale of 1 (Low), 3 (Medium), or 5 (High). How to Use The Project Scoring Criteria For each category, select a score that best describes the project's complexity in that aspect. The sum of the scores calculates the Total Complexity Score. Categories and Project Scoring Criteria Project Size Simple (1): Changes to existing processes or technologies. Moderate (3): Introduction of new solutions or processes without disruption. Complex (5): Replacement of existing technologies, multiple dependencies. Project Scope Small Team/Customer (1): Impacts only a small team or a single customer. Internal Stakeholders (3): Many internal stakeholders but not customers. Many Customers (5): Involves many customers and stakeholders, potentially across offices. End User Impact Unnoticeable (1): End users unlikely to notice any change. Minimal (3): Minimal visible change; some awareness but no in-depth re-training required. Major (5): Major training, documentation, and communication required. Technologies Used Simple Upgrade (1): Simple upgrade or no technology required. Well Understood (3): Technology is well understood but new to the organisation. New Technology (5): A new technology, not widely used, high training or external support required. Suppliers Existing Suppliers (1): Delivered using existing suppliers and solutions. New Products (3): Existing suppliers but new products and terms. New Supplier (5): New supplier and contracts. Approach Phased Migration (1): Users can migrate in phases, no major cut-over. Mixed Approach (3): Groups of users could be transferred to new technology in batches. Major Cut-Over (5): Existing solution turned off, new solution turned on. Capital Costs (Setup) Up to £10,000 (1) £11,000 to £69,000 (3) £70,000+ (5) Operating Costs (On-Going) Up to £10,000 (1) £11,000 to £69,000 (3) £70,000+ (5) Resource Requirements Internal Only (1) Minimal External (3) Major External Dependencies (5) Project Duration Up to 1 Month (1) 2 to 5 Months (3) More Than 5 Months (5) Other Specify any other criteria relevant to your project The total score can serve as a general guide for stakeholders to understand the complexity and resource requirements of the project.