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 🙂

SAP HANA – slowly moving out of hype into actual projects


2011 was when HANA hype was on over drive – it was along the lines of “HANA will solve world hunger by feeding entire generations on perceived future business value” . Every where I mentioned HANA, customers were pushing back with raised eyebrows. That did not stop SAP from selling HANA though. SAP customers do not typically buy licenses piecemeal – they buy a basket of stuff, and apparently HANA was in a lot of baskets, especially in the last quarter. This is not unusual buying behavior – it is the norm.

And then 2011 ran out. When I came back from vacation, I was amazed with the demand for big ERP projects. And right on its heels, came demand for HANA projects. Not isolated demands – many customers, some of them VERY big names – are now sufficiently intrigued to start pilots for HANA. To say the least, it has taken me by surprise – the pleasant kind.

There is a huge amount of misinformation on HANA that has been spread knowingly or unknowingly in 2011. I think the first half of 2012 will be spent setting expectations straight.

A very common scenario I am running into these days is customers that have custom built data warehouses in Oracle or SQL Server. These have thousands of Stored procedures etc. They want to find out how to migrate this over to HANA. Or more specifically – they want to know if there is a way to semi-automate the conversion of SQL of existing solutions to HANA’s SQL. If they cannot do that – the cost of re-inventing the solution in HANA from scratch is not something they seem to have an appetite for. I have pinged SAP to ask what they think about this. If you know the answer – please post a comment.

Another common question – “so we buy HANA as a datamart, then put HANA under BW as DB, and then under ECC – will this all sit in one appliance? do we need to buy more and more licenses and hardware?”. So far I have not had to explicitly answer this question. Funny enough – they look at the expression on my face and deduce the right answer magically 🙂

Basis experts invariably ask me “hey can we virtualize HANA? Can you put it on a cloud and offer us as a service? When will SAP support non-intel processors and other OS? ” . My answer usually is to point them to existing documentation. If they persist, I show them the installation files and how it can be hacked. That is the best way to deal with techies , right?

Landscape Sizing, HA and DR are all high on CIO agenda – they just want assurances that they can safely deploy this in production. This is a lot more easier now to answer than even a few months ago, since there are more options available, and we have more experience with sizing. This is also where people start getting an idea of the real cost in putting up a HANA system – and there is always an aha moment.

The other half of the aha moment comes from clients understanding there is no one HANA consultant who makes the system stand up and work. SAP started off by saying “HANA is an appliance” – and that is partly to blame for this. An appliance is like a fridge or a wireless router – you buy from a store, bring it home and it starts working after it is powered on with very few instructions. HANA is not a true appliance in that sense- and once customers get that, they realize it is like every other project. HANA needs multiple skills to pull off successfully – data modelling, BOBJ, Admin/security, ETL etc.

BW on HANA has captured the attention of several customers. SAP is doing a good job pushing it in the field. I met several field sales people at FKOM, and was amazed to see how pumped up they are to sell HANA. But more than BW itself – a lot of customers are waiting for BPC to work on HANA. I was not very pleased with the BOBJ integration with HANA initially, but it has improved and I know more improvements are planned. It is best for SAP to nail it before customers start several projects in parallel and stress out SAP support.

Many of my customers – and me too – are waiting eagerly to see how many companies will SAP parade at SAPPHIRE as live on HANA , especially for the BW case. If SAP shows a large number of customers on the key note stage, then we should have a great HANA year in 2012. Towards middle of the year, I think many more HANA projects will start – and not just small pilots. And If SAP does come out with ECC on HANA by end of the year, it will be an excellent shot in the arm. 2012 could well ramp into a terrific 2013 for HANA.

What does Apple’s outsourcing have to do with farming and manufacturing in Kerala ?


If you chop a tree for firewood, you should plant a tree to compensate. And you should do it even if you are not into the whole green thing. Or else you will be turning in your grave constantly when your children and grand children swear ad-nauseum about the trouble you put them in . But I digress.

So Apple outsourced a LOT of manufacturing to China. You should read this excellent NYT article http://www.nytimes.com/2012/01/22/business/apple-america-and-a-squeezed-middle-class.html?_r=1&hpRT , and feeling depressed after reading it should be expected.

