IICTP Bloghttps://iictp.org/Technical practice explained, and how IICTP compares with project management credentials. Each item is the full content of one page of the International Insignia of Certified Technical Practitioners website.en© IICTP. All rights reserved. Use is governed by https://iictp.org/termsIICTP site build (scripts/feeds.mjs)https://www.rssboard.org/rss-specification1440Wed, 21 Oct 2026 18:53:58 GMThttps://iictp.org/favicon.svgIICTP Bloghttps://iictp.org/IICTP Blog: Technical Practice, Explainedhttps://iictp.org/bloghttps://iictp.org/blogWed, 21 Oct 2026 18:53:58 GMTBlogIICTPPlain-language writing on the knowledge behind the IICTP credentials, and on how they compare with project management credentials. Every claim names its source.

The IICTP blog

Technical practice, explained.

Plain-language writing on the knowledge behind the IICTP credentials, and on how they compare with project management credentials. Every claim names its source.

Latest writing

Eight posts to start.

Five on the domains of the TPBOK, the body of knowledge behind every IICTP exam, and three on how IICTP and PMI differ. PMI facts are sourced and dated.

IICTP vs PMIvs
Featured · IICTP and PMI

IICTP and PMI: two credentials for two different jobs

People often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions y…

21 October 20267 min readRead the post
Domain 101
TPBOK domains

Architecture decisions are the ones that are expensive to undo

Most engineering choices can be reversed in an afternoon. A few cannot: how a system is divided, where its data lives, and which parts must agree wit…

21 October 20266 min
Domain 202
TPBOK domains

Speed and stability are not a trade-off: the case for small batches

Many teams believe they must choose between shipping fast and shipping safely. The research behind the second TPBOK domain, Engineering Governance &…

21 October 20266 min
Domain 303
TPBOK domains

Applied AI: use it where it helps, and verify what it produces

The third TPBOK domain, Applied AI & Emerging Tech Integration, is not about knowing the newest model. It is about a durable skill: deciding where a…

21 October 20266 min
Domain 404
TPBOK domains

Infrastructure and security: design for the failure you will have

Systems fail, and credentials leak, and people make mistakes. The fourth TPBOK domain, Infrastructure & Security, starts from that fact. The goal is…

21 October 20266 min
Domain 505
TPBOK domains

People leadership in engineering: structure shapes behaviour

The fifth TPBOK domain, People Leadership in Engineering, can sound soft. It is not. It covers how team structure, incentives and learning habits dec…

21 October 20266 min
PMP vs CTPvs
IICTP and PMI

PMP and CTP side by side: exam, eligibility and what you prepare for

The PMP is PMI’s best-known credential and the CTP is IICTP’s flagship. They serve different jobs, but people want to know how the exams and entry re…

21 October 20266 min
Which first?
IICTP and PMI

PMI or IICTP: which should you take first?

If you are weighing a PMI credential against an IICTP one, start with the work you actually do. Both are respectable; they point at different jobs. T…

21 October 20266 min

Prefer a feed reader? Subscribe to the blog RSS feed.

Where do you stand?

Find the credential that fits the work you do.

]]>Architecture and Systems Design: Decisions That Are Expensive to Undohttps://iictp.org/blog/architecture-decisions-expensive-to-undohttps://iictp.org/blog/architecture-decisions-expensive-to-undoWed, 21 Oct 2026 09:00:00 GMTBlogIICTPMost engineering choices can be reversed in an afternoon. A few cannot: how a system is divided, where its data lives, and which parts must agree with each other in real time. This is the first of five TPBOK domains, Architecture & Systems Design, and it is about making those choices well.

Blog / TPBOK domains

Domain 121 October 20266 min read

Architecture decisions are the ones that are expensive to undo

Most engineering choices can be reversed in an afternoon. A few cannot: how a system is divided, where its data lives, and which parts must agree with each other in real time. This is the first of five TPBOK domains, Architecture & Systems Design, and it is about making those choices well.

In this post
  1. Hide the decisions most likely to change
  2. Separate essential complexity from accidental complexity
  3. Your system will look like your organisation
  4. Distributed systems force trade-offs you cannot avoid
  5. A short checklist before you split a system
  6. How this appears in IICTP exams
  7. Sources and further reading

