Tailoring Project Enablers to Enterprise Needs
Organisations invest substantial resources in developing project methodologies and technological tools—collectively known as project enablers. Executives who authorise their adoption mandate compliance, expecting these enablers to resolve persistent delivery issues. They also anticipate measurable performance improvements to validate their endorsement of enablers that claim to guarantee success in enterprise IT projects.
However, a standardised model cannot meet the full range of scope, complexity, and technical demands across different project types. This misalignment often results in the following issues:
- enablers do not meet project-specific needs
- organisations lack defined protocols for consistent use
- project teams do not receive structured training
- teams cannot access support to configure tools for their environment.
Project teams often cite tight deadlines as justification for ignoring mandated tools. They default to ad hoc practices, developing their own methods while the authorised enablers go unused. Executives, perceiving failure, approve new tools and perpetuate a cycle of replacement.
To prevent this, organisations should tailor enablers by:
- matching tools to project attributes such as scale, timeline, and complexity
- establishing protocols for consistent application across initiatives
- providing structured training for team members
- ensuring access to configuration and troubleshooting support
- monitoring adoption and effectiveness using defined performance measures.
By aligning tools with both delivery needs and team capabilities, organisations can optimise project delivery and avoid applying a one-size-fits-all model.
High Cost, Low Value
Enterprise IT projects incur significant costs, with human resource expenditure forming a substantial portion of the budget. This makes participant capability critical to achieving delivery outcomes. However, high cost does not guarantee high performance. In practice, enterprise IT projects often reflect a reality where investment does not correspond to capability or output.
Wingers typically resist process maturity—not because structure is irrelevant, but because they lack the knowledge to apply it. Common phrases include “let us not overthink this” or “let us keep it simple,” used to justify improvised decisions that bypass critical planning and delivery steps.
The following case study illustrates the risks of assigning project roles to wingers.
Winging It, Fixing It
Background
Billy V. Bull is an independent contractor known for his confidence and spontaneous delivery style. He rejects structured delivery methods in favour of intuition and improvised execution. Data Dynamics selects Billy to lead Project Wingback, which involves building a complex data analytics platform within a structured enterprise IT environment.
The Project and the Challenge
Project Wingback operates outside the organisation’s delivery framework. Billy avoids planning, governance, and requirements management. He assumes that rapid delivery comes from immediate action rather than formal documentation. This results in:
- Undefined scope and timelines: Lack of clear project boundaries and schedules causes tasks to extend beyond the planned four-week milestone by six weeks.
- Unclear requirements: Deliverables suffer from poorly defined and ambiguous requirements.
- Reduced morale: Team members experience frustration due to unclear direction and frequent rework.
Approach
Billy’s team does not follow any structured method. They maintain task lists verbally and provide daily status updates without formal artefacts. Stakeholder engagement is reactive. Although six meetings occur, the requirements remain incomplete and lack traceability. Poor communication leads to three significant change requests in the first two months.
Consequences
The client initiates a mid-project health check, which identifies:
- failure to meet delivery milestones
- critical errors in analytics outputs and missing audit documentation
- project confidence score at 40%, triggering escalation.
The client expresses concerns about delivery reliability. Internal stakeholders question whether the project can recover.
Resolution
Data Dynamics appoints Paige Turner, a qualified project manager, to recover the initiative. Paige reinstates the organisation’s delivery standards, including:
- a gated planning structure
- clear documentation practices
- defined roles and responsibilities.
The recovery plan includes:
- Scope and timeline reset: Conduct three working sessions to redefine project scope and establish realistic timelines, ensuring alignment with organisational priorities.
- Requirements quality improvement: Apply structured requirements elicitation and validation techniques to clarify ambiguous requirements and ensure deliverables meet baseline quality standards.
- Team realignment and role clarity: Reassign team members based on skill and role fit, clarifying responsibilities to enhance accountability and reduce rework-related frustration.
The project stabilises within six weeks, and the client provides positive feedback on transparency and responsiveness. All deliverables meet baseline quality expectations, and stakeholder confidence improves to 85%.
Misaligned Hiring Priorities
Overemphasising Tool Proficiency
To justify enterprise tool adoption, hiring managers often prioritise experience with specific enabling technologies. This results in recruitment processes that favour candidates with tool familiarity rather than those with delivery capability. A team member may know how to operate tools like Azure DevOps or Jira but be unable to define a complete and coherent set of requirements.
This focus on tool proficiency produces participants who appear competent in using technology enablers but lack the ability to create quality deliverables.
Overemphasising Process Proficiency
Similarly, organisations aligning to Agile delivery models often prefer candidates fluent in Agile language. Familiarity with stand-ups, retrospectives, and sprints becomes more important than core discipline competencies.
Candidates may eloquently describe ceremonies but are unable to produce outputs. The result is higher delivery risk due to misplaced emphasis on language over substance.
Human Influences on Project Delivery Processes
Participants interpret project delivery based on their knowledge and experience, approaching it through science, applied science, or art.
Rigour from Methodologists
Enterprise IT is a technical discipline. A Bachelor of Science in Information Technology or Software Engineering affirms its scientific basis. This approach promotes rigorous, structured delivery, with:
Science is methodical, precise and planned.
- clear task definitions and mapped dependencies
- adherence to established frameworks and standards
- detailed documentation of all activities
- disciplined execution to minimise rework.
Scientific delivery improves predictability and consistency. However, its rigidity reduces responsiveness in changing environments. Participants without practical experience often apply theoretical methods without adaptation, producing inefficient outcomes.
Utility from Pragmatists
Applied science is methodical, precise and planned, with acceptable tweaks.
Enterprise IT delivery is fundamentally an exercise in applied science. Unlike pure science, applied science adapts to real-world constraints, delivering within fixed time and cost parameters.
Applied science retains method and discipline but introduces practical adjustments. It accepts that while theory informs delivery, execution requires flexibility. In this approach:
- standard practices are maintained
- minor deviations accommodate project-specific issues
- decisions balance theory with feasibility.
Teams that combine theoretical knowledge with enterprise experience operate in what is effectively a creative science. These participants understand the rules well enough to know when and how to adapt them.
Artistry from Improvisers
When delivery ignores scientific methods, project execution becomes artistic. Participants substitute structured delivery with improvisation. They rely on anecdotal experience, past habits, and internet searches instead of established practices.
Art is non-methodical, flexible and unplanned
Here, a Bachelor of Science in Software Engineering morphs into a satirical Bachelor of Arts in Software Cutting Corners.
This leads to:
- vague or absent schedules
- unclear scope and responsibilities
- arbitrary decisions and weak documentation
- poor traceability and lack of outcome reliability
- shifting roles and responsibilities
- endless meetings debating what needs to be done.
Projects executed as art projects fail to meet quality, time, and cost targets.
Table 3 compares key project aspects across science, applied science, and art lenses to illustrate impacts on delivery.
| Aspect | Science | Applied science | Art |
|---|---|---|---|
| Schedule | Detailed tasks with strict timelines | Detailed tasks with critical path flexibility | High-level tasks, no firm deadlines |
| Scope | Fixed and defined | Defined and prioritised | Vague and undefined |
| Roles and responsibilities | Clear, expertise-specific, accountable | Clear, collaborative, accountable | Fluid, uninformed, unaccountable |
| Decision-making | Evidence-based, methodical | Evidence-based, feasibility-adjusted | Subjective, experience-driven |
| Deliverables | Model-prescribed documents | Model-prescribed with practical adjustments | Meeting notes and emails |
| Final product | Technically superior | Functional and user-focused | Minimal, workaround-heavy |
| Effectiveness | Medium—rigid in dynamic settings | High—adaptable and reliable | Low—unpredictable and error-prone |
Participants in Misplaced Project Leadership Roles
Enterprise IT projects face significant delivery challenges resulting from human factors, including misaligned enablers, overemphasis on tool use, and unqualified participants relying on intuition. Poor project leadership often amplifies these issues through weak judgment and uninformed decisions, dragging the entire project down. These conditions increase execution risk and reduce delivery reliability.
- Underqualified project leaders: Many individuals assume leadership roles based on tenure or successive role changes rather than verified capability. Without recognised qualifications or proven delivery competence, they apply personal preferences and trial-and-error methods. Teams adopt these unstructured practices and carry them forward into future projects, weakening standardisation and consistency.
- Decision-making for delivery: Project outcomes are compromised when leaders apply standards too rigidly or ignore them entirely. Effective leadership depends on accurate assessment of project context—knowing when strict protocols are necessary and when adjustment is required to meet technical and operational needs.
- Resistance to delivery discipline: Some leaders avoid structured methods because they do not understand how to apply them. Instead of seeking support or clarification, they rely on informal approaches that may appear efficient but introduce hidden risks and inconsistencies.
- Team capability: In the absence of strong leadership, teams experience repeated rework, ineffective tool usage, and low morale. Competent leaders assign clear responsibilities, align work to objectives, and maintain progress through structured oversight and support.
Strengthening leadership capability through qualification, delivery discipline, and contextual judgement reduces the risk of avoidable failure. Projects benefit when leadership is informed, structured, and aligned with enterprise delivery expectations.
Reviving Project Zombie’s Leadership
Background
Digital Data, a software development firm, launches Project Zombie to replace a client’s legacy data management system. The $4 million engagement involves complex integrations and is scheduled for completion within 12 months. However, by the halfway point, poor leadership and a lack of delivery discipline place the project at risk.
The Challenges
Project Zombie is led by Tim Elder, a long-serving delivery lead with 15 years of experience in smaller-scale system enhancements. He has no formal project management credentials, and he enforces the use of frameworks and tools without considering whether they are fit for purpose.
By month six:
- 70% of project milestones are missed
- rework costs exceed $500,000
- team members are unclear about roles, which affects morale and coordination.
Client deliverables are delayed by three months, prompting concern about the project's viability.
Addressing the Issues
Digital Data replaces Tim with Howie Dewitt, a PRINCE2-certified project manager with ten years of structured delivery experience. Applying the ‘people first, then process, supported by technology’ principle, Howie conducts a rapid assessment and implements targeted actions to restore delivery discipline.
Structured interventions include:
- Providing enablers and support: Team members have not been trained on the mandated platform. Howie arranges targeted training, configures tools to match project needs, and introduces structured user support. Platform-related issues drop by 50% within two weeks.
- Reducing speculative delivery: Tim’s unstructured methods cause repeated rework. Howie implements PRINCE2 governance and introduces Scrum delivery practices. This reduces rework by 30% and avoids $150,000 in unnecessary effort.
- Building requirements capability: The team lacks formal business analysis competence. Howie recruits CBAP-certified analysts who complete the requirements specification in six weeks, aligning fully with client expectations.
- Clarifying roles and delivery discipline: Role responsibilities are undefined under Tim’s leadership. Howie assigns specific roles, enforces handover and approval processes, and increases milestone completion from 30% to 85% over three months.
Outcomes
Project Zombie recovers within six weeks of leadership transition. Full scope is delivered one week before the 12-month deadline, and total costs are contained at $3.9 million. Client feedback is strongly positive, with particular praise for transparency and responsiveness. Digital Data’s credibility for delivering complex IT programs is reinforced. The restructured team becomes an internal reference for disciplined execution.
