Home » Posts tagged 'project management'
Tag Archives: project management
Larger projects are NOT riskier
Is Complexity Theory Right that Bigger Is Riskier? Evidence from Information Technology
Ajazi, Nickelsen, Schmidt, Flyvbjerg & Christodoulou
Overview
Conventional project management wisdom assumes that larger IT projects are inherently more risky because they involve greater complexity, more stakeholders, and stronger interdependencies. This study challenges that assumption using one of the world’s largest empirical datasets of completed IT projects.
The authors analyzed 5,094 IT projects (cost performance) and 831 projects (schedule performance) from 64 countries, covering software development, ERP, BI, cybersecurity, and other IT initiatives. Their conclusion is striking:
Project size is not a reliable predictor of project risk. In fact, the smallest IT projects exhibit the highest cost risk, while schedule risk shows no consistent increase with project size.
Research Objectives
The study tested two widely accepted hypotheses:
- H1: Larger IT projects experience greater cost overruns.
- H2: Larger IT projects experience greater schedule overruns.
Project size was measured by the approved project budget at the Final Investment Decision (FID), while project risk was measured by:
- Cost overrun (Actual Cost / Estimated Cost)
- Schedule overrun (Actual Duration / Planned Duration)
Key Findings
1. Smaller Projects Are Not Safer
Contrary to conventional belief, very small projects demonstrate the highest average cost overruns.
| Project Size | Average Cost Overrun |
|---|---|
| Very Small | 192% |
| Small | 53% |
| Medium | 42% |
| Large | 42% |
| Very Large | 57% |
The statistical analysis found no evidence that increasing project size leads to higher cost risk. Instead, the smallest projects performed significantly worse than all other groups.
2. Schedule Overruns Do Not Increase with Project Size
The analysis of schedule performance also rejected the traditional assumption that larger projects are more likely to finish late.
| Project Size | Average Schedule Overrun | Projects with >50% Delay |
|---|---|---|
| Very Small | 37% | 20.4% |
| Small | 30% | 21.7% |
| Medium | 75% | 43.4% |
| Large | 67% | 44.0% |
| Very Large | 26% | 33.1% |
Although medium and large projects showed higher average delays, statistical testing found no consistent upward trend between project size and schedule risk. Very large projects actually demonstrated the lowest average schedule overrun.
3. IT Project Risk Has “Fat Tails”
A major contribution of the paper is confirming that IT project overruns follow fat-tailed (power-law) distributions.
This means that:
- extreme overruns are not rare exceptions;
- catastrophic outcomes occur much more frequently than predicted by traditional risk models;
- conventional approaches based on normal distributions systematically underestimate project risk.
Importantly, this characteristic applies to projects of every size, although it is strongest among the smallest projects.
Why Are Small Projects More Risky?
The authors suggest several explanations:
- Small projects often receive less executive attention and governance.
- Organizations frequently assign less experienced teams to smaller initiatives.
- Risk management processes are typically less rigorous for projects below predefined budget thresholds.
- Cognitive biases (such as the Dunning–Kruger Effect and Uniqueness Bias) contribute to underestimating project complexity and organizational capability.
Practical Implications
The findings challenge several common project management practices:
- Budget should not be used as the primary indicator of project risk.
- Small IT projects require the same level of governance and risk assessment as larger initiatives.
- Organizations should evaluate project risk based on team capability, organizational maturity, technical complexity, and uncertainty, rather than project size alone.
- Risk management frameworks should explicitly account for fat-tailed risks, recognizing that extreme overruns are an inherent characteristic of IT projects rather than statistical anomalies.
Conclusions
The study fundamentally challenges the long-standing assumption that “bigger means riskier” in IT project management. Instead, it demonstrates that all IT projects carry substantial risk, while small projects are often the most vulnerable to severe cost overruns.
For practitioners, the key lesson is clear: project governance should be driven by risk characteristics rather than budget size. Organizations that automatically devote greater oversight only to large projects may inadvertently overlook the projects most likely to fail.
Original article
Practical AI implementation in Project management
Practice in AI implementation in project management activities. Learn now!
Only 3 days till 26th February! Learn by doing for $9.99 only – AI assistants and agents for each project stage – from Initiation till Clodure.
More than 10 practical cases with demo following your own practical activities.
PMI updates its flagship products
Project management institute (PMI) issued PMBO 8th edition (Our overview and analysis coming soon)
PMP certification exam will be updated since July, 2026. Content outline is published.
Main updates and topics are
- Future-forward topics, like AI, sustainability and valueWe’ve incorporated emerging topics to keep exam content current.
- Adaptive approaches that reflect how teams work todayAgile and hybrid methods will be emphasized over predictive approaches.
- Defining project success through outcomes and impactValue delivery will be emphasized over scope, schedule or cost.
- Inclusive, globally aligned eligibilityApprenticeships and vocational education will be recognized.
Ethix Code is updated as well.
And PMI’s AI assistant Infinity is updated –
The next iteration of AI that speaks project management, now available on PMI.org and the PMI Official mobile app.
CPMAI – A Methodology for AI projects development by PMI
PMI has released its AI project management methodology — Cognitive Project Management for AI
The first question is why?
Traditional project management and application development methodologies do not fully address the
complexity of AI projects. AI solutions are data-driven, not just software-driven, which requires a
systematic approach that ensures:
● Alignment with business objectives and ROI
● Proper data preparation and management
● Robust model evaluation and operationalization
● Iterative development to adapt to changing data and needs
CPMAI is data-centric and based on an iterative approach.
The methodology provides 7 patterns —
Conversational and human interaction
Recognition
Patterns and anomalies
Predictive analytics and decision support
Hyperpersonalization
Autonomous systems
Goal-driven systems
The methodology includes 6 main phases
Business understanding
Data understanding
Data preparation
Model development
Model assessment
Transfer to operational use
In the presented methodology, a separate section is devoted to the issues of trust in AI, and embedding trust in each phase of the project. (Note: For those interested in issues of trust and ethics in the development of AI systems, I refer to my presentations — 1 and 2)
Key roles in AI projects
Project Manager/AI Project Lead: oversees the entire AI initiative, ensuring its compliance with the CPMAI stages. Project Manager: Provides leadership support to the AI project, allocates resources, and helps align the AI initiative with the broader organizational strategy. This role coordinates timelines, manages risks, engages with stakeholders, and ensures the project aligns with business goals.
● Data Engineer: Creates the data pipelines and architecture that power the AI systems. They
perform tasks such as data ingestion, integration, cleansing, transformation, and ensure the reliability, scalability, and security of data flows, which is critical to smooth model development and deployment.
● Business Analyst/Subject Matter Expert: Ensures the AI solution aligns with real business goals and domain needs. They help define success criteria, interpret results, and translate AI insights into actionable actions for stakeholders and end users.
● MLOps/DevOps Engineer: Bridges the gap between model development and deployment to production by managing version control, continuous integration/continuous delivery, and ongoing performance monitoring.
● Data Scientist: If an ML model needs to be developed from scratch or requires fine-tuning to extend existing models, organizations may also need a data scientist on the team. This role focuses on building and validating models. The data scientist has expertise in statistics, machine learning algorithms, and model experimentation. They must translate business needs into technical requirements and make modeling decisions accordingly.
AI Soft Skills and Culture
● Critical Thinking and Problem Solving: AI projects are experimental by nature, so
teams must be able to conceptualize approaches, test solutions quickly, and iterate.
● Communication and Storytelling: Stakeholders need clear explanations of complex AI results, whether to justify resource allocation or solve user problems.
● Collaboration and cross-functionality: AI projects span data, engineering, and business domains. Strong teamwork and cross-functional alignment are essential.
● Adaptability and tolerance for uncertainty: As models evolve and data changes, teams must be prepared for iterative cycles and the ability to iterate.
SUMMARY
Use CPMAI’s iterative, data-driven, AI-specific approach
● CPMAI’s six stages: From understanding the business (stage I) to operationalizing the model (stage VI), each stage ensures that the right problems are being addressed, the right data is in place, the AI is being developed responsibly, and that real needs are being met.
● Iterative, data-driven approach: AI projects are not static. They require iterative cycles of data preparation, model refinement, and stakeholder feedback to stay relevant and avoid drift.
● Integration with organizational processes: CPMAI stages effectively complement conventional project management practices (including Agile and DevOps/MLOps),
providing the AI-specific conditions necessary for success.
● Trustworthy AI: Ethical, responsible, and transparent development practices are integral to long-term AI adoption. CPMAI places special emphasis on bias detection, governance, and stakeholder engagement at each stage.
● Team and culture: AI success depends on the right distribution of roles – data engineers, data scientists, analysts, subject matter experts, and project managers – working together using an agile, learn-as-you-go approach.
Project vs Program management
PM vs PgM in a single picture. (c) Gabor, 2025.
Google User Lab Handbook
My graduate MBA student published an extremely helpful playbook for Product teams. Enjoy!
Discussion on PMBOK 8th draft
last month, the PMBOK8 draft was published, and the first comments on it appeared, causing a heated discussion in the professional community.
One of the striking differences is the return of the process model directly to the structure of the PMBOK8 body of knowledge. Let me remind you that in version 7, based on principles, the processes were taken out of the PMBOK itself and placed in a separate material on the website. A serious discussion broke out around this change, which I personally think is excessive, since project management in the modern world is so diverse that it is hardly possible to “drive” all the options into the framework of predefined processes. Therefore, the model of principles (which, by the way, also remain in version 8) seems to me to be quite appropriate.
The number of principles is reduced from 12 in version 7 to 6 in version 8. Let’s see. At the same time, no one is belittling the value of processes as a repetitive activity. The process records the best practices, but at a more local level. So this discussion, in my opinion, is too methodological. Even with the inclusion of processes directly in PMBOK, each enterprise will still adapt the model “for itself”, which has always been the case.
The concept of “Value” is still in the spotlight. However, the focus is shifting to a more practical understanding – Benefits prevail over costs – the classic “scales”.
In the definition of key project characteristics, a very useful concept of a unique context has been introduced, in my opinion. As has been obvious for many years, not every project (or rather most of them) is completely unique, but the conditions for implementation are unique (or different). So this definition is more accurate. In version 8, the division of product and project management roles is developing. In essence, classic analysis (first divide) and synthesis are implemented. As practitioners have been saying for many years (including me, I will be immodest), a project is a way of implementing and developing a product.
The product owner can act as a customer of a project for the creation/development of a product.
It is proposed to remove the chapter “Methods, Models, and Artifacts” from PMBOK 8, which in my opinion will significantly reduce the usefulness of PMBOK itself. Although the authors write in their blogs that this is positive, since the chapter did not fit into the context, but – again in my opinion – the context here is not necessary, this chapter is actually a reference book in version 7, from which you can get the necessary specific information as needed. A step back. Perhaps they will publish it separately, but it is not known yet.
Functional elements have been added to project management – 7 basic functions
- Review and coordination
- Feedback
- Facilitation and support
- Execution of work
- Application of expert skills
- Providing business direction and “inside view”
- Provision of resources
Communications, quality and delivery have been removed from the performance domains. If everything is clear with deliveries, this area has essentially been outside the scope of the project for a long time, and the RP acted as an internal customer, then the removal of communications and quality looks strange.
We look forward to the continuation of the discussion, access to the draft itself can be obtained in reviewer mode (commenting is not required)
Smart Learning 