Hide the decisions most likely to change

In 1972 David Parnas argued that the way to divide a system into modules is not by the steps of a process but by the design decisions each module hides. If a decision is likely to change, such as a data format or a vendor, only one module should know about it. When that decision changes, one module changes, not forty.

This is still the best test of a boundary. Ask of any proposed split: what is hidden behind it, and how likely is that thing to change?

Separate essential complexity from accidental complexity

Fred Brooks, in “No Silver Bullet”, separated the difficulty that comes from the problem itself (essential) from the difficulty we add through our tools and choices (accidental). Better tools can remove accidental complexity. Nothing removes the essential kind, so a practitioner’s job is to avoid adding to it. A design that needs three services, two queues and a cache to do what one function could do has added accidental complexity.

Your system will look like your organisation

Melvin Conway observed in 1968 that organisations design systems that mirror their own communication structure. If three teams must agree on every change, you will end up with three tightly bound components. Practitioners use this deliberately: change the team boundaries first if you want different system boundaries.

Distributed systems force trade-offs you cannot avoid

When a network can fail, a system cannot be both fully consistent and fully available. Eric Brewer put this forward as a conjecture, and Seth Gilbert and Nancy Lynch proved a formal version in 2002. The practical lesson is not to memorise the theorem. It is to decide, per feature, which you would rather give up under failure, and to say so in writing.

A short checklist before you split a system

  1. What decision does this boundary hide, and how likely is it to change?
  2. Which team owns each side, and can they release independently?
  3. What happens to each side when the other is down?
  4. What will it cost to run, monitor and debug as two things instead of one?
  5. How would we undo this in a year if we were wrong?

How this appears in IICTP exams

Architecture & Systems Design carries 30% of the CTP exam and 24% of the ATP exam. The ATP asks whether you can read a baseline architecture and see how its parts depend on each other. The CTP gives scenarios, such as whether and how to split a system under load, and asks for the best decision, not a perfect one. See the exam facts for every credential’s share.

Record your decisions as you make them. A short written note, with the options you rejected, is worth more than a diagram nobody updates.

Sources and further reading

  1. Brooks, F. P. (1987). “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer 20(4).
  2. Conway, M. E. (1968). “How Do Committees Invent?” Datamation 14(4).
  3. Evans, E. (2003). Domain-Driven Design. Addison-Wesley.
  4. Gilbert, S. and Lynch, N. (2002). “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services.” ACM SIGACT News 33(2).
  5. Nygard, M. (2011). “Documenting Architecture Decisions.” Cognitect blog.
  6. Parnas, D. L. (1972). “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15(12).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Engineering Governance and Agile Delivery: Speed and Stability Togetherhttps://iictp.org/blog/speed-and-stability-engineering-governancehttps://iictp.org/blog/speed-and-stability-engineering-governanceWed, 21 Oct 2026 09:00:00 GMTBlogIICTPMany teams believe they must choose between shipping fast and shipping safely. The research behind the second TPBOK domain, Engineering Governance & Agile Delivery, points the other way: the practices that make delivery fast, mainly small changes and automated checks, are the same ones that make it

Blog / TPBOK domains

Domain 221 October 20266 min read

Speed and stability are not a trade-off: the case for small batches

Many teams believe they must choose between shipping fast and shipping safely. The research behind the second TPBOK domain, Engineering Governance & Agile Delivery, points the other way: the practices that make delivery fast, mainly small changes and automated checks, are the same ones that make it stable.

In this post
  1. The four measures that matter
  2. Why small batches work
  3. Waterfall was never the plan
  4. Define “done” so a reviewer can check it
  5. Anti-patterns
  6. What to do on Monday
  7. Sources and further reading

The four measures that matter

The DORA research programme, summarised by Nicole Forsgren, Jez Humble and Gene Kim in Accelerate (2018), found that delivery performance can be described by four measures: how often you deploy, how long a change takes from commit to production (lead time), how often a change fails, and how quickly you recover when one does. The first two measure speed. The last two measure stability. In their data, the same teams tended to do well on both.

  • Deployment frequency. How often you release to production.
  • Lead time for changes. From code committed to code running.
  • Change failure rate. The share of changes that cause a failure needing a fix.
  • Time to restore service. How long recovery takes.

