Patient Zero’s 2 biggest Lessons Learned on ORICO…

Quick background…I used to blog quite often on Blogger but moved over to WordPress quite recently. Deleted the previous blog, because it’s content as an adult was cringeworthy… This is the first article; written as the author (me) goes through a transition (albeit minor) in his career.

I recently moved out from a large 100+ man, $3.4m + portfolio where I played the role of a Project Manager. Let’s call this project Orico (pseudonym – corporate red tape and what not). From an offshore resourcing perspective, I was first on board Orico, patient zero; and over the last year and 9 months gave everything to the logo and studied the full length and breath of it till the point of transition.

Here are a the 2 key lessons that I learned on Orico:

Remediation engagements are f***ing cans of worms – More often than not, when inheriting the shitty work done by an incumbent vendor, we are more likely to be eager to win the work (since there is another party involved and things need to move quickly) and could tend to forget basics; like am I okay to inherit, remediate and consequently own the architecture done by someone else?; or am I really happy with the fact that someone other than ourselves elaborated part of the requirements which we are to assume as gospel truth atop which we are to build a fully furnished product which we own?; or is it really in the best interest of the engagement and the client for us to waive off not having traceability between pre-constructed application and database due to poor documentation on the incumbent’s part? And these are just 3 questions of many lined up.

Do over? – Something I missed to suggest at inception was running a proper honest round of sanitization. Always, and I mean always, if you’re inheriting something – sanitize !!! Sanitize and spend time, money and effort into massaging your inheritance to a form you are willing to take 100% ownership of – be it for requirements, architecture or test traceability. Chances are you will own the incumbent’s trash somewhere down the line, no matter how indemnified through paperwork your ‘charming’ sales guy tells you, you are.

Cans of worms can be dealt with – so long as it is one worm at a time – As with all things in life, how and when you do something matters. Taking on a remediation engagement with unstable requirements on a fixed price contract is very easily the mother lode of bad ideas; given the fact that Orico had a very ‘fixed’ scope and ‘fixed’ timelines – triple constraints yo ! – But all  ‘fixed’.

What this means is that the people delivering the project will effectively have to bust their balls on a daily basis (to put it mildly) We took a few weeks for ‘DESIGN’  and came up with an end to end, project plan with 6 iterations. Having taken our time to clearly understand all technical and functional dependencies when making this plan we never saw the need to shuffle things around builds [SARCASM !] What’s interesting is that we constructed all modules that made up the whole system we were building in parallel.

Do over? – This is just my 2 cents, and I’d like to preface this by saying that I’m no expert in project management which means what I’m saying here could very well be hooey;

When the modules that constitute your solution have a natural business sequence (in this case Underwriting >> Claims >> Finance >> Reporting; ) I feel it would be best to drive construction respecting this sequence. You might compromise on how early you get to see end to end business workflows but you do get to build something completely, test what you’ve built in its entirety and see how well it fits with what’s already built of other modules (integration testing)

And what could have made this easier? – running things on top of a time & material contract – a smaller team fixing a module at a time over a longer time frame; making for a team of experts in ALL modules at the end of the day, better product cohesiveness and quality, lesser defects and lesser need for regression testing.

P.S – All this stands to reason, provided we do a solid sanitization run (as harped on before) and identify all critical functional/technical dependencies and integration points. This also doesn’t mean we lose out on the advantages of getting end to end visibility as soon as possible – it wouldn’t hurt to have a a smaller focused sub team on this…

Bonus:

All of these problems are non-factors if you have a team as awesome as I did on Orico. Not wanting to sound too corny, it was an absolute joy to have shared nearly 2 years with them. Mad love to them – Here’s to all the lovely memories and a successful delivery: