You are on page 1of 1

The bits I learnt

Good judgment comes from experience, and experience comes from bad judgment. (Fred Brooks)

Project Management

Technology

Peoples Management

Risk-Based Project Management should be the primary focus - other parameters are of less priority Proper offshore infrastructure/tools need to be in place in advance for proper evaluation of deliverables - Force the higher management to proceed if necessary Artifacts should be reviewed by CoEs at every step/milestone A large project should have (1) a PL dedicated for overall management & delivery planning, (2) separate technology & functional(onsite) leads (3) A data modeler (4)an overall architect, (5) reviewers and (6) CoE personals (7) H/W specialist (8) Business Analyst at Requirement stage (9) Testing resources - all having a stake. Every key decision with the client should be in records Every key decision/event should be shared & discussed with the higher management & a nod is needed for a go-ahead. Flags should be raised & escalations to higher management whenever necessary - attack upfront & not wait to defend later Nothing should be treated trivially & neglected small issues may blow-up in bad times. Stuff which seem apparently trivial at times should be treated with utmost priority Say No to things which I know are risky & have no option to validate in advance. Consulting - Should be aggressive & attacking problems; come up with detailed suggestions not wait for the client to initiate threads if an issue has already been identified. Client should be insisted to do reviews even if they are reluctant. This should be encouraged to involve them as partners and stake-holders. Not doing it may be hurting later on. Too many concurrent threads for attaining a single goal may hurt - more of time-killing, less productive If client raises some flag, need to take it seriously first-up even if it appears not too serious at that point - prompt communication is necessary - no blame-game initially Given an option, avoid involving a team within the organization to cater/deliver a dependency item Proper Capacity Planning required when architecture is done NFRs should be treated very seriously upfront & proper aggressive strategy should be taken Before starting with any artifact (design, code etc) - standardization & performance guidelines should be in place. Reviewers will own the cleanliness of the artifact Functionality is first, but optimization of code should be a parallel process - every piece of functionality should be seen in the light of performance - starting from design, prototyping, coding. Tuning & continuous profiling should be done in parallel. Refrain from changing/upgrading technology intermediately Data Model should be as flat as possible for performance-sensitive systems - forget about normalization if necessary Tendency of over-protecting certain client stakeholders may backfire - should be done to a certain extent. However a team needs proper people to accept any challenge. All team members should be made aware of processes & quality practices - PL should not be overburdened - hurts the project & the team long-term Should not be too accommodative or too pessimistic in front of the client. Overstressing the team can be fatal Need to look into the personal gains of each team member at the same time need to have a monitoring system for everyone & set the expectation of give-and-take this is the key to success.

You might also like