Why small batches work

A large change is hard to review, hard to test and hard to undo. When it fails, you do not know which part failed. A small change fails in a way you can see and fix quickly. There is also arithmetic behind this. Little’s Law, proved by John Little in 1961, says that the average time work spends in a system equals the amount of work in progress divided by the rate at which it finishes.

Waterfall was never the plan

Winston Royce’s 1970 paper is often cited as the origin of the strict sequential “waterfall”. Read it and you find the opposite: he warned that a single sequential pass is risky and recommended building a pilot first so the hard problems appear early. The lesson is to find risk early, not to follow phases in order.

Define “done” so a reviewer can check it

A good quality bar is binary. Tests pass, the change is reviewed, security checks have run, the feature can be switched off. If “done” depends on someone’s feeling, it will drift under pressure. Automating the bar, in a pipeline that blocks release when a check fails, replaces a meeting with a rule.

Anti-patterns

  • Water-Scrum-Fall. Sprints in the middle, but requirements are fixed up front and release is a separate big event at the end.
  • Velocity inflation. Points are used to compare teams, so they inflate, and the number stops meaning anything.
  • Long-lived branches. Integration is deferred until it hurts.

What to do on Monday

  1. Measure your lead time for the last 20 changes. Do not guess.
  2. Limit work in progress so that finishing matters more than starting.
  3. Pick one manual gate and automate it.

Engineering Governance & Agile Delivery is 28% of the ATP exam and 24% of the CTP exam. The specialist Agile Delivery Practitioner (ADP) goes deepest. See exam facts.

Sources and further reading

  1. Forsgren, N., Humble, J. and Kim, G. (2018). Accelerate. IT Revolution Press.
  2. Humble, J. and Farley, D. (2010). Continuous Delivery. Addison-Wesley.
  3. Little, J. D. C. (1961). “A Proof for the Queuing Formula: L = λW.” Operations Research 9(3).
  4. Royce, W. W. (1970). “Managing the Development of Large Software Systems.” Proceedings of IEEE WESCON.
  5. Takeuchi, H. and Nonaka, I. (1986). “The New New Product Development Game.” Harvard Business Review 64(1).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Applied AI and Emerging Tech Integration: A Practitioner’s Viewhttps://iictp.org/blog/applied-ai-verify-what-the-machine-produceshttps://iictp.org/blog/applied-ai-verify-what-the-machine-producesWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe third TPBOK domain, Applied AI & Emerging Tech Integration, is not about knowing the newest model. It is about a durable skill: deciding where a probabilistic tool belongs in a system that must behave predictably, and how to check its output before anyone relies on it.

Blog / TPBOK domains

Domain 321 October 20266 min read

Applied AI: use it where it helps, and verify what it produces

The third TPBOK domain, Applied AI & Emerging Tech Integration, is not about knowing the newest model. It is about a durable skill: deciding where a probabilistic tool belongs in a system that must behave predictably, and how to check its output before anyone relies on it.

In this post
  1. The core problem: output is probable, not guaranteed
  2. Where to start: low-risk, reversible, checkable
  3. Checks that belong before anything merges
  4. Designing systems that include a model
  5. Follow the published frameworks
  6. Sources and further reading

The core problem: output is probable, not guaranteed

A traditional function returns the same answer for the same input. A language model returns a likely answer. That is useful, and it means the cost of verification moves to the user. Brooks’s point that the hard part of software is its essential complexity applies here too: AI can draft code quickly, but someone still has to decide whether the code is right.

Where to start: low-risk, reversible, checkable

A practitioner’s first question is not “can AI do this?” but “what happens if it is wrong, and how will we know?” Good first uses have three properties: a mistake is cheap, a mistake is visible, and a person or a test can check the result.

  • Drafting tests, documentation or boilerplate that a reviewer will read.
  • Searching and summarising internal material, with sources shown.
  • Suggesting changes in a pull request that still needs human approval.

