Analyzing Project Success – talent wins games, teamwork wins championships !

I am on cloud nine at the moment – our team successfully finished a huge big project go live in a “minimum fuss” way (THE way go-live should be) and I am getting ready to party hard with the gang.

It was a journey that started in the fall of 2009 – and the team is as intense today as they were 2 years ago. But the one thing that gives me more satisfaction than anything else is that there was no “us and them” between client team and “my” team apart from a contractual/legal perspective. I hold this as the prime reason for our success – we could have done every thing else right, but without this “joined at the hip” partnership – we would not be here today celebrating, and smiling ear to ear. Due to confidentiality reasons – I cannot disclose the client or the exact work we did, but I thought some one would benefit from my experience if I shared a few highlights from the project. If I manage to get the legal hurdles cleared, I will make a second post to complete the picture.

The client brought in an A team from their side – and the project was owned by a senior executive from business. Both business and IT leadership reported to her. Consequently, everything was done with the sole objective of making sure business got what they needed. The Program manager, technical manager, development manager, architects and project managers were all great people with great domain expertise – and they all wanted to “get the job done”. Even when they disagreed (passionately), they had the maturity and trust in each other to discuss and get to common ground.

Right from the start, we partnered at all levels of the program organization – from developers to sponsors. We had several hiccups along the way ( attrition issues, technical issues, relationship issues etc) – but since we had strong relationships, there was no difficulty in having honest conversations on what is happening , and how we are going to solve it. In a large complex program spread over multiple locations – this is critical. Nothing was ever hidden in status reports – full transparency, and joint plans to solve problems, and joint parties to celebrate successes .

A fantastic example of the partnership that I remember on top of my head was when we were finalizing scope early on. I, and another person brought up a discussion that the number of reports to be developed looked out of whack based on past experience. The leadership team took it seriously, and went back to discuss more on this – and came back with a scope that was about a third of what was originally proposed. They identified redundancies, and lower priorities and diligently worked through to save the project a lot of unnecessary work. I had made this recommendation on reducing scope, despite it meaning my team will bill significantly lower hours and there by make less $$ . The point is – $$ billed is not the biggest success factor for a consulting company. The primary goal for the consulting company is extremely high customer satisfaction leading to long term partnership, and being elevated to ” Trusted Adviser” status with the client. My mentors taught me that lesson early in my career, and I try to teach that to the next generation of PMs that come after me.

Change requests have a big bad name in project management field, especially with analyst community – and the word on the street is that SIs use it to milk a client dry. I never had any trouble in this regard – all changes were discussed in detail and agreed on, before we proceeded with any change requests. Every change had full justification and agreement, and I am very proud of the fact that not once in the whole life of the project did any one have to say “lets see what the written contract says”. That is the beauty of having a solid relationship across all parties involved, and a solid process to govern the project change control.

As I look back in time, the one thing that strikes me most is the sheer number of people who learned valuable skills and experience in the project from both client and our side. Leadership is all about empowering the team , and delegating authority and not just responsibility. While the project had a well defined escalation path, a lot of decisions were successfully taken by people closest to the issue, with appropriate heads up given to management for integration purposes. Having gone through this experience, I am sure we are all well positioned for success at whatever comes next in our careers. It gives me a lot of satisfaction that a lot of leadership talent was identified and nurtured through the program.

One thing I learned in the course of the last 2 years is that there is no one-size-fits-all way to motivate a big team. Some get motivated by money, some by getting additional responsibility and visibility, yet others by periodic change of roles within the project and so on. My project leaders and architects are exceptional – they found what made every team member tick, and acted on it, taking my help where needed. I still remember being fascinated by developers in my team pretty much competing for fun on who will find the most bugs, who will fix the most bugs and so on – over weekends and holidays, on their own time. How awesome is that? I could not be more proud of my gang – they rock. We have our fair share of disagreements – but team work and a common goal of making the project successful, ensures we get over them in the shortest time, and healthiest manner possible.

Last but not least – there is a lot I am thankful to my support staff, ,my managers and my mentors. A two plus year project of this size meant that I had to ask for help periodically. They not only gave me support and guidance behind the scenes – they also came in person and celebrated our successes. They cared – and we appreciated that a lot, and it is a lesson we will take with us as we progress in our own careers.

Most people who read this would have made an assumption that this was an SAP project – with me being an out-and-out SAP guy, and an SAP mentor and all that. Well, this was NOT an SAP project. It was my first non-SAP project too. I am an extremely hands on person when it comes to technology – but I had to learn to trust the technology experts on this gig. It was very unpleasant for me at the beginning, since I am used to providing a lot of technical input to my team in SAP projects . But I learned that there are many people with MUCH better technical talent than me – and I should just trust their judgment. That was a HUGE lesson for me, and one of the most important ones I learned. Of course I did not learn it fully (yet) and occasionally jump in and make comments based on what I think are corresponding scenarios in SAP 🙂 . I must also say that this has made an impact on my view of SAP. There is a lot SAP practitioners can learn from the non-SAP world, and I am glad I now have this experience under my belt.

Success is multi-dimensional. A lot of times projects get measured along time lines and budgets alone. We surely managed by SPI, CPI etc – but that was just one of the many dimensions. We were clear on conditions of satisfaction, and both my client counterpart and I were committed all the way to make sure we kept each other in the loop on what is happening. It is a professional relationship I cherish, and I am sure it will continue past this project too.

As Michael Jordan said ” Talent wins games, but teamwork and intelligence wins championships” . I second that – 3 cheers to the team ! There is more work to be done for remaining phases of the program – but for now,let us Party 🙂