I was working as the PM for the SW development company in the Sales Enablement Organizations (Presales, Professional Services), responsible to support Sales operations in the Pre-sales, Delivery (Implementation) and Post-Implementation phases in providing technical and project management expertise in delivering projects to the customer, initiated to develop and deliver components of automation for business processes in the enterprise IT environment.
Our standard Project Management Methodology, used to manage regular delivery (implementation) projects, was the proprietary project management methodology supporting SDLC, with much resemblance to the classical â€œwaterfallâ€ approach. The reason behind this was often in the customer request to use the project management methodology compatible with their SW developemnt and deployment methodology, used for all production implementations in their environment and the customer reluctance to, under normal circumstances, accept any deviation from their standards. As lessons learned pointed out, for implementations of complex EITM solutions, including extensive programming efforts in customizing the solution using standard APIâ€™s, this methodology did not provide the ideal framework to ensure the project success. In case of changes in design specifications later on in the project, it was quite inflexible, inefficient and costly. The recognized shortfall of the â€œwaterfallâ€ approach is the lack the flexibility in accommodating change requests regarding change of requirements later on in the project. That lack of flexibility was particular obstacle for project categories including trials, POCâ€™s (Prove of Concepts), pilots and rescue projects (CIPâ€™s). These projects all have in common similar profile regarding risks (high), visibility to the CA and customer management (high), financial impact on failure (high â€“ in case of trials and POCâ€™s the value of the lost potential business and in case of rescue projects the value of the future business), initial understanding of the scope (low) and time available to gain (regain) stakeholders confidence and trust (short).
Main characteristics of these projects is a recognition that, during an engagement, customers can change their minds about what they want and need, together with the appearance of previously unanticipated and unpredicted challenges, all having major impact on project constraints. This situation could not be easily addressed in a traditional predictive or planned manner (following SDLC â€œwaterfallâ€ approach) and managing like projects required adopting a fresh and empirical approach:
â€¢ accepting that the problem cannot be fully understood or defined before the start of the project
â€¢ focusing instead on maximizing the team's ability to deliver quickly
â€¢ responding to emerging requirements by decomposing the project deliverables in smaller parts
â€¢ enabling iterative and incremental approach
Rescue projects are probably the most complex category of project engagements. These projects were initiated when the regular delivery projects failed. Some recent statistics, according to recent Standish Group study (in US, assuming no difference for the rest of the world), points out that 23% of SW projects fail to deliver any working SW at all and for projects that do deliver software (the outstanding 77% of all projects), 45% are over budget, 63% over schedule and when they are done they deliver only 67% of originally planned functionality. Based on the industry track record, the SW projects estimated to take 12 months to complete and cost about $1Million can be reasonably expected to take closer to 20 months and cost $1.5 Million delivering only about 2/3 of the requirements.
The big question is why IT projects fail and what kind of project management framework would increase the likelihood of success? I believe the answer is obvious when we answer the question why the SW solutions are developed in the first place. In most cases, the objective is not to craft some algorithm, it is to satisfy some business need, and because of that the first and the most important PM governance objective is to manage the project by aligning the project and business objectives. For most projects delivering EITM solutions for automation of some business process, there is no requirement to achieve 100% accuracy in delivering solutions by implementing 100% of initial requirements, unlike implementation of real time banking or accounting solutions, where 100% accuracy is the first and most important project objective.
That means that, in all area of business automation or EITM deployment, where 100% delivery of requirements is not the prime project objective, it is O.K to make solution not perfect
(it cost too much to be perfect), but functionally acceptable compromise between engineering natural drive to perfection and required and sufficient business functionality. To be able to deliver on those objectives, the project management framework must support that objective. What developers lack, from my broad experience as a developer and a PM, is the business understanding that we have to deliver the best possible solution to the business problem using limited resources to accomplish this goal. That is the reason why developers have to understand the business processes they are trying to automate to make purposeful, appropriate, business-conscious technical decisions so that a business sponsor (one always exists, the one who is paying our salary) can get the most out of limited resources. From my personal experience as a developer and a PM, the agile framework is one such framework which can overcome that gap, and because of that, it was the natural choice to use it, in the management of rescue efforts in salvaging failed EITM projects. When our cavalry was called in to rescue a project, the project was usually in the critical phase. The blame was surfacing in communications with the customer project sponsor, and the relationship with the customer reached all time low. The options left on table either included the arbitration regarding deliverables (what would have negative impact not only on the relationship with that customer and potential future business with them, it would have negative impact on the whole business in the region) or bite the bullet and sponsor the rescue effort, which will reestablish the confidence in our (vendorâ€™s) ability to deliver. That was the reason why the agile framework, including the customer as a partner to the project team with its incremental approach in delivering functional solution components, was an ideal candidate for the management of the rescue projects, making sure that problems are not going to be covered under the carpet and that steady stream of deliverables will reestablish the customer confidence in the our ability to deliver. At the same time, the project steady progress had a positive impact on the project team, which was already working in the hostile environment and under the extreme pressure to deliver where others failed. It is my experience that the PM on these projects should have not only PM experience in managing projects but as well deep technical understanding of the solution and that he/she had already earned the respect of the usually small team of technical specialists, tasked to deliver the solution. In that situation there is a role to play for the seasoned PM:
â€¢ to create a development plan selecting requirements for the iteration (iteration scope) with the team, taking into account the outcome of the previous iteration and priority of requirements
â€¢ acts as a buffer between the team and any distracting influences, focusing the team on the current prototype, not allowing any change of the focus or the scope for the iteration cycle
â€¢ removing impediments to the ability of the team to deliver iteration goals, if necessary by escalation to the project sponsors (both the vendor and the customer)
â€¢ be the owner of the escalation process to the project sponsor and/or vendorâ€™s development and technical support distributed teams, coordinating join development and test activities
â€¢ owning Risk Mitigation, Monitoring and Management (risk analysis) at every stage
â€¢ frequently informing project stakeholders of the project progress and providing advance warning for the potential project slippage and deviations ahead of time
â€¢ facilitating daily open and honest communication and cooperation among the team members