Every project manager knows that delivering a successful project takes organization, skill, a commitment to maintaining momentum and the ability to deal with the unexpected. All factors that are multiplied when working on a large-scale project involving multiple vendors are working together to achieve a common goal.
This is something we experienced at first hand when working on a large regional bank's ATM Migration project. The migration involved a combination of internal teams and external vendors, including the two different divisions tasked with satisfying the migration requirements and meeting the company’s goal of migrating its 8,500 ATMs to Windows 7. As well as these internal teams, we had to work with the software vendors: Diebold, NCR and WinCor, who provide software and hardware to the bank's ATM fleet, and Star by First Data, the provider of backend cash dispensing and accounting processes. Finally, we had the endpoints to consider: the ATM fleet consists of ATM machines in both branch facilities and kiosks located within three convenience store chains, Wawa, Sheetz and Thornton's. And throughout the development, testing and rollout process, we had to coordinate with them, too. Here’s how we made it happen:
Breaking down the language barrier
One issue we encountered was the need to establish common nomenclature between vendors. Communicating the requirements and coordinating delivery of each vendor's OS windows image was an immediate challenge because terminology and nomenclature used was different for each of them. Even baseline terms for things such as the "WIM or "image" needed to be clarified and standardized so that we could speak the same language with each vendor representative and communicate more effectively.
We then produced the requirements documentation and gave each vendor deadlines for receiving the OS WIM. Task sequence (TS) development and testing was then able to commence, with vendors being re-engaged to provide fixes when any issues arose.
Appreciating that everyone is different
Development for this project included creating a TS to complete the XP to Win7 migration and then upgrade to the latest version of the WinCor ProCash ATM software which handles all the customer transactions on the ATM.
Because the project included working with multiple vendors, that also meant working with multiple versions of software releases and updates in addition to regular security patches to the Win7 images. So, rather than taking a one-size-fits-all approach, we created a task sequence for each vendor's OS window's image, both attended and unattended versions. This came in useful because, as it happens, the vendor software updates were often found to be untested prior to release and we found many failures in vendor software releases during TS testing. To minimize the impact this had, we implemented a repeating cycle of testing to ensure all the latest releases worked together as planned.
Articulation of Technical Detail
Throughout the development process, maintaining excellent communication and coordination with each vendor and the bank was essential. To help establish a rapport, we initially held status meetings on a daily basis, and then help them less frequently once good working patterns were established. At each meeting, we reviewed and tracked current progress and any risks and roadblocks preventing task completion. Any issues manifested during testing or discussion were quickly escalated to resolution and responsible parties from each vendor were held accountable as required.
Due to the very technical nature of the project it was essential for the Project Manager to work closely with the consultants to understand the complexities and time consuming steps taken to complete development and testing. Having an appreciation of the technical issues encountered is essential in driving the status calls, gaining clarity of the real issues and clearing a path to resolution. Multiple issues on several levels were discovered during the TS testing. What helped us deal with this effectively was keeping a history of all issues uncovered throughout the project became substantial backup for any timeline slip justification although many items were easily fixed during the process.
Holding Vendor Representatives Responsible
One of the collaboration snags we came up against was the fact that one of the hardware vendors, NCR, was extremely late in delivering its OS WIM for TS inclusion. Not only did this delay TS implementation and verification, it ultimately caused a schedule slip for the NCR TS. There was tremendous pressure from outside the immediate team to bring the schedule in as much as possible and prevent schedule slip. Transparent communication when it came to outlining the steps involved in development, implementation and testing played a vital part in helping outside teams understand the time needed to compete the tasks. We were able to impress upon them that while we might appear to be losing time, skipping verification/remediation steps would only reduce the quality of the development work, leading to extensive rework and longer delays.
Pilot Phase, Remediation and Following the Process
As the pilot began, many issues reared their heads. Most of the problems resulted from the miscommunication of specific settings and timing problems. A team effort was required by all parties to eliminate issues such as reducing the number of overall reboots in the TS to eliminate redundancy and to reduce the overall time required for the migration to complete. Because of the groundwork we’d done at the start of the project, all teams had the rapport needed to rally together to work through all issues and coordinate who does what/when for settings, and to streamline the TS.
Large projects like the one described here are a delicate balancing act and require levels of diplomacy and tact that don’t come naturally to many of us. But, as with any project, it's important to remember that haste makes waste and a methodical testing cycle is the best option.