Checks that belong before anything merges

  • Automated tests that fail when behaviour changes, so generated code is held to the same bar as human code.
  • Human review of anything touching security, money or personal data.
  • Secrets and personal data kept out of prompts and out of generated code.
  • A record of which output came from a tool, so problems can be traced.

Designing systems that include a model

When a product calls a model, treat it as an unreliable component. Retrieval-augmented generation, introduced by Patrick Lewis and colleagues in 2020, grounds answers in documents you control. It helps, but it adds its own parts that can fail: how documents are split, how they are ranked, and whether the answer is faithful to the source. Test each part. Measure answers against a fixed set of questions so you can see whether a change made things better or worse.

  • Cost and rate limits. Put limits and fallbacks around every call.
  • Data privacy. Decide what may leave your boundary before you integrate.
  • Observability. Log inputs, outputs and decisions so you can investigate an odd answer.

Follow the published frameworks

You do not have to invent your own risk language. The NIST AI Risk Management Framework and the OWASP list of risks for applications built on language models are public, maintained, and a good starting vocabulary. For evidence on how AI changes delivery performance, read the latest DORA reports directly rather than relying on summaries.

Applied AI & Emerging Tech Integration is 16% of the ATP exam and 18% of the CTP exam, and the largest share (36%) of the specialist AI Practitioner (AIP) exam. See exam facts.

Sources and further reading

  1. Brooks, F. P. (1987). “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer 20(4).
  2. Lewis, P. et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” Advances in Neural Information Processing Systems 33.
  3. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1.
  4. OWASP Foundation. OWASP Top 10 for Large Language Model Applications.
  5. DORA (Google Cloud). Accelerate State of DevOps reports, published annually.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Infrastructure and Security: Designing for Failurehttps://iictp.org/blog/design-for-the-failure-you-will-havehttps://iictp.org/blog/design-for-the-failure-you-will-haveWed, 21 Oct 2026 09:00:00 GMTBlogIICTPSystems fail, and credentials leak, and people make mistakes. The fourth TPBOK domain, Infrastructure & Security, starts from that fact. The goal is not a system that never breaks, but one where a break is small, visible and quick to recover from.

Blog / TPBOK domains

Domain 421 October 20266 min read

Infrastructure and security: design for the failure you will have

Systems fail, and credentials leak, and people make mistakes. The fourth TPBOK domain, Infrastructure & Security, starts from that fact. The goal is not a system that never breaks, but one where a break is small, visible and quick to recover from.

In this post
  1. Old principles, still the right ones
  2. Limit the blast radius
  3. Measure reliability and spend it deliberately
  4. You cannot fix what you cannot see
  5. Practise recovery before you need it
  6. After the incident
  7. Sources and further reading

Old principles, still the right ones

In 1975 Jerome Saltzer and Michael Schroeder set out design principles for protecting information. Most of them still read as practical advice today.

  • Least privilege. Give every person and program only the access it needs.
  • Fail-safe defaults. Access is denied unless explicitly granted.
  • Complete mediation. Check every access, every time.
  • Economy of mechanism. Simpler designs are easier to verify.
  • Open design. Security should not depend on the design being secret.
  • Separation of privilege. Sensitive actions need more than one condition.

Zero trust, now described in NIST SP 800-207, is these ideas applied to modern networks: do not trust a request because of where it comes from, verify it.

Limit the blast radius

Assume something will go wrong and decide in advance how far the damage can spread. Separate environments, narrow credentials that expire, and isolated components mean one failure stays one failure. Infrastructure defined as code and kept in version control makes environments reproducible, so you can rebuild instead of repair.

Measure reliability and spend it deliberately

The Site Reliability Engineering practice from Google describes service level objectives, a target for how reliable a service should be, and the error budget, the amount of unreliability you can afford before you stop shipping new features. It turns an argument about risk into a number both product and engineering can see.

You cannot fix what you cannot see

Observability rests on three kinds of signal: metrics that show trends, logs that record events, and traces that follow a request across services. Together they let you ask a question you did not plan for when an incident starts.

