Darkest Day in the History!

What happened on 16th December in Peshawar Army School is extremely tragic. Unfathomable crime against humanity. 141 people including 131 kids killed in the school by Taliban Terrorists!
My emotions are taking over my ability to channel my thoughts into a blog entry. Listening and reading dreadful stories of what transpired during the shoot out - pictures, news and interviews you are exposed to, more perturbable one gets. What are the parents of those kids going through? Oh God!
People asking me "Were the attackers Muslims?". My answer is "They were not even Humans!"
Such barbaric and heinous crime. It was reported by one of the survivor, one of the attacker said to another "I have killed all the kids, now what" to which the other attacker replied "wait for Army to arrive and we shall kill them next".
Have been grown up hearing all incidents and tragedies happening in Pakistan but this is the mother of all tragedies happened in Pakistan. This is our 9/11 - darkest day in this history of Pakistan. The price Pakistan is paying for eradicating extremism (in the form of Taliban) from its soil.
May Allah assuage the parent's suffering. May Allah protect the people from Pakistan from outside evil. May Allah bring the severest punishment on the attackers and the people behind it. Never under estimate the power of a Dua.
I advise people to remember the victims in your thoughts and prayers. I urge the people in power not to see this as an opportunity to pull a publicity stunt to score quick brownie points. Actions like candle vigils, donations, walk , etc - as long it is done with right intentions.
Media and non-Pakistani people responses were much to be desired but again it is time for us to stay united and not get carried away with trivial matter. Support system should be re-built amongst the countrymen that is more important as we got hurt the most!

Personal Insight into Project Management

[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.