Entry Criteria
Professionals earn their status through education, training, and adherence to ethical standards as defined by recognised professional associations. For instance, cardiologists complete postgraduate degrees, undergo specialised training, and follow strict codes of conduct to perform heart surgery. Similarly, certified mechanics conduct brake repairs with precision, backed by comprehensive automotive training and ethical accountability. These fields uphold high standards through uniform qualifications and professional integrity.
In contrast, enterprise IT projects lack such rigorous entry criteria, allowing participants to assume professional roles without formal qualifications or training. Despite many charging fees comparable to those of regulated professions, the open market enables entry without verified expertise. This absence of standards compromises project integrity, as unqualified participants deliver substandard outputs, resulting in costly delays and poor outcomes.
Organisations must establish entry criteria, requiring participants to hold role-specific certifications and demonstrate practical experience in enterprise IT projects. Professional associations, such as PMI or IIBA, offer frameworks to uphold expertise and accountability, increasing the chances of participants meeting the demands of complex IT delivery.
Trust Me, I’m a Professional!
Background
Pearly Whites is a group of independent dental practices offering general and specialised services, including complex procedures such as dental implants. These practices apply varying professional standards. In contrast, BrightSmile Dental Hospital enforces strict clinical protocols and requires verified qualifications to uphold consistent, high-quality care.
Risks emerge when generalist dentists within Pearly Whites attempt advanced implant procedures without recognised training. Claimed competence is often unsupported by formal education or supervised experience. This mirrors enterprise IT projects, where participants are placed in specialist roles without validated expertise or structured delivery capability.
Participants
The key participants include:
- Dr. Buck Von-Shivers: A general dentist with 30 years of experience in routine dentistry. He owns a Pearly Whites practice and claims expertise in dental implants based on self-study using online videos. He lacks formal implantology qualifications and accredited training.
- Dr. Ivy Crown: A certified implantologist at BrightSmile Dental Hospital. She holds a postgraduate degree and has completed five years of formal training in complex implant procedures.
- Molly Molar: A patient seeking dental implants, expecting professional standards from the Pearly Whites practice.
Scenario
Dr. Von-Shivers offers dental implants at a 30% discount. He charges $5,250 per implant compared to Dr. Crown’s $7,500 and assures Molly that his general dentistry experience and online research qualify him for the work. He claims implants are similar to routine fillings and require only steady hands and good judgment.
The procedure exposes the risks of:
- Lack of expertise: Dr. Von-Shivers misplaces a metal post near a nerve. Molly experiences severe pain and requires corrective surgery at BrightSmile, costing $15,000. His implant failure rate reaches 50%. Dr. Crown’s failure rate remains below 5% due to rigorous methods and formal training.
- Cost to Pearly Whites practice: Dr. Von-Shivers’ practice faces a $30,000 compensation claim from Molly and others. Negative reviews on health referral networks lead to a 10% drop in bookings.
- Reputational damage: The Pearly Whites brand loses credibility as local clinics withdraw referrals and question its professional standards.
- Impact on Dr. Crown: Dr. Crown spends 15% of her time correcting failed procedures initiated by Dr. Von-Shivers. This delays scheduled surgeries by two weeks and reduces her clinic’s patient capacity. .
Parallel to Enterprise IT Projects
Enterprise IT projects face similar risks. A team of self-taught managers, analysts, developers, and testers is engaged to deliver a critical system implementation. Without formal methods and practical delivery experience, they produce incomplete requirements, defective code, and insufficient test coverage. Project progress is disrupted, and quality is compromised.
In regulated professions, high professional fees reflect formal qualifications and validated capability. While quality is not always guaranteed, entry requires meeting minimum standards. In enterprise IT projects, participants charge comparable professional fees without equivalent scrutiny. Claimed expertise is often based on overstated role titles from prior engagements, perpetuating a cycle of poor delivery outcomes.
Regulated professions apply consequences for malpractice, including revoked licences, legal penalties, or permanent loss of standing. By comparison, enterprise IT project participants operate without a verified baseline capability. There are no enforceable consequences for delivery failure or professional misconduct. Those responsible for poor outcomes often move to the next organisation, continue charging professional rates, and repeat the same behaviours without consequence.
Conclusion
This case study illustrates the risks of participants claiming professional expertise without formal qualification or validated experience. Just as patients must reject general dentists performing specialist procedures, enterprise IT projects must require role-specific certifications, proven delivery experience, and enforceable professional standards.
Competency Standards
Competency standards define the qualifications, skills, and behaviours required for enterprise IT project roles. These standards enable participants to deliver quality outcomes and reduce risks caused by underqualified participants through insufficient expertise, weak decision-making, or poor collaboration. Role-specific competencies align with frameworks from organisations such as PMI and IIBA, supporting integrity, accountability and consistency across projects.
The competency profiles in Tables 22, 23, and 24 outline expected behaviours across project leadership, team leadership, and specialist roles. Each table highlights critical behaviours and the risks associated with underqualification.
Project Leadership Roles
Project leaders set the strategic direction for enterprise IT projects. They manage scope, budgets, and stakeholder expectations across complex deliveries such as system integrations or cloud transitions. Typical roles include project owner, programme director, and project manager.
| Competency Area | Required Behaviours | Risks of Underqualification |
|---|---|---|
| Planning | Define clear delivery plans, including scope, sequencing, and milestones | Produce vague or conceptual plans with undefined dependencies |
| Leadership | Provide consistent direction and earn trust through practical guidance | Lose respect due to inconsistent or reactive behaviour |
| Decision-making | Resolve issues promptly using data and agreed escalation paths | Delay action, ignore risks, or avoid responsibility |
| Stakeholder management | Manage expectations through transparent communication and status tracking | Mislead stakeholders with selective updates or unclear reporting |
| Accountability | Accept delivery responsibility and support corrective actions | Shift blame or avoid accountability when issues arise |
| Team development | Support team capability growth and share credit for success | Claim individual success and withhold development opportunities |
| Resource management | Allocate and adjust resources based on delivery demands | Overcommit or misallocate resources, creating delivery gaps |
| Methodology usage | Apply delivery methods suited to the project context | Misapply methodologies or follow templates without adaptation |
Team Leadership Roles
Team leaders manage delivery for a functional area such as development, testing, or business analysis. They align their team’s outputs with project objectives while managing team capacity and technical risks.
| Competency Area | Required Behaviours | Risks of Underqualification |
|---|---|---|
| Technical expertise | Hold discipline-specific qualifications and delivery experience | Claim expertise without formal credentials or practical exposure |
| Scope control | Manage scope changes and track impacts on budget and effort | Ignore scope creep, causing uncontrolled delivery costs |
| Team leadership | Set direction, manage team workload, and support collaboration | Fail to manage workloads or isolate teams from project goals |
| Communication | Maintain open dialogue across teams and disciplines | Restrict information or create silos |
| Performance management | Provide coaching and address delivery issues constructively | Offer poor guidance or avoid performance concerns |
| Executive alignment | Represent team priorities while working constructively with leadership | Prioritise executive relationships at the expense of team needs |
| Quality management | Support test readiness, defect management, and technical reviews | Avoid quality controls or treat them as secondary tasks |
| Risk awareness | Identify delivery risks early and raise mitigation options | Miss risk indicators or delay escalation until impacts occur |
Specialist Roles
Specialists deliver key outputs such as requirements, code, configurations, or test results. They are expected to apply professional standards and collaborate effectively with other team members. Roles include business analysts, developers, testers, configuration specialists, and data migration leads.
| Competency Area | Required Behaviours | Risks of Underqualification |
|---|---|---|
| Role proficiency | Solve problems within their area of competence | Attempt tasks outside their skillset, introducing delivery risk |
| Practice standards | Apply suitable methods aligned to the project context | Reuse outdated or unsuitable methods without adaptation |
| Collaboration | Share information and work with other teams to meet shared objectives | Work in isolation or compete for credit |
| Accountability | Accept responsibility for quality and completeness of deliverables | Avoid follow-up or pass responsibility for rework to others |
| Continuous learning | Stay informed about tools, standards, and delivery approaches | Rely on outdated knowledge or avoid new practices |
| Testing readiness | Prepare deliverables for validation and support defect resolution | Submit incomplete work or treat testing as a secondary task |
| Configuration control | Use agreed change and version control processes | Introduce uncontrolled changes or work outside configuration tools |
| Documentation | Produce maintainable, clear documentation supporting delivery | Provide insufficient or unclear documentation |
