The Never Ending Story (End Case Study)
This case study examines how unclear expectations, defensive reporting, and uncontrolled software changes can prolong an international project. It also considers the challenge of combining formal project controls with relationship-based working practices.
Q1. Identify the issues in the project initiation phase.
During initiation, unresolved difficulties can slow a project's progress. Different ideas about what the project should be and produce can create confusion. Ideas and concepts are easier to integrate when the team has a clear foundation for discussing objectives and requirements.
In this case study, progress reports reflected top management's expectations rather than clearly identifying delays. This led to defensive reporting from both sides, concealing problems and presenting a more favorable picture.
There was also a lack of management commitment, while the project team did not provide sufficient formal feedback about project status. This resulted in a lack of open and clear reporting against predefined milestones.
The original account describes the Indonesian project managers as unfamiliar with large-scale change management processes. They did not implement the formal time-performance and progress procedures requested by the international CEO of c-consulting.
Separate Initiation Weaknesses from Later Symptoms
Some of these problems concern ongoing delivery rather than initiation alone. However, they point to arrangements that should have been established early: shared objectives, management responsibilities, reporting expectations, and a method for evaluating progress.
Defensive reports are particularly problematic because they reduce the opportunity for corrective action. A useful report should explain the actual position, the consequences of deviations, and the decisions required.
A Stronger Starting Point
A proposed initiation review would confirm:
- The business purpose and expected outcomes.
- The initial scope and important exclusions.
- The people authorized to approve decisions.
- The evidence required to demonstrate progress.
- The route for escalating problems and disagreements.
The European Commission's PM² resources include a business case, project charter, progress reports, and decision and issue logs. These provide useful templates for documenting such arrangements.[1]
Q2. How could scope creep have been avoided?
Building on the first answer, BIG requested several software changes concerning information workflows. As a result, some completed work became redundant. Undocumented changes substantially expanded the scope without corresponding additional fees.
Breaking the project into smaller milestones could have improved visibility. The original recommendation was to keep these milestones no more than one month apart. This could provide a useful review rhythm, although the appropriate interval depends on the work and the decisions required.
When estimating international project tasks, the team should also allow for uncertainty. Appropriate contingency can make the plan more realistic, but it does not guarantee completion below budget or ahead of schedule.
It is also important to collaborate with the client and produce an agreed plan. A clearly defined scope, understood by both parties, helps establish what is included and excluded. This reduces the likelihood of service expectations developing beyond the agreed work without a corresponding decision.
Control Changes Rather Than Prevent All Change
Client requirements may legitimately evolve. The issue is whether changes are assessed and authorized before the team commits to them.
APM defines change control as the process through which requests to alter the baseline are captured, evaluated, and approved, rejected, or deferred.[2]
A client request should therefore prompt an assessment of its implications, including any effect on completed work, testing, resources, schedule, and commercial commitments.
Proposed Change-Control Workflow
The following table is an illustrative improvement framework, not a record of procedures used in the original project.
| Step | Required action | Recorded outcome |
|---|---|---|
| 1. Capture | Describe the requested change and the business reason. | A uniquely identified change request. |
| 2. Assess | Identify affected workflows, completed work, dependencies, and tests. | An impact assessment with stated assumptions. |
| 3. Decide | Obtain a decision from the authorized parties. | Approval, rejection, or deferral, including any agreed commercial adjustment. |
| 4. Update | Revise the affected requirements and plans after approval. | A traceable, current version of the agreed commitments. |
| 5. Verify | Check the implemented change against its acceptance criteria. | Test results and the acceptance decision. |
Illustrative Example
Suppose BIG requests an additional approval step in an information workflow. That request could affect user permissions, notifications, reports, and existing tests.
Recording and assessing it before implementation would help both parties understand the consequences. This example illustrates the control process; it is not an additional event reported in the case.
Q3. Where do you see the impact of national cultures in this case?
Organizations working internationally need to adapt their management practices to different operating environments. Successful management must address cultural influences alongside organizational, contractual, and technical challenges.
In this case, the original analysis identifies two approaches: task management, emphasizing formal reports and action lists, and relationship management, emphasizing networks and interpersonal relationships. Their conflicting expectations negatively affected planning and implementation.
Combine the Strengths of Both Approaches
These approaches do not have to conflict. Relationships can make it easier to discuss concerns, while formal records help participants maintain a shared understanding of commitments.
PMI's discussion of multicultural projects emphasizes culturally aware leadership, effective communication, mutual respect, and reconciliation.[3] Applied here, that suggests agreeing workable procedures together and explaining the purpose of reporting requirements.
National culture should be treated as one possible influence rather than a complete explanation. Reporting incentives, leadership behavior, authority, experience, and contractual pressures also need examination. Individuals from the same country may have very different working preferences.
Illustrative Review Schedule
This proposed schedule develops the original recommendation for frequent milestones. It is not the historical project timetable.
| Frequency or event | Review focus | Expected output |
|---|---|---|
| Before delivery begins | Objectives, initial scope, responsibilities, and acceptance expectations. | Agreed starting commitments and open questions. |
| Weekly | Actual progress, obstacles, and decisions required. | Evidence-based status report and assigned actions. |
| At each change request | Business value and effects on delivery commitments. | Documented assessment and authorized decision. |
| At short milestones, potentially monthly | Completed deliverables and remaining work. | Review against agreed acceptance criteria. |
| When commitments become unachievable | Recovery options and management decisions. | Approved action rather than an unchanged optimistic forecast. |
Conclusion
The project needed clearer starting agreements, honest progress reporting, and controlled decisions about software changes. Short milestones could have exposed problems sooner, while a shared communication approach could have connected formal controls with effective working relationships. Together, these measures would provide a stronger basis for managing an evolving project.
Sources and Further Reading
These sources support the expanded management discussion rather than independently verify the original case events. The tables and example are proposed analytical additions.
- European Commission. PM² Artefacts.
- Association for Project Management. What Is Change Control?
- Anbari, F. T., et al. (2009). Managing Cross Cultural Differences in Projects. Project Management Institute.