OK, that’s a little misleading. There really wasn’t a collision. But there could of been. But a seasoned IT executive nimbly navigated the team through recognizing the differences in model between 2 teams that now had to work together, and they’re finding their way through it.
One Business Unit has had a good track record running proper Agile projects. They’ve brought several projects to market using it. They trust it, they’re successful, and they know what they’re talking about.
The IT organization is traditionally Waterfall. They count on Charter’s, extensive architectural designs, complete planning and resourcing up front, etc.
Now the BU and IT have to come together to launch a new customer portal. The BU owns the project and key project resources. IT will be providing API’s and server support, etc.
But when we started talking project process, talk about confusing! The IT exec openly states that he really doesn’t understand Agile, and that all the Agile projects that he’s seen before were dismal failures (because they weren’t really run Agile; they were run sloppily). But he knows the track record of the BU and is open to supporting it. But he wisely recognized that the IT team wouldn’t know how to interact on an Agile project, so he helped guide the combined team through some high-level understanding of the approach challenges. We’ll follow with a kickoff that includes some specific approach instruction for the waterfallers now having to be agile.
A lot of organizations probably face similar things, but may not all navigate it well. Project leaders need to be conscious of selecting the right approach for the project (to wit, Waterfall or Agile or something else) and to bring along the project team’s understanding of the project approach so that they can executive it well.
Projects really don’t just happen. And a variety of approaches can be used on any given project successfully — but not all at one time! The project team has to settle on an approach and then drive that approach successfully.
Category: 
