[Disclaimer - The article below was written for a Project Management Course. The thoughts are of my personal and does not represent the company's (CAASCO) view points. Many details have been omitted/dramatized]
Project Description:
“You are off the hook for now Ali” – stated Victor, the Finance
Director of CAA Insurance. He along with 3 other Managers from different
business units (Adjuster, Claims and Reporting) were testing the new Finance
Reports while I (Architect/Developer) was on the conference bridge hearing them
validate those reports. I have to admit my heart beat was racing. As much I was
relieved that I don’t have to ‘face’ them while they are doing their UAT (User
Acceptance Test) in Montreal office but at the same time oblivion of what is
going on there in the conference. The project deployed was in 2 days and any
major defect discovered would put the project schedule in jeopardy.
The project was called ‘Finance Gateway Reporting’ project.
The Reports were mix of daily pulls and monthly pulls. The data source of the
Reports were ‘cubes’ (aka Multi-dimensional Data entities) from our Enterprise
Data Warehouse (EDW) which were to be hosted in SharePoint. The business
stakeholders were ‘straight shooters’ – they want accurate numbers in the
Report. Difference of 0$ between the Reports was the criteria as Reports would
be useless if not otherwise. All the Reports have to reconcile with each other
and displays detailed-transaction level details that can be drilled-up to
summary level.
The Finance Gateway Report Project kick-off was 6 weeks
before. The timelines delegated to the Business were aggressive. In the
planning phase, all the stakeholders along with a Project Coordinator (acting
as a Project Manager), a Business Analyst, a Quality Assurance Analyst and me –
the solo Developer/Architect were present. I estimated timelines based on
‘sunshine’ scenarios and full time dedicated effort for the project. The timelines
had to be given during the Planning phase meeting. To give correct work effort
estimate while you were on the hot seat was as good as using a black box to
generate random number for the work tasks.
However, the project was deemed successful with on time
delivery and execution. Measurable acceptance criteria (eg. Bug Tracker for
bugs) were set in place. Agile methodology was adopted and we had daily ‘scrum’
meetings hosted by the Project Coordinator every morning. The objective of
these Scrum meeting was to give a succinct account of your status: tasks
accomplished and task intend to do next and apprise about any obstructions or
challenges encountered. The meetings were kept with 10 min run time. This was a
platform where business were informed in every step of the project. Any
ambiguous (or redundant) business case was raised for clarification during the
scrum meetings. Project Coordinator would update the ‘sticky notes’ on the
board along with email send out to everyone ensuring any changes or updates we
have captured are not missed.
The challenge I experienced was in the planning phase when
the Finance Director said “Why can’t the IT get the damn Reports right.” The Reports were simple tabular (with
expand/collapse feature along with Export to Excel/PDF), so it was perceived as
less development effort. At the same time, not plucking the correct data from
the data warehouse and displaying it in the Report was also perceived as a callous
attitude with no due diligence of the IT in front of business. Moreover, there is this popular perception
around EDW in Business Intelligence world, “Data goes in to EDW to die” hurting
our cause of delivering the Reports. It was my first client-facing project at
CAA Insurance and knowing the history of IT vs Business; I saw this as an
opportunity as not only to redeem IT but also to establish myself as a force to
reckon (sounds cheesy).
The goal of winning business’ heart or better put - to salvage the reputation
of IT in front of Business was the driving force that led the project to be
successful. The daily scrums were seen as a transparency barometer gauging not
only the progress of the project but also gauging the authenticity and
intention of everyone involved. I used that opportunity to foster stronger relationship
with the Business. Raising the ‘umbrella high’ sets the tone of the project. I
would promptly set-up a meeting with a Business person to explain or proof of
having this in the Report instead of asking next day at the Scrum meeting.
Being proactive and showing ‘human’ side by showing empathy and care to their
requirement goes a long way in not only making the project successful but also
fostering relationship with Business.
All risks were put on the table and were managed by having
placed them in risk registers and having an action items against that risk as
part of risk mitigation plan. The inherent risk that was not explicitly enunciated
was the business knowledge. Able to understand the business and able to
converse in Insurance business jargon was a steep learning curve.
Project Analysis
In terms of following best practices with building trust and transparency,
project scope was clearly defined. Work breakdown structure (WBS) and Solution
Design Document (SDD) were documented with sign offs from key stakeholders. One
of the key scope for the project was that data inception is assumed to be from
the Enterprise Data Warehouse (EDW) and not
from the heterogeneous data sources that feed the EDW. This was the highlighted
clause that was made sure it is well understood across the table and no
surprises crop up during the project execution.
If one of the sources feed an erroneous data into EDW, the
projects that are in progress for that faulty system must be notified and are
responsible for the fix. The onus of that is conveniently transferred to other
project. The projects at CAA run in isolation. Project boundaries are high
enough for other projects to see. Raising the issue with the leadership was also
futile. Different projects deal with different systems. Different teams work on
different systems. In order to tell the Project Manager for ‘SystemA’ to tweak
their design was easy said than done. Each Project Manager wants his/her
project to succeed. Each project runs in isolation with having no incentive for
cross-project learning. This ties to the structure (or lackof) for
cross-project learning. Each Project’s objective is to execute on time with
absolutely no bargain. In the scope of the project it was conveniently
addressed that other system’s issues would not impact our delivery. I had
raised the concern of not sharing knowledge amongst projects does not bring the
most value to the organization. My concerns were shrugged off by “that’s how
Agile works – I know it’s a drawback” remarks from the Project Coordinator.
Adaptive Project Organization is what CAA projects need to
apply. In Adaptive Project Organization, all projects are dealt as part of a
same body. If any part of the pains, whole body feels the heat. Such integrated
project organization allows better resource sharing and also better equipped
with facing the stakeholders. Although the overall approach is ‘Chaotic’ but
the project was dealt with ‘Adaptive’ mindset. Resources were highly committed
to the projects. Personally speaking I had worked lot of long hours every day
during the project so that the project could see light at the end of the tunnel
on time. We had a ‘Demo’ every Friday to the Business emphasizing engaged
project culture and being transparent and open to Business.
The Project Coordinator ensured everyone was aligned with
Project and the progress was pacing well towards the finishing line. The
Project Coordinator also raised the umbrella by negotiating delivering the
‘functional aspect’ of the Report was higher importance than the ‘cosmetic
aspects’ of the Project. Project Coordinator took the Business in confidence
that any ‘cosmetic bug’ that arises during UAT will be taken care during the
warranty period as delivering Reports with data-integrity was placed in higher
value. Cosmetic bugs (e.g. number formatting to 3 decimal instead of 2
decimals, font color and size, or order of columns) will not hinder or impact the
delivery of the Project. This was a key win as we certainly did not want the
Project to get delayed because of a font size!
Management showing trust after seeing our efforts was also
heartening. After all both units (IT and Business) work for the same
organization. Both have the same motivation and drive to succeed. Management understand
the value IT brings to the table. Management also noticed the off-hours efforts
being put in the project. This was also a reason why Management agreed to delay
the cosmetic enhancements during the warranty period and focus on the core
Report functionality (e.g. Logic of data retrieval and the calculations based
on Claims Payments, Reversals, and other charges).
Best Practices:
The three best practices that I would adopt in my career
based on my experience and the takeaways from the course are:
- Raising the Umbrella high: Trust has to be earned and cannot
be taken for granted. When Raising the Umbrella high, it sets the tone of the
project and gives Management confidence that the project is in ‘good hands’.
-
Identifying risks and plan to tackle it: This is something I
should strive more in my career. I have a tendency to follow “sunshine
scenarios” and not even account for any potential risk or concerns. Be able to
identify risks and putting on the table is half the battle won. To plan and
mitigate and abate those risks is the other piece of the puzzle. The biggest
risk in my project was the dependency (or intersection
points) with other systems (and teams). To coordinate the dependency and
escalate it should be included in the plan.
-
Communicate with Intent: This single trait makes or breaks a
project. Keeping the Business Management in the loop and making sure everyone
is aligned with the requirements and how those requirements are tied into strategy.
If the communication is with intent and transparency, any challenge will be
dealt with care from all the stakeholders. Be it Scrum meeting, email
communication, weekly Demo – communicate with intend is winning over Business
through work ethics.
Recommendation
Even though Project execution and delivery was near-flawless
but it was much to be desired in terms of graduating from ‘Chaotic’ to
‘Adaptive’ project leadership at CAA.
To have a Project charter underlining Project strategy and
Project leadership gives the projects some branding and therefore a
responsibility. The onus of delivery was heavily skewed towards the Architect
(me in this case) and the Project Coordinator. The responsibility should be
shared and resources should be better planned out. To adopt a Project
leadership where projects are integrated as single unit and treated fairly
rather than me (first project) facing business clients and appointing a Project
Coordinator instead of a Project Manager. Projects sharing best practices and
lessons learned amongst projects strengthening Project Implementation and
Strategy. This practice of leveraging knowledge from other projects can be
iterated and included in the Project resource kit. To have a holistic Project
implementation plan amongst projects where time estimates can be negotiated and
risks be identified and put into the plan schedule.
