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 :)

How do you measure success and failure of projects?


There are quantitative and qualitative ways to describe the success or failure of a project.

In general, a project is considered succesful when it meets its objectives while staying within an agreed up on budget and time line. This sounds simple enough, except that it is not !

First, who decides if a project is succesful? And if a project passes a series of tests and goes live, is it considered succesful? The common model is to celebrate success at go-live. But going live is just the beginning of the journey. It takes a fair amount of time to judge if the business got sufficient value out the project. Also, at what cost? Did they have to hire more people to support the implementation? Can they make enhancements to the functionality as requirements change, without costing an arm and a leg? Do we attribute this to the original project?

Since I am more familiar with SAP projects than non-SAP projects, let me quote examples from SAP area. In the nineties, SAP was not as rich in functionality as it is today. Many implementations had dirty modifications to source code to make it work according to requirements. These were called succesful projects at the time. 15 years later, these same modifications have caused the customers a lot of trouble in upgrading their systems. So do we still call them succesful?

Second, all stakeholders have to agree to a set of objectives that a project has to meet. Sounds simple enough – but then, it is kind of hard to accomplish too. First, there is the legal issue – if you cannot express it in a language that lawyers agree to, the objective will not be present in the contract. And if it is not in the contract – it is hard to ensure it will be met. Then there is the question of the definition of who a stakeholder is. In large projects, there are many people who are affected, and it is impossible to get them all enlisted to create a list of objectives. So a subset of people is assigned as leads or representatives, and they may or may not know how the new project is going to affect the work of the whole population. 

In one of my first succesful SAP projects, I remember going to the office the day after go-live and finding a large number of trucks backed up from the loading bay all the way into the street. Guess what? no one remembered to capture the requirements of the picking department – so they tried to do it the old way, like they have done all their lives – and then could not update the system with the results. Thankfully, we could solve it with some quick work around – but the point is – you cannot figure out every one’s requirements all the time in big projects.  Voice of the majority does not mean something is right – there are plenty of exceptions in every business process, and they all should be handled.  Consultants swear by “Mutually Exclusive and Collectively Exhaustive” – just that as scope increases, the chance for hitting this paradigm decreases.

Third – how do you agree up on project time line and budget? It is by estimation, which is an inexact science by definition. Based on prior experience, some one thinks that a certain task will take a certain amount of time to finish.  Just as the stock market has taught us that past performance is not a good measure of future (for the short-term),  there is no guarantee that these estimates will hold true across the life of the project. Techniques like PERT make us eliminate bias by using formulae that goes from pessimistic to optimistic. But as all experienced project managers will attest – estimates are best guesses, irrespective of techniques. 

Now – this means estimates have to be revised as projects progress and we have more data. But the question remains – if I estimated $2M today, and then re-estimated after 3 months to find that it actually costs $3M – is the project already a failure? The world outside the project typically looks at projects with this perspective. Once an estimate is made for time and money, then the world expects it to be set in stone, come what may. There is no room for re-estimation.  So most projects get into this situation that they are set up to fail from the beginning.

Finally, no project has unlimited resources – so scope and timeline usually is subservient to available money. This means some one has to prioritize scope. And in this process, some requirements will need to be dropped. Despite the due diligence in this exercise - it is hard to avoid a decrease in value to some part of the customer organization. But when the project finishes and these gaps get exposed – usually it is put as a failure of the project.

Now, I am not the only one to have this knowledge – most customers, consultants and software vendors know this. But why would not this situation change? Just a rhetorical question of course :)

South beach diet didn’t work for me, and neither did Agile development.


Normally, I would write this in my SCN blog – but this is not about just SAP projects, I am going to do it here. As always, these are strictly my personal opinions – not that of my employer.

Some of you have seen me  – at work, at some tech conference, dog show or at an airport. I doubt if “Agile” was the word that came to your mind when you met me. I could easily lose 20 pounds and have some one ask me “hey, why are you not doing something about your weight?”. You get the idea. I have tried many a weight loss / excercise plan – and have  come to the firm conclusion that the magic bullet for weight loss is to eat less of everything I like (Rice, red meat, fried food) and excercise more.

In parallel, I was going through a similar excercise at work – trying to find an optimum way of managing the projects I get to run. I have read and tried several different things over the years in a variety of projects. Over the last couple of years, I have been fascinated with Agile development and hence I have been reading, talking to others, and trying it out in teams I manage – and again, I have  come to the firm conclusion that, just like the various dieting schemes – Agile also does not work for me.

This is not to say Agile does not work for others . South beach diet must have worked for others, and I am sure Agile would too. For me – no sir, I will pass. That being said, let me explain why it does not work for me.

Would you pay an Agile contractor to build your deck?

I need a deck built, and I don’t know how to build one. So I hire some one else to do that. And this dude tells me he can do it one of two ways. 1. I can discuss with him on how a basic deck has to be built, and he can give me an estimate. Or 2. I can give him a rough idea, and he will start building the deck, and every day or two – he and I can get together to see how it is going and what changes I want, and I can pay him for work that he has done every day. Of course in the second option, he cannot tell me how much the deck will cost me or how long it will take him to build me one – but I can see progress every day. I don’t know about you – but I know what option I will go for.  Same thing with my clients – if the work and schedule are not predictable – it is hard for them to just pay as I go.

