Assessment and Recovery of Projects in Trouble
Whenever my organization is called upon by major international organizations to deliver our core services of coaching and facilitation, their strategic initiatives are in trouble. Most often, they have tried to implement a solution for months just to discover that no progress (except for spending time and money) has been achieved.
Medical Factory Implementation
We got involved in a major program to implement a big factory to produce medical equipment using cheap raw material to deliver an end product of high quality to be used worldwide at a price to be acceptable even to poor people.
The program was run like a project with one project manager facing several internal key-stakeholders with considerable internal power and many external stakeholders with legal and political power. The external stakeholders were delivering:
- Production machinery
- QA equipment
- Logistics equipment
- Internal machine control information systems
- Administrative information systems based on the SAP Enterprise Resource Planning COTS software package
The internal key-stakeholders were:
- The future factory manager
- The CEO
The work to be done was defined at a very low level (work packages by contractor) and a lot of work overlapped between contractors.
Arbitration between contractors and project manager was handled at weekly project meetings.
More and more conflicts between all parties surfaced very early. An important reason was that more than one contractor made key decisions and that these decisions were contradictory or at best not visibly aligned with the overall project objectives. This was caused by weakly defined objectives.
The project was finally declared in trouble because major deliveries were slipping without clear responsibility for the delay.
It was obvious that a program organization was needed to govern all stakeholders. Furthermore, a clearly defined unambiguous requirements specification for each contractor was needed and had to be agreed on by all parties.
Our contributions to this program that has since delivered one of the most successful solutions in the history of the pharmaceutical industry were:
- Establishment of a program organization based on visible high-level objectives (critical success factors) and clearly defined high-level activities that each one was a major project on its own. The organization, the objectives, and the activities were approved by top corporate management that became visibly involved in the program management. The project manager of the building implementation said: "This process should have been used from the beginning to avoid the troubles that started more than a year ago …"
- Coaching of the contractor responsible for delivery of the complete factory control system (a network of control computers connected to the numerical control on all production and quality control equipment).
- Our coaching comprised the establishment of the detailed project plan. We also delivered the method and coaching to develop the normalized data structure and content, and the normalized process structure common to all control computers
- The normalized data and process structure allowed fast corrections of failures and resolution of problems, and ensured an efficient interface with the SAP-based order and production planning and control environment.
- The normalized data and process structure was used and verified early in Simulated Accept-Testing to prove the efficiency of the solution to be developed and delivered.
- We coached the setup and execution of Simulated Accept-Testing supervised by corporate management (the program management team) that signed off on the solution development and implementation.
Our methods used were:
- Process quality assurance to establish the objectives and a complete project plan that allowed reliable estimation, forecasting, and tracking.
- An Information Requirements Study to identify all core objects with their purpose and usage and to ensure that they were complete with respect to the overall success factors for the program and the detailed success factors for the control system production and implementation.
- The Object Lifecycle Analysis to detail, define, and normalize all data and process objects in such a way that all control systems could be developed and implemented where needed, ensuring full integration among control computers and with external systems (numerical control and SAP).
- Simulated Accept-Testing to prove the feasibility of the data and process structure.
Both the pharmaceutical enterprise and the control system contractor coached by us implemented major method and organization improvements in order to benefit from the methods used also in the future.
Complete Swap of All IT Systems in a Private Bank
The new IT manager in a private bank brought us in to assess the situation (the project quality) of the biggest IT and business development program (only defined as a project) ever implemented in this (private and asset management) bank.
The task was that the old computers with COBOL-based Information Systems had to be swapped out and replaced with new technology. The old COBOL-based Information Systems were interfaced with multiple standalone solutions internally and externally. As most of the old in-house developed core-banking IT solutions were getting more and more inefficient, they were not candidates for swapping.
The corporate management had opted for a COTS standard system implemented on state-of-the-art IBM technology (including DB2 relational database) to be interfaced with the set of standalone solutions (mostly in house development) that they expected to survive and to continue to be used in business after the swap.
This COTS system was bought because a neighbor private bank used it and was relatively happy with its solution.
No requirements specifications were established.
A large number of external consultants and internal employees, mostly from IT, had spent more than 18 months with evaluation of the quality of the old solution components while trying to produce a GAP analysis (as is and to be definitions of the software that had never been documented before!).
There were no usable results from this GAP analysis.
Very expensive COTS vendor consultants were working on setting up the COTS system in the private bank even before complete requirements to solution infrastructure, security, safety, and technical environment had been defined. This was, of course, a complete waste of time and money.
In parallel with the GAP analysis, the future end users (bank employees and a few IT employees) were "trained" in the new COTS software that had not been adapted to their requirements (these requirements did not exist).
The users from business and IT were all deeply unhappy and frustrated with what they saw during training and demonstrations. This sporadic and very expensive training provided by the COTS vendor created more frustration and mistrust than learning.
IT management declared the project in deep trouble, stopped all GAP analysis and training activity, and laid off all involved external consultants. During this initial clean-up process, the relatively innocent internal project manager was removed from the project.
Once on board, we established a strategy to recover the project.
This meant, among other major changes, to involve the business organization deeply in planning and requirements specification, while preparing it for future solution implementation, evaluation, and testing.
In order to avoid the risk of losing a lot of capital on activity that does not deliver visibly useful results, we re-planned the program and the projects with a focus on real tangible deliverablesit was made Lean.
The deliverables were real solution components that could be developed, interfaced, and thoroughly tested to be satisfactory to the bank and the employees.
We succeeded in procuring external experts from major service organizations that agreed to deliver the solution components on fixed time and cost based on the solution requirements to be produced by the private bank.
The bank management committed to contribute to the solution requirements and the knowledge and the capacity of resources necessary for solution design, development, Accept-Testing, implementation, and operation. Internal and external responsibilities were clearly defined, but it was also clearly defined that problems were resolved by mutual proactive solution contribution from all parties.
Payment to external sub-contractors could only be obtained after fully accepted delivery of solution components.
The involvement and re-motivation of the very frustrated user organizations inclusive of IT was established through usage of Project Quality Assurance that quickly visualized the key success factors and all the activities required to achieve the success factors. Success factors in this context are solution capabilities, business and work conditions, organizational competence, and events.
The user organizations agreed to produce requirements specifications quickly that could be used as a foundation for procuring solution providers and COTS-based solution components at a fixed price.
We supported the user management with an adapted and combined Information Requirements Study and Object Lifecycle Analysis that resulted in clearly defined use cases (or sprints) that were used as a basis for structuring the complete business requirements exposed to the potential service providers and sub-contractors.
In order to structure, plan, and track the progress of requirements spec production, we defined a very specific method for how to document all pertinent business processes to be supported by the COTS application and the interfaced standalone systems. To this end, we recommended use of a relatively easy workflow documentation standard that complemented our own Information Requirements Study and Object Lifecycle methods. This was relatively well accepted by the involved business users of the future solution because they had accepted that no solution could be delivered without documented requirements.
It was obvious that external experts from the COTS solution vendor and from organizations with broad and deep experience from implementing the COTS solution were requiredand fast.
In parallel with the production of the requirements spec, we prepared the solicitation and tendering among potential sub-contractors. No current business process was left out or adapted in the requirements documentation, which minimized the negative impact from risk-exposed changes to known business processes. Suggested improvements to current business processes were allowed to be documented, but they could be used only for inspiration to the developers and implementers, not as requirements. In this way, we were able to present a complete solution process overview and the first complete work fl w documentation very fast to the potential internal and external expert organizations that could perform development and solution implementation.
After 3 months of intensive negotiations and contracting, we had a complete project organization in place for development and implementation, where development consisted mainly in setting up and interfacing COTS applications and development of integration components. Implementation consisted of usage documentation preparation, training material preparation, user training, Accept-Testing, and operation setup.
Nine months later the first solution component went into production. Our contribution to this program comprised:
- Coaching and program management based on project management tools such as Project Quality Assurance, Project Planning with Professional Procurement, and Program Management with many stakeholders and many Work Package project managers. t t Coaching of business management with the establishment of the required physical environment for development and implementation with buildings (containers), rooms, networking, security, and IT. This resulted in a huge war room being made available to all program resources with ID card for entry and exit. For confidentiality reasons, involved development resources were only allowed to work on-site in the war room while fully supervised, while implementation resources from IT and business could work in their own environment when they prepared training material and system operation procedures.
- Establishment of the program organization and the project teams with more than 100 resource persons of whom more than 50% were working full time on the program.
- Progress tracking that was performed once a week with all involved project managers.
- Handling of any cross-organizational issues on a day-to-day basis at 8:30 meetings in the war room.
- Functional implementation issues were analyzedusing Object Lifecycle Analysis to ensure a complete and consistent solution implementation.
- Simulated Accept-Testing was established between internal future support, external solution implementers, future end users, and, to some degree, internal management.
- The end users were only formally trained once the future solution components were ready for final Accept-Testing and production.
Frustration was avoided, confidence was re-established, and to some extent, the stakeholders were happy. Unfortunately, it was not possible to cope with all technical issues concerned with the bought COTS software, but that is another story.
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082015 Taylor & Francis LLC. All rights reserved.