Citisoft has made a name for itself since our earliest days in the implementation and transitioning of countless asset managers from legacy systems to new platforms and operating models. We have worked on some of the largest transition-oriented programs in the industry over the past two decades, and as a result, have stored up a fairly long list of lessons learned. For the purposes of this blog post, I have cherry-picked my own Top 10. The thoughts and opinions are my own; do not try this at home.
Without further ado, and in no particular order, here is my Top 10 Project Management "Lessons Learned, Pet Peeves and Gotchas":
- Steering Committee Meetings – I'm all for Steering Committees, don't get me wrong, but if I had a dime for how many times I've attended Steering Committee meetings only to hear everyone pat each other on the back or worse (i.e. crickets)……..well, you know the rest of the riddle. Think carefully about the composition of your steering committee, and don't be afraid to ask the tough questions.
- The Honeymoon Period – all too often, especially on lengthy transition projects and programs, everything is seemingly "rainbows and unicorns"; meanwhile, there are elephants lurking in the corners of most rooms, that are not getting pointed out. Project teams don't want to upset the apple cart, so initiatives remain in green status when they are often deep into amber, if not red. Transparency is always the best policy – communicate the real status and openly discuss project risks early and often. Don't wait until the honeymoon turns into a nightmare.
- Testing – When project analysis gets bogged down and development lags, what is one to do in order to hit that precious date? Well, shortening the testing period often does the trick. Granted, it also spikes your project risk to untenable proportions, but who is really going to call you on it? Your project Steering Committee? See above.
- Too many chiefs – I don't think I need to finish the phrase, as you likely get the point. How many times have I been asked to look at the resource chart on a major initiative and remarked "so who is going to do the actual work?" Too many times to count. Before you pencil in an SVP or Operations Team Lead into a Business Analyst or Workstream Lead position on a project, ask yourself two things – 1) Are they willing to roll up their sleeves and pump out the work; 2) When was the last time that they performed such a role on a similar project?
- Poor communication – nothing earth shattering here, except to state that over-communication as a policy is never a bad thing. Even if it's for cynical reasons (e.g. CYA), it's a policy worth following. Regularly scheduled status meetings, check-ins, milestone meetings, newsletters, video conferences, written status reports and the list goes on – they are all effective means of ensuring that project resources and stakeholders are on the same page. There is no excuse for not doing this!
- PMO 'Generalists' – in our area of expertise (Buy Side Investment Management Ops & Tech), it is an absolute must to have some level of domain expertise to be effective in the execution of projects. Those that feel otherwise, I would be happy to debate (tom.secaur@citisoft.com). Unfortunately, several organizations have turned the PMO into a 4-letter word and a trigger to commence with eye-rolling when their name is invoked. Some level of PMO involvement and pure administration is involved on every project, however don't mistake project administration for project management or leadership. They are two very different animals.
- Tech before people and process – it's a theme that runs through this Top 10 list – the rush and the impulse to move into implementation or go live prior to building the foundation and pouring the concrete to sustain your operation. "People, process, technology" is a common refrain, and we've all heard it; well, it should be thought of in that order. Make sure that you have a handle on your business and operating models prior to massive technology investments.
- Lack of due diligence – so what's the hurry? Why do firms with 100's of billions of $$$ in AUM feel compelled to rush into decisions that could take them years to unwind? Analysis does not necessarily lead to paralysis. Take the necessary time to ensure that you are making the right decision at the right time for the right reasons. Look at your decision-making process from all sides and evaluate the project and vendor risk. Spending time on proper due diligence is time well spent, plain and simple.
- Inability to prioritize and sequence properly – I could also call this one "the inability to say NO" when it comes to taking on yet another massive project that runs concurrent with several other invasive initiatives. At some point, you do quite literally run out of bandwidth, and everything else suffers – the quality, the morale, the budget, BAU, etc. Leaders need to make the hard decisions, and ensure that the right projects are getting the green light at the right time. Having to tell your business partner that they have to wait for that enhancement or new, shiny application comes with the territory – you can't please everyone, so make the tough decisions, execute with precision and vigor, and then move on to the next adventure.
- Resources, Resources, Resources – this should probably be #1, even though I instructed the readers to not pay attention to the order. IT'S THE PEOPLE, STUPID! Maybe that gets your attention. The fact is that the #1 risk to any project has to do with resources – call it bandwidth, resource constraints, attrition, etc. The fact remains that if you don't have the right names in the right boxes on your project organization chart, you are destined to fail. Start there on your next project and don't put it aside, until you are 100% comfortable with the project and workstream leaders that you designate. And don't be afraid to remove those resources mid-project that lose their effectiveness. You can thank me later.