10 interesting lessons from 1 interesting project

I’ve spent six interesting months on my current project and my association with it is at last coming to a close. The design phase is largely over and I can finally move on to other things.

Like some sort of technological Santa Clause, I skip from chimney to chimney spreading good cheer, pixie dust and sooty footprints as I go. I like to think I leave happy families in my wake, opening the little ‘presents’ I’ve left behind to shrieks of excitement (or is that terror? I never can tell). I do know they’ll be looking forward to seeing me once more, no matter how much coal they ended up with in their stocking this year :-).

Anyway, this current assignment has been a most interesting project; as in “May you live in interesting times” and “Why yes, Nurse, this is quite an interesting case”.

Yup, that kind of interesting.

It’s a pity that most of the lessons that this project have taught me are of the political, managerial and interpersonal variety than those of the technical type! I’ve noted some of them down in this post, more as a reminder to myself than anything else.

A quick overview


The project aims to develop a Java based data entry application for a large Swiss financial services firm. The onshore team was from a German company (part of the corporate group) and the offshore development was handled in Mumbai. There are around 20 devs, 5 designers and various testers, managers and other assorted mischief makers. The project is now over budget, delayed and the quality of the deliverable is not up to snuff. The only reason there’s any hope of completing in time is because individually, the team members are very highly skilled. It’s just that getting people to work together seems to be very difficult.

I joined the project just six months ago, when the good ship INS T******s had already struck ice and was beginning to list rather alarmingly. I came onto the scene just in time to miss the preceding bit where most of the mistakes had been made, but just in time to start seeing their effects start to become apparent. It’s no fun joining a project and immediately realising that you’re going to have to fight your way to the lifeboats before long! :-)

Mind you, it’s not been as bad as some projects I’ve worked on, but in many ways it’s been even more frustrating, because success was so close, and now it’s oh so far.


The 10 lessons

1. People have to be aligned to project success

If people can succeed at the expense of the project, then the project will suffer. If you make it almost necessary for them to bury the project to further themselves, then stand clear of the stampede for the shovels!

People are not intrinsically evil. They want to do the right thing and they will too, if given the chance. However, if you inadvertently stack the environment such that the only way they can advance their own position is by stepping on someone else’s face, then there will be a lot of people wandering around with bloodied mugs. It’s the responsibility of the project manager(s) to align individuals and teams properly, so everyone is pulling together towards project completion and success.

Fail to do so and you doom the project to delay and possible failure.

Some things to keep in mind:

1. There should be no gain in shunting blame between onshore and offshore.
2. Onshore should not be allowed to ‘succeed’ by leaving offshore behind and vice-versa.
3. Onshore should gain nothing by show-casing itself independently before the client and neither should offshore.
4. Onshore should be reassured that their roles and jobs are secure and that they will not be ‘Bangalored’.
5. Offshore should not attempt to aggressively infiltrate and displace onshore. See point 4.

2. Architectural Vision is vital

You don’t have to nail down each and every detail before you start the build. You can back-track once the build has started and update the design to reflect new learning’s. However, you cannot start the build without having a very clear picture of what you want, how you want it and how you’re going to get it.

The first thing I noticed and flagged when I joined the project was a lack of project vision. No one really knew how exactly things were going to interact with each other or how changes to one component were going to impact another. There were a lot of things which were just up in the air and it was anyone’s guess as to where they were going to land.

A major reason behind this was the lack of a proper POC (proof of concept). Had one been constructed, the entire design and build stages would have been several orders of magnitude easier. If there’s one thing I’ve taken away from this project, it’s this:

Don’t skip the POC.

3. Never split tasks and teams across geographies

Take a stale, grilled cheese sandwich and start pulling it apart. You’ll notice that there’re all kinds of tendrils and gloopy bits and amoebic pseudopodia keeping the ends together. There’s also a rather distressing smell, but that’s orthogonal to our discussion (thanks be to God). Now if you pull the bits apart far enough, the tendrils start to snap and you’re eventually left with two soggy pieces of bread rather than a single, disgusting whole.