Practise recovery before you need it

  • Write down how much data you can afford to lose (recovery point objective) and how long you can be down (recovery time objective).
  • Test restores from backup. A backup you have never restored is a hope.
  • Run a game day: break something in a safe environment and watch how the team responds.

After the incident

Hold a review that asks what in the system made the mistake easy, not who made it. Record what you will change, assign an owner, and follow up.

Infrastructure & Security is 20% of the ATP exam and 18% of the CTP exam. The specialist Cloud Architecture Practitioner (CAP) and IoT and Embedded Systems (IESP) exams give it 34% and 30%. See exam facts.

Sources and further reading

  1. Beyer, B., Jones, C., Petoff, J. and Murphy, N. R. (eds.) (2016). Site Reliability Engineering. O’Reilly Media.
  2. Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207.
  3. Saltzer, J. H. and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE 63(9).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>People Leadership in Engineering: How Structure Shapes Behaviourhttps://iictp.org/blog/structure-shapes-behaviour-engineering-leadershiphttps://iictp.org/blog/structure-shapes-behaviour-engineering-leadershipWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe fifth TPBOK domain, People Leadership in Engineering, can sound soft. It is not. It covers how team structure, incentives and learning habits decide whether good engineers produce good systems. Most of its ideas come from research, not opinion.

Blog / TPBOK domains

Domain 521 October 20266 min read

People leadership in engineering: structure shapes behaviour

The fifth TPBOK domain, People Leadership in Engineering, can sound soft. It is not. It covers how team structure, incentives and learning habits decide whether good engineers produce good systems. Most of its ideas come from research, not opinion.

In this post
  1. Look at the system before the person
  2. Cognitive load is a real constraint
  3. Structure comes first, and it shows up in the code
  4. Find the constraint
  5. Safety is how teams learn
  6. How to run a blameless review
  7. Sources and further reading

Look at the system before the person

W. Edwards Deming argued that most failures come from the way work is organised, not from the people doing it. His often-cited estimate puts the large majority of problems on the system and management, and a small remainder on individual causes. You do not need the exact figure to use the idea: when the same mistake keeps happening to different people, the system is the thing to change.

Cognitive load is a real constraint

A team can only hold so much in its head. Matthew Skelton and Manuel Pais, in Team Topologies, treat cognitive load as the limit that decides how much a team can own well. Their answer is to design teams around the work: teams that own a flow of value end to end, platform teams that make that easier, and enabling teams that help others learn. If a team owns too many things, quality drops, however good the people are.

Structure comes first, and it shows up in the code

Conway’s observation that systems mirror the communication structure of the organisation that builds them is a leadership tool. If two teams keep blocking each other, look at ownership and boundaries before blaming individuals. Moving a boundary can remove a recurring conflict that no amount of coaching would.

Find the constraint

Eliyahu Goldratt’s Theory of Constraints says a system’s output is limited by its slowest step. Improving anything else does not help. In engineering the constraint is often review, testing, release approval or a single overloaded expert. Map the flow of work, find where it waits, and fix that first.

Safety is how teams learn

Amy Edmondson’s 1999 study of work teams found that psychological safety, the belief that you will not be punished for speaking up, was linked to how much teams learned from their mistakes. Ron Westrum described a spectrum of organisational cultures, from pathological to generative, and the DORA research has linked generative, high-trust cultures to better delivery performance. In practice this means treating incidents as information.

How to run a blameless review

  1. Write the timeline from what people knew at the time, not from what we know now.
  2. Ask how the system made the mistake easy, and what would have made it hard.
  3. List changes, each with an owner and a date.
  4. Share the write-up widely, so other teams can learn from it.
  5. Check back that the changes happened.

People Leadership in Engineering is 12% of the ATP exam and 10% of the CTP exam, and 15 to 20% of the PgTP and PfTP exams, where leaders work across teams. See exam facts.

