What is Project Management
-
noun
an individual or collaborative enterprise that is carefully planned to achieve a particular aim.
"a research project"
NORTH AMERICAN
a government-subsidized housing development with relatively low rents.
"her family still lives in the projects"
verb
estimate or forecast (something) on the basis of present trends or data.
"spending was projected at £72,900 million"
extend outwards beyond something else; protrude.
"I noticed a slip of paper projecting from the book"
-
(also ‘program’ in American English)
noun
a set of related measures or activities with a particular long-term aim.
"an extensive programme of reforms"
a series of coded software instructions to control the operation of a computer or other machine.
verb
provide (a computer or other machine) with coded instructions for the automatic performance of a task.
"it is a simple matter to program the computer to recognise such symbols"
arrange according to a plan or schedule.
"we learn how to programme our own lives"
-
noun
a large, thin, flat case for loose sheets of paper such as drawings or maps.
"under his arm he carried a large portfolio of drawings"
a range of investments held by a person or organisation.
"a portfolio of insured municipal securities"
-
noun
the process of dealing with or controlling things or people.
"the management of the economy"
ARCHAIC
trickery; deceit.
"if there has been any management in the business, it has been concealed from me"
What this is
Organisations utilise different levels of management to ensure teams are aligned with business objectives related to strategy, financial growth, and operational efficiency. The three primary levels of strategic management are project, program, and portfolio management. While these terms are sometimes used interchangeably and share similarities, they have distinct contributions to larger organisational goals. The following definitions of portfolio, program, and project are derived from the UK Government Office of Government Commerce's 2008 publication "Portfolio, Programme, and Project Offices (P3O)." These definitions align with the core principles of the Project Management Institute's (PMI) definitions.
Defining Projects, Programmes and Portfolios
Projects: Projects focus on outputs and are relatively less complex. They have defined start and end dates, agreed budgets, specific scopes, and lower risk levels. Projects can be viewed as temporary organisations, existing for shorter durations than programs or portfolios. They deliver one or more outputs, typically aligned with a specific business case.
Programs: Programs focus on outcomes and are higher in complexity compared to projects. They typically have longer timeframes, larger budgets, less defined scopes, and higher risks. Programs can be seen as temporary and flexible organisations established to coordinate, direct, and oversee the implementation of related projects and activities. Their purpose is to deliver outcomes and benefits aligned with an organisation's strategic objectives.
Portfolios: Portfolios aim to maximise return on investment. They represent a balanced mix of projects, programs, and operational activities that contribute to an organisations strategic objectives. Portfolios are ongoing and involve higher levels of risk. They encompass an organisation's total investment (or a segment thereof) in the changes necessary to achieve strategic objectives. A portfolio may consist of various projects or programs from the same or different business units within the organisation.
Leading practices of Project Management (P3M & P3O):
The international organisations, Project Management Institute (PMI) and the Office of Government Commerce (OGC), are working towards promoting better project management practices and aligning the definitions of "Portfolio," "Programme," and "Project." They use the term P3M as an umbrella term to encompass the application of project, programme, and portfolio management practices, methods, procedures, techniques, and competence to achieve defined objectives. The term P3O refers to a functional model that provides a decision-enabling and delivery support structure for organisational change. This model can be established as a single permanent office, which may have different names such as Portfolio Office, Centre of Excellence, Enterprise, or Corporate Programme Office. It is important to note that P3O not only refers to the function itself but also encompasses the P3O accreditation program and the P3O manual for practitioners seeking certification in this field.
The terms P3M and P3O are commonly used in a government context in the UK, New Zealand, Australia, and Canada, originating from the UK Government OGC's 2008 publication "Portfolio, Programme, and Project Offices (P3O)."
The leading international organisations, PMI and OGC, are the most influential advocates of better practices in P3M. The Project Management Institute (PMI) is a not-for-profit membership association that claims to be the world's leading professional organisation for project management. They include the disciplines of programme and portfolio management within their definition of "project." PMI has published globally recognised standards, such as:
PMBoK® - The Project Management Body of Knowledge
The Standard for Program Management
The Standard for Portfolio Management
OPM3® - The Organisational Project Management Maturity Model
PMI has also overseen the development of the international ISO Standard 21500 "Guide to Project Management," involving over 30 countries, which was published in 2012.
The UK Government's Office of Government Commerce (OGC) was established to help the UK government achieve optimal value from its spending. OGC is well-known for developing and promoting high-value P3M practices and methodologies, including:
ITIL - Information Technology Information Library
PRINCE2® - Projects in Controlled Environments
MSP® - Managing Successful Programmes, developed to address increasingly complex change programs in Government that PRINCE2 alone could not handle
OGC Gateway - an assurance review process for large, high-risk projects and programmes
P3M3® - Portfolio, Programme, Project Management Maturity Model
P3O® - Portfolio, Programme, and Project Offices, providing guidance on establishing support structures, often referred to as PMOs, for the management of portfolios, programmes, and projects
Portfolio Management Guide - guidance on portfolio management in organisations
The evolution of project management maturity models
In recent years, P3M advocacy groups have made significant progress in developing Capability Maturity Assessment models and methods to assist organisations in the following:
Understanding their level of P3M capability compared to international benchmarks.
Assessing improvements in the value of their P3M implementations resulting from investments made in capability.
Identifying which aspects of P3M practice capabilities to focus on to achieve the highest return on investment (for their capability-improvement budget).
Two primary maturity models have emerged from this work:
OPM3® - Organisational Project Management Maturity Model, developed by PMI.
P3M3® - Portfolio, Programme, and Project Management Maturity Model, developed by OGC.
Project management as a discipline typically exists on a maturity continuum within organisations. These organisations may employ legacy or current best practice methodologies or have recently reengineered their ways of working to deliver more effective strategic outcomes. The complexity of terminology, maturity levels, and the diverse range of experience project professionals bring to their work can make project delivery challenging. This challenge applies not only to newcomers in the field but also to well-established practitioners.
Why this is important
In simple terms, portfolio management plays a crucial role in delivering organisational strategy and objectives by emphasising the selection of the appropriate mix of projects. On the other hand, project and programme management are concerned with executing these projects correctly.
The methodologies and models
-
In 1896, Karol Adamiecki, a Polish engineer, created the Harmonograph, also known as the Harmonogram or Harmonograf, to address the challenges of sequencing and scheduling in production. His solution was essentially a workflow diagram, published in 1903, which bears a striking resemblance to what we now refer to as a Gantt Chart.
Henry Gantt popularised Gantt Charts with his 1910 theory, which incorporated project milestones as a means to achieve efficient project completion. The Gantt Chart is often associated with the "waterfall" method due to its structure, which lays out the work, milestones, and deliverables of a project in a work breakdown structure. By defining the work from start to finish (top to bottom) and the chronological progression of the work (left to right), the sequenced tasks visually cascade over time, resembling a waterfall.
The term "waterfall" as a methodology gained prominence in software development through Winston W. Royce's 1970 publication. However, it wasn't until 1976 that the term "Waterfall" was introduced in a white paper titled "Software Requirements: Are They Really a Problem?" by T.E. Bell and T.A. Thayer.
In 1985, the United States Department of Defense adopted this approach and established standards for working with software development contractors. These standards required the implementation of a software development cycle comprising six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing.
Since the 1970s, Royce's model (systems and software requirements, analysis, design, coding, testing, operations) has undergone evolution based on project context and requirements. However, one constant remains: progress to the next phase can only occur once the current phase is complete, reviewed, and approved. Nowadays, the most common waterfall model incorporates the following phases:
Requirement analysis: Gathering information and business rules to define the product and its functions.
System design: Selecting hardware and system requirements in accordance with the defined requirements to meet the overall system architecture, followed by code development.
Implementation: Developing and testing individual units for functionality (unit testing).
System testing: Subjecting the software to systematic testing to identify and resolve any errors or issues.
System deployment: Once tested, the product is released into the customer's environment.
Maintenance: After installation, maintenance activities involve making adjustments to improve performance or implementing modifications to rectify faults or accommodate changing customer needs.
Waterfall vs Agile Project Management
Waterfall project management, a predictive delivery system, follows stringent guidelines and processes, aiming to deliver a comprehensive project package to the customer upon completion of the project lifecycle. Agile, an adaptive system that addresses the shortcomings of waterfall, such as design constraints, lack of customer feedback, and delayed testing, introduces a more flexible approach. Agile employs collaborative, organising cross-functional teams that deliver increments to the customer through a rapid and iterative process. This allows for gathering insights and continually adjusting requirements based on the knowledge gained throughout the project.
-
PRINCE2 is a structured project management methodology and practitioner certification programme. The method emphasises dividing projects into manageable and controllable stages that follow a linear path. First developed in 1989 by the UK government, the method was designed primarily for information system projects and was originally known as Project Resource Organisation Management Planning Technique (PROMPT).
Since its first iteration, the method evolved throughout the 90s as organisations began to realise that the techniques could be applied to projects beyond IT. After a rewrite to remove IT jargon in 1996, PRINCE2 was launched. The model and materials are "owned" by Axelos (since 2013), in a joint venture between the UK Government and Capita, with its methods having been adopted in many countries worldwide, including the UK, Western European countries, and Australia.
The method is also recognised by the Project Management Institute (PMI) as a compatible methodology within its Project Management Body of Knowledge (PMBOK) and Project Management Professional (PMP) certification. Because of its simple yet defined process steps, PRINCE2 has become known as a good beginner methodology with millions of PRINCE2 practitioners around the world using its principles.
The 6 aspects of a PRINCE2 project are:
Scope: outlines goals, deadlines, and project deliverables.
Costs: represents how much money the project will cost.
Time: indicates how much time the project will take to be delivered, including estimated time to complete each task.
Risk: involves a risk management process with proactive identification of risks and mitigations.
Quality: provides a clear definition of the standards expected for all deliverables to ensure they meet customer expectations.
Benefits: ensures there is a clear business justification for undertaking the work.
The 7 core principles of PRINCE2 are as follows:
Continued business justification: It is managed within a business case and updated at every stage of the project to ensure the project remains viable.
Learn from experience: Projects maintain a lessons log to continuously learn from their own and previous project logs, preventing unnecessary work effort.
Defined roles & responsibilities: Structured roles are established across four levels, including corporate or programme management, project board, project manager, and team level.
Manage by stages: The project progresses through planned and controlled stages, involving updates to the business case, risks, and plans based on new developments.
Manage by exception: Tolerances are defined for each objective, including the six aspects, to establish delegated authority in case tolerances are exceeded. For example, if timelines exceed the estimated duration for a planned deliverable, escalation is required to the next management level for decision-making on how to proceed.
Focus on products: There is a strong emphasis on defining and delivering products, with particular attention given to meeting quality requirements.
Tailor to suit project environment: The PRINCE2 methodology is tailored to suit the specific project environment, considering factors such as size, complexity, importance, time capability, and risk. It undergoes regular reviews at each stage to ensure its suitability.
The 7 project phases of PRINCE2 are as follows:
Starting-up: The project manager and executive (the person with ultimate responsibility) are assigned, a team is appointed, and a project brief is produced.
Directing: The project board, a group of individuals who make high-level decisions on the project, reviews the project brief and makes decisions on how to move forward. This may involve making changes to accommodate resource or time constraints.
Initiation: A business case or project initiation document is constructed, which includes baselines for time, cost, quality, scope, risk, and benefits. Once approved by the project board, the project officially begins.
Controlling: The project manager breaks the work into manageable parts or work packages and delegates them to team members for completion.
Managing product delivery: The project manager ensures that the delivery of products progresses smoothly and meets the quality standards outlined in the quality register. The project board reviews the deliverables and either approves them or requests changes or additional work for the project.
Managing stage boundaries: At the end of each stage, a review is conducted to determine if the project should continue or be stopped.
Closing: The project manager completes final documentation, outcomes, and reporting to conclude the project lifecycle.
-
Managing Successful Programmes (MSP) complements the PRINCE2 methodology and helps organisations better align their projects with corporate strategies and business capabilities to achieve maximum value. MSP was developed in 1999 to respond to the increasingly complex landscape of change that PRINCE2 was never designed to address. The model and materials, like PRINCE2, are owned by Axelos in a joint venture between the UK Government and Captia.
MSP defines a program as a specific set of projects identified by an organisation that together will deliver a defined objective or set of objectives for the organisation. The objectives or goals of the program are typically at a strategic level, enabling the organisation to achieve benefits and improvements in its business operations. The methodology and certification pathway consist of a set of principles and processes to use when managing a program.
The principles in MSP provide guidance on how to:
Organise people to ensure clear responsibilities and lines of communication.
Plan the work in a way that achieves results.
Ensure that the organisation benefits from undertaking the program.
Involve all interested parties (stakeholders).
Resolve issues as they arise.
Identify and manage risks.
Ensure quality.
Maintain up-to-date information that tracks the continually changing environment.
Conduct program audits to ensure adherence to standards.
The processes in MSP describe how to:
Identify the aim of the program and the envisioned benefits for the organisation.
Define the program and specify how the organisation will be different afterward.
Establish the program.
Monitor and coordinate the projects within the program to a successful conclusion.
Manage the transition between the "old" and "new" ways of working, ensuring benefits are realised.
Close the program and ensure the achievement of the end goal.
-
The UK Government's Portfolio, Programme, and Project Management Maturity Model (P3M3) is an assessment model widely used in the UK, Australia, and New Zealand. The model was mandated for use on all major ICT projects by the Australian Federal Government. In 1998, the New Zealand State Services Commission (renamed in 2020 to the Public Service Commission) used it to conduct a facilitated assessment of the capability maturity of 15 Government agencies. The model originated from the Office of Government Commerce (OGC), a UK Government department tasked with helping public sector organisations improve efficiency, achieve better value for money in procurements, and deliver improved success in programs and projects.
Initially released in 2005, P3M3 was based on the Capability Maturity Model Integration (CMMI), a framework for integrating process improvement across multiple areas. The first version of P3M3 had limited uptake, but the second version, released in 2008, gained more success and was adopted by the Australian and New Zealand governments as the method for measuring and managing performance in their departments.
By that point, all UK government departments and many private sector organisations had undergone assessments using P3M3. Over the years, P3M3 has become increasingly sophisticated, including its use for validating supply chains. As more data and insights were gathered regarding the model and organisational characteristics, improvements were incorporated, leading to the release of the third version in 2016.
Similar to PRINCE2 and MSP, the P3M3 model and materials are owned by Axelos in its joint venture between the UK Government and Capita. Companies and organisations can access the P3M3 model and materials through the Axelos website for self-assessment purposes. The assessment provides a maturity measure indicating maturity levels across five stages:
Awareness process: The organisation can recognise projects but lacks a structured approach to dealing with them.
Repeatable process: Some areas are starting to use standard processes, but there is no consistency across the organisation.
Defined process: A consistent set of standards is used, with clear process ownership.
Managed process: Efficiency is monitored and measured, and active interventions for improvement are in place.
Optimised process: Quantitatively managed processes are optimised based on changing business needs and external factors.
-
PMBOK, short for Project Management Body of Knowledge, is an extensive compilation of processes, best practices, terminologies, and guidelines that have gained widespread acceptance as standard practices in the field of project management. The PMBOK guide is authored by project managers, specifically for project managers, and is supervised by the Project Management Institute (PMI), established in 1969.
The PMI does not advocate for any specific methodology, as the processes within the PMBOK can be tailored to suit various project management situations. Managers select what they need for their respective companies, teams, and projects. The PMBOK itself is not a methodology or step-by-step process for executing specific projects, and it does not contain every fact. However, it is considered the definitive guide to the topic and is therefore updated every few years, with the latest edition published in 2021.
The PMBOK serves as a valuable resource for both companies and project managers, offering an industry framework that integrates best practices in project management. It aims to assist companies in standardising their practices, customising processes, and mitigating project failures. While it is commonly linked to the waterfall methodology, which follows a sequential project stage alignment, the PMBOK is also adaptable to modern methodologies like Agile.
The PMBOK is broken into two parts:
Part 1 : It includes basic information about project management, consisting of 13 chapters:
Chapters 1-3: They establish the foundation:
Project management basics, defining what a project is.
How the processes fit together, illustrating how project management integrates into the business structure and process groups.
Knowledge requirements, outlining the necessary knowledge for project managers.
Chapters 4-10: These chapters cover the knowledge areas to be practiced, including how to manage and integrate:
Project schedule.
Cost.
Risk.
Scope.
Part 2 : The PMBOK has been registered as a standard for the industry by the American National Standards Institute (ANSI). This section describes the process groups and processes within the PMBOK, including inputs, outputs, and benefits for each. It also covers the formal review process and the set of standards associated with it.
The PMBOK defines the following process groups:
Initiating Process Group: This group includes processes required to launch a new project or a new project phase. It involves the development of the project charter and the identification of project stakeholders. The primary outcomes are the charter document and stakeholder register. The project charter includes the business case, project scope, deliverables, objectives, required resources, key stakeholders, high-level timeline, cost estimate, and known risks, issues, or dependencies. The stakeholder register lists the project stakeholders, their interests, and communication expectations.
Planning Process Group: This group encompasses processes related to defining and planning the project scope, schedule, budget, and stakeholder management. It consists of 24 processes and aims to create a detailed project plan. The primary outcome is the project management plan (PMP), which may include sub-plans for critical areas or subsections for smaller projects. The PMP is a living document that is updated throughout the project.
Executing Process Group: This group involves processes related to the completion of project activities and tasks. It includes 10 processes focused on managing project work, project knowledge, communications, risk responses, stakeholder engagement, resource acquisition, team development, and communication management.
Monitoring & Controlling Process Group: This group covers processes related to tracking, monitoring, reporting, and controlling project performance and progress. It consists of 12 processes designed to provide oversight, identify and mitigate issues, and update the project plan as necessary. Monitoring project work is a critical process in this group.
Closing Process Group: This group includes processes required to finalise and complete a project or project phase. The primary process involves closing out the project or phase, ensuring customer acceptance of deliverables, completion of documentation, and addressing any remaining tasks.
—
PMI / PMBOK Accreditations:
The Project Management Institute (PMI) offers two main accreditations:
Certified Associate in Project Management (CAPM)
Project Management Professional (PMP)
These accreditations provide project managers with a reliable resource, such as the PMBOK, to answer questions and provide guidance in various project management positions.
-
The Organisational Project Management Maturity (OPM3) Assessment Model, developed by the Project Management Institute (PMI), is designed to help organisations enhance their capability in implementing strategies through project execution. Published in 2003 after extensive collaboration involving project managers from over 30 countries, OPM3 expands beyond the scope of the Project Management Body of Knowledge (PMBOK), which primarily focuses on managing individual projects.
OPM3 enables organisations to assess their maturity level by analysing approximately 600 best practices derived from defined capabilities within their business model. The model encompasses four levels of maturity across three domains: Projects, Programs, and Portfolios. Its central emphasis lies in establishing the correlation between an organisations ability to manage projects, programs, and portfolios and its effectiveness in strategy implementation.
OPM3 is applicable to profit and non-profit organisations of varying sizes, industries, and geographical locations, and can be implemented at different levels such as division, business unit, or department. The OPM3 process comprises three essential steps:
Knowledge: Acquiring knowledge about best practices in organisational project management.
Assessment: Evaluating the organisations current maturity level of project management.
Improvement: Identifying a pathway for continuous improvement based on the organisations understanding of best practices and its current maturity level in project management.
-
In 2001, a group of 17 software developers and engineers gathered at The Lodge at the Snowbird Ski Resort in Utah, where they formulated a set of values known as ‘The Agile Manifesto’.
The Agile Manifesto represents a departure from the traditional project management methods prevalent at that time, which relied on the waterfall approach for project delivery. The conventional approach, from the early 1900s to the 2000s, required extensive upfront planning before any work could commence. The waterfall method necessitated fixed project charters and scope statements from the outset, while software development lifecycles (SDLCs) demanded detailed technical and user requirements prior to development initiation.
It is understandable why the best practices and tools of the waterfall method gained significant adoption across various industries. This approach was credited with the success of prominent projects such as the Hoover Dam, the Polaris Submarine project, and the 1968 Winter Olympics. However, organisations in the 90s, particularly those centered around software development, began to realise that the "old" project management ways, characterised by rigid and heavyweight methodologies, were no longer effective.
The lack of flexibility, adaptability, and autonomy hindered teams from responding to changes or incorporating learnings during the work process. The predefined project plans left no room for surprises, making deviations costly. This is where Agile came in. Rooted in software development, Agile introduced new and innovative values and principles that revolutionised project management and found applications across diverse teams, from product to marketing, in their day-to-day work.
The original Agile Manifesto outlines four core values, stating that "while there is value in the items on the right, we value the items on the left more":
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
These core values serve as the foundation for all Agile project management approaches, guiding everything from standard ways of working to the 12 Agile project management principles. It is evident from these values that Agile approaches prioritise collaboration and people-centric approaches. In the words of the Manifesto, the 12 key principles are as follows:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for shorter timescales.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Provide them with the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximising the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Implementing Agile practices, which support ways of working rather than dictating them, enables organisations to embrace continuous improvement methodologies. These methodologies unlock visibility, flexibility, and collaboration necessary to keep work progressing. Tools like Scrum or Kanban boards have become essential project management tools, not only to help teams adopt Agile but also when organisations seek to scale their Agile practices.
-
The term 'scrum' in software development was initially mentioned in a 1986 paper titled "The New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. The authors borrowed the term from rugby, where a scrum refers to a method of restarting play by closely packing players together to gain possession of the ball. They used the scrum metaphor to emphasise teamwork.
The scrum framework was developed in the 90s and was presented in a 1995 paper at the 'Business Object Design and Implementation Workshop' by Ken Schwaber and Jeff Sutherland. The duo continued to test and improve scrum, eventually making contributions to the 2001 Manifesto for Agile Software Development. As a result, scrum gained widespread recognition in the early 2000s as a vital framework for agile project management.
In scrum, work is divided into short cycles called 'sprints,' typically lasting 1-2 weeks. Each sprint focuses on specific items taken from a 'backlog' and brings them into the iteration. The backlog is a prioritised and structured list of deliverables that define the project's scope. It consists of individual items that need to be completed. In development circles, the backlog is also referred to as a 'product backlog,' which is derived from a technology roadmap and its requirements.
During a sprint, a scrum team is formed with three main roles:
Product Owner: This person is responsible for maximising the value of the work completed by the Development Team, including managing the backlog.
Development Team: A small group of individuals who work on the project. The team operates with a flat hierarchy and is self-organising. Once goals are set, team members are free to tackle them as they see fit.
Scrum Master: The Scrum Master facilitates and supports the Scrum process across the Product Owner, Development Team, and the larger organisation. Their role involves removing roadblocks and distractions that may hinder the team's progress. They ensure adherence to the Scrum framework, act as a liaison between the scrum team and external stakeholders, and are committed to the scrum values and practices. They also conduct sprint retrospectives to review performance and make necessary changes before starting the next sprint.
The scrum methodology is widely adopted in agile project management. It shares core values and principles with other agile methodologies, emphasising individuals and interactions, working software or prototypes, customer collaboration, and responsiveness to change.
Here's a brief overview of how scrum works:
All tasks required to build the product are listed in a backlog and prioritised by the Product Owner. The Product Owner ensures the backlog is clear, accessible, and well-organised.
Scrum utilises fixed-duration sprints, typically a few weeks but always less than a month. Each sprint has a predefined goal, and the team selects items from the backlog to work on during the sprint.
Before a sprint begins, sprint planning takes place to identify the sprint goal and determine how it will be achieved.
During the sprint, the development team holds a daily stand-up meeting called a daily scrum. They provide updates on the previous day's progress, discuss their focus for the day, and address any identified risks.
At the end of each sprint, the team conducts a sprint review to present their accomplished work and evaluate it together. The focus is on the product and identifying areas for improvement in future sprints.
The team then holds a sprint retrospective to assess their performance and inform the next round of sprint planning. The focus is on evaluating the sprint process and fostering a culture of continuous improvement.
Iterate, iterate, iterate.
-
Kanban is a framework within agile project management, emphasising visual representation of tasks progressing through columns on a kanban board. Originating from the manufacturing industry, kanban utilises a predefined backlog, a prioritised master list of tasks. Work is pulled continuously from the backlog based on the team's capacity and progresses through the columns on the board, each representing a stage of the process towards completion.
The strength of kanban lies in its ability to provide an instant visual overview of the status of each work item. It can be applied to various areas such as project management, content marketing processes, or even hiring and recruitment. By visualising the workflow, potential bottlenecks can be quickly identified and addressed.
In agile project management, it is common to impose work in progress (WIP) limits, which restrict the number of tasks in progress at any given time. This ensures that teams can work more effectively by focusing on individual tasks without spreading themselves too thin across multiple tasks simultaneously.
-
Scrumban, a term coined by Corey Ladas in 2008, is a project management framework that combines elements of scrum and kanban methodologies. It aims to enhance team agility, efficiency, and productivity by integrating the structured routines of scrum with the flexible nature of kanban.
One of the main advantages of the scrumban framework is its emphasis on continuous workflow. Unlike traditional scrum, where tasks are selected at the start of each sprint, scrumban allows teams to pull tasks from the backlog based on their capacity, similar to kanban's approach. This approach enables teams to maintain a constant workflow while incorporating essential project planning, review, and retrospective activities as necessary.
Primary certification bodies
CAPM: Certified Associate in Project Management
PMP: Project Management Professional
PfMP: Portfolio Management Professional
PgMP: Program Management Professional
+ a variety of other certification routes i.e. Programme Management, Agile
PRINCE2 Foundation
PRINCE2 Practitioner
+ a variety of other certification routes i.e. Agile