Does that make them evil – probably not. They are a profit seeking entity, and they sell all over the world. They can do whatever works for them. Did China win that work because of cheap labor? yeah – they probably did. But the manufacturing did not flourish there solely because of cheap labor. It flourished because China has plenty of engineers, built an ecosystem around Apple’s manufacturing needs and then started offering that service to other companies. And then other innovative companies started investing in China to build manufacturing. The story repeats in concentric circles – and it seems to fuel itself.

Did America lose out big because Apple outsourced manufacturing? yeah – I guess it did. But Apple was not the first to do so. And neither is manufacturing the only thing that got outsourced. But did America get anything in return? yes of course. We can now walk into mega marts and buy things a lot more cheaper. We can walk to an Apple store and buy an Apple product much cheaper than if it was manufactured locally.And so on and so on.

So is this a fair trade off? hardly, in my opinion – if what is happening to farmers in Kerala is an indication.

Kerala, my home state in the southern tip of India, literally means “land of coconut palms”. And Kerala is a place where people eat rice in some form 2 or 3 times a day. When I was young – the state had a large number of vast rice fields and coconut plantations. Around the time I was in high school, this was not the case any more. Many farmers moved from growing rice and coconut to growing rubber. Rubber was a “cash crop” which fetched handsome prices from tire manufacturers etc. Fast forward to today. Keralites still eat rice and coconut based food 3 times a day, but they have to buy these (and most vegetables) from neighboring states for a huge price. And rubber values fluctuate so much that not many farmers got rich that way. As agriculture declined, the problem was compounded by lack of supply chain efficiencies in buying and storing food grains and vegetables. End result – farmer suicides started happening in an accelerated manner. Many of them lost their land and fortune and their loved ones. And prices still go up significantly most years.

While Keralites are extremely enterprising and capitalistic when they live and work outside their state, they are mostly left leaning when they live in Kerala. Manufacturing has steadily declined in the state, and it has become a consumer economy for the most part. The state has 100% literacy, and has extremely high standards for health, higher education etc compared to many other Indian states. But despite all of this – manufacturing won’t flourish there. Both parties (well, alliances of convenience is a better phrase) that typically rule Kerala are left leaning to various degrees, and both have strong trade unions which actively discourage manufacturing. Except for IT, I think everything else in Kerala that generates money has a union presence that threatens its existence. This environment is the prime reason why lots of Keralites get out of the state after their education, and live and work outside. I am one such guy too – who finished college and could not wait to get out of there. Due to many people leaving the state, there is a positive side too – these people send a lot of money back to their families that live in Kerala. So the consumer economy generally has always been excellent.

When I read the article on Apple’s outsourcing to China, the situation of Kerala is what rushed to my mind immediately. The long term implications are stark – once you let go of something you do well, you have to be prepared to pay the price. And you should be able to invest in something else to compensate for the long term repercussions. It is the price to pay when economy takes a global flavor. You cannot pick up your toys and go home arbitrarily when you don’t like the game after some time – you need to stay in the game and invest wisely for future. Globalization is not exactly a bed of roses – it is a mixed bag.

IT outsourcing is something I am very familiar with. If a company outsources some IT functions and uses the savings to invest elsewhere, it works great. If it just eats up the savings, and don’t invest elsewhere – it just won’t survive in the long term. Outsourcing might create other kinds of jobs too – like Apple being responsible for increased demand for AT&T etc and creating jobs there. Or the outsourcing companies in India creating jobs in the US when they want to get into high end consulting etc. Apple has a large consumer base in China – and makes money in that market. One day when tax laws make it attractive to bring that money to US, Apple might do that – and it will help US economy. It is pretty hard to judge – at least for me – on how much these indirect benefits will offset the long term costs. But at a minimum, it does offer some relief.

Outsourcing of manufacturing and IT and other things won’t go away – although in an election year, many might say it will. The question is how will we compensate for the long term impact ? There is no one magic bullet – it needs a lot of things to fall in to place – on both public and private sector. And sadly, it might not get much traction in US till the presidential elections are over.