Page 19

Project That Demanded Agile By Parag Tipnis


roject Management is both a ‘Science’ and an ‘Art’. There are thumb rules, principles, laws and guidelines but there are also analogies and intuition. And one of the most intuitive tasks in Project Management is selecting the right Project Management methodology. There is a let’s just do it approach, there is the traditional waterfall method of Project Management and then there are agile methodologies like Lean, Kanban, Scrum and Extreme Programming. Essentially, sometimes the camps get divided into the supporters of traditional or waterfall methods with focus on detailed planning (more time spent planning, less time spent worrying) and the proponents of Agile methodologies with more responsiveness to changing requirements. Most often the choice of the Project Management methodology is a factor of type of project, organizational policies, legal requirements (especially in fixed cost contracts where the scope has to be defined in advance) and the personalities and preferences of the PMO director and project managers. However some projects demand a certain Project Management methodology. One such project was with a multi country development organization which worked with governments of different countries on development projects. This organization was the client of the company I work with and our role was to provide a software solution to the client. The technical specifications had been prepared by a reputable consultancy firm which also saw the vendor selection process in which we emerged as the successful bidders. The same consultancy firm was selected as the principal project manager for the project. The approach that this firm took was that of following the traditional waterfall method and we received a detailed scope document. Nothing was left out, every process, every screen, every field and every user role was described in detail. They could have sent the document halfway across the globe and got the system developed from someone who had never even heard of the country that the client organization worked with, that too without any face to face or video/audio interaction. It was possible to build the system just by reading the document. But, one of the activities we had proposed was scope validation. Our team went onsite and discussed with the client the scope which was provided to us. It turned out that all the stakeholders in the client organization had not been involved in the process. We raised the concern to the consultant acting as the project manager. It was decided that a new round of system requirement study would be undertaken and we would receive a new scope document. Negotiations were held on how much variation could be allowed in the scope since it was a fixed price bid. The new scope document arrived in some time, this time signed by all the stakeholders in the client organiFeedback:

zation (even now some stakeholders had given verbal approval). We worked as per the new scope and created a prototype system. We hosted the prototype system in our test environment and went onsite for scope verification. The meetings that happened were stormy and full of passionate energy. As can be expected in software projects, it is always difficult for the users to envision the system before they actually see it, and when they saw the system, they did not feel like their requirements were captured correctly. The client refused to sign the acceptance documents and for a while contract dispute loomed large on our heads. The project had already been delayed and we had incurred more cost than originally planned including unpaid onsite travel (yes it’s a real life scenario!!). We realized we had to do something quick to allay the situation and to successfully close the projects. We could not perpetually keep investing time, money and technical resources to the project and the prospect of arbitration or legal proceedings did not seem appealing although the result might have been in our favor (given the fact that we had worked on a detailed Request for Proposal and a signed scope). Any such action could result in loss of reputation or erosion of goodwill in our customer community. We decided to positively influence the result of the project. We proposed that the Project Management methodology be changed to Agile. We committed to sending few experts of our development team onsite for three weeks. The client organization agreed to pay for the travel and boarding expenses of our team. We planned three day iterations, where every three days we showcased the client our progress on requested changes. And as time progress we saw that the client became more and more satisfied with the result. Just three weeks of Agile development resolved a conflict and completed a project which had exceeded its planned time by three months. If we had followed Agile from day 1, we might have completed the project before time and saved on costs. This was a project that demanded Agile!! About the Author Parag Tipnis is a Project Manager with over 9 years of experience of managing complex multi country and multi-year projects involving remote teams and numerous stakeholders, strong technical understanding and significant exposure to finance and procurement. He has led project teams, handling multiple projects at same time. His skill set includes strong interpersonal skills

Synergy Oct 2015, Page 19

Synergy Issue 15 - Oct 2015  

Quarterly Newsletter of PMI North India Chapter