Project Janus

A Project Manager's Perspective of Agile Approach

October 30, 2014

1/5
Who am I ?
My name is Kishor Chandra Das. I have been working as a Project Management Consultant
for past 15 years. I completed my PMP certification in March 2007 and maintained it until
2018. I have successfully delivered 7 large scale IT development projects and 5 business
change/consulting projects in last 10 years. My professional publications include
“Outsourcing IT Development: Monitoring the Six Dimensions, PMI Knowledge Shelf, 2012”,
“Project Value: The Modern Mindset of Project Management, 2013”, and “Collateral
Management: Optimization, Efficiency and Effectiveness, 2012”. After working in the
consulting industry for 17 years, I have now started my own management consulting firm
in 2013.

Why did I become a PM ?

A project can never be completed successfully without effectively communicating with all
the relevant stakeholders. In my early career when I was working as a team member, I had
observed several instances where the communication channel between teams/stakeholders
were broken and projects were moving at a very slow pace. As I started bridging the
broken communication links, I automatically assumed the role of project coordinator. After
realizing the value of effective project coordination, I was made in-charge of the projects.
My instinct of questioning the status quo and my skills of effective coordination landed me
in the PM role.

How has PMP contributed to my success?

Owning the Project Manager responsibility without any formal training or education on
project management, I many times entered into unfamiliar situations. My knowledge on
Project Management at that time was not sufficient to resolve the unfamiliar situation and
that's why I decided to do PMP and enhance my knowledge of project management from
the community of experienced project managers. In any one project I never needed to
apply all the knowledge from PMBOK but every project is unique and each project requires
different set of knowledge and skills to execute it successfully. PMP gave me the overall
knowledge that will be ever required in any project. With that knowledge I felt more
confident and competent the PM role. The knowledge that I acquired after doing PMP,
helped me in successfully executing many time-boxed, fixed budget, outsourcing,
transition and business change projects. One of the key turning points in my PM career
was when I attended the Synergy 2009 and listened to the projects success stories and how
the projects were managed. The credit of my success as a Project manager goes to the
PMP community who have shared their knowledge and experience through different
forums.

The most impactful project in my career

Delivering a service integration project on time, with in budget and with no service
disruption is no trivial accomplishment. Janus, as the name suggests, brought a new
beginning in one of my client's business. My client is one of the leading FX and
International Money Transfer businesses based in London.

2/5
I was hired to deliver this service integration project and to migrate 120,000 existing
customers. My client had won the contract against the existing the service provider to
provide a white labeled international payments platform. The contract with the business
partner was not only to migrate their existing customers but also to provide a new best in
class international payments platform. When I was interviewed for the project, I thought it
would be like one of the other projects I have executed in past. Having worked at CMC
Markets on the white-labeling, internationalization, and customer migration projects and
having delivered multiple time-boxed fixed cost projects, Janus sounded like an easy
project for me. But no project goes without its twists and turns and Janus was no different.

My day one challenge

On day one I was given a brief 20min introduction to the project and the work that has
been done so far. After the introduction session I was asked to prepare a project plan and
send it to the business head by end of the day. I anticipated a lot of challenges in the
project, but not this challenge on day one of a new project. From that point I knew it will
be an exciting project to work on. After a long day of going through the project proposals
and contract documents, I managed to produce a draft copy of the project plan divided in
6 sprints.

Over the next few days I read through, in detail, the bid presentations, contract documents
and email threads and also conducted many meetings with the account manager, pertner's
product manager, marketing team, digital agency consultants, development team and
senior stakeholders to assess scope and size of the project. Within a week I had a fair
understanding of the scope and I prepared a product backlog of all the identified features.
In consultation with the business stakeholders, I prepared a functionality tree map and
color coded with prioritization for the estimated 6 sprints. Then in the next round of
estimation and planning with the technical lead and development team I realized that not
enough resources are available to complete the product development in 6 sprints. More
realistically it looked like 8 sprints will be required to build the technical framework and
complete all the requested features. An immediate meeting with the business stakeholders
and other senior stakeholders was necessary to take an approval for this change. Although
there was no impact to the project cost but project timelines needed to be adjusted and
leaving less time between product completion and product launch date. That adds
additional risk to testing and business acceptance cycle. The governance board reviewed
the change along with the risk mitigation plans and agreed to extend the development to
8 sprints. This was my first success in winning confidence and trust of senior stakeholders
in this project and I felt very positive seeing business and IT working cohesively towards
the project goals.

Wearing multiple hats to successfully deliver the project

The next challenge for me was to understand the product functionality and features to
sufficient detail so that the impediments in the development cycle can be kept to minimal.
I needed an experienced BA with sufficient business knowledge to write the stories. The
best resource I could find for the project had sufficient business knowledge but no BA