The communication links within a team look like those tendrils of stale cheese. There’s a tremendous amount of communication which goes on within a team. You simply can’t stretch those links across a continent and expect them to hold together. You won’t end up with one team, but two distinct teams.

Now if you acknowledge that and formalise the interface between the two teams, then there is no problem. However, if you ignore the separation you’re going to end up facing all kinds of problems, all of which can be traced to the narrow communication bandwidth.

In short, stack two sandwiches one on top of the other if you want, but don’t try to pull one apart. That’s just nasty.

4. If analysis is incomplete, it’s a major red flag

Is analysis incomplete? Are the analysts walking around looking sheepish and mumbling something about Agile project management? Well, then, start screaming now and don’t stop till they bundle you away in the coat with the wrap around sleeves. Electro-shock therapy is positively relaxing compared to what you’re going to go through otherwise.

Not convinced? Then be prepared for a constant stream of ‘defects’ which are simply holes in the requirements and specifications. Watch the analysts dodge and deflect criticisms as they desperately try to blame everyone but themselves. Laugh as the client tears the hair off his head in frustration. Cry as you work week-ends to try and reduce the defect count. It’s a never ending spectacle of terror and rage!

Coming soon to a project near you! Well, unless you insist that the analysis be up to snuff before you start to build the application. I don’t care how much the client is screaming, complete the analysis. To do otherwise will simply postpone the whipping, not help you avoid it.

5. You can’t estimate use cases which have not been analysed yet

Seems pretty obvious, doesn’t it? So why oh why did the drivers of this train wreck go right ahead and do that? Why oh why did they then commit on these fantastical dates to the client? And why oh why did we not fall over ourselves laughing when they wanted us to meet those deadlines?

6. If the onshore team has never done offshore before, it’s a major project risk

There’s a first time for everything and ignorance is nothing to be ashamed of. However, not recognising the lack of experience as a project risk and not mitigating it is inexcusable. Do not pass ‘Go’, do not collect $200. It’s straight to jail for you.

7. One month RUP iterations are too short

A one month RUP iteration may be too short. The team was always running to keep up, with hardly any time to breathe. With a one month iteration, you have one week of defect fixing from the previous iteration, two weeks of build activity and then one week for integration. Of course, you’ve not actually planned for that one week of defect fixing, so everything is running behind schedule from the get go.

You have to choose a pace which is sustainable. Anything else is asking for developer frustration, burn-out and murderous rampages.

8. Requirements – keep them simple, keep them consolidated

If you find yourself with more than 3-5 requirement documents in your design document’s references section, then you’re in trouble. Scattering requirements across too many documents means you’ll always miss something out and have to re-work it.

Keep the analysts on a short leash. Left to themselves, they’ll loose themselves in a twisty maze of interdependent documents, all alike. Only it’s you who’s likely be eaten by a grue, not them.

9. Regular, formal communication is a must

If the project can afford it, then get yourselves a full or part time secretary. Involve him in all your onshore/offshore meetings and have him keep the minutes and publish them. Appointing someone from within the team might also work, but people hate to keep minutes.

You need at least two long video conferences a week to synchronise on design and one quick sync meeting a day for the team leads and testers. Keep them short.

10. Constant reviews are a must

You have to keep reviewing project and team performance on a background thread. Someone has to have enough mental bandwidth to spend some time every Nth iteration examining all the problems faced in N-1 and apply any lessons learnt to N+1. Don’t expect the project manager to do this, since he’ll be too busy fighting fires. Ideally, this should be done by the delivery head or the project champion.


So that’s it. The project is limping along with the harried offshore build team chained to the oars. Morale is low and the pace is slow. However, it’s still likely that the project will be delivered in some form or another. We’ll have to wait and watch.

The only bright spark is that the onshore team (which I’m holding responsible for much of the mess here) has had their bonuses canceled and are going to be getting coal in their stocking this year. Now that’s something to put a smile on Sadistic Santa’s face.

Ho. Ho. Ho.

Socialize: del.icio.us | digg | reddit | Technorati | Yahoo My Web