Sources and further reading

  1. Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study.
  2. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44(2).
  3. Goldratt, E. M. and Cox, J. (1984). The Goal. North River Press.
  4. Skelton, M. and Pais, M. (2019). Team Topologies. IT Revolution Press.
  5. Westrum, R. (2004). “A Typology of Organisational Cultures.” Quality and Safety in Health Care 13(Suppl 2).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>IICTP vs PMI: What Each Credential Is Actually Forhttps://iictp.org/blog/iictp-and-pmi-two-credentials-two-jobshttps://iictp.org/blog/iictp-and-pmi-two-credentials-two-jobsWed, 21 Oct 2026 09:00:00 GMTBlogIICTPPeople often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions your job asks you to make. Here is a fair look at both, including where

Blog / IICTP and PMI

IICTP vs PMI21 October 20267 min read

IICTP and PMI: two credentials for two different jobs

People often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions your job asks you to make. Here is a fair look at both, including where PMI is clearly ahead.

In this post
  1. What PMI certifies
  2. What IICTP certifies
  3. Side by side
  4. Where PMI is ahead
  5. Where IICTP’s approach fits technical people better
  6. You may want both
  7. Sources and further reading

What PMI certifies

The Project Management Institute is a long-established body for project management. On its certifications page (read 20 October 2026) it lists four core credentials, CAPM, PMP, PgMP and PfMP, and a set of specialised ones, including PMI-ACP for agile, PMI-RMP for risk, PMI-PBA for business analysis, PMI-SP for scheduling, PMI-PMOCP for project management offices, PMI-CP for construction, CSPP for sustainability and PMI-CPMAI for managing AI projects. PMI says it has 1.7 million or more certification holders worldwide and has led the field since 1969.

PMI describes the PMP as demonstrating the ability to lead projects without being tied to any one methodology, industry or geography. That is a credential about running projects: people, processes and business priorities.

What IICTP certifies

IICTP certifies technical practice, meaning the decisions engineers and technical leaders make about systems. Its body of knowledge, the TPBOK, has five domains: Architecture & Systems Design; Engineering Governance & Agile Delivery; Applied AI & Emerging Tech Integration; Infrastructure & Security; and People Leadership in Engineering. There are ten credentials, from the entry-level ATP and the flagship CTP to program and portfolio levels and six specialist credentials.

Side by side

PMIIICTP
Main subjectManaging projects, programs and portfoliosTechnical decisions: architecture, delivery, AI, infrastructure, security, engineering leadership
The question it answersWill this work be delivered within scope, time and budget?What is the best technical decision here, and who does it affect?
Typical holderProject managers, program managers, PMO staff, and others who manage deliveryDevelopers, tech leads, engineering managers, architects, technical program managers
Exam contentProject management knowledge across people, process and business environment (per the PMP page)Scenario-based technical judgement across the five TPBOK domains
Track recordSince 1969, with 1.7M+ holders (PMI’s figures)New in 2026; no holders yet
PMI column from pmi.org, read 20 October 2026. IICTP column from iictp.org.

Where PMI is ahead

PMI is established and widely recognised. It has decades of history, a very large community and chapter network, a mature continuing-education system and an extensive training-partner network. PMI also states that its PMI-ACP exam is ISO-accredited. IICTP is a new independent credential and is not ISO/IEC 17024 accredited, and we do not claim otherwise. If an employer specifically asks for a PMP, an IICTP credential will not substitute for it.

Where IICTP’s approach fits technical people better

  • It tests the decisions technical people make. A project management credential, by design, does not ask whether you can choose between two architectures, contain a failing dependency or set guardrails for AI-generated code. IICTP exams do.
  • Scenario-based, not recall-based. CTP candidates face 150 scenario questions in 180 minutes and are asked for the best decision, not a memorised definition.
  • The exam is described in the open. Questions, time, pass mark and the share of questions per domain are published for all ten credentials on the exam facts page, with a blueprint PDF for each.
  • Vendor-neutral. Nothing in the TPBOK depends on one cloud, tool or framework.
  • Renewal tied to technical growth. Credentials renew through Technical Development Units earned from learning and from giving back, such as mentoring and open source. See how renewal works.

You may want both

A tech lead who also runs delivery might reasonably hold a project management credential and a technical one. They answer different questions. The decision guide in our third post in this series maps common roles to the credential that fits.

