Managing the largest project on the floor

I originally wrote this blog for a post on the IBM intranet but thought of sharing it on my blog as well. This post has been rewritten to ensure IBM’s confidentiality is maintained. Lastly – The postings on this blog are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

Does the thought of managing a multi-million dollars project give that “butterflies in the stomach” feeling?  When you know there will be more than 100 people working on it and you are the single point of contact, when you know you are the person with one hundred percent responsibility and accountability of the success or failure of that project, as a Project Manager, trust me the butterflies will soon find their way to the stomach 😉

This project was a major change in the existing software architecture. Think of it as a construction of an over-bridge over an existing road. You need to ensure that the heavy traffic of the existing road is not affected because of the construction. And not just that, you also need to ensure that the over-bridge is tested to be sturdy and large enough to handle all the heavy traffic which would eventually come to it as the road beneath is planned to get scrapped. And of course there were many other requirements and risks for which I cannot find an easy analogy as I wasn’t really dealing with an over bridge construction, it was after all a ‘complex architecture change in the software’. The project followed the waterfall model of the software development life cycle (pictured for reference)

I am thankful to IBM for this opportunity. The project of this size brought with it a bunch of lessons that can be compiled to an equivalent of a university degree. Let me share the top 3 lessons here,

1. The single biggest problem in communication is the illusion that it has taken place. (George Bernard Shaw)

Shaw could have been such a good project manager! 😃

Every Friday, a comprehensive project status was sent to the entire project team which covered everything from action items to open risks to change requests to dependencies. And ‘entire project team’ here means everyone, from the Managers that handle technical teams to the System Testers. It was totally astonishing when a Software Developer or a Tester would respond to that email with latest updates or queries because that affirmed that communication was actually taking place.

2. Stuff in the closet should be easily accessible

(And that is clearly not a quote 😉)

Handy information is something that can easily save 30 minutes daily. Since the size of the team is 100+ you are bound to receive 2 calls and 3 messages daily with trivial questions and you may not have the answer for those at top of mind. This will initiate a time consuming data search activity. How do you solve this problem? Enter the “Project Worksheet” which was created with separate tabs containing all of the possible handy information and it soon became the single point of reference for everything! I didn’t have to refer to the plethora of Project Management tools for the info as it was right there on my desktop.

3. The importance of understanding what’s important

In an hour long call full of technical jargons, it becomes important to understand at least the conclusion and circulate it to all the stakeholders via meeting summary even if its just 3 lines. On multiple occasions, I would request the techies to explain the issue in layman terms and it would turn out that the issue didn’t require rocket science theories to understand and solve. I learnt it was very important to understand what is an absolutely urgent and must deliverable item and what priorities number 2, 3 and 4 are.

This blog reminded me of one of my previous blogs about managing one of the biggest college events and the lessons learned from it, you can check it here – Unison 2010 – From my eyes

Also, if you want more on Project Management, check out my website PMCLounge.com