top of page


184 items found for ""

  • Death March Projects Explored

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

  • Mastering ITIL Practices: A Comprehensive Guide to Streamlining IT Services

    Streamlining IT services requires a solid grasp of ITIL practices within the IT Service Management framework. Struggling with service disruptions, slow response times, and user dissatisfaction? You're not alone. The inability to efficiently manage IT services can spell disaster for your career and your organisation. The key to overcoming these challenges lies in mastering ITIL practices. We'll take you through a hands-on exploration of ITIL practices, showing you how to transform your IT operations and secure your place as a leader in IT service management. Don't let outdated methods hold you back. Discover how these practices can be your game-changer and propel your team to new heights. Key Takeaways ITIL 4 provides a structured framework for IT service management, divided into practices like service management, technical management, and general management, forming a versatile toolkit for efficient service delivery. The ITIL 4 Service Value System encompasses a service value chain and practices designed to convert demands into value, emphasising flexibility, adaptive value streams, and continuous improvement. ITIL practices align with modern IT approaches, such as Agile and DevOps, enhancing digital transformation, and ITIL certifications offer pathways for career advancement in IT service management. Understanding ITIL 4 Management Practices Central to ITIL 4 is the comprehension of management practices. These resources are specifically intended for carrying out tasks or achieving a goal within an organisation. They are carefully orchestrated to support these objectives. The practices are divided into three categories: General, Service, and Technical Management. These interrelated activities, or processes, transform inputs into outputs, ensuring a comprehensive approach to delivering value. ITIL 4 has practically defined practice success factors (PSFs) that rely heavily on key metrics and align with the principles of ITIL. Each practice guide offers detailed procedures, workflow maps, and lists of inputs, activities, and outputs for each process, serving as a comprehensive manual for implementing ITIL practices. The Essence of Service Management Practices ITIL 4 hinges on service management practices. They are designed to support delivering IT services that meet specific business needs and objectives. For instance, consider a bustling e-commerce website that promises round-the-clock services. Here, service management practices ensure that agreed service availability and performance levels are met, keeping the digital doors open and the virtual shelves stocked. When the unexpected happens - say, a sudden surge in traffic crashes the website - incident management jumps into action. It's all about quickly restoring functionality, minimising disruption, and keeping the virtual shopping carts rolling. In the same vein, service request management streamlines the handling of user requests and queries, while service configuration management ensures optimal system settings. Service financial management plays a role in keeping customers satisfied and operations smooth. Technical Management Practices Unveiled In IT, technical management practices are the engineering force behind well-functioning machinery. They ensure the optimal performance of the organisation's IT physical and hardware resources, from servers to software. Picture this as the team that keeps your IT operations going smoothly. Infrastructure and platform management, which supervises the organisation's operational environments, is vital. It's like the control centre that ensures all software and development platforms are in top shape for service development and delivery. The stability of IT operations heavily leans on the effective management of these resources. Think of it as the regular maintenance and tune-ups that keep a high-performance sports car running at its best. Implementing industry-standard best practices, like routine updates and standards compliance, stabilises IT operations and facilitates smooth, high-speed IT services. General Management Practices Explained While technical management practices act as the engineers, general management practices serve as the strategic planners in the ITIL 4 ecosystem. They address the broader aspects of service management, such as partner relationship management and sourcing considerations. One of the critical decisions organisations face is determining capabilities, roles, and resources that can be outsourced. This is where sourcing considerations come into play. They help assess risks and benefits, weighing the pros and cons of outsourcing. It's like deciding whether to host a party at home or hire a party planner - each has its benefits and risks, and the decision should be strategically aligned with the organisation's objectives, resources, and risk tolerance. Partner relationship management, on the other hand, is all about managing third-party dependencies and building effective relationships with partners and suppliers. It's like maintaining good rapport with the caterers, decorators, and entertainers for your party to be a hit, an essential aspect of supplier management. The Structure of ITIL 4 Service Value System The ITIL 4 Service Value System (SVS) provides a holistic perspective on how various organisational components contribute to generating value. At the heart of SVS, the service value chain is a central component that outlines the key activities required to respond to demand and facilitate value realisation. Service Value Chain Dynamics The Service Value Chain (SVC) functions as the operational model for the ITIL 4 SVS. It outlines six key activities integral to value creation: Plan Improve Engage Design & Transition Obtain/Build Deliver & Support Like the steps in a dance routine, each activity in the SVC is interconnected, allowing seamless transitions from one move to another. The SVC is structured to assist every facet of IT operations, from the upkeep of existing procedures to the incorporation of business changes. It's like the choreographer who ensures every step and move contributes to the overall performance, creating a spectacle that leaves the audience (or, in this case, the customers) spellbound. The SVC model in ITIL 4 emphasises flexibility, catering to varied service creation and delivery needs, just like a versatile dance routine that can be adapted to different music styles, venues, and audiences. Service Value Creation In the world of ITIL 4, value streams are the paths that enable the transformation of demand into value delivery. It's like a map guiding you from the start to the end of a journey - from demand to value delivery. The journey can be iterative and complex, involving multiple primary activities and repeated or non-linear paths through different activities. It's like an adventurous road trip, where the route is flexible, and you can choose to take detours, scenic routes, or shortcuts depending on various factors. Practices such as service level management and continuous improvement are integral to this journey. They are the compass and the roadmap, ensuring that service providers can consistently meet customer needs and adapt to changing requirements, ultimately delivering greater value. Diving Into Specific ITIL 4 Practices ITIL 4 serves as a framework and a reservoir of 34 practices, each with detailed guidelines to facilitate effective service management. These practices are like the individual tools in a Swiss Army knife, each designed for a specific purpose, but together, they form a versatile toolkit for managing services. Asset Management in Action Asset management is a practice that directs organisations in overseeing the entire lifecycle of IT assets, right from acquisition through to disposal, including release management. Imagine it as the caretaker of your IT assets, ensuring they are well-maintained and efficiently used throughout their lifecycle. Information security management is crucial in protecting these assets from potential threats and vulnerabilities. The objective of ITIL 4's asset management practice is dual-faceted. First, it seeks to maximise the value derived from IT assets. It's like ensuring that every dollar invested in IT assets brings the highest possible return. Second, it strives to control and minimise the costs incurred throughout its lifecycle, like a prudent financial advisor who helps you cut unnecessary expenses and optimise your budget. Maintaining an accurate inventory of assets and understanding their lifecycle stages aids in making informed decisions regarding IT asset investments and optimising asset utilisation. Enhancing Service with Service Desk and Request Management The service desk practice in ITIL 4 resembles a hospitable hotel receptionist, ensuring guests receive timely and suitable assistance. It's the primary contact point between service providers and users, handling incident resolution and service requests. Imagine a scenario where a user encounters a problem with a service. The service desk practice ensures that the user's problem is handled efficiently, restoring regular service operation as quickly as possible. This practice is not static; it evolves through continuous improvement to elevate the quality of IT service management. The goal is to enhance service delivery and improve customer experiences, like a hotel receptionist who goes the extra mile to ensure guests have a pleasant stay. Ensuring Continuity with Service Continuity Management Service continuity management in ITIL 4 is analogous to a ship's lifeboat. It's designed to build organisational resilience and protect services in the event of a disruptive incident - the lifeboat that keeps IT services afloat when unexpected waves of disruption hit. This practice handles risk management for IT services, striving to preserve agreed service levels and assist in recovering services after an interruption. It's like the lifeboat drills on a ship, preparing everyone for potential disruptions and ensuring a safe and orderly response when they occur. The sub-processes of ITIL 4 service continuity management include: Support Design Training Testing Review These sub-processes ensure comprehensive strategies for disaster preparedness and recovery. Leveraging ITIL Practices for Optimal IT Service Delivery Utilising ITIL practices can be compared to fine-tuning a musical instrument. It enhances customer and employee satisfaction, increases efficiency, and reduces costs, creating a harmonious symphony of efficient IT service delivery. Incident and Problem Management: Restoring Normal Service Operation Incident and Problem Management hold crucial positions within the ensemble of ITIL practices. ITIL 4's Problem Management practice is designed to minimise losses and mitigate costs associated with IT service unavailability, much like a skilled conductor who quickly rectifies a wrong note to ensure the performance flows seamlessly. On the other hand, incident management is like the first aid kit for ITIL practices. When an incident occurs, it rapidly restores regular service operations. It drafts detailed plans and implements feedback mechanisms to improve the efficiency of incident resolution, just like a first aid kit equipped with everything needed to address minor mishaps during a performance. Strategic Practices for Long-Term Success The strategic practices in ITIL 4 act as the visionary composers in the symphony of IT service management. They align IT services with business objectives and manage the changes and risks of implementing advanced technologies. Imagine your organisation as a symphony orchestra. The strategic practices, like architecture management and continual improvement, ensure that all sections of the orchestra (IT services) work cohesively, creating a harmonious symphony that aligns with the overall vision (business objectives). They manage the changes and risks in technology adoption, like a composer introducing a new instrument or a different music style into the orchestra, ensuring it blends seamlessly into the symphony. ITIL 4 Practices and Digital Transformation ITIL 4 bridges traditional IT service management to the rapidly evolving world of digital transformation. It integrates Agile, DevOps, and Lean principles into its framework, fostering a flexible and efficient approach to adopting digital technology. Adapting to Agile and DevOps ITIL 4 collaborates smoothly with Agile and DevOps methodologies throughout the digital transformation journey. It's like blending traditional and modern dance styles to create a unique performance that captivates the audience. ITIL 4 doesn't just coexist with Agile and DevOps; it integrates their principles into service management, enabling faster service delivery and increased flexibility. It's like a dance ensemble where each dancer, irrespective of their dance style, moves in sync with the music, creating a mesmerising performance. Integrating Agile and DevOps principles makes IT service management more responsive and adaptive, turning IT operations into a graceful dance that adapts to the changing rhythm of business demands. Embracing New Technologies ITIL 4 does not merely focus on managing existing services; it also welcomes the adoption of new technologies. It includes recommendations on automation and tooling, supporting the adoption of new technologies in service management. Imagine ITIL 4 as the guide who helps you navigate the landscape of new technologies, from selecting the right tools to integrating them into your IT operations. Although ITIL 4 doesn't recommend specific tools, it provides a framework that can be applied irrespective of the technologies used. This flexibility makes ITIL 4 a versatile framework that can adapt to the rapidly evolving world of IT services. Career Advancements with ITIL Certifications ITIL certifications are stepping stones for your career advancement in IT service management. Starting with the ITIL 4 Foundation certification, which serves as the entry-level qualification, there are numerous other certifications that you can pursue to specialise in specific service management areas or to demonstrate your leadership capabilities. ITIL Specialist and Strategic Leader Pathways The ITIL Specialist and Strategic Leader pathways can be compared to advanced hiking trails guiding you to the apex of your IT career. For example, the ITIL 4 Practitioner: Service Desk module offers IT professionals the opportunity to validate their skills in a specialised area of ITIL practices. It's like earning a badge of honour that showcases your expertise and commitment to continuous learning. These certifications validate your skills and open up new opportunities for career advancement, helping you climb higher on the career ladder. Continuous Learning and Development In the rapidly evolving IT world, continuous learning serves as the fuel driving your career progression. ITIL's framework is updated periodically, necessitating ongoing education to keep your skills and knowledge current. Higher-level ITIL certifications, like ITIL Managing Professional or ITIL Strategic Leader, provide evidence of in-depth understanding and the ability to lead in the IT realm. They are like advanced driving licenses that certify your ability to drive different types of vehicles or to drive under challenging conditions. Engaging in continuous learning and acquiring advanced certifications allows IT professionals to adapt to rapid technological changes and industry demands, ensuring that your career engine keeps running smoothly, irrespective of the terrain. Summary Journeying through the world of ITIL 4 practices, we've explored the different management practices, the Service Value System, specific practices like asset management and service desk, and how ITIL 4 supports digital transformation. We've also discussed the career advancement opportunities offered by ITIL certifications. Equipped with this knowledge, you're ready to navigate the landscape of IT service management, leveraging ITIL practices to streamline services, enhance service delivery, and boost customer satisfaction. While the journey of IT service management may be complex, remember, with ITIL 4 as your guide, every step is a step towards success. Frequently Asked Questions What are the three categories of management practices in ITIL 4? In ITIL 4, the three categories of management practices are General Management, Service Management, and Technical Management. These practices encompass various aspects of IT management and are essential for effective service delivery. What is the ITIL 4 Service Value System (SVS)? The ITIL 4 Service Value System provides a holistic view of how organisational components contribute to value creation, with the service value chain being its central component. It's a comprehensive approach to understanding value creation within an organisation. How does ITIL 4 integrate Agile and DevOps methodologies? ITIL 4 integrates Agile and DevOps methodologies by incorporating Agile, DevOps, and Lean principles into its framework, fostering a flexible and efficient approach to digital technology adoption. This allows for a more adaptable and practical approach to technology adoption. What are some of the ITIL 4 certifications that can help advance my career? Consider starting with the ITIL 4 Foundation certification to build a strong foundation. As you progress, you can aim for certifications such as ITIL Managing Professional and ITIL Strategic Leader to advance your career in ITIL. Why is continuous learning important in ITIL practices? Continuous learning in ITIL practices is important because it helps IT professionals maintain the relevance of their skills, adapt to rapid technological changes, and meet industry demands. Staying up to date is vital!

  • An Introduction to Project Management

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

  • The Project Phases

    Introduction to the Project Lifecycle In this section, we'll get a sense of each of the main phases of a typical project. We've already summarised them, but let's refresh our memories. Typically, they are; Initiation: Defining the project and establishing its feasibility and options for delivery so that it can be rubber-stamped to start in earnest. Planning: Now that we have a solid basis, we start building out the scope and objectives and plan in enough detail around the 'who', 'what' and 'when' to allow us to start executing. Executing: Implementing the project management plan; this is where the magic happens and disasters strike. Monitoring and Controlling: Tracking progress and controlling the goat rodeo. Closing: Finalising all activities and bringing the project to an orderly conclusion. Every project is different and may have stages such as research, development, testing, and go-to-market, to name a few, but they essentially fall under one of these main phases. Let's take a closer look at each before we step through each phase in detail. Initiation The initiation phase is the first step in the project lifecycle, where the project's foundation is established. We are pulling things together at this stage, choosing the best folder structure, and working out the coolest project code name. Naivety and optimism are high. The critical initiation activities are; Create the Project Charter The charter captures the project's scope, objectives, justification and primary stakeholders. It's effectively a high-level summary of why the project exists, how you expect it to unfold, who needs to be involved, and what it seeks to deliver. Getting this right is crucial as it's the foundation for everything that comes next. Assemble the Project Team Once the project's scope and objectives are clearly defined and the foundational documentation is in place, you can assemble the project team. Walk them through the charter and get critical feedback on it. Undertake Initial Assessments The early assessments often occur concurrently with the other early tasks. It includes conducting feasibility studies and preparing a high-level risk register. These assessments, or feasibility studies, are essential for understanding the project's viability, potential challenges, and delivery methods. But, they are estimates, rarely ever 100% soul-ownership level binding commitments. However, they'll likely be the only thing anyone remembers, so we'll take extreme care about what is communicated when shared. Develop a High-Level Plan With the project documentation set, the team assembled, and initial assessments undertaken, this plan will detail how the project will be executed, monitored, and controlled. We'll need a high-level end-to-end project plan sketched out for all phases but a reasonable level of detail about the project's next phase, "planning". Planning Gate Approval "Gates" are approval steps. During a gate, we decide whether to proceed with the detailed planning phase, adjust the project scope, or halt the project if it's no longer viable. Cancel a project?! I hear you say? Yes. In some extreme circumstances, your feasibility assessments might demonstrate it isn't as viable as you once thought. Planning The planning phase sets the blueprint for executing, monitoring, and controlling the project. Here are the key activities; Build a Comprehensive Project Plan This step involves refining the high-level 'table-napkin' initial plan created during the initiation phase. It should now be built out to include detailed sections covering cost, schedule, quality, and risk management. The updated plan will serve as the central guiding document for the entire project. Develop a Detailed Work Breakdown Structure (WBS) This activity involves breaking down the total scope of the project into smaller, manageable chunks, which helps in organising and defining the total scope of the project. Think of it like a hierarchical 'mind map' of the deliverables. Nothing seems scary once you've broken it down into smaller parts and worked out what you need to work on first. The WBS is also helpful for updating the plan regarding effort assessments and costs in the next activity. Prepare a Comprehensive Budget Based on the detailed WBS, this step involves estimating the costs associated with each component of the WBS and aggregating these to form an overall project budget. This budget will outline all expected costs and funding allocations across the project lifecycle, ensuring adequate financial resources are available. Establish a Quality Plan This involves setting specific quality criteria and standards for the project's outputs. The quality plan ensures that the project deliverables are high quality and meet the requirements specified by the stakeholders. For example, if you are delivering a software project, you'll need to define your approach to testing here. I struggle to think of any kind of project that doesn't have some testing or quality control steps. That said, I've been on the receiving end of some organisations who have tried not to have quality control phases, which always ends in a shit show. Develop a Communication Plan This plan outlines how information will be communicated to the project's stakeholders (frequency, format, and responsibilities). The more complex the project, the more complex the plan. The simpler the project, the… you get it. Execution Gate Approval Approval of the project management plan and authorisation to start execution. Those last pre-flight checks before you start building things in earnest. Adjustments may be required if there are gaps or misalignments. Executing The Execution phase is where plans are put into action, and the project's deliverables start to take shape. We've talked about it a lot, and now is the exciting part: rolling up your sleeves and getting busy. The activities within Executing include; Direct Management of Work This is the primary activity of the Executing phase, where the project team actively engages in the tasks outlined in the project management plan. It involves allocating resources, whipping junior team members, executing planned tasks, and ensuring each task aligns with the project timeline and objectives. Where collections of work might be complex, then a workstream might be created, driven by a work package (a summary of the requirements for that specific area). This helps break the workload into more manageable chunks. Review Quality Standards Remember the quality plan from earlier? The project needs to continuously monitor and evaluate the deliverables to ensure they meet predefined quality standards per your plan. This includes regular testing, quality checks, and reviews. If deliverables don't meet quality expectations, adjustments and improvements are made. Manage Scope and Handle Changes Most projects encounter people trying to make small changes to the scope, usually prefixed with the words "Can we just…". So, it's vital that we keep the project within its defined scope as much as possible. This involves managing scope 'creep' and implementing any approved scope changes. Implementation Planning The crux of ensuring that the project can transition smoothly from execution to closure is effective implementation planning. This phase is about laying down a detailed roadmap for how the various elements of the project will be implemented, ensuring alignment with the project's strategic objectives and readiness for final delivery. In implementation planning, the focus is on integrating all pieces of the project puzzle. This involves scheduling the final steps, assigning responsibilities for last-mile tasks, and ensuring synchronisation of all teams. Here's what needs to be done; Project acceptance criteria are created and agreed upon to allow the project to close down Ensuring training & documentation are taken into account System testing & User acceptance might be phases that need to be done Consider it a plan for 'going live' with your project, and not just dumping your delivery and running. Every project should not consider the finish line as the end of the main deliveries, but the smooth transition into business-as-usual. Project Closure Gate Finally in this stage, we determine if the project is ready to move into the closing phase or if additional work is needed to meet the agreed-upon deliverables. Normally it'll be in the form of a stage gate, or approval meeting that looks at the project acceptance criteria, and says whether the project has delivered what it set out to do. If so, then the project can move into the very final phase of "project closure". Monitoring and Controlling The Monitoring and Controlling phase ensures the project remains on track and aligned with the set goals and standards. It provides the necessary checks and balances through regular reviews, audits, and adjustments. Typically, the Monitoring and Controlling phase runs concurrently from the Planning Phase to the Execution phase. The key activities; Generate Highlight Reports Performance, or 'highlight', reports provide insights into whether the project is on track concerning its timelines, scope, and budget. Typically, they are sent out on a schedule to keep everyone updated about how progress is unfolding. Maintain Decision, Risk and Change Logs This activity involves keeping records of all identified decisions made or needed, risks (and issues) and changes requested or implemented during the project. These logs is where a lot of arse-covering happens. Implement Corrective Actions Based on the insights from the risk and change logs, implement necessary corrective actions to address and mitigate risks. So, if something is going 'amber' in a status report, how do we stop it from going red and losing our jobs? Host Regular Progress Reviews Invite everyone who wants to come, and then some more (they'll come anyway, even if you try to keep it small), and make sure the communication is happening, the progress is being reviewed, and any exceptions are being escalated. Closing The Closing phase marks the conclusion of the project lifecycle. This phase involves wrapping up all project activities, finalising deliverables, and ensuring all documents are signed off and archived. The focus is on formally accepting the project outcomes and disbanding project resources in an orderly manner. The key activities are; Compile a Final Project Report This report should summarise the entire project, including the objectives, what was accomplished, the methods used, and the outcomes. The report should also detail the performance against the original plan, noting any deviations and their causes. Undertake Lessons Learned Conduct a thorough review of what went well and what didn't throughout the project. This should include feedback from all team members and stakeholders to gather a comprehensive view of the project's successes and challenges. Archive All Project-Related Materials Ensure all documents, reports, contracts, and correspondence are organised and stored in a designated location. Archival is important and often overlooked. It's essential for future reference and compliance with regulatory requirements. It's about thinking of others in the future when they need to check on something and find a piece of information such as a contract that was missed, and knowing where to locate it. Organise a Closure Meeting or Event We wrap it all up nicely now, with a step to formally conclude the project. A closure meeting serves as an opportunity to thank the project team and stakeholders, review the project's achievements, and discuss the next steps, if any. It's also a chance to celebrate the project's success and recognise the efforts of all involved. Glossary of Terms Business Case: A document that justifies the necessity of a project, outlining the expected benefits, costs, risks, and strategic alignment with organisational goals. Change Requests: Formal proposals for changes to any aspect of the project, including the scope, timelines, or resources, which need approval before implementation. Communication Plan: A strategy document that outlines how information will be communicated to stakeholders, including the methods, frequency, and responsibilities. Corrective Actions: Steps taken to bring the project back on track when deviations from the plan are detected or when facing unforeseen issues. Feasibility Study: An analysis conducted to assess the practicality and viability of the project, considering technical, economic, legal, and operational aspects. Final Project Report: A document summarising the performance and outcomes of the project, including details on scope, quality, costs, and time, along with challenges faced and resolutions. Issue Logs: Records that track problems and issues during the project, including details on their resolution. Lessons Learned: Insights and reflections recorded during and after the project aimed at improving future project management practices. Project Acceptance Documentation: Formal confirmation from the stakeholders or clients that the project deliverables meet the predefined criteria and are accepted. Project Breakdown and Budgeting: The process of creating a detailed Work Breakdown Structure (WBS) and a comprehensive budget plan that outlines all expected costs. Project Charter: A document that formally authorises the project, defines the project's objectives, scope, and participants, and grants the project manager the authority to proceed. Risk and Change Logs: Documents that record potential risks and changes encountered throughout the project, detailing the analysis, response, and management strategies. Risk Register: A tool used to identify, analyse, and manage potential risks that might affect the project, detailing mitigation strategies. Stakeholder Register: A document listing all parties interested in or affected by the project, including their roles, requirements, and level of influence. Updates and Quality Control: Continuous monitoring and adjustment of project schedules, management of quality assurance activities, and documentation of necessary changes.

  • Initiating a Project

    Introduction to the Initiation Phase I'm all for Read-Fire-Aim tactics, but kick-starting a project isn't about jumping in headfirst; you've got to set the stage first, or chaos will reign, even in the simplest of projects. In the initiation phase, you line up the dominoes to ensure they fall just right; we're setting up its entire trajectory. It's more than choosing the right folder structure, picking a killer project code name, and doing a bit of crystal ball gazing. As humans, we just can't help it when we start something new - naivety and optimism run away hand-in-hand, telling us it's all going to go well and it'll be completed within a week or two. We can't help it. We are hard-wired for something referred to as 'reckless optimism'. Spoiler alert: it never goes easily. If any project manager tells you it always does because they have the 'formula' to guarantee success, they are peddling snake oil. Something always causes the project to derail to a greater or lesser extent. It's about preparing well and managing the issues effectively when they do happen. But we run ahead of ourselves, so more on that later. In the initiation phase, we're pulling together the big pieces and the tiny details that'll define the entire project. This is the critical first play in our game plan, where we establish what needs to be done, who will be on our team, and whether the whole thing is feasible. Getting this right means everything that follows can have the best chance of success —or at least as close to it as possible. It's all about foundations. Think of it as laying down the keel of a ship. The initiation phase holds everything else up, so we must ensure it's rock solid. If done right, we're on our way to a smooth sail; if not, it's anyone's guess. Let's get into how we do this right, doing the best we can to ensure our project is something everyone will remember for the right reasons. [Diagram showing relationship to other phases] The Main Activities of Project Initiation Create the Project Charter Importance of the Project Charter The charter sets out the "what" and the "who," defining not just the boundaries of the project but also who has the authority to do what. The Project Charter isn't just creating documentation for the sake of it; it's the green light for the project and, I'd argue, probably the most crucial document of the entire project. I see the charter as the bedrock upon which everything else will be built. It's about getting everyone on the same page—literally. Sometimes, fireworks fly when you put the charter before stakeholders because of differing opinions, and that's a good thing to flush out early on. Getting the charter right means securing an upfront commitment from upper management and a clear mandate for the project manager to know what they need to achieve and the parameters within which the project needs to operate. Key Components of the Project  Charter Project Scope: This is where you draw the line in the sand. It's about defining what's in and, very importantly, what's out. Keeping the scope tight and well-defined helps avoid the dreaded scope creep and keeps everyone focused. Objectives and Goals: Here's where the aspirations for the project are penned down. Concrete, achievable, measurable goals to see if they are achieved. This section ties the project back to tangible business outcomes, making it relevant and justified. Project Justification: We must ask ourselves, "Why are we doing this?" This part needs to make the case loud and clear. Whether it's market demand, a business need, or a strategic opportunity, this is your chance to determine why this project matters. One of my biggest mistakes was to allow a CEO to state, "I am the business case!". We sold 2 copies of the product, which cost upwards of £500k. Main Stakeholders: Who's in this? Identifying key players and their roles early prevents confusion and sets the stage for effective engagement. Knowing who has a stake in the project outlines the network of influence and support needed to push the project forward. Steps to Draft and Approve the Project Charter Drafting the Charter Start with a draft that captures all the essentials: scope, goals, justification, and stakeholders. This isn't about perfection; it's about direction and clarity. Get something written down. Consultation and Feedback: Share the draft with key stakeholders. This isn't just about getting approval but engaging them to refine and enhance the document. Feedback at this stage can save a lot of headaches later. Final Approval: Once the charter is polished and everyone has had their say, it's time for the formal sign-off. This approval is the project's official go-ahead, so ensure it's documented. Assemble the Core Project Team Criteria for Selecting Team Members Picking may or may not be something the Project Manager can influence. You need experience, energy, expertise, enthusiasm, intelligence, dexterity, and wizardry skills. Here's how you do it: Skill Match Obviously, you need people who know their stuff. Whether technical prowess, project management expertise, or specific subject knowledge, the team's skills should align closely with the project's requirements. Team Dynamics It's not just what you can do; it's how you work together. Look for individuals who bring skills and the right attitude to the table. Give me someone enthusiastic, hard-working, and inexperienced over someone lazy and disruptive but skilled any day. Availability Realistically, you need people available to dedicate the required time to your project. Overcommitted team members are a recipe for project delays. Roles and Responsibilities of the Project Team Once you've got your team, setting clear roles and responsibilities is crucial. I just want to underline that it needn't be complicated. Indeed, the smaller the project and team, the less need for vast amounts of detail, but it is still essential to iron out. You can probably capture it in a table format within a document, but it is important to clearly define who's responsible for what. If you don't, ambiguity slips in, people don't do things you expect them to do, and they'll shrug and say, "I didn't know that was me." Here's how to ensure everyone knows what they're supposed to do. Clear Definitions: Each team member should have a clear description of their role and what's expected of them. This clarity helps prevent overlaps and gaps. Authority Levels: Just as critical as roles are the authority levels. Make sure people know what decisions they can make and what needs to be escalated. This is important to capture because they might sit on issues that should otherwise have been escalated. Equally, you'll want people to feel they can solve problems however they see fit. Interdependencies: Highlight how team members' roles interlink and depend on each other. Understanding these connections helps foster collaboration and prevents bottlenecks. Conduct The Initial Briefing Bring everyone together for a kick-off meeting. This isn't just about walking through the project charter; it's about building a team spirit and opening lines of communication. Make it interactive, not a lecture. Seek input regarding pitfalls and potential dependencies you might not have seen. Undertake Initial Assessments Conduct Feasibility Studies Before diving too deep, you've got to check the water is okay. Feasibility studies are your first reality check. There can be several perspectives to a feasibility study, but typically, they could be based on the following: Technical Feasibility Can we actually do this? It's about determining whether the technical resources and capabilities are available to deliver on the project's objectives. Will you do it yourself and try to save money (no), or bring in expertise (yes)? Economic Assessment Does it make sense money-wise? This involves crunching the numbers at a high level to see if the project's benefits outweigh the costs. It's about ensuring that the project is economically viable. Legal Considerations Are we clear on the legal front? This includes checking for regulatory requirements or legal constraints that could impact the project. Don't underestimate this in a world where increasing regulatory compliance and things like GDPR and Data Protection regulations shape how we must approach so much. For a smaller project, you may not need to go into detailed feasibility studies but don't underestimate it or dismiss it out of hand. Think to yourself; What are the influences that might impact my project and its outcome? For example, are there regulatory aspects we need to investigate that might influence how we go about our project? Are there different ways to approach this project delivery, and what's the best option? For example, should we build, buy, or outsource it to someone else? Do we have the skills to deliver and support this if we build it? Feasibility studies may even go as far as a brief proof of concept or supplier evaluations. So, this step may be far more involved than it first appears. Develop a High-Level Risk Register No project is without risks, but not all risks are created equal. I don't try to seek out every single risk anyone can think of, but only the large ones that would keep me awake at night if they were to start materialising. For example, my immediate thoughts would be; Is anyone on the project a single point of failure that would disrupt the project if unavailable for some time? So, have we hinged the entire delivery on someone who might be brilliant but erratic? Is my supplier in robust financial shape? Have they got a proven track record, or are they attempting to do something they haven't done before? If there was a delay to a particular delivery, would it cause a disruption to the entire project, and if so, can we have a mitigation plan? Evaluating & Writing Up Risks Here's how you size them up: Identifying Potential Risks: Start with a brainstorming session with your team to list possible risks. It's about thinking about what could go wrong and planning for it. Assessing Impact and Likelihood: For each risk, assess how likely it is to happen and what the impact would be if it did. This helps prioritise which risks need the most attention. Preliminary Strategies for Risk Mitigation: Start thinking about how to handle these risks. It's about having a game plan ready, even if you hope never to use it. Preliminary Delivery Methods Deciding on how you'll deliver the project is as important as figuring out what you need to deliver. Here are some steps to consider; Choose Delivery Methodology: Will this be an agile, waterfall, or something in between? The choice depends on the project's nature and the environment. If these terms mean nothing to you, just start planning it out. Outline High-Level Phases: Sketch out the significant phases of the project. This doesn't need all the details yet, just the broad strokes Validate with Stakeholders: Run this high-level plan past your key stakeholders. Their buy-in is crucial, so ensure they're on board with the proposed approach. Develop a High-Level Plan High-level planning is about drawing the map that guides the ship. The early plan carves out the route from start to finish, setting out the major landmarks along the way. It's about big-picture stuff—laying down the main tracks before getting bogged down in the granular details. Too much detail at this stage is a progress killer. If you need a lot of detail, you should ask yourself why. It's okay to break things down into phases and stages and plan only the next one in serious detail. Once that is done, look to the next stage in detail, and so forth. Elements of a High-Level Plan Major Milestones: Think of these as your project's headline acts—the significant dates everyone needs to keep their eyes on. These are your benchmarks for tracking progress. Key Deliverables: What are we actually delivering here? Each milestone needs a tangible outcome to show for your efforts. Resource Allocation Overview: Who's on deck, and what tools do they need? This is about matching your team and tech to the tasks without diving into the minutiae. Timeline Sketch: Rough out the timings. When should what happen? The timeline at this stage is more about rhythm than beat-by-beat precision. Crafting the Plan Drafting the Plan: Write down the essentials—milestones, deliverables, resources, and timelines. Remember: it's your rough draft, not the final manuscript. Iteration and Feedback: Throw it out to the team and the major stakeholders. This is where you chop and change it based on what they throw back. It's a bit of give and take to mould it into shape. Preliminary Approval: This is about getting a nod or a shake from up top. It's not the green light for go; it's more of a yellow light for 'on the right track'. Planning Gate Approval Once the high-level plan is drafted and all the above components are ready, it doesn't just sit there; it goes under the microscope. This is the stage where we see if our broad strokes match the canvas we're working on. It's about making sure the plan's workable in the real world. Evaluation by Key Stakeholders This isn't a solo performance; it's a complete ensemble act, and it's important to get multiple perspectives. From department heads to project sponsors, key stakeholders get to weigh in. Their insights can turn a good plan into a great one, catching oversights and adding crucial wisdom. Typically, these guys are experienced but have objectivity and a bit of distance from the details, so they have a unique perspective worth listening to. Integration of Feedback The feedback isn't just for show. Each piece needs to be considered and woven into the plan where appropriate. This might mean stretching some deadlines, scaling back some goals, or adding new milestones. Decision Making Scope Adjustments: Sometimes, the scope needs a tweak—narrowing down to focus on what's truly important or expanding to cover critical bases we might have missed. Go/No-Go: The ultimate decision—is this plan ready to roll, or does it need more work? This isn't just about having all the answers now but being confident in the direction. Project Halt: In some cases, the brakes get applied if the feasibility just isn't there. It's better to stop before resources are wasted. This is the gutsiest thing to do. And honestly, I've rarely seen it done, but it takes enormous courage for a team to say, 'No, it's not panning out as we expected.' As humans, we suffer from loss aversion and would much rather double down than call it a day on something that isn't working, which is why we have so many sequels to Pirates of the Caribbean. Conclusion The initiation phase is where we set the compass for the entire project. It's where big ideas get their grounding and project visions start taking shape. We don't know everything about how our project will unfold, but we make the big decisions to shape it. In this phase, we've laid out the framework, established the ground rules, and determined if the project has legs to stand on. We've tested aspects of the feasibility, and its outlines are sketched and ready to be fleshed out in the detailed planning phase.# Transition to the Next Phase: Planning Having established a robust initiation foundation and approval to proceed, we're now set to dive deeper. In the detailed planning phase, we turn our high-level roadmap into a street-level guide, detailing every turn.

  • Planning a Project

    Introduction to the Planning Phase Welcome to the project planning phase, where the foundations laid during initiation begin to take shape, and the roadmap to project delivery is drawn. Without robust planning, projects are like ships without rudders. Planning sets the tone for how the project will proceed and, perhaps more importantly, how it adapts to the inevitable challenges and scope adjustments. Here, the abstract becomes defined, and the nebulous, clear. The Main Activities of Project Planning Gather Requirements Requirements Gathering & Business Analysis Before we roll up our sleeves and dive into the brass tacks of project execution, let's talk about the linchpin of project success; Requirements Gathering & Business Analysis. This is about deeply understanding the 'as is' processes, envisaging the 'to be' scenarios, and sculpting a path that bridges the two effectively. Laying the Groundwork Identifying Stakeholder Needs Begin with the stakeholders. Who are they? What do they need from this project? This involves engaging them through interviews, surveys, and observation sessions to capture their requirements accurately. Mapping Current Processes Detail out the existing processes. This step isn't glamorous but is essential. You need to know the current state of affairs - warts and all - to understand the baseline from which improvements or changes will be made. The worst thing a project can do is introduce new ways of working without understanding the old ways and ensuring that whatever it introduces (new tech, process, etc.) doesn't adversely affect those it seeks help with. Frankly, it's easily done. Recently, I worked on a project where it was crucial to the Finance team that VAT was calculated in alignment with some complex EU legislation, and boy, am I glad I did my homework because it transpired the software we were implementing couldn't handle it – imagine going live with a problem like that, and then realising… Documenting Existing User Flows Each user interaction with the system or process should be mapped. These user flows help visualise the user's journey through the current system/processes and identify pain points and areas for enhancement. User Flows can be vital if you introduce software or a new process. They can be a bedrock for developing test plans later. Maybe your project has little or nothing to do with technology or software, but if it has humans as part of it, they'll likely be undertaking tasks that need to be captured. Here's an example of a user flow, but they can be in many formats. Whatever works. Facilitating Workshops Bring together cross-functional teams to thrash out ideas, challenge existing norms, and brainstorm new solutions. Workshops are great for uncovering hidden requirements and forging consensus, but they need careful planning regarding their objectives, the questions that need answering and how you will engage people. Just walking into a room without preparation probably won't cut it. Develop a Work Breakdown Structure (WBS) All right, let's roll up our sleeves and dive into the nuts and bolts of the project by creating the Work Breakdown Structure (WBS). The WBS is about slicing the project into bite-sized pieces and setting the stage for execution to ensure that every task is manageable and less intimidating. It's an optional but much-valued technique that can help you visualise the composition of your project. Map Out the Major Deliverables Identify the significant outcomes required to complete your project. Using the example of planning a big party, consider the critical elements—such as the venue, catering, and music. These are your major deliverables. Clearly outline these deliverables upfront because they represent the key results your project promises to achieve. Break It Down Decompose each primary deliverable into smaller, more manageable tasks. For instance, if the venue is a major deliverable, your related tasks might include booking the venue, confirming the availability on your chosen date, and coordinating decorations and seating arrangements. This step involves detailing every component that needs to be addressed to deliver the larger items successfully. Understanding WBS Elements: Not every element in a WBS is a direct output like a product or service; some may be phases, stages, or categories of work. However, the majority of elements should be deliverables. Decomposition: Break down each deliverable to the point where it can be assigned and managed independently. This often means decomposing to the work package level, which is detailed enough for assignment to a team or individual but general enough not to include step-by-step tasks. Assign responsibility Assign a team member or a group responsible for each work package. This helps in accountability and ensures that every part of the project has a designated owner. Review & Refine Review the WBS with stakeholders and refine it. This ensures that the WBS accurately reflects all project aspects and receives buy-in from everyone involved. Why Bother with a WBS? Creating a WBS might seem like an extra step, but it's a powerhouse tool that keeps everyone on the same page. It breaks the mammoth task of managing a whole project into smaller, more digestible parts, making it easier to track progress, allocate resources, and spot potential issues before they become big problems. Build a Comprehensive Project Plan Once the transition from initiation is in our rear-view mirror, it's time to steer into the heart of the project—crafting a comprehensive project plan. The project plan is the tentpole of your project, ensuring every part is coordinated and every action purposeful. Selecting a Tool I'm kinda glossing over creating a project plan here because it is such a big thing and deserves its own guide. However, many tools in the marketplace can make it easier. There are lots of things that might help you select one, but consider the following; Do you have the budget for a tool? If not, that will limit your options, but there are still lots to explore. Will a spreadsheet do? It might do if your project is small and without many dependencies. How many people are working on the project, and do they need a single tool to update their activities/workstreams? What does your organisation already have in place? I can't tell you how often I've seen projects go off and purchase their own project management tool without looking at what's already available. Break the phases into stages and gates. Depending upon the size and nature of your project, you may wish to consider breaking it into stages and more manageable sections. For example, you might plan out a proof of concept stage, a development stage, and a test stage, all of which sit within the Execution Phase of the project. It's entirely up to you. The benefit of segmentation of a project like this is that it allows larger projects to improve their focus and manageability. So, you lay out all the stages in the project plan but only paint the details for the stage you are about to go into. This can help you avoid constantly revising project plans in minute detail. At the end of each stage should be a project gate. A project gate is an approval step whereby you review the outputs of the stage with the stakeholders and ensure the project is ready to move forward before doing so. Unfortunately, projects often lay out the stages and gates but then barrel through them in their anxiousness to get completed. Gates act as checkpoints throughout the project, and the criteria for passing each one may be different, but here are some examples of the kind of things you might have; Completion of Deliverables: All scheduled deliverables for the stage have been completed and meet the pre-defined quality standards. Budget Adherence: The project is on budget, with expenditures closely aligned with the forecasted amounts, and any variances are well-justified and approved. Milestone Achievement: Key milestones are achieved according to the project timeline, and any delays are addressed with a clear plan for getting back on track. Risk Management: Existing risks have been effectively managed and mitigated, and new risks are identified with strategies in place to handle them. Stakeholder Approval: All key stakeholders have reviewed progress and outputs, providing formal approval to move forward to the project's next phase. Build out the Schedule Every project is bound by time, which is one of the significant constraints. Making a detailed schedule is critical to the project plan. Lay out the timelines for each task, identifying dependencies and critical milestones. Don't consider it a finished article but an evolving canvas. Create broad blocks for the latter stages of the project, as well as details for the next stage. You need just enough to give confidence in the project's scheduling, shaping and costing. Allocate Resources Ensure your plan clearly outlines who does what, when, and with what tools. This section ensures every team member has the necessary resources at the right time, avoiding bottlenecks and maximising efficiency. With these elements in place, your project plan becomes a robust guide for navigating the execution complexities. It's a living document that adapts and evolves but keeps the project progressing towards its objectives. Validate and Approve Before this plan can take effect, it needs the green light—approval from key stakeholders. This validation step is crucial as it ensures the plan aligns with the business objectives and has the backing it needs to move forward. I would typically circulate the plan beforehand and then call the core project team together to ratify it. Update the Budget Next on our project planning agenda is crafting the budget—where we get real about the numbers. Think of this as your project's checkbook. Without a well-planned budget, even the most brilliantly devised project plan can run aground if the cash isn't there when needed. Base Estimates on the WBS Start with the Work Breakdown Structure we just fleshed out. For each task, estimate the costs associated with personnel, materials, equipment, and any other resources you'll need. It's like putting together a shopping list for a big dinner party—you need to know what you'll buy before figuring out how much it'll cost. Aggregate Costs to Form the Project Budget Once you have individual cost estimates, roll them up to form the overall project budget. This includes direct costs like labour and materials and indirect costs such as administrative expenses and contingency funds. Think of this step as totalling up your grocery receipt. Incorporate Contingency Funds Always include a buffer for the unexpected. Projects rarely go exactly to plan, so having a contingency fund is like bringing an umbrella when there's a chance of rain—it's better to have it and not need it than to need it and not have it. Typically, contingency will run at 10 to 15% of a project, but depending on how much risk is involved, it may differ. You only have to watch a couple of house renovation projects on TV to realise that they usually underestimate their costs by about a third and then quickly justify the overspend to the camera. I'd say this level of underestimation is prevalent in projects. Always go for the more pessimistic number. Review and Revise Go over your budget with key stakeholders. This ensures that everyone agrees on the financial plan and understands where the money goes. It's also a chance to trim costs or reallocate funds if necessary. Approval and Baseline Once your budget is approved, it becomes the financial baseline for the project. This is your financial "line in the sand," helping you track actual spending against planned spend as the project progresses. It's like setting a speed limit—it keeps everyone driving at a safe speed. Develop a Procurement Plan I could write pages on this alone. Purchases often form a significant part of a project. It could be procuring services, purchasing a software system, or, in many cases, both. It could be a major expenditure within your project and something you are keen to get right, so I can't cover it all here; the focus really is on the components of the Planning phase rather than diving into too much detail, but here is a summary of the major activities; Key Elements of a Procurement Plan Now, as you read through these steps in a procurement plan, you'll start to see what it is: a mini-project plan, and that's not a bad way to think about it. Identification of Needs This initial step involves specifying the project's requirements for materials, equipment, and services. A thorough understanding of the project scope and deliverables is required to ensure that all procurement activities support the project objectives. Supplier Selection Choosing the right suppliers is crucial. They can make or break your project. The plan should outline the criteria for selecting suppliers and the process for evaluating bids. It often includes pre-qualifying suppliers to streamline the procurement process when the project is underway. Just a quick word of advice; choose an organisation with a proven track record. Don't go with someone's friend. Don't go with a small organisation that is cheap, keen and enthusiastic but inexperienced. Timeline for Procurement Integrating procurement milestones into the overall project timeline is essential. This includes specifying when bids will be solicited, when contracts will be awarded, and when delivery of goods or services is expected. Aligning these timelines helps in avoiding project delays. Always clarify the ramp-up timescales with suppliers. They'll likely have a waiting period, so you must factor that into your project timeline. Budget and Cost Management The procurement plan must also detail the budget allocated for each item and overall cost controls. This includes mechanisms for dealing with cost variances and ensures that the procurement activities do not exceed the budgetary constraints. Risk Management Identifying potential risks associated with procurement, such as supply chain disruptions or non-compliance by suppliers, and outlining mitigation strategies is a crucial component of the procurement plan. What happens if your supplier speaks a good game but can't deliver when it comes to it? How much dependence is your project putting on the supplier? Can you go elsewhere in the future, or are you locking yourselves in? If so, what happens if the supplier realises this and decides to exploit it? I've seen companies get into awful circumstances with suppliers when they realise nobody else can provide the service they can (such as data provisions). Contract Management Effective contract management ensures that all parties meet their contractual obligations. This section of the plan details how contracts will be managed, monitored, and closed out upon completion. This will likely be underpinned by the legal review next, but make sure you have tangible measures written into the contract or statement of work that clearly outline what good looks like. Legal and Compliance Ensuring that all procurement activities adhere to applicable laws and regulations is critical. The plan should include strategies to manage legal risk, including compliance with local and international laws that affect procurement activities. So, does your organisation have a procurement policy you must follow, or do you have to engage with certain suppliers for specific reasons (common in government contracts with a roster of approved suppliers)? Access to a lawyer can make a lot of difference to having a contractual agreement with some bite. However, we don't always have that luxury or the ability to change terms and conditions, so sometimes you have narrow parameters to operate within, and that's fine. Establish a Quality Plan Now that we've tackled the budget let's shift our focus to ensuring the quality of our project deliverables meets the mark. A Quality Plan is about ensuring that the end product is something we can be proud of. I've been involved in enough projects with third parties who shovel crap over the fence to the customer and expect them to test it. By clarifying your approach to testing, measurement and how you are going about it up front, you are making it a crucial part of your plan. Define Quality Standards Start by setting clear, measurable standards defining your project's quality. This could be anything from a customer service system's response times to a construction material's tensile strength. It's like setting the rules for a game—everyone needs to know what counts as a win. Plan for Quality Control Activities: Determine what tests, reviews, audits, and inspections are needed to measure and achieve these quality standards. Think of this as your quality checkpoint strategy—where you plan to check your project's health pulse. Assign Responsibilities: Clearly define who is responsible for which aspects of quality management. Assigning roles might include a quality assurance team, project managers, or specific task owners. It's about ensuring everyone knows their part and keeping the project up to standard. Moving Forward with Quality Assurance With a robust quality plan, your project is set to succeed and excel. High standards will help safeguard the project's outputs, ensuring they deliver the intended value and meet or exceed stakeholders' expectations. Now that our quality plan is geared up to guide us through the project's lifecycle, it's time to step into the next phase—communication planning. Ready to establish how we'll keep everyone informed and engaged as we roll out our project? Develop a Communications Plan Having set the bar for quality, let's ensure our communication is just as sharp and effective. A Communication Plan is crucial to keep everyone in the loop and ensure that the loop doesn't turn into a noose. It's about more than blasting emails or holding endless meetings; it's about making every message count, and valuing people's time. Crafting Your Communication Strategy Identify Stakeholders: First things first, who needs to know what? Identify your project stakeholders, from team members to external partners, and identify their information needs. Define Key Messages: What critical pieces of information need to be shared? Whether it's project milestones, budget updates, or changes in scope, make sure you know what messages need to go out to which stakeholders. Choose Your Channels: Decide how you'll communicate. Will it be weekly email roundups, a project dashboard, or regular face-to-face meetings? Choose channels that fit the message and the audience—for instance, instant messaging might be great for quick updates, but significant changes might need a more personal touch. Set the Frequency: How often will you send out updates? The frequency can depend on the phase of the project or the stakeholders' needs. It's about finding that sweet spot between saying too much and not saying enough. Assign Responsibilities: Who's responsible for sending out each type of communication? Assigning clear roles ensures that communications are timely and effective. Trigger the Execution Gate Approval Before we let the horses out of the gate and charge into the execution phase, there's an essential checkpoint we need to clear—securing the Execution Gate Approval. This isn't just a formality; it's a crucial review to ensure that our detailed project management plan doesn't just look good on paper but is fit for the ground's realities. Why Is Execution Gate Approval Critical? The Execution Gate Approval serves multiple vital functions in the project lifecycle: Ensures Stakeholder Alignment: It confirms that everyone with a stake in the project's outcome agrees and is ready to support the approach. It's like ensuring all players are ready before kicking off a big game. Validates the Plan's Feasibility: This approval process helps verify that the plan is practical and achievable, not just a theoretical exercise. Builds Confidence: Securing this approval boosts confidence among the project team and stakeholders. It's a collective affirmation that you're all set for the journey ahead. Gate Steps Present the Project Management Plan Gather all your key stakeholders in the 'room where it happens'. Lay out the project management plan in all its glory, detailing your project's who, what, when, and how. This is your moment to showcase the plan that will guide your project to success. Highlight Alignments and Address Gaps This step demonstrates how the plan aligns with the project's objectives and stakeholder expectations. It's crucial to discuss any potential gaps or misalignments openly. Think of it as aligning gears in a machine; everything must fit perfectly to run smoothly. Seek Feedback and Make Adjustments Encourage stakeholders to provide feedback. This isn't just about nodding along—it's about actively seeking their insights, which could reveal blind spots or opportunities for optimisation. Adjust the plan based on this feedback to ensure it's as robust as possible. Secure Final Approvals Once all stakeholders are satisfied and all tweaks have been made, it's time to get the formal nod. This approval is your green light; it means your stakeholders trust that the plan is sound and ready to be implemented. Wrapping Up With the Execution Gate Approval in hand, we're not just crossing a checkpoint; we're reaffirming our roadmap, tightening our focus, and energising our team. Now, with everyone on board and every detail scrutinised and stamped, we're ready to dive into the action-packed world of project execution. It's go time, and we're all systems go!

  • Executing a Project

    The Execution Phase of Project Management No matter its size or complexity, every project reaches a point where planning transitions into action. Sometimes, a little too quickly. Welcome to the Execution Phase of the project lifecycle, where we start building and delivering on things. Here, project managers and their teams take the strategic blueprints developed during earlier phases and work to breathe life into them. Despite meticulous planning and detailed forecasts of the prior phases, this phase is often unpredictable. It is the real test of a project's planning and preparation phases, and that is why I stressed the importance of getting the charter and other artefacts right before we started in earnest. The Execution phase is typically characterised by a dynamic environment where adjustments are frequent, and flexibility is critical. You'll need to be on your toes, ready to tackle unforeseen issues while ensuring the project remains aligned with its defined scope and objectives. While the activities of the earlier project phases are primarily sequential, the following activities are cyclical throughout the phase and likely run in parallel. Therefore, the tasks aren't laid out as steps but as groups of activities under a shared banner. The Main Activities of Project Execution Direct The Management of Work The execution phase starts with a flurry of activities, where the direct management of work takes the forefront. This involves actively engaging with the tasks and ensuring they align with timelines and objectives. But how can we organise the work effectively? There are many ways, but I frequently fall back on two predominant ones: workstreams and work packages. Define Workstreams Workstreams are themes of related tasks that are allocated to a team. For example, in a project, you might have an 'infrastructure' workstream responsible for spinning up the servers and technical infrastructure for a project. You might have another workstream for 'Security'. Workstreams facilitate parallel processing, where multiple teams can progress independently on different fronts yet towards the same objective. This approach not only speeds up execution but also allows for specialised management of diverse project aspects, from technology implementation to customer outreach. The benefit of workstreams is that they allow you to put in place a reporting hierarchy and delegate work to those workstreams, and then you only have the workstream lead reporting progress to the project team. Ideally, this is how I like to organise my projects, but it's entirely down to the size and nature of the project. Sometimes, you have an orchestra and are the conductor; at other times, you can find yourself doing everything. Create Work Packages Work Packages are something I gravitate to a lot in projects. They are a formal way of outlining precisely what you want from a team member or workstream regarding deliverables. So, a work package will outline the objective and what is needed as an output but won't tell the person it's assigned to exactly how to go about it; that's their business. But, work packages should be developed with the owner, not simply dictated to them. For example, if you need servers delivered from the IT Infrastructure Team, you might write a work package that says what you need, like a shopping list, when you need it, and how much your budget is. Just outline it clearly like a mini-project charter so someone can run with it. Work packages have several benefits, including; Defines accountabilities for objectives Removes ambiguity and assumptions about the deliverables Sets clear expectations on timelines and milestones Allows the project to define tolerances within which the work should be delivered, such as budget Helps identify resources and where additional support might be required. Identifies dependencies on other workstreams within the project Clarifies reporting expectations For an example template, see here; Implementation Planning After establishing clear project acceptance criteria, the next crucial part of the Execution phase is implementation planning. This group of tasks sets the concrete steps necessary to transition from strategic planning to operational execution, ensuring the project's deliverables are achieved efficiently and effectively. Coordinating Activities and Resources Implementation planning involves a detailed coordination of activities, resources, and timelines. The aim is to ensure that every project element is aligned and synchronised to achieve the desired outcomes. Key components include: Scheduling Develop a detailed timeline that specifies when and in what sequence project tasks should be completed. Effective scheduling helps prevent resource conflicts and ensures that milestones are met. Resource Allocation Assigning the right resources, whether human, financial, or technical, to specific tasks. Proper resource allocation is critical for maintaining project momentum and ensuring team members are not overburdened or underutilised. Risk Management Anticipating potential issues and planning mitigations. This process includes updating the risk register and preparing contingency plans for likely challenges. Integration of Systems and Processes In projects that involve complex systems or multiple departments, integration is a pivotal focus of implementation planning. It ensures that different systems and processes seamlessly support the project objectives. This might involve: Technology Integration: Ensuring that new software or hardware integrates smoothly with existing systems, which may require beta testing or phased rollouts. Process Integration: Aligning new processes with current organisational practices. This often requires training sessions and detailed documentation to ensure staff understand new workflows. Stakeholder Communication and Involvement Keeping stakeholders informed and involved throughout the implementation planning phase is vital for maintaining alignment and managing expectations. Communication plans should outline how updates are given and how feedback is gathered and used to refine the implementation process. Setting Milestones and Checkpoints Milestones are critical achievements within the project timeline that act as checkpoints to review progress and make adjustments. The implementation plan should clearly define these, providing the project team and stakeholders with a roadmap of success at various project stages. Effective implementation planning not only prepares the project for the practical aspects of execution but also sets the stage for the final steps towards completion. It bridges the theoretical planning and the tangible, operational activities that will bring the project to life. Team Management This is perhaps the most challenging part of a project; the people. Some will be great, some will be awful, and most will deviate from what they think the project should be doing rather than the agreed plan if left to their own devices. So, rather than dive into this subject too deeply, I'm going to make just a couple of points here; Empower the team. Delegate where you can, depending on the size of your project. Empowerment boosts the sense of ownership within the team. Set clear expectations. Use some techniques, such as work packages, to clearly outline expectations and ensure everything you need is captured: deliverables, timeframes, budget, reporting, etc. Communicate! Ensure communication throughout the project is consistent in pace and messaging gets to everyone. Recognise achievements. Ensure achievements are recognised to keep morale high and the feeling of progress underpinned. Have a coffee chat. Talk to people and ask them how they feel about their role and the project. I was once told by a team manager everything was on track and A-OK. I spoke to a team member while having a coffee and found out everything was far from okay. These side conversations are crucial for really getting a sense of how things are going. Plan The Project Closure Gate The Project Closure Gate serves as a checkpoint towards the project lifecycle, determining whether the project is ready to advance from the execution phase to the formal closing phase and start wrapping things up. It needs consideration during the execution phase to know if proceeding to the closure phase is okay. We must ensure that all deliverables meet the predefined project acceptance criteria and that the project is on track to achieve its goals. Think of it as the airport security check before you go to the departure lounge. Our project shouldn't start to shut down before we've assessed whether it is ready to do so. 1.  Review project objectives & completion status. Before we can claim we are ready to close down a project, we need to prove that we have met the original objectives. Remember when I said the objectives should be unambiguous and measurable? This is why we need to measure the project's output against the objectives. Only when you have met the objectives or the sponsor has agreed to the deviations can you consider moving through to Project Closure. 2.  Prepare for Ongoing Support & Maintenance We'll explore this more in the project closure phase, but we must ensure we are clear on what is needed for the project to become business as usual. For example, what training, processes, support structures, etc., need to be implemented so the project can enter an orderly shutdown? There are lots of questions here to ask, including; Who owns the supplier relationships going forward? What budget is assigned for ongoing support and maintenance? Who will fix things if they go wrong in the future? Are there any known defects or workarounds that need to be accepted? 3. Ensure documentation is complete and organised. As the project winds down, handing over all the documentation to those needing to reference it is essential. This can include project logs like risk logs, decision logs, etc. so that they can find the reasoning if they need to look back and understand why something was done the way it was. It also includes the technical documentation, support documentation, end-user documentation, etc., that is needed. 4. Obtain Stakeholder Approval Like all gates and approvals, I like to talk to people first and make sure that when it comes to it, I know if they will or won't approve something. You don't want to be in a meeting and suddenly have the seat kicked from beneath you because you didn't check with a key stakeholder that they were happy to proceed and have everything they need to be confident in the decision. This may or may not result in an actual project gate closure meeting. Once we know we have approval to move out of the execution phase and into the project closure, we should be on a high, but there is still more yet to be done!

  • Monitoring & Controlling a Project

    Introduction The Monitoring & Controlling phase is about keeping an eye on progress and actively adjusting strategies and actions to align with project goals. The phase runs in parallel with Project Planning & Execution. Think of it like a background phase that checks on the others in a fatherly way. Monitoring & Controlling helps project managers address potential risks proactively, manage changes, and ensure that the project adheres to its schedule and budget. This is where the project manager will spend much of their time; checking and creating reports, managing the various logs, etc. Key Objectives Alignment with Goals: Continuous project oversight ensures that every aspect aligns with the initial strategic goals, adjusting as necessary to respond to internal and external changes. Standard Compliance: Monitoring and controlling activities ensure the project complies with the set standards, laws, and regulations, which can vary significantly across industries. Quality Assurance: Regular checks and balances during this phase help maintain the quality of the deliverables by identifying quality gaps and implementing improvements. Stakeholder Satisfaction: The phase helps meet or exceed stakeholder expectations, fostering trust and confidence in the project management team by keeping the project on track. The Monitoring & Controlling phase comprises several activities that ensure the project remains aligned with its objectives and can adapt to any changes or risks that arise. Here's a deeper look into these. The Main Activities of Monitoring & Controlling a Project Generating Highlight Reports Highlight reports are pivotal tools in project management and the bane of a project manager's life. They are essential but annoying to create, and often, you get pushback when they go out if something is slightly incorrect, which can range from grammar to more important things. Highlight reports regularly give stakeholders a snapshot of the project's status. Typically, these reports include updates on the schedule, budget, scope, and risks. They are crucial for maintaining transparency and informing all parties of progress and potential issues. Tips for Effective Highlight Reporting: Regular and Timely Ensure reports are generated consistently, which helps in timely decision-making and keeps stakeholders engaged. Nothing is as irksome as sporadic highlight reports and not on a regular heartbeat. Also, don't mess with the format constantly. Settle on something at the start, and maybe have one or two iterations of style based on feedback, but don't mess with it constantly. Clear and Concise Avoid overloading the report with unnecessary detail. Focus on key metrics that indicate project health. With a lot of data, trying to capture it all is tempting. The simpler the report for someone to read and get the flavour of things, the better. For example, if you have a significant issue with an aspect of your project, I'd suggest writing that up in an exception report and linking it to the highlight report. Not everyone will want that level of detail, but they will want to know, well… the highlights. Action-Oriented Highlight reports should present data and suggest actions and next steps. What is anticipated between this highlight report and the next one should be clear. Then, the following report can reflect on that progress. Don't expect people not to read the highlight report and look at the details. In my experience, the project sponsors usually pick up on inconsistencies and where you might try to gloss over things, so be honest. Maintaining Logs: Decision, Risk, and Change Keeping comprehensive logs of decisions, risks, and changes is vital for traceability, accountability and arse covering. These logs help capture the rationale behind decisions, the management of risks, and the implications of changes. For example, who decided that the project should be delivered only in French, and when? The logs I'd suggest every project maintains are; Project Action Log: Records actions that need to be taken to resolve issues, who is responsible for them, and their due dates. The are records of workpackage issued, tasks, and other odds and ends. Issue Log: Keeps track of ongoing issues, their impact on the project, and the steps taken to resolve them. Risk Register: Documents identified risks, their severity, likelihood, and the strategies employed to mitigate them. Decision Log: Captures key decisions made during the project, including who made the decision and the reasons behind it, ensuring transparency. Change Log: Records changes to the project scope, timelines, or resources, along with the rationale for these changes and their effects on the project. I'm all for consolidating these where you see opportunities. For example, I often consolidate the issues and risks logs because they are similar in structure. Heresy! People say. To hell with it, I say. I'm getting older and care much less what they think. Sometimes, these logs are kept under one roof called the 'AIRAD' report (Actions, Issues, Risks And Decisions). Key Metrics and KPIs You may want to consider some key KPIs for your highlight report or dashboard and use them to track some of the aspects of your project. It will depend on your project and the value you put on them. I'd suggest only tracking metrics that would make a difference or tell you something you can act upon. There are so many data points these days in various apps, etc., that it has become information overload, so choose carefully. Here are some high-level suggestions. Managing Scope and Handling Changes During most projects, there will be requests for changes to the scope of the project's deliverables. There are a host of reasons, but typically, they will be due to; Unclear or incorrect initial requirements Stakeholders suddenly wake up and ask for something Force Majeure (Translated as "Superior Force") means things that happen outside anyone's control. Floods, world events, etc. A natural evolution of ideas and concepts occurs when we see them in reality. Some of the above causes are controllable, and some are not. Some result from poor planning, which underlines the importance of good analysis upfront. Or maybe it was caused by not including the right people. It all underlines the importance of going through the earlier phases of the project in preparation for the execution phase of the project. We call changes like this 'scope creep'. Sometimes it's clear and obvious, but often it's little things, tiny changes that add up and become project delaying 'death by a thousand cuts'. So, it needs careful management. The ability to handle changes skillfully while your project is in flight can often be the difference between success and failure in delivering on time and within budget. But what do you do when faced with changes that fly at you while you are knee-deep in a project? Handling and Approval Processes for Scope Changes Managing changes efficiently involves: Ensure You Have a Change Control Process Implementing a robust change control process ensures that every proposed change is evaluated, approved, or rejected through a structured process instead of just at the whim of someone who forcefully asks for something. The change control system should outline who can approve changes and under what circumstances. It's not usually for the project manager to determine what is allowed in and out of scope, but rather the project owner/sponsor. However, it may well depend upon the nature and size of the change. Carry out An Impact Analysis Before any change is approved, its impact on the project's schedule, budget, and resources should be thoroughly considered. An analysis of the change helps make informed decisions about whether the benefits of the change outweigh the costs. There must be a 'price' to a change. They don't come for free unless you are taking something out. Remember when we discussed the 'triangle of project management' in an earlier section? We can't change scope without an impact on time and budget. Agile projects claim to embrace changes late into the delivery, which is excellent, but they only really reprioritise, pushing something down the to-do list of requirements. Agile can't magically change time and space to allow all changes to occur without some kind of sacrifice. Ensure Scope Changes are Communicated Transparent communication with all stakeholders about the implications of scope changes is essential. Make sure people know what and why. This maintains trust and ensures that everyone understands the reasons for changes and their potential impacts on the project. Sadly, I've run projects where the scope changes are agreed at a workstream level but don't filter down effectively to the people at the coalface, leading to confusion and disgruntlement. Or, a decision is made without consultation with the end-user or whomever you are delivering to, which has also been pretty bad. Scope Reduction and the "MVP" Virtually every project technique talks about scope creep like it's an increase in project deliveries, and to be fair, those are the ones that present the risk, but as your project gets closer to the delivery date and you realise that you aren't going to make it, then you may need to consider reduction of scope (among other actions). In the latter phases of a project, you may need to lighten the project load like a hot air balloon trying to get over a hill, so you might try to drop some ballast. I've done this many times, and it is a valid approach, but here are some things to consider; Make sure you have approval from your project sponsor/team. Any project manager who makes decisions in isolation from those they deliver for will likely end up in hot water. Consider your MVP very carefully. An MVP is a "Minimal Viable Product, " meaning "What's the most minimal solution we can go live with and meet our project's primary objectives?" How does reducing scope impact future project deliveries? For example, you may have intended to deliver your project, high-five everyone, and go home, but if you say something is out of scope for go-live, you'll likely have to add another phase to mop up the loose ends. So, give it careful consideration and make sure the price is outlined to those making the decision. What to do when things start to go wrong Like so many of the concepts I've squeezed into this series of guides, I could write reams on this subject alone, but here are some basic pointers in the interests of brevity. When a project begins to veer off course, it can induce stress and uncertainty among the team. Effective management and strategic redirection can help salvage the situation and steer the project back to success. Here are some strategic steps to consider when you find your project starting to go off the rails: Acknowledge the Situation The first step in addressing a faltering project is to acknowledge issues. Pushing your head into the sand and hoping things improve isn't an option. Ignoring problems or delaying their acknowledgement will only exacerbate the situation. Early recognition allows for quicker intervention and minimises the risk of further complications. Remember what I said earlier in another section? I hope so. There will be a test; "The problem is rarely the real problem. The response becomes the problem". The sooner you advise your project sponsor and teammates of a problem, the sooner people can rally around and support a solution. Assess the Extent of the Issues Once issues are acknowledged, conduct a thorough assessment to understand their nature and extent. This involves reviewing project timelines, budgets, resources, and the quality and scope of work completed. Identifying whether these problems are isolated or systemic will help determine the next steps. Getting a good definition of the problem is also crucial. Be specific and write up a problem statement. In project talk, we call these 'exception reports' when something hasn't gone according to plan. You'll need to circulate it and ensure those nearest to the issue have an input in the report. Communicate Openly Maintain open lines of communication with your team and stakeholders. Transparency about what's going wrong and what steps are being taken to address the issues can help manage expectations and maintain trust. Regular updates and honest communication are critical in keeping everyone aligned and engaged during the troubleshooting phase. Revisit Project Objectives In times of trouble, revisiting the original project objectives is vital. This ensures that the project remains aligned with its initial goals and helps re-evaluate the feasibility of the existing timeline and deliverables. Sometimes, it's easy to get dragged off into a rabbit hole, but a little distance and perspective might show that it is not as critical as first thought. Adjustments may be necessary, and defining what success looks like under the new circumstances is essential. Prioritise and Focus With a clear understanding of the current project state and objectives, prioritise tasks and focus on critical components. This might mean reallocating resources, halting less critical tasks, or revising the project scope to concentrate on core functionalities or deliverables. Timebox assessments, actions, etc, so that it's clear when there will be updates and how much effort can be put into the assessment. Implement Corrective Measures Based on the assessment and re-evaluation, implement corrective measures. This may involve setting up additional resources, changing project management methodologies, or employing new technologies. Establishing clear, achievable milestones and enhancing monitoring are also valuable for keeping the project on track. Learn from the Experience Every project, especially those that encounter difficulties, provides a learning opportunity. Conduct a post-mortem analysis once the project is back on track or completed. Discuss what went wrong, what worked in the recovery process, and how similar issues can be prevented or mitigated in the future. Provide Support and Motivation It's crucial to support and motivate your team throughout this process. Challenges can demoralise team members, so positive reinforcement, acknowledging their hard work, and celebrating small victories can boost morale and productivity. Leverage Professional Advice Don't hesitate to seek external advice or consulting if the situation is beyond the team's expertise. Sometimes, fresh eyes can provide new perspectives and solutions that internal team members might overlook. Be Prepared to Adapt Flexibility is vital in project management. Be prepared to adapt your strategies as the project progresses. Responsive and dynamic approaches can help manage unforeseen challenges more effectively.

  • Closing a Project

    Introduction Whew… You didn't think we'd get here, did you? Well, we did. Congratulations on reaching the final leg of your project's journey—the Closure phase. If you've been following our guides, you've just navigated through the gate that transitions from the hectic world of execution to the structured process of closing down your IT project. The closure phase is not just a formality but takes the learnings and sets the stage for future initiatives. As a new project manager, you might find the closure phase refreshingly orderly compared to the dynamic nature of project execution. It really should be a slam-dunk now the hectic part is over. It's about tying up loose ends, reflecting on what has been learned, and ensuring that the project's outputs are fully integrated into the business-as-usual (BAU) environment. Doing this well enhances your reputation as a starter-finisher and prepares you better for your next project challenge. Let's look at the activities that make up the project closure phase. The Main Activities of Project Closure Conducting a Lessons Learned Review One of the most pivotal activities at the closure of any project is the lessons learned review. What have we learned? This isn't just documenting what didn't work (which is the tempting thing to do); it's equally important to capture what went well. The aim is to offer valuable insights that can be used to streamline future projects, fostering a culture of continuous improvement within you, your team and the broader organisation. It also promotes a transparent culture where teams feel valued and understood, knowing their experiences contribute to the bigger picture. Steps to Effectively Gather and Document Insights Collate the lessons learned. Some of the lessons will come straight to mind. Others might be harder to remember if your project duration has been quite long (in which case, it is probably best to collate lessons learned after each stage gate). Check the logs (risks, issues, etc.) for resolutions, which will help jog your memory. Put it out to the wider team; create a template for them to complete and submit their thoughts before any review meeting you might hold. Prioritise the lessons. Not all lessons are created equally. Just ask Liz Truss, the UK Prime Minister who lasted just 44 days in office. You can't and shouldn't try to carry everything forward with you. Maybe pick up the top 10 learnings and use those. Decide how you will carry the lessons forward. So, you've got a great list of lessons learned. You put them into a spreadsheet, pat yourself on the back, and consider it 'job done', but what are you really doing? Just creating shelfware that nobody cares about or will ever use again? Ask yourself, how will tomorrow be different because of these learnings? How will you change future projects? Is it just for you, as a project manager, or is it for the improvement of the organisation? Look for ways in which to improve processes; Introduce new steps into a procurement process Adjust future project gate criteria Update the project management training and materials Whatever it is, ensure each learning has a tangible outcome that makes a difference going forward. Engaging the Team in Reflective Discussions Make these sessions interactive and inclusive. Perhaps introduce a rotating chair for the meeting, allowing different team members to lead the discussion at different points. This approach diversifies the perspective and enhances engagement, as team members feel directly involved. Through these reviews, you'll build a repository of best practices and cautionary tales that will serve as a roadmap for project management within your organisation. Handover of Project Documentation As the curtains draw on your project, handing over comprehensive documentation to the Business As Usual (BAU) teams is crucial. This ensures the seamless integration of project outputs into regular operations and provides a reference point for any future maintenance or development work. Archiving Documents for Future Reference Store all project documentation in a central, secure location accessible to those who need it. Digital archives are preferable, providing easy access and searchability. Ensure there are clear guidelines on who can access this information and how it should be used, safeguarding sensitive data and intellectual property. By meticulously organising and handing over project documents, you ensure a smooth transition to BAU operations and safeguard the organisation against future uncertainties. This thorough approach to documentation supports ongoing operations and facilitates easier future updates or iterations of the project. Compiling the Final Project Report The final project report comprehensively summarises everything that transpired over the project's lifecycle. The highs, the lows, the laughter and the tears. It is a historical document that offers insights into the project's execution, successes, and challenges. This report is valuable for stakeholders to understand the project outcomes, for the project team to reflect on their work, and for future projects to build upon. That said, I'd only create one if you work as part of a PMO (Project Management Office) or Project Team that can do something with it. Again, if you are writing a document for the sake of it, and it serves no actual purpose, then ask yourself if it's worth spending your time on it. If you decide it has value, then great. Here's what you might include. Key Components of a Final Project Report Executive Summary: A high-level overview of the project is provided, highlighting key outcomes and whether the initial objectives were met. Project Objectives: Reiterate the project's objectives and scope, detailing the degree to which these were achieved. Timeline and Milestones: Outline the project timeline and whether the key milestones were met on schedule. Budget Overview: Detail the financials, including the initial budget, final expenditure, and explanation of any variances. Challenges and Resolutions: Discuss significant challenges faced, how they were resolved, and the impact on the project. Successes and Achievements: Highlight the project's successes, particularly those that added extra value to stakeholders. Lessons Learned: Summarise the key lessons learned (as previously detailed in the lessons learned review) and recommendations for future projects. Conducting a Post-Project Review Wrapping up a project with a post-project review is about diving deep into what the project managed to achieve and what it didn't. This candid look back helps everyone involved—whether they nailed their tasks or faced challenges—learn from the experience. Validate Outcomes: Make sure that what was delivered matches what was promised. This isn't just about checking off completed tasks—it's about ensuring these outcomes provide real value. Gather Feedback: This is your chance to hear directly from those on the ground about what worked and what flopped. This feedback is gold dust for sharpening your project management skills. Celebrate the Wins: Don't just focus on what went wrong. Highlight the successes, big or small, and discuss how these positive outcomes can be replicated in future projects. Identify Improvement Areas: More importantly, determine where things could have been better. Was it the timing, resources, or scope management that threw off the project trajectory? Pin down these areas with your team. Align Perceptions: Everyone must be on the same page regarding the project's impact. Misalignments here can lead to skewed perspectives on the project's success. Set the Stage for Future Projects: This review can be a launching pad for future strategies. What insights can you carry forward? What strategies need rethinking? Closure Event or Meeting Rounding off a project with a closure event or a formal meeting is like the final chord of a symphony—it marks a definitive end and celebrates the effort of the entire ensemble. While we needn't dwell heavily on the minutiae, it's essential to acknowledge this as a pivotal moment for the team and stakeholders. Marking the End: Just as it's important to kick off a project with clear objectives, it's equally vital to mark its conclusion. A closure event does just this, signifying that the project has officially wrapped up. Celebrating Successes: After the grind, it's time to shine a light on the achievements. Whether toasting to the project's success or simply gathering everyone for a well-deserved thank you, recognition goes a long way in boosting morale. Conclusion And there you have it—the final act in the drama is project management. Wrapping up a project with a structured closure is about giving the project, your team, and yourself the closure you deserve. This isn't just the end. It's an invaluable space between projects where you can pause, reflect, and gear up for the next challenge. Remember, every project you complete, successful or otherwise, is a stepping stone to becoming a more effective and insightful project manager. The lessons you gather, the documentation you archive, and the celebrations you host contribute significantly to personal growth and organisational knowledge. So, take these closure activities seriously, but also enjoy them. You've earned it. Use this time to prepare for the next big thing—with more experience, a refined approach, and a team ready to confidently tackle whatever comes next.

  • Infrastructure & Platform Management

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

  • Deployment Management

    Introduction The Purpose Deployment management is a critical IT service management practice that aims to structure and safely transfer new or changed hardware, software, documentation, and other IT components to live environments. The key purpose of deployment management is to ensure these components can be moved to other environments for staging or testing purposes. This practice is essential for maintaining the continuity and integrity of IT services during updates or new implementations. Scope This article will cover the deployment management of IT components across various stages of their lifecycle, including development, integration, testing, and production. The scope is designed to encompass all the processes, roles, and tools required to manage and execute these deployments effectively. Key Benefits The key benefits of adopting a robust deployment management practice include: Enhanced Business Agility: Swift and efficient deployment of IT services allows businesses to respond more rapidly to market changes and customer needs. Reduced Risks: Proper deployment management reduces the potential for errors during transitions, minimising downtime and the impact on end-user services. Efficiency Improvements: Streamlined deployment processes, which eliminate unnecessary work and automate repetitive tasks, lead to faster delivery times and reduced costs. Basic Concepts and Terms In deployment management, understanding key terms and concepts is crucial for grasping the practice's full scope and implementation. Here are essential definitions: Deployment refers to the activity of moving new or changed hardware, software, documentation, processes, or any other component to live environments or other environments such as testing or staging. The aim is to make these components operational and ensure they integrate seamlessly with existing systems. Environment: A subset of the IT infrastructure used for a specific purpose. Environments are usually differentiated by their roles in the software development lifecycle and can include: Development/Integration: Where components are initially created and integrated. Test: Where components are rigorously tested to ensure they meet the required standards. Staging: Where components are assembled to replicate the live environment for final testing and validation. Live/Production: Where components are fully deployed and become accessible to end-users. Processes Deployment management involves a series of structured processes to ensure the smooth transition of IT components from development to production environments. Here are the key processes: Deployment Planning This process involves the detailed preparation for deploying service components. Planning includes defining the deployment's scope, identifying necessary resources, scheduling activities, and preparing contingency plans. Effective planning ensures that all prerequisites for deployment are met before initiation, reducing the risk of disruptions during the transition. Scope Definition: Identify and document exactly what components will be moved, to which environments, and for what purpose. Resource Allocation: Determine the human, technical, and financial resources required for the deployment. Risk Assessment: Analyse potential risks associated with the deployment and prepare mitigation strategies. Scheduling: Set timelines for each deployment activity, ensuring they align with business operations to minimise impact. Stakeholder Communication: Develop a communication plan informing all stakeholders of the deployment's progress and any potential impacts. Pre-deployment Testing: Conduct tests to ensure the components are ready for a smooth transition to the production environment. Final Review and Approval: Obtain necessary approvals from relevant authorities to deploy. Deployment Execution Execution is the active phase where the planned deployment activities are carried out. This includes the physical or virtual moving of components to the target environment, configuring them as needed, and ensuring they function as intended within the new setting. Execution must be closely monitored to promptly address any issues that arise. Initiation: Activate the deployment plan and begin the transition of components as scheduled. Monitoring: Continuously monitor the deployment process for any deviations from the plan or unexpected issues. Issue Resolution: Promptly address any problems during the deployment to prevent delays or failures. Configuration and Integration: Configure the moved components to operate within the new environment and ensure they integrate seamlessly with existing systems. Validation and Testing: Conduct post-deployment testing to verify that the components function as intended in the live environment. Documentation: Update all relevant documentation to reflect changes made during the deployment. Closure and Review: Once all components are successfully deployed and operational, formalise the deployment process and conduct a post-deployment review to capture lessons learned and improve future deployment activities. Relationship with Other Practices Deployment management does not operate in isolation; it is intrinsically linked to several other IT service management practices, ensuring that IT services are delivered and maintained effectively. Here's how deployment management interacts with other practices: Change Enablement: A change process often triggers deployment management. Effective deployment ensures that the change is implemented correctly in the live environment. The change enablement practice provides a structured approach to managing the change, including risk assessment and stakeholder communication, which are critical for successful deployment. Release Management: Closely connected to deployment, release management focuses on the planning, scheduling, and controlling a release to ensure its correct build, test, and release. Deployment management handles the operational aspect of moving the release into production, ensuring all components are installed and functioning correctly. Service Validation and Testing: This practice ensures that deployments meet the organisation's quality requirements. It validates that the new or changed service functions as intended and identifies potential issues before the deployment is complete. Configuration Management: Deployment management relies on accurate configuration information to ensure all components are correctly positioned and integrated within the IT environment. Configuration management provides the necessary information about the relationships and dependencies among IT assets, which is crucial during deployment planning and execution. Incident and Problem Management: These practices are essential post-deployment. If issues arise after the deployment, incident management addresses and resolves these faults quickly. Problem management helps identify underlying causes of incidents caused by a deployment and ensures that these issues are rectified to prevent recurrence. Roles & Responsibilities In deployment management, clearly defined roles and responsibilities are crucial for effective execution and governance. Here are the key roles typically involved: Deployment Manager: This role oversees the entire deployment process, from planning through execution. Responsibilities include: Coordinating with other IT practices to align deployment activities. Managing resources and schedules to ensure timely and effective deployments. Overseeing the risk management and resolution of issues during deployment. Communicating with stakeholders about deployment status and impacts. Deployment Practitioner: Individuals in this role are responsible for the hands-on tasks involved in deploying the components. Their responsibilities include: Executing the deployment according to the plan. Conducting pre-deployment and post-deployment testing. Ensuring that all deployment documentation is accurate and up to date. Addressing any technical issues that arise during the deployment process. Quality Assurance (QA) Team: While not exclusively part of the deployment team, the QA team plays a critical role in the deployment process by: Verifying that the deployment meets the predefined quality standards. Conducting thorough testing before and after deployment to ensure functionality and performance. Providing feedback to the deployment team on any issues found during testing. IT Service Management (ITSM) Coordinator: This role helps to integrate deployment management with other ITSM practices, ensuring: The deployment activities are aligned with ITIL guidelines and organisational policies. Effective communication between the deployment team and other ITSM practices. Continuous improvement of the deployment process based on lessons learned and feedback. Frequently Asked Questions About Deployment Management To help clarify common queries about deployment management, here’s a compilation of frequently asked questions and their answers: What is the difference between deployment and release management? Deployment management focuses on the technical aspects of moving new or changed service components into live environments. Release management, on the other hand, oversees the overall process of planning, testing, and releasing new functionalities, ensuring they are coordinated across multiple changes and deployments. How can deployment frequency impact business operations? Higher deployment frequency can indicate more agile and responsive IT services, but it also requires robust processes to manage the increased operational risk. Frequent deployments must be well-planned and tested to avoid disruptions to business operations. What are the best practices for ensuring successful deployments? Best practices include thorough testing, stakeholder engagement, detailed planning, and automation to reduce manual errors. Continuous improvement based on feedback from previous deployments is also crucial. Can deployment management be automated? Yes, many aspects of deployment management can be automated, especially in environments that support continuous integration and continuous deployment (CI/CD). Automation helps improve accuracy, speed up deployments, and reduce the likelihood of human error. How do you handle deployment failures? Handling deployment failures involves immediate rollback mechanisms to previous stable states, thorough investigation to identify the root cause, and applying lessons learned to future deployments to prevent recurrence.

  • Software Development & Management

    Introduction to Software Development and Management Purpose The fundamental purpose of software development and management practice is to ensure that software applications meet the diverse needs of internal and external stakeholders. These needs encompass functionality, reliability, maintainability, compliance, and auditability. The practice guides organisations in developing and maintaining software, ensuring it supports and enhances business processes. Scope Software development and management is an extensive practice that spans the entire lifecycle of applications. This lifecycle can vary significantly, averaging 10 to 15 years, with some applications serving business needs for several decades. The scope of this practice encompasses not only the development of software but also the underlying infrastructure that supports and enables the development and operation of these applications. In the modern digital landscape, software is not merely a support tool but a core component of business service delivery, necessitating a comprehensive approach that integrates development with ongoing management. Key Benefits Implementing robust software development and management practices offers numerous benefits to an organisation. Key among these is aligning software functionalities with business objectives, ensuring that applications are functional and strategic assets. Effective management practices significantly reduce the costs of maintaining and upgrading software, particularly in managing technical debt and ensuring compliance with relevant standards and regulations. This strategic alignment optimises performance and enhances the reliability and security of software applications, which is crucial for maintaining trust and delivering value to customers. Basic Concepts and Terms Understanding the foundational concepts and terms in software development and management is crucial for effectively navigating the practice. Here are some of the key concepts and terms that are essential for grasping the complexities of this field: Software Software comprises the set of instructions that command the hardware components of a computer to perform specific tasks. This includes applications designed for end users and the infrastructure necessary for developing and operating these applications. As an integral component of modern business services, software enables and often defines the functionality of these services, transitioning from being merely supportive to being central in service delivery. Software Development Software development involves creating and enhancing applications according to specified functional and non-functional requirements. This process includes the initial design and development and the ongoing enhancements and corrections needed to adapt to changing requirements. Maintenance Traditionally viewed as a separate process, maintenance in modern software practices is increasingly integrated into the development phase. This includes corrective, preventive, adaptive, and perfective tasks—each aimed at enhancing software functionality and performance while ensuring compatibility with evolving business needs. Technical Debt Technical debt refers to the future cost of reworking software to correct expedient but suboptimal decisions during development. It represents the trade-off between quick fixes and more sustainable, long-term solutions, impacting software's overall quality and maintainability. Software Quality Software quality is assessed based on a product's adherence to defined criteria encompassing functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. These criteria are critical for ensuring that software meets or exceeds the expectations of its users and stakeholders. SDLC Models Software Development Life Cycle (SDLC) models outline the phases involved in software application planning, creation, testing, deployment, and maintenance. Standard models include the waterfall model, incremental, iterative, and Agile methodologies, each with distinct characteristics suited to different projects and organisational contexts. Processes Software development and management are structured around various methodologies that ensure software's systematic creation and maintenance. This section delves into the fundamental processes that are integral to this practice. Value Streams and Processes Software development and management contribute to organisational value through multiple value streams. These streams integrate the practice with other ITIL management practices to deliver high-quality services efficiently. The principal value chain activities include 'obtain/build' and 'deliver and support', which correspond to the phases of coding, building, and running the applications. This integration ensures that software development is not an isolated activity but a central part of broader business processes. Defining Processes Software development and management processes are defined through interrelated activities that transform inputs (such as requirements and user feedback) into outputs (like software products and updates). These processes are designed to be repeatable and are adapted to suit the specific needs of the organisation and the projects at hand. Common Processes Product Planning and Prioritisation: This involves identifying and organising the work to be done based on business priorities and technical requirements. Software Design and Production: After planning, the following steps are designing the software architecture and writing the code necessary to build the application according to the specifications. Code Review and Maintenance: Ensuring that the software code not only functions as intended but is also maintainable and efficient is vital. This includes reviewing code for quality and refactoring it to improve performance and maintainability. Defect Handling and Technical Debt Management: Identifying and fixing defects is an ongoing process crucial for maintaining the quality of the software. Simultaneously, managing technical debt is vital to prevent compounding problems that can hinder future development. Version Control and Deployment: Managing different software versions and ensuring that updates are successfully deployed to production environments are critical for maintaining application stability and integrity. Relationship with Other Practices Software development and management are deeply interconnected with various other ITIL practices, enabling a holistic approach to service management. Understanding these relationships is essential for effectively leveraging software development within the broader organisational context. Key Relationships Architecture Management: This practice involves planning and maintaining the overall architecture of IT services. Software development and management must align with this architecture to ensure that applications integrate smoothly into the broader IT infrastructure. Business Analysis: The role of business analysis in gathering and interpreting requirements is crucial for ensuring that the software development aligns with business needs and expectations. Collaboration between software development and business analysis practices ensures that applications are technically sound and business-relevant. Deployment Management: Software development must work closely with deployment management to ensure that applications are successfully transitioned from development to production environments. This includes managing the deployment of application artefacts and ensuring that new or updated applications perform as expected without disrupting existing services. Service Validation and Testing: This practice ensures that new or changed services meet the intended requirements and do not adversely affect the existing services. Integration with software development is vital for conducting thorough testing and validation processes. Risk Management and Information Security Management: These practices are integral to managing the risks associated with software development, including those related to data security and compliance. Ensuring that software development adheres to security protocols and risk management strategies is crucial for maintaining the integrity and reliability of IT services. Collaborative Efforts The collaborative nature of these relationships ensures that software development is not performed in isolation but as part of a coordinated effort that spans multiple practices and disciplines. This integration helps optimise resource utilisation, minimise risks, and enhance overall service quality. By aligning software development with these related practices, organisations can achieve more cohesive and robust IT service management, driving more excellent value from their investment in technology. Roles & Responsibilities Clearly defined roles and responsibilities are essential for effectively delivering software projects in software development and management. This section outlines the key roles involved and their respective responsibilities within the practice. Key Roles Software Developer: This person is responsible for designing, developing, and maintaining software applications. This includes writing code, debugging, and implementing new features based on functional and non-functional requirements. Project Manager/Product Owner: This role is the liaison between the development team and stakeholders, ensuring that the project meets business needs. This role prioritises work, defines project scopes, and manages timelines and resources. Quality Assurance Tester: This role ensures the software meets all specified requirements through rigorous testing procedures. It is crucial to identify bugs and issues before the software goes live. IT Architect: This role oversees the software architecture, ensuring it supports current and future business needs. It involves strategic system design planning and interfacing with various IT practices to align technology with business strategies. Business Analyst: This role translates business needs into technical requirements. It bridges the gap between business processes and technical implementation, ensuring software solutions accurately reflect the intended business outcomes. Responsibilities Planning and Analysis: Determining what software solutions are needed, outlining the requirements, and planning the development lifecycle. Development and Implementation: Build the software according to specifications, test it to ensure functionality, and implement the final product within the business environment. Maintenance and Upgrading: Continuously updating and maintaining the software to adapt to business changes or technological improvements. Risk Management: Identifying potential risks in the development process and creating strategies to mitigate them, ensuring the delivery of secure and reliable software. Collaboration and Communication: Regularly communicating with team members and stakeholders, facilitating a collaborative environment to ensure that all aspects of the software development meet the business objectives. Implementation Advice Implementing software development and management practices effectively requires thoughtful consideration of critical metrics and awareness of common pitfalls. This section guides both aspects to help ensure successful implementation. Key Metrics Stakeholder Satisfaction: Measuring the satisfaction levels of stakeholders with the software products and the development process can provide valuable insights into the effectiveness of the practice. Compliance with Requirements: Regular assessments to ensure that software meets internal and external requirements are crucial for maintaining quality and compliance. Delivery Frequency and Speed: Tracking the frequency and speed of software deliveries helps gauge the agility and efficiency of the development process. Defect Rates: Monitoring the rate of defects found in software post-deployment indicates the quality of the coding and testing phases. Technical Debt: Monitoring the accumulation of technical debt is essential to avoid future costs and potential service disruptions. Resource Utilisation: Measuring how effectively resources are utilised during software development can help optimise costs and improve efficiency. Things to Avoid Overlooking Technical Debt: Allowing technical debt to accumulate without remediation plans can increase maintenance costs and reduce system performance. Inadequate Testing: Skipping thorough testing phases or rushing through them can result in buggy software failing to meet user needs, impacting satisfaction and trust. Poor Requirements Management: Failing to properly gather, understand, and manage software requirements can lead to products not aligning with business goals or stakeholder expectations. Ignoring Stakeholder Feedback: Not incorporating feedback from users and stakeholders throughout the development process can lead to missed opportunities for improvement and innovation. Resistance to Change: In the fast-evolving field of software development, resistance to adopting new technologies or methodologies can hinder an organisation's competitive edge and operational efficiency. Frequently Asked Questions This section addresses some of the most common inquiries related to software development and management practices, providing clear and concise answers that can help stakeholders better understand and engage with these practices. What is the most effective software development methodology? The effectiveness of a software development methodology can vary depending on project requirements, team size, and organisational goals. Agile methodologies are popular for their flexibility and focus on rapid delivery, but traditional methodologies like Waterfall Are suitable for projects with well-defined stages and fixed requirements. How can technical debt be managed effectively? Managing technical debt requires regular reviews and assessments to identify and prioritise the debt items. Implementing refactoring and code improvement initiatives as part of the ongoing development cycle can prevent technical debt from accumulating and impacting the software's performance or maintainability. What are the key factors to consider when planning software maintenance? Key factors include understanding the software's lifecycle, anticipating future business needs, assessing the current state of the software, and allocating resources for regular updates and improvements to ensure continuous alignment with business objectives. How can stakeholder satisfaction be measured in software projects? Satisfaction can be measured through regular feedback sessions, surveys, and direct interviews with stakeholders. Tracking the usage and performance metrics of the software also provides insights into how well the software meets the needs of its users. What role does risk management play in software development? Risk management is crucial for identifying potential issues that could derail the project or cause financial losses. It involves assessing risks throughout the development process, from initial design to deployment, and implementing mitigation strategies. Can software development practices adapt to changing technological landscapes? Yes, software development practices must evolve continuously to incorporate new technologies, tools, and methodologies. This adaptability ensures the organisation is competitive and can meet its strategic goals through enhanced software solutions.

bottom of page