mercury-mbs.com

IT Project management, especially in a waterfall world,  is a very predictive discipline. Starting with a set of assumptions about the project, people and the environment, the project manager builds a plan that looks far into the future to predict how the world will at the end of the project and then sets this plan out in a Gantt chart. Dates are defined and published based on the implicit assumptions that are never fully explained, documented or understood by the project team. Time is treated as a linear variable with tasks stacked up end to end and although a number of tasks can be scheduled in parallel the project is a linear progression from start to projected end.

As the project starts and time progresses the predefined assumptions begin to fail, the immediate reaction is for the project manager to build out a number of change requests to the project to be approved by the project sponsors. Each of those change requests is based on a new set of assumptions and very soon the predictive model that started the project has been destroyed but very rarely will the project model be rebuilt and re-approved. This is one of the prime reasons why so many projects fail even though all the change requests have been documented and approved, risks defined with mitigation plans, and issues logged and agreed.The project manager continues to act as a predictive agent working off the assumptions that are no longer valid but trying to make the new world fit the old model. The project manager will make decisions based on these changes that could move the project back on track but the chances of this are much less than taking the project further off target  and so each decisions has a random impact on the project.

Training was the next step. The leadership team was at very different levels of understanding of this new agile methodology - even though a lot of the lower level changes were already beginning to take root. Buzz words and phrases were used imprecisely and with mixed understanding. Basic definitions of iterations, user stories, releases were not yet fully understood and the ultimate goal was very grey. We spent many sessions discussing how the methodology could break down under specific instances and rehashing the problems we might encounter.

It was time to make the jump. Clearly. if we are going to move forward we must implement an Agile methodology. The first step was to train the team by bringing in an agile coach / scrum master to help us gain a basic consistent understanding of the methodology. The second step was to get the IT management and PMO on board. The Third step, ensure that this is rolled out at the grass root level and not top down, I have seen enough initiatives stall because it was solely a management push.