Sources and further reading

  1. Project Management Institute. “Project Management & Specialized Certifications.” pmi.org/certifications. Read 20 October 2026.
  2. Project Management Institute. “Project Management Professional (PMP)® Certification.” pmi.org/certifications/project-management-pmp. Read 20 October 2026.
  3. Project Management Institute. “PMI Agile Certified Practitioner (PMI-ACP)® Certification.” pmi.org/certifications/agile-acp. Read 20 October 2026.
  4. IICTP. Exam facts and eligibility. iictp.org/certifications/exam-facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>PMP vs CTP: Exam and Eligibility Comparedhttps://iictp.org/blog/pmp-and-ctp-exam-eligibility-side-by-sidehttps://iictp.org/blog/pmp-and-ctp-exam-eligibility-side-by-sideWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe PMP is PMI’s best-known credential and the CTP is IICTP’s flagship. They serve different jobs, but people want to know how the exams and entry requirements compare. This post lays out the published facts, with sources, and says plainly what is not being compared.

Blog / IICTP and PMI

PMP vs CTP21 October 20266 min read

PMP and CTP side by side: exam, eligibility and what you prepare for

The PMP is PMI’s best-known credential and the CTP is IICTP’s flagship. They serve different jobs, but people want to know how the exams and entry requirements compare. This post lays out the published facts, with sources, and says plainly what is not being compared.

In this post
  1. The numbers, from each body’s own pages
  2. What the experience requirements actually ask
  3. What you would study
  4. One rule change worth knowing about
  5. Which is easier?
  6. Sources and further reading

The numbers, from each body’s own pages

PMP (PMI)CTP (IICTP)
Questions180150, scenario-based
Time240 minutes180 minutes
Experience with a bachelor’s degree3 years managing projects36 months of technical leadership
Experience with a high school diploma5 years managing projects60 months of technical leadership
Other routesAssociate’s degree: 4 years. Degree from a PMI Global Accreditation Center program: 2 yearsNone
Required training35 hours of project management trainingNone for the CTP
Pass markNot covered in this comparison70% scaled score; no negative marking
What it coversPeople, processes and business environment (PMI’s description)Five TPBOK domains; Architecture & Systems Design is the largest share at 30%
PMP column from pmi.org/certifications/project-management-pmp, read 20 October 2026. CTP column from iictp.org/certifications/exam-facts.

We have not compared pass marks because we did not capture PMI’s on the pages we read. We would rather leave a cell out than guess it.

What the experience requirements actually ask

Both credentials gate on experience, and both count years rather than titles. The difference is the kind of experience. PMI asks for time spent managing projects in a professional setting, taking responsibility for planning, decisions, delivery and outcomes. IICTP asks for time in technical leadership: owning technical decisions for a team’s systems and delivery. Someone can have years of one and little of the other.

What you would study

For the PMP, PMI points candidates to its Exam Content Outline, which describes three domains: people, process and business environment. For the CTP, the blueprint lists the five TPBOK domains with their share of the exam.

CTP domainShare of questions
Architecture & Systems Design30%
Engineering Governance & Agile Delivery24%
Applied AI & Emerging Tech Integration18%
Infrastructure & Security18%
People Leadership in Engineering10%
From the CTP exam blueprint, version 1.0.

One rule change worth knowing about

PMI’s PMP page states that from 1 December 2026, live instructor-led classes count toward the 35 training hours only if delivered by a PMI Authorized Training Partner, a China Registered Education Provider, or an eligible accredited higher-education program. If you plan to take the PMP, check PMI’s current rules before booking a course.

Which is easier?

That depends on your background, so we will not claim either is. A strong engineer with no project management experience will find the CTP closer to daily work. An experienced project manager with a light technical background will find the PMP closer to theirs. Neither exam rewards memorising a list.

Sources and further reading

  1. Project Management Institute. “Project Management Professional (PMP)® Certification.” pmi.org/certifications/project-management-pmp. Read 20 October 2026.
  2. IICTP. “Exam facts, eligibility and blueprints.” iictp.org/certifications/exam-facts.
  3. IICTP. “CTP® exam blueprint,” version 1.0, 21 October 2026. iictp.org/blueprints/IICTP-CTP-Exam-Blueprint.pdf.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>PMP, PMI-ACP or CTP? Which Certification to Take Firsthttps://iictp.org/blog/pmi-or-iictp-which-to-take-firsthttps://iictp.org/blog/pmi-or-iictp-which-to-take-firstWed, 21 Oct 2026 09:00:00 GMTBlogIICTPIf you are weighing a PMI credential against an IICTP one, start with the work you actually do. Both are respectable; they point at different jobs. This guide maps common roles to the credential that fits, and says when the answer is “both”.