3/5
skills, so I was required to put on the BA shoes for a while until I could coach and train her
to effectively play the BA role. That didn't took me too long to train her, with her business
knowledge she proved to be the best BA for the project. Following the agile practice, the
BA then elaborated the stories that are part of the next sprint. In many discussions with my
peers I am asked, if a story is being elaborated at this stage then how could you do a
proper estimation and sizing at the start of the project and how could you arrive at an 8
sprint product development cycle. In an agile project it's important to create a bird's eye
view of the project before starting the project and use the right tools and techniques to
arrive at a fair estimate of the effort. Then as you start the project, do a rolling wave plan
taking into account the ground realities such as shifting requirements, resource availability
and technical difficulties. In this case, the product tree map along with the prioritization
color codes for each of the sprints was the bird's eye view of the project. The estimation
was derived from consultation with the developers, architects and technical experts. The
rolling wave plan was to elaborate the stories for the next sprint and based on the progress
from the last sprint, identify the stories for the next sprint. This approach worked quite well
in this project.

When I was comfortable with planning of the project and started the execution, my next
challenge was to keep the stakeholders engaged in the project. In a time-boxed project like
this it is very critical to have the stakeholders engaged all throughout the project lifecycle.
So I invited the senior stakeholders to join daily standups and to participate in the demos
at end of each sprint. Of course they couldn't join the standups everyday but they joined
few standups at beginning of the sprints and participated in the product demos. That was
a big win for me in this project. When senior stakeholders are engaged in the project it
helps in a) In making the teams understand the broader objective of the project and its
importance to the business b) Evaluating at every step if the project is meeting its business
expectations c) Keeping the project agile with right order of prioritisation from the
business perspective.

The go-live adrenaline rush

In the project plan there was 8 weeks time between completion of the product
development and the launch date. The 8 weeks slack was kept in the plan mainly for the
product testing, business acceptance and all the preparation for the operational readiness.
The switchover date for the service migration was agreed for 3 rd of May 2014. Between the
start of the project and until the very last moment it has gone through positive phases and
also unexpected unfolding of new situations. As the existing service provider has lost a
significant size of business that's why probably they didn't want this migration to go very
smooth. Due to the politics between two competitors there was no clarity on how and
when the data can be migrated from the old service provider to the new platform. This was
one of the major risks in the project. Five different mitigation approaches were kept in the
plan to address different scenarios such as data not received, data quality is not good, data
comes too late etc. And the cost of putting these mitigation plans was huge as it involved
consent and approval from Legal, Marketing, Compliance, IT, Business and Operations
teams. Until the very last moment this was the highest risk item in the project. Since it was

4/5
a service migration project, all the client communications were sent in advance advising
client of changes to the terms and conditions and change in the service provider. There
was no option to move the launch date, whatever may happen the change must have to
happen on that given date. Although I had done other time boxed projects in past but this
was different as services to 120,000 customers could potentially be affected. The IT
development work was planned to be completed in 8 sprints followed by QA, Performance
Testing and User Acceptance. But, as in any other development project, minor scope
changes kept on coming until very last moment. Instead of 8 sprints, it took 9 sprints to
complete all the required development work and that had a ripple affect on other things
such as testing and preparation for production readiness. On 2 nd of May, a day before the
due date, I was running from one corner in the office to the other corner coordinating with
all the teams to ensure all necessary infrastructure from IT infrastructure, software,
telephony, printers, IT security to teams in application support, operations, fraud and
compliance are all geared up to handle any unexpected situations. It was looking all
chaotic in the morning of 2nd of May, but by the evening when I left office at 7:00pm all
systems were tested to working fine. Now that everything was successfully testes I had full
confidence for the go-live and I went to the pub with the entire team. Next day morning I
did a sanity check and started the countdown 10 seconds prior to 10:00 o'clock. Ambiance
in office on that morning was like the NASA mission control room. As soon as the services
were made available to the public, we started seeing traffic on our Janus platform. For next
1 hour all development and support teams kept a close watch on the control dashboards
and logs, I was constantly in touch with operations and customer service teams. After
monitoring the system running smoothly for an hour I had a sigh of relief. The biggest
complement for me in this project was this quote from the CIO “The project is by far the
smoothest one in our recent history”.
This is one of the most impactful projects in my career for the reasons
1. The project was affecting such a large customer base and the margin of error was
zero.
2. I could instill the culture of agile project development, not only in the IT teams but
also in the business and operations teams, which paid off at the end.
3. IT and business teams had maintained an ideal relationship to a achieve a common
goal
4. There was no incident of data breach.
5. Delivered value was much bigger than the projected value.

5/5