Have you ever taken on a job, at work or at home, that looked like a quick fix only to find yourself deep in the mire hours, days, weeks, even months later? I call that the Tip of the Iceberg Syndrome. It’s manifested by decisions based only on what can be seen, when we are blind to what lies below the surface. As a result, we have a limited understanding of who and what else may be affected and we have minimal awareness of what skills, capabilities, practices and technologies may be needed to remedy the situation.
The iceberg metaphor is appropriate. Up to 90% of an iceberg is below the surface. As the tragic example of the Titanic revealed, it’s the size of the whole that matters most. That was the challenge with the following project. It looked, on the surface, like a simple, easy, short term undertaking. Fortunately the assigned leader didn’t fall for the trap.
Ahmad Darman was a Scrum Master at a large multi-national financial services firm. He had handled his share of large, complex projects over the years. So when Ahmad’s boss approached him and asked him to take on a small project that was being proposed by the Operations manager, he said sure. He thought he could wrap it up in a couple of months and get on to something more challenging.
Ahmad’s new project was to automate a manual procedure rotated among three staff that was completed daily in the early morning hours. The existing process shipped stock trades made by his company’s clients to the involved fund companies through a clearing house. Sounds like a walk in the park? What Ahmad didn’t realize at the start: beware the tip of the iceberg syndrome.
Automate the transfer of stock trades recorded in the company’s administrative systems to the involved fund companies through a third party clearing house. The change would eliminate the early morning work and the costs and risks of the current manual procedures.
As Ahmad began to make plans and put his team together, his first stop was a chat with the project’s sponsor, the manager of Operations. That discussion revealed a larger, more complex project then Ahmad had originally suspected:
- That little manual procedure done by one person over three to four hours in the wee hours of the morning actually transferred hundreds of millions of dollars of trading information. Daily! It was a critical cog in the company’s operations.
- The clearing house handled trillions of dollars of securities on a daily basis. They would demand rigor throughout the project.
- The procedure involved confirmation checks between the company and the clearing house and between the clearing house and the fund companies.
- Any automated process would have to encompass the actual preparation and transfer of the data from the feeding administrative systems, confirmation that the transfers were successful at all points and the mechanisms around security, continuity, backup and recovery.
That small, simple project now necessitated the participation of seven organizations/entities: Operations staff, systems development staff who supported the company’s administrative systems, the clearing house, the fund companies, an offshore testing organization that handled all the testing for the administrative systems and the company’s IT Operations and Security organizations.
Ahmad proceeded to contact the key stakeholders and secure their input, support and commitment. The Operations manager assigned three staff to the project, one as the primary participant and two as backup. Fortunately the three were the ones responsible for the current manual procedure and so were intimately familiar with the details. Ahmad’s team quickly grew to seven full time resources plus the assigned clearing house, fund company contacts and QA organization contacts and part time IT operations and security staff.
The team used a hybrid agile approach, applying user stories to elicit the requirements and leveraging Rally from CA Technologies to manage content and progress. 15 minute daily stand-up meetings were the primary team communication vehicle. Ahmad held regular weekly meetings with the project sponsor and clearing house contacts and on demand discussions with other key stakeholders as needed. There was no steering committee. Because of the nature of the infrastructure, only one release was planned over four months including concurrent build activity between Ahmad’s team and the clearing house.
One of the key deliverables early on was robust documentation of the new operating processes and procedures including what ifs, contact information (emails, phone #s, etc.) and information on escalation levels. The work was guided by a Business Analyst on Ahmad’s team and was reviewed and tested by all the players plus call center representatives.
Testing of the end-to-end solution was a challenge. Ahmad’s team used a production box with dry runs for modified data sets. The business was given control to nullify the results once the runs were completed. Security also had to work some magic to arrange suitable testing user ID’s and passwords for the duration. And so the project continued.
The project was delivered successfully on schedule in line with the four month plan. The implementation included a two week parallel operation of the old manual process with daily confirmation checks. All the key stakeholders were thrilled with the project and the results, including the three business staff who no longer had to be in the office in the wee hours of the morning. And the sponsor paid for the celebration lunch!
How a Great Leader Delivered
Change is difficult. The more organizations and people involved, the more complex things can become. Fortunately, Ahmad didn’t get sucked in by the tip of the iceberg syndrome. He did his due diligence and recognized the breadth of the challenge early on by following the following practices.
- Understand the sponsor’s needs – The initial meeting with the sponsor set the proper scope for the project and provided Ahmad with the frame of reference he needed to get the project off to a great start and deliver successfully. The regular weekly meetings helped provide the continuous course confirmation and occasional correction to keep the project progressing on the right path.
- Engage with the key stakeholders – The project’s success was a testament to Ahmad’s stakeholder collaboration. He brought each of the involved individuals and entities to the table at the project’s inception and continued that active engagement throughout, expertly dealing with disparate needs and remote players according to their requirements.
- Use tools and techniques that have delivered results – Ahmad and his team adapted the practices and tools used within the organization to the unique needs of his project. There was only one release because of the vagaries of the infrastructure involved but a multitude of sprints yielded the functionality and capability required.
- Foster the dialogue – There was a very diverse group of stakeholders to deal with, including the offshore QA group, the clearing house, the fund companies and the internal organizations and staff. Ahmad worked tirelessly to ensure each group’s needs were understood and well articulated and that all understood the collective needs and shared the common goals. He used face-to-face, phone, email, video, reports, simulations, ad hoc gatherings, whatever was required to move the group forward together.
- Celebrate success – Every time a sprint finished there was a celebration to mark its completion. The sponsor was always among those acknowledging the success and all parties were involved. It helped all participants share in the feelings of accomplishment and take pride in the progress being made.
So, if you’re involved in a project that looks like a piece of cake, consider the approach Ahmad and his team took to avoid the tip of the iceberg syndrome. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and the Decision Framework right up front so you don’t overlook these key success factors.
Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, a favorite best practice, or an interesting insight that can make a PM or change manager’s life easier, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.