#002 - Project Keystone: Navigating New Requirements and Team Conflict
Project Keystone is a large IT transformation programme within a fictional insurance company, FirstGuard Insurance. The programme aims to replace aging core systems with a modern, virtualized platform. The programme uses a strict Waterfall approach and involves building multiple environments - Development, Test, Staging, Production; from left to right.
Two major teams are involved:
A) The Infrastructure Task Force (build team) responsible for provisioning the environments.
B) The Business-As-Usual (BAU) team that will eventually operate the systems but is still positioned within the transformation phase.
During the build phase, the build team hands over each environment to the BAU team once it is completed. The BAU team becomes responsible for that environment and the build team ceases involvement. However, due to the extreme complexity and sizing of the built environments, a new requirement emerges: several application teams realize that additional VMs are needed to host certain security monitoring tools. This requirement was not a scope miss; rather, it arose from continuous validation and adjustment of the initial design during the build. The build team had been refining sizing and architecture as they learned, which is typical in complex transformations even when a Waterfall model is used.
The build team is hesitant to provision these new VMs because the affected environments have already been handed over. They argue that new builds fall outside their contractually defined scope and the build team is not allowed to touch anything within the handed over environments. The BAU similarly team refuses to pick up the work, claiming they are operations, not builders.
Both sides dig in:
Build Team PM: "The Development and Test environments were signed off. We delivered according to the design. Any new VMs require a formal change request."
BAU Manager: ”You built these environments; you fix them. We aren't staffed for additional builds."
Build Team PM: "These aren't defects but new requirements. If we keep adding ad-hoc work without change control, we risk scope creep and delay of our Key Milestones."
BAU Manager: "Our security team will stop testing unless the tools are in place. You're putting the programme at risk."
Build Team PM: "This is also an opportunity for your team to gain experience. Future small enhancements will be your responsibility after handover."
BAU Manager: ”Don't tell my how to run my team. Your job is to deliver what we need."
Build Team PM: "Then let's resolve it constructively: raise a change request, split the cost, and we'll walk your team through the process."
BAU Manager: "Fine, but management needs to approve. If they don't act, we're stuck."
Escalation to Management
The conflict is escalated to the programme's management. Unfortunately, the leadership is reluctant to make any decision and the submitted PCR gets rejected immediately, no discussion allowed. Both teams are only instructed to get it sorted themselves and ‘absorb’ the additional workload.
With no clear guidance from above, both teams recognize that work cannot progress without resolving the issue. They finally put emotions aside and ultimately decide to create a joint ad-hoc working group to tackle the problem.
The joint group agrees to split the labor cost and effort of provisioning the additional VMs. The build team provides technical guidance while the BAU team executes the build under supervision. This solution unlocks progress and helps transfer knowledge (the build process is recorded and lessons stored in the BAU team’s knowledge base) to the BAU team, which will eventually handle similar tasks once the build team leaves.
Situation Assessment
This is not a scope miss but an emergent requirement due to the complexity of the environments. Strict Waterfall processes can still encounter new requirements when real-world constraints emerge.
Role confusion: the BAU team considers itself operations-only, yet during transformation it must build capability for future enhancements. VM rebuilds are not extremely rare, even within BAU.
Management reluctance to intervene forced teams to create an ad-hoc solution, which may not align with governance and project management standards.
Final Thoughts & Recommendations
Control Scope: Even with emerging requirements within the grey zone, follow the agreed change control process. Document the new requirement, evaluate its impact on cost and schedule, and seek approval. If nothing else, this fulfills the PM’s obligation of being a ‘PM process guardian’.
Validate Scope Continuously: Incorporate iterative validations during design & build phases to catch sizing and tooling needs earlier, even in Waterfall models.
Clarify Roles: Insist on updating the programme RACI matrix to reflect that BAU takes on build-type work during transformation too. Provide training to build capability.
Facilitate Joint Solutions: When management is reluctant, empower teams to form cross-functional working groups to resolve issues while still adhering to governance.
Escalate Effectively: Document the issue and proposed solution for executive visibility. If leadership won’t decide, communicate risks and obtain documented concurrence for the ad-hoc approach.