Blog / IICTP and PMI

Which first21 October 20266 min read

PMI or IICTP: which should you take first?

If you are weighing a PMI credential against an IICTP one, start with the work you actually do. Both are respectable; they point at different jobs. This guide maps common roles to the credential that fits, and says when the answer is “both”.

In this post
  1. Start with your daily decisions
  2. A guide by role
  3. When the answer is both
  4. What employers may ask for
  5. Questions to ask yourself
  6. Sources and further reading

Start with your daily decisions

  • If your week is plans, budgets, stakeholders and status, you manage delivery. A project management credential fits.
  • If your week is design reviews, release calls, incident response and mentoring engineers, you make technical decisions. A technical credential fits.
  • If it is a mix, which most tech leads and technical program managers find, you may eventually want both.

A guide by role

If you are…ConsiderWhy
Early career, aiming at project managementPMI CAPMPMI describes it as the foundation for project management skills, with no experience required.
Early career developer or QAIICTP ATPCovers the software life cycle, baseline architecture and delivery fundamentals. 100 questions in 120 minutes; no work experience required.
Managing projects for 3 or more yearsPMI PMPThe established credential for leading projects across industries.
Tech lead or engineering managerIICTP CTPTests system design, trade-offs, technical risk and delivery governance.
Running agile ways of working with teamsPMI-ACP, or IICTP ADPPMI describes PMI-ACP as validating how you engage stakeholders, apply agile approaches and lead teams. ADP focuses on technical agile governance: pipelines, technical debt and release flow.
Leading AI projects as a managerPMI-CPMAIPMI positions it for leading AI projects and driving business impact.
Building and securing AI systemsIICTP AIPCovers applied AI engineering, retrieval systems, edge deployment and safety guardrails.
Leading sustainability in project deliveryPMI CSPPPMI describes it as leading resilient, sustainable projects.
Building greener softwareIICTP CSTPCarbon-aware development, efficient computing and hardware life cycle.
Running a program or portfolio of technical workPMI PgMP / PfMP or IICTP PgTP / PfTPChoose by whether the role is mainly managing programs and portfolios, or governing the technology inside them.
PMI descriptions from pmi.org/certifications, read 20 October 2026. IICTP descriptions from iictp.org.

When the answer is both

A tech lead who has become accountable for a delivery date and a budget is doing two jobs. A project management credential covers the delivery job. A technical credential covers the judgement job. Holding both costs time and fees, so choose based on which gap hurts more today.

What employers may ask for

Some job posts name a specific credential. If a role requires a PMP, take the PMP. If you are applying for engineering leadership roles, there is no single credential that every employer asks for. A public, checkable credential can help you show your judgement, but we will not promise that it gets you a job or a raise. No credential can.

Questions to ask yourself

  1. What decision did I make last month that I am most proud of, and which credential would have tested it?
  2. What is the next role I want, and what do people in it hold today?
  3. Do I need a recognised name for this employer, or evidence of technical depth?
  4. Am I eligible now? Check the eligibility planner for IICTP and PMI’s own requirements for theirs.

To go deeper, see the first post in this series on what each body certifies, and the exam facts for every IICTP credential.

Sources and further reading

  1. Project Management Institute. “Project Management & Specialized Certifications.” pmi.org/certifications. Read 20 October 2026.
  2. Project Management Institute. “Certified Associate in Project Management (CAPM)® Certification.” pmi.org/certifications/certified-associate-capm. Read 20 October 2026.
  3. Project Management Institute. “PMI Agile Certified Practitioner (PMI-ACP)® Certification.” pmi.org/certifications/agile-acp. Read 20 October 2026.
  4. IICTP. Credential pages and exam facts. iictp.org/certifications.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>