Global and Agile are like Oil and Water – They don’t mix.

I forgot the last time I had all the IT and Business guys and gals working in the same location.  Most often – we have people working on a project from all over the globe. It is seldom possible to get teams from Japan, India, Germany and US to be on a conference call. And even if you do – without a written document explaining the problem and/or solution – it is hard to get anything done. 

There are only so many super stars in this world

In any given team, the norm is to have a few super stars, several average performers and a few below average ones. This has a direct effect on pulling off delivery in an agile fashion. Not every one can go away with minimal instructions and come back with the right solution, and right questions to ask for next day. 

It can be argued that Agile needs less programmers, and hence you can keep just the super stars and let go of every one else. This argument works only if the scope is small.  The day still has only 24 hours – and even super stars  cannot work 24X7  all the time to get everything done.

Most projects do not have dedicated business users.

The whole idea of Agile is to get something back to business users faster than in a waterfall model, and keep them informed of progress frequently. This is very good – except it won’t happen in most projects. Most companies find it hard to dedicate full-time business people to a project. More often, business users have to do project work on the side. So – even if the tech  team wants constant face time , the chance of that working out is low.

A few product companies have tried out Agile successfully. However, in the couple of cases where I got a chance to talk to people from the team – it seems, the customer was almost never present in the scrum meetings. Instead, the product manager assumed the role of being the customer voice. If that is the case, I would have to wonder aloud “so what is new?”.  Product manager is not the one who has to live with the product after it is out – it is the customer.

What works for you –  people over process? or process over people?

This is what it boils down to – Agile manifest claims the superiority of people over process. And traditional waterfall puts process over people. For me – as a manager of big teams, with a deadline and budget that seldom cuts me any slack – I would trust a good process to compensate for the human errors most of the time. I think it is a high risk for me to trust that every one in the team will perform to the same high standards. Having a disciplined process helps me get the best out my team, despite not every one being a super star. 

Would you build a mission critical solution using Agile?

I don’t know – but I keep wondering if NASA would use Agile for designing systems for their next space mission? I somehow can’t see any application that is very important and deals with life and death, or dealing with large amounts of money – like air traffic control or stock market transactions –  to use Agile.

I hope every one knows about 3C. This was the big Chrysler project that was the poster child for XP (Extreme programming). Well, guess what – that didn’t quite work out. Check this out http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System  or just google and you will find several interesting takes on it.

Building a car and building a software solution have similarities in design. However, there are significant differences too. Just as it is impossible to build a car without knowing what exactly needs to be built – we cannot build a good software solution without knowing what the heck we are building. Otherwise, even if you follow Toyota manufacturing Process to build a Camry – you could end up with a Chevy Malibu.

Is Agile really good for long-term stability of a solution?

Most software is built by first putting a framework in place, and then building on top of it. It is the rough equivalent of putting a good foundation for your house. If you know that you will have a house with 2 floors – you will probably put a certain amount of concrete in your foundation. Now that you have finished the house – and for some reason, you now want one more floor – would you put one more floor without also doing some additional foundation work? And if you build by constantly messing with your foundation – I am definitely not going to buy that house or rent it for living.  Same thing with software – the way sprints happen from what I have seen, I doubt if it is possible to put a solid foundation in place.

It is fun, but is that good enough for customer to pay?

One thing I really like about Agile is that every one involved in it usually has more fun than in a waterfall project. This improves team morale and all the good stuff – temporarily. When you cannot get user involvement, or if a blame game starts – where there is no documentation to go back and clarify what every one agreed to, this fun does not always last. And fun for the development team, while important in a project, is not the sole reason why some one pays for a solution.

Waterfall is not such a terrible thing to do, as its opponents make it to be. And it is a big exaggeration to say the team does a very long design up front, and that user gets to see things only at the end. That is not how most projects run. Waterfall can also have users involved more frequently. Also, you can build in plenty of  feedback options and test driven development in a waterfall project. Also there are very strong visualization tools that can give the users a taste of the solution very early in the process.  For example – iRise is a great tool to use for that. Do try it out, and your whole perspective will change. Also, once you have a good change control process established, changing requirements can be handled very effectively.

So, when do I think Agile would work?

Despite all these points above, I am not an extremist when I think of methodologies.  In my opinion, Agile is going through a hype cycle exactly like how it happened with SOA.  Once the hype died down a little, we mostly figured out what is possible with SOA and what is not. SOA is great for several use cases, and terrible for others. Same is the deal with Agile.  Just because Agile possibly has the issues I called out above, it should not be inferred that Agile should not be used. If you have a bunch of highly skilled people, where the team has a clear vision of the end product, and/or where time to market is not such a big deal - all these challenges will vanish. Such a team can probably come out with a great solution using Agile. But in the type of projects I am dealing with – I don’t think Agile can succeed. 

Rather than take an extreme view of either/or – it is probably best that we let individual projects decide the methodology they want to follow.