Project Confusion in Transition Management

My project involves the deployment of reliant systems for aviation safety. The project was called, tendered, & awarded as waterfall. At the start of the project, there were unprecedented, IMO irrational new requirements with a mandated condition of urgency to complete the project ahead of schedule.

With unanticipated new requirements, there was a sense the project will need a different approach to management if the team were to keep to the proposed timelines. It didn't happen. Because interestingly nobody could agree nor willing to deep dive into project management methods!

So the project continues with negotiated mindless commitment to accommodate to needs, wading through waterfall demands that are difficult to compromise. Our upside of commitment is cohesive customer-vendor collaboration; developed through working in proximity. But it could easily go the other way.

This brief presents the lessons learned in introducing & adapting Agile in a contracted waterfall project. The introduction which was unintended & unplanned for. Where Agile is informally practiced. 

The project eventually settled into a regime that emphasizes meeting deadlines on essential deliverables. And communicating developments particularly issues verbally & in a timely manner. Compromises were made on:

• Reporting progress through unconventional means ie. through text messaging on a medium that is familiar, effective & comfortable with everyone e.g. sharing pdf files, diagrams, scribbling on images.
• Resolving problems without meeting formally, keeping everyone informed & updated using the same medium (additionally in our case we quietly ditched the CCB process).
• Reducing or setting aside for later- formal paperwork. 

Now in its final stages, the project runs & feels like an Agile project. Where communication is key to keeping everyone updated on progress & ready to resolve problems, if any arises. It is informally Agile with prescribed waterfall submissions, minus the embellishments typical of Agile methodologies.

Our Lessons Learned 

Thus far, we applied with intent the following:

1. Plan just enough. Let the project & plans evolve. Help the project team get comfortable & agree to planning with whatever information is at-hand.
2. Lead the customer. Take time to demonstrate & tweak processes towards the Agile framework.
3. Trust the project team wholly. Most importantly trusting the customer to deliver their part.
4. Apply Agile at the level of comfort for everyone involved. There will be people who are ignorant or resistant to the approach. Work on processes instead of convincing everyone.
5. Meet waterfall obligations. This sounds counter-intuitive when applying Agile practices; however there are always protocols that must be followed e.g. contracts especially in procurement, warranty claims, billing cycles.

Success factors 

My take on our success, in addition to the above lessons:

• Customer is aware of Agile - the customer had prior organisational training but not the experience in practicing Agile; and 
• Customer is 100% willing & committed to attempt a different approach to complete the project.

The project team continues to maintain & prescribe project management functions e.g. QA, risk assessment on work packages. Work now runs on a fast track. Yet without compromising on essential tasks e.g. audits.

Agile Communications 

Stakeholders simplified communicating project performance & progress, both formally & informally primarily to:

• Report on accomplishments 
• Inform on immediate scheduled plans & work about-to-start 
• Highlight & work to resolve problems

Tip! - Keep reporting on progress & performance to a minimum but at an acceptable level or standard. Check with the customer regularly for feedback on communications & clarity.