Project Management is NOT for dummies

Leaders in everyday life

2016-03-01T22:28:00.000-08:00

Just like there are no perfect humans, there are really no perfect leaders. Effective leaders are those who are self-aware and consciously work on their limitations and also surround themselves with effective partners who can compensate for their shortcomings.
Leadership as a term has very romantic notion associated with it as mostly heroic public personalities typically representing a large group of people and fighting for their cause against someone else. While those public leaders are easy to spot and are appreciated generously, we cannot and should not forget those who are leaders in their everyday life. It is these everyday leaders that first lead themselves and inspire others around them day in and day out by their action.
Whether it is at work place or at home or among friends, here are some traits of an effective leader that I noticed:

Strives to be the best in whatever he/she does - Chasing Excellence
Self-aware - Understands strengths, weakness, opportunities and threats (SWOT) very clearly
Recognizes the talent around him and appreciates and elevates - not insecure about giving credit where it is due
Focused - Has a balanced view on life and never loses focus on his/her purpose and mission
Trustworthy - Has genuine interest in the people working with him/her and imbibes confidence in them
Leads by example: Inspire others by action
Can act with an edge - not afraid to take tough decisions and stands by them.

In short, you can spot a leader in your everyday life when you see someone with positive attitude towards himself & his work and influences others with his positive energy, integrity and genuine interest in the well-being of everyone around.

Emerging Trends in IT Outsourcing

2015-10-19T21:28:00.004-07:00

The global IT Services industry holds significant opportunities for industry players due to continued increase in IT spending. Disruption is evident in software and services delivery, business models, vast amount of money is being poured into startups of all stripes, the cloud, big data, entrepreneurial-ism, and constant innovation. Against that backdrop, companies can no longer rely on one-note value strategies.

Some emerging trends I see in this industry are:

Industry Matures

Tactical non-critical Operations as Cost Center to Innovative Technology Solutions as Business Accelerator

Increasingly, technology firms are re-examining the structure of their businesses and taking bold steps to squeeze out better financial performance. In the past, outsourcing focused on tactical, nonessential activities such as payroll processing or manned security stations. But the focus is shifting. Businesses are quickly realising that it is crucial to transition their application development streams from a cost center to a business accelerator to keep pace in the digital age. This transition is not easy as the operating environment and rules of engagement calls for a fundamental shift.

Pushed by companies to demonstrate not just business value but, also business advantage and edge, service providers have to build robust, highly tailored offerings that deliver economic, strategic, operational, and all round business benefits. Further, they have to differentiate their offerings by demonstrating clear industry or domain expertise.

Not Just about Cost

Although, the pressure to cut costs shows no signs of abating — it will increasingly share importance with more strategic drivers in the decision to outsource technology services. Increasing competition, pressure on billing rates of traditional services and increasing commoditization of lower-end services are among the key reasons forcing the software services industry to make a fast move up in the software value chain. The companies now need to be positioned to offer higher value-added services like consulting, product development, R&D as well as new digital technologies like social media, mobility, analytics, and cloud computing (SMAC) to survive and compete in this market.

Shifting from Delivery to Engagement

IT organizations concerned exclusively with service delivery will almost certainly be disengaged from the business and its problems. This may lead the rest of the enterprise to view such service providers as a temporary arrangement to help deliver some tactical low end deliverables. This poses a serious threat as such service providers fail to move up the value chain making them rapidly insignificant in this market.

In contrast, the business-engaged IT services organisation takes control of its destiny. Engaged and integrated with the business, it becomes an active and influential participant in solving business problems, thus transforming themselves from being just a delivery partner to a strategic business partner.

Complex Multi-Sourcing Engagements

The marketplace for outsourcing is far more varied than it was a few years ago, with competitors of all sizes operating primarily from India, China, Russia, Middle-east and the Philippines and offering their wares to customers around the world. Enterprises will look to outsource different parts of their operations and business to different proven experts to extract the maximum return on their investment. This increases the need for multi-service integration capabilities, called service integration and management (SIAM) or multi-sourcing services integration (MSI)

Where is "Critical"

Companies will be forced to carefully choose offshored sites to optimize a mix of factors: access to a qualified work force, access to technology clusters or academic institutions, access to desirable markets and the presence of a welcoming business environment. This means service providers should be ready to offer a customized multi-location service model to best suit the needs of the businesses so they can offer the “Best of Both Shores” (near-shore, offshore and onsite)

Outsourcing IT projects - What, Why, How, Who

2015-03-23T23:32:00.001-07:00

As I am working with a number of clients helping them setup a dependable and repeatable delivery process for their IT projects, the questions that most often come up are 'Should we outsource or not?" What to outsource, Why? and of course to Whom?

Offshoring IT Projects - Best Practices from Vasantha Gullapalli

Just in Time Lessons Learnt - My experiments with PMing myself

2011-07-12T10:11:00.000-07:00

All said and done, everyone knows Good Project Management is easier said (read 'preached') than done. In this post, I want to go over my experiences while managing myself as I was designing, developing and launching JITLL.

For some brief context, while working in the PM practice for the last many years, I noticed one of the most forgotten or neglected phase of any project is the 'Debrief' and the whole cycle of saving and sharing lessons learnt effectively is very much ignored, often costing us dearly in the way of many avoidable mistakes repeated again and again. This, I feel is pretty much the case in most companies across the world. Even in places that follow the practice of debriefing and capturing lessons learnt after a project completes, they are often stored in documents or powerpoint presentations that are hard to find when you need them. To extrapolate from here, I think this problem of not learning enough from our(and others) past experiences, applies to pretty much all walks of life. So, from this experience came the idea of this simple application - JITLL - Just in Time Lessons Learnt. More of the context and thinking behind this is here.

So, if we map back to the project management triangle:
WHAT: An application that allows people to share their lessons learnt in an easy to search way. The USP of the product is easy to share and easy to search. This is pretty much the extent of requirements I had in mind.
HOW: I knew I wanted to use one of the recently upcoming and talked-about frameworks/platforms. So, after a quick search and research, I zeroed in on Drupal since it pretty much met all my requirements, had decent sized production sites and a reasonably active developer support group. That is it, I really didn't know any Drupal, how much of it I would use and how much I would customize etc., Just, jumped straight in with the intention to learn, sink, swim and eventually build something. Along with building JITLL, my other main driver was to learn something new.
WHO: I knew the users were anyone who ever used the internet and had a lesson to share or was looking for some lessons to learn from. While this was too broad a group, I intended to target facebook users since they already seem comfortable sharing their experiences with the world. My users were my stakeholders who will yay or nay this app and my team was just me and myself.
I started this off more as a learning exercise for myself.. I wanted to get into Drupal, understand what it is, set it up myself and customize it as needed for this JITLL app. I started off with a pretty vague scope/requirements and no timeline for myself, but with some solid determination to complete it and not give up. How often do you in a real job have a project with no detail scope and no timeline at all.. While no detailed scope is very common.. in fact, it has become the norm now with most agile projects.. but, no timeline is never the case.
Setting up an instance of Drupal running on my localbox and learning enough Drupal to setup the vanilla version of the app took me about 2.5 weeks. I was now all pumped up and spent the following month in adding few more features and tweaking the theme and design.
So, in total it took me about 1.5 months from start to finish the initial version of the launch ready JITLL. Finish here means when I had it hosted and announced the URL on facebook. So, here is my account of the lessons learnt during this process:

Scope: Although, I didn't have elaborate requirements or designs, I knew the absolute must have's for the product from day one and added few more as I went ahead. But, once I had the basic version of the app ready, it was hard to decide when it was good enough to launch and which features/design explorations were worth delay..so, I just went with my gut. Taking the time to do bit more user research in this area might have helped.

Internet users these days are used to seeing, using many features on sites like facebook, twitter. So, going live without some of the basics can make it hard to attract users. So, make sure you don't compromise on these basic minimum even if it means a delay in timeline.
While the above is true, don't add features that don't necessarily make sense. For example, there was a bit of discussion if we should add friending and following on JITLL. I didn't because it just doesn't make sense. The USP of JITLL is that its an open platform to share lessons learnt in a way to make searching and finding easier. Moreover, why would users want to maintain another social network on JITLL? Instead, a chat feature would have been useful so users can contact others instantly about something they shared.

Some features are harder to add post launch: Once I launched the initial JITLL, almost instantly feedback from many users was that the site was too broad since I said "lessons learnt about anything under the sun".. so, they suggested splitting into different sub-domains that are more topical. From this came about Student JITLL and R2I JITLL. Adding this feature after JITLL was live was particularly tricky since I had to make sure the users already on JITLL were not disturbed.

Design: Design was my weakest link. Not being a designer myself, made design and UE decisions quite difficult. For the most part, I just went with my intuition and made sure I used some of the basic design principles I learnt over the years like:

KISS: Keep it simple and stupid
Users should be able to access most functionality in as few clicks as possible
Make the calls for action prominent and right on the first page

Development: Learning Drupal and developing in it was lot of fun. I spent a lot of time reading the forums and drupal.org site. Along the way, I learnt that for any feature, there is more than one drupal way to build it. So, I ended up spending lot of time in figuring out the right approach and/or changing the approach after using one and finding a better way later. Would I have saved time if I seeked a drupal experienced person? ... I think so, but the point of this exercise was for me to learn, so I decided to stick it out and learn it the hard way.
Launch: Launch in this case meant migrating it over to my hosting partner and setting up all the SEO stuff.
Post Launch: Post Launch has been an interesting ride till date. Lessons learnt so far:

Content, Content, Content: For any such user generated(crowd-sourced) content site, content is what attracts users to add more content. So, it is very very important to have a realistic and real strategy on how to populate seed content. Don't just assume your friends and family will do it.
User incentives: Announce interesting and creative incentives for users to both register and start sharing. You need to make it either fun or useful for them to register and share before they start realizing the full benefit of the product.
Soliciting Feedback is very hard: It is very hard to get useful feedback on design and product from users. Think of ways to solicit this creatively. You will be surprised on how hard it is to get honest and useful feedback and suggestions even from your own friends and family.

All in all, I think I accomplished the main goals I had for myself which was to learn and have fun...and the fun is never ending since I am continuously learning as I am now forced to get out of my comfort zone of technology implementation and ending up focusing more on product marketing, user interaction, etc.,

Professionalism - Whose job is it anyway?

2011-03-07T21:49:00.000-08:00

This post deserves a spot on this blog too since it shows when to give PMship a pass in lieu of some peace of mind.

Lessons Learnt - How to capture them and use them JUST IN TIME

2010-12-09T05:15:00.000-08:00

The way facebook and such sites - twitter, orkut, myspace have taken off is pretty impressive and they seem to have defined or rather re-defined what the internet means to us and have pretty much defined what 'social networking' means on the web and led us to web 2.0 and now web 3.0.
People have become more and more comfortable sharing a lot of their lives on these sites and where it becomes useful and interesting is that they share a lot of their experiences, frustrations, gotchas from which others can learn from. That said, there is still no easy way to search and get to these lessons learnt when we need them. For example, you remember that a friend of yours commented something about their cruise trip when they went on it few months ago, but when you are researching and about to book the trip for yourself, its not easy to navigate through pages and pages of facebook profile to find what they had said then. Experience tells us that effective ways to learn from past experiences is not just a personal issue, but is a larger issue for corporations. Given the constant churn of people and the fast pace at which business needs to be conducted in today's competitive market, most companies often struggle to make sure the lessons learnt from the past projects/initiatives are followed through effectively.From this issue was born the idea for JITLL - Just in Time Lessons Learnt. So, if this same topic was saved on JITLL and tagged appropriately, one could search for it using some appropriate keywords and get to it in about 2-3 clicks.
This is the value of JITLL - Save Pain, Gain Time. JITLL can make it easier to share, save and search the lessons, debriefs on an ongoing basis. Come, join me on JITLL and share a lesson, blog your experience and also send me your feedback to make it even better for you and me.

Safety Net

2010-06-19T05:22:00.000-07:00

Freedom is not worth having if it does not include the freedom to make mistakes: Mahatma Gandhi

In today's economy, companies cannot sustain and compete if they are afraid of taking risks and don't dare to travel the road less traveled. Now this culture of innovation and risk taking translates into the projects also getting more and more aggressive with the common theme being to get a lot done in the cheapest, fastest way. While there are reams and reams of books talking about effective corporate cultures that encourage innovation and provide the support structure needed to take calculated risks, having a right support structure for project teams and PMs in particular is not well known or talked about.

In most companies, the safety net/support structure needed for PMs and project teams is not explicitly set in place or is not well known so the teams often don't get to use it effectively. While, the PM needs to take and feel full ownership for his/her project, here are some tools and processes that I have seen help make the life of a PM less nerve wrecking.

1. Project Reviews: While the concept of having an external member review the state of the project to help provide a more objective assessment and suggest some improvements is fairly common in Consulting/Services oriented companies, it is not all that common in other companies. I cannot say enough about the value of these reviews and the key to making them useful is to execute them in the right spirit by the right set of people. Reviews work best if they are setup as a standard process across the company or group and done consistently and the results used constructively. If not done in the right setting, the danger is that the project team can become defensive and view this as some sort of performance review and will be hesitant to actually put forth the challenges and seek help. Project Reviews at a minimum are critical to be conducted upfront just before the scope and timeline is base-lined, during the execution phase to assess true status and review the plans for upcoming phases such as QA, Pilot, and during QA to review the QA metrics to assess quality.

2. Regular Status Reviews and Reports: Having regular status meetings and publishing status reports is a basic job requirement for any PM. However, if used correctly and consistently, these tools can help with proactive escalation of issues and risks along with forcing more active participation from the extended teams and business stakeholders in timely decision making.

3. Timely issue escalation: Apart from the issues related to the project artifacts such as scope, timeline, quality, etc.,which usually surface during status meetings and other communications, PMs also get to face quite a few people and logistics related issues with either the core team or the extended team/business partners. For these, the ownership is on the PM to a) identify these issues and b) escalate and seek help appropriately. This is easier said than done because the corporate structure and culture needs to support this and make sure such escalations are being heard and taken seriously and not viewed negatively. This is where a PM's experience, people skills and communication skills come in play so the whole process is handled constructively.

These are some that I have seen work and I am sure there may be other tools or tips that other PMs have used successfully. I would love to hear about them.. so, please add them here.

Different Project Management Groups

2010-06-18T12:02:00.000-07:00

In my not so many years of employment, I have seen different flavors of Project Management groups in corporations. In some cases, to make things more confusing, these different flavors are operational all at once in the same company.

I am hoping this post will clarify the difference to at least a few who may be just as confused as I was.

There are at least 2 flavors of Project Management Groups:

1. Delivery Oriented: These are PMs and Project Management groups who are assigned to and are responsible for the end to end delivery of projects. There are slightly different flavors based on how the project teams are structured -

a) Matrixed:

Most corporations today are highly matrixed in terms of organizational structure. In this case, the core project team is assigned either 100% or close to that and a number of ancillary teams participate as and when needed. The PMs are expected to navigate through a very matrixed organization of varied disciplines to get projects tasks done and eventually deliver the project. In this world, PMs have a lot of responsibility and accountability, but very little authority.

b) Project Based:

In most consulting companies, the Project Management practice is taken quite seriously and in those companies, for the duration of the project, the project team is a) dedicated to the team and b) expected to report to the PM. So, here the PMs are highly accountable and also have good amount of authority and decision making power.

2. Administrative oriented: These are PMO groups where PMs are viewed more as admin roles, pretty much responsible for corporate/division/department-wide project status reporting and are responsible for maintaining projects' resource allocation and such artifacts.

As you can see, both these roles are very very different in terms of work involved, skills needed and so one would have to be very clear on which position they are getting into before getting into it.

Levels of Project Managers

2010-06-18T07:29:00.000-07:00

As promised in my previous post, I will try to articulate the differences between the different levels/tiers of Project Managers - Project Manager (PM), Senior Project Manager(Senior PM) and Program Manager.

The descriptions here are based on how I have seen people progress through these roles and my expectations of someone filling in these roles. Also, the numbers (in terms of team sizes,etc) used here are not an exact science and they are meant to be used to convey the basic distinction in relative terms. So, don't take them literally.

Project Manager(PM): Most of the posts on this blog describe this role in depth. Basically, this is someone who can lead and manage project teams of about 10 people with 2-3 distinct tracks of work and somewhat well defined scope and solution (limited ambiguity).
Senior PM: This is someone who can manage either multiple projects at a time or few large/complex project of up to 20-25 people, 4-6 different tracks/disciplines, different locations and with a good amount of scope and/or timeline challenges. Clearly, some of the attributes a Sr. PM should have are strong leadership skills, ability to multi-task, delegation as and when appropriate, ability to handle ambiguity and ability to work in a highly political environment and/or under high pressure. So, many a time even if the actual scope/solution of the project is not huge, some of the other factors can warrant the need to have a Sr. PM manage it
Program Manager: Program Manager is someone who can oversee a portfolio of projects. What this means is to be able to work with the PMs and Sr. PMs managing the individual projects within the portfolio in defining consistent project management tools and processes and to be able to use those processes and tools to distill the overall health of the portfolio. Program Manager, often called Program Lead is also the first point of executive contact for anything related to the portfolio of projects. This means the Program Manager needs the experience and insight to distill through the individual project data (status, issues, risks, dependencies) and pull it up a notch to summarize for the executives, identify themes and synergies that need to be addressed at the higher level. So, essentially what makes a good Program Manager is the experience of having led different kinds of projects in the past so he/she can draw themes or identify issues/risks from patterns and the sharp business acumen so you can align business priorities to projects appropriately and make the right decisions about priorities as and when needed.

As you can see these roles are somewhat progressive in nature and the best way is to move from one to the other since the skills needed in one role are built upon from the previous one.

Of Analysts, Coordinators and Managers

2010-05-11T09:33:00.000-07:00

I decided to write about these three roles – Business Analyst, Project Coordinator and Project Manager because these three roles are often mistaken to all mean the same or similar thing, while in reality they are very different with different skill set and expectations from them.

Project Manager in the most simplistic terms, is the Captain of the Ship. He has the responsibility to make sure the ship is heading in the right direction to reach the right destination at the right time. He is the communication hub that needs to regularly communicate progress, current ETA and more importantly any course correction that needs to be taken.

For IT projects, there is also a role called Technical Lead or Architect that works shoulder to shoulder with the PM. I am sure there is a similar role in other domains as well – basically the domain specialist. The Tech Lead is responsible to make sure the path chosen is the right one, prepare the ship and the team for upcoming storms and generally make sure the ship doesn’t sink and reaches the destination in good shape and on time.

In most companies and groups, the above two roles are fairly well established although there may be slight variances in how much of the team management responsibility falls under the PM vs. the tech lead. But, the concept of these two roles having shared ownership of the overall on-time, on-budget quality delivery of the project is well understood at least on paper.

Business Analyst(BA): The official definition of this role is this. I have seen this being an official full-time role in financial firms and less in emerging media and technological firms. Typically, the PM along with the IA and tech lead is expected to fill this role. A typical BA cannot be assumed to be a PM because the BA focuses primarily in understanding and documenting the detail business requirements and translate them into functional specifications. BA is also not responsible for scope management and/or schedule and delivery management whereas the PM needs to always have an eye on these important aspects of any project. This is precisely the reason why some firms/groups think it’s necessary to invest in a full-fledged BA role that can focus on complete requirements gathering and documentation before the project management whip comes and starts chopping or amending scope in the interest of time and money.

So, net-net: A BA is not the PM.. there is a clear distinction in focus and trying to have the BA run the project as a PM is a clear recipe for disaster due to their fundamental difference in focus and DNA. PM can sometimes fill in the role of a BA but, given the inherent focus a PM has on scope and schedule, he/she may not be able to be a 100% BA unless he removes the PM hat at that time which is very hard to do. A BA’s job is considered well done if the business requirements and the corresponding functional requirements are well documented. A PM’s job just begins here and the PM’s job is considered well done if he delivers these requirements or some sub/super set of them within the constraints of the project. A popular career path for BAs is to move onto product definition and product management.

Project Coordinator: Going back to my initial analogy of the ship, in addition to the Captain and his Chief Commander, there are others who help coordinate various different tasks on the ship – like someone overseeing the catering services, someone overseeing the security services, etc. These are coordinators who, once given a task and detail instructions, can do the running around and coordination between different teams and get things done. Coordinators are generally not tasked with figuring out how to do something, but once the ‘how’ is determined, they are expected to execute the steps and get the task done. Again, there is a clearly distinction between Project Coordinator and Project Manager. PM is expected to clearly understand the what, how, who of the project so that he/she can work with the team to clearly chart out the path to the destination (a.k.a executable, trackable project plan). The PM is also expected to know how to track against this plan and be experienced enough to know when to call for a change in course. The Project Coordinator on the other hand, is focused on the task(s) he is given to manage and is expected to get them executed by coordinating with the different people involved. Project Coordinators can grow into becoming a PM with some experience and on-the -training since inherently they are expected to have the drive to deliver. But, trying to make a project coordinator become a PM too soon is yet another recipe for disaster that often happens in corporate world when we are exactly not sure how to distinguish between these different grades of project management personnel and how to assign them to the appropriate size/complexity of projects.

I will write in my next post about the distinction between PM, Sr. PM and Program Manager since there is clearly a difference between those three as well, although the difference is much more subtle and probably not as risky or detrimental even if mixed up (apart from just the frustration from the person itself for not being able to perform in their strength areas)

7 Habits of Highly Effective PMs

2010-03-04T12:43:00.000-08:00

These are my top of mind effective habits that a PM should have:

Proactive: Always thinking ahead. You have to anticipate the issues or roadblocks that can hit the team next day, week or next month and plan/prepare for them.
Effective Communicator: Crystal clear communication to the direct team, extended team, stakeholders and executives.
Balance between the forest and the trees: Don’t lose sight of the forest for the trees and at the same time know when to focus on the trees and the weeds.
Multi-task: You are a PM not because you choose what to work on, but because you have to work on all the things that make others’ work smoother.
Motivator: An effective PM is more a leader than a manager. Needs to be able to be a person the team, stakeholders and executives trust and look up to.
Calm under pressure: I cannot emphasize this enough, PM is the captain of the ship and needs to guard the team from as much of the external noise as possible and provide the most optimal environment for the team to keep progressing towards the destination.
Sense of humor: Don’t forget to have fun while doing all this and let others have some fun, laughs and good times.

I am sure there are more than just '7' must-have qualities of a PM and I have tried to describe them in some of my previous posts (here and here). But, feel free to comment and add yours to this list.

Project Management Methodologies - Common Sense Triumphs

2009-10-30T11:10:00.000-07:00

As anybody who is a half-serious PM knows, there are a lot of Project Management Methodologies that people talk about and supposedly practice. I have always been a firm believer that the fundamental practice of project management is lot to do with common sense and discipline than anything else. For example, a PM needs to know how to break down a big project vision into explicit tasks that can be estimated, planned, tracked, measured.. one methodology calls this ‘Work Breakdown Structure’ while the other calls it ‘Backlog’… but the actual process to get down from the Grand Project Vision to this tasks list is the same.

Anyway, the most heated debate in the PM communities in the recent years has been about Waterfall vs. Agile and ‘Agile’ is often construed to be ‘modern’, ‘fast’ and waterfall is perceived to be ‘old-fashioned’, ‘traditional’, ‘slow’. This post is to describe briefly my experience with both these methodologies and the intent is to prove that ‘methodology’ alone will not let you successfully deliver and what one needs to successfully deliver a project from start to finish is a solid understanding of “what, how, who”, hands-on experience in the basic project management competencies, lots of common sense and discipline that will make you pick and shape various aspects of various methodologies to work within your context. Each methodology has its pros and cons and environments in which it thrives vs. fails. Common sense is useful so you recognize this and adjust the methodology or methodologies to the context. Methodology has to fit the project and not the other way round (i.e. no project will 100% fit a methodology).

Common Sense Project Management Methodology

View more presentations from vgulla.

How I became a Project Manager

2009-09-16T14:00:00.001-07:00

Hi All,

Vasantha invited me as a guest poster to share my story about the road I traveled to get to the wonderful land of project management, so here you go.

I have loved computer technology since I was very young. My grandmother gets the credit for spurring this in me. She started the first BBS user group in Iowa in the late 70’s with a TRS-80 and continued as a BBS operator for more than two decades. She took me under her wing as she began collecting home computers and educated me (informally) throughout my childhood. I also went to a progressive school where we actually assembled our own version of an Atari 800 from salvaged parts so I got to learn a lot hands on. I was young then and of course video games were what interested me most. I started writing adventure games in BASIC and learned a lot about computer technology just trying to get games to install and run well on early PCs.

Eventually my fascination with games and HW technology lead to beginning a career in IT. For a while I couldn’t decide whether I was more interested in the infrastructure/hardware end of the technology space or software development and had a few jobs on both sides right out of school before realizing that I did not have the mindset to be a success in either one. I was actually on the verge of changing my direction entirely and leaving the technical field (as a career) altogether, what changed my mind was the first time I was given a team lead position on a consulting gig basically because there was no one else available to do it.

I was totally green and was given no guidance about how to lead or manage a project and surprise, I failed miserably. Despite this I actually got a taste of the complexity of dealing with a team of very (technically) bright people and a group of (business) savvy clients and something just clicked. I realized that the true complexity and challenge in development projects was in managing the people and the process more than just solving a business problem with a technical solution.

The first experience opened my eyes to the fact that you can have really smart people, completely capable of doing what is needed, dedicated to the success of a project and still fail to accomplish the goal, entirely due to not controlling/managing the process of getting work done (stakeholders and technical team members) well from inception through support of the finished product.

Thereafter I knew that this was the challenge and the game for me. I began to study everything I could on project management and software development methodology, theory and practice and devoted myself to finding out what works and making it work better.

I have often been asked to mentor new PMs and those thinking about taking up project management as a career. What does it take? It takes someone who can handle having no friends during a project other than the project itself. As a PM everyone is going to hold you accountable for the ultimate success of your project just like you have to hold everyone from your team to any stakeholder accountable. This means that you are going to be put on the spot constantly and you are going to have to do the same thing to others, even your superiors (if you know what is good for you in the long run).

This is a high stress position but for my part maybe I am genetically predisposed to this kind of work, as every time I have ever had my blood pressure checked (even in the midst of high profile, high stress projects) it has been better than average. There is a real rush that comes from winning this game (delivering the projects within the given constraints) and these days I win more than I lose so I get the validation I need to continue doing what I do.

How do I become a PM - there is no single path

2009-09-16T05:44:00.001-07:00

I have asked few of my colleagues who I regard as competent PMs to publish their path to PMship. Once you see a handful of these, I hope you will be able to extract some common themes and patterns on what kind of background and personality makes a good PM.
Look forward to posts from or on behalf of them in days to come...

How to become a Project Manager?

2009-08-28T12:17:00.000-07:00

A friend of mine asked me few days ago about how she could become a PM and specifically asked if there are any particular trainings or exams she can take to become a PM. Well, I know some people may disagree, but this is another fundamental difference between say becoming a software developer vs. project manager. There is only so much of the project management discipline you can learn from books, courses, etc. Its not like writing Java code that you can learn from books, practice a bit, take java certification and become a professional developer.. most of project management is something you learn on the job. There are some core skills that you can learn from books like different project lifecycle methodologies, different estimation techniques, different ways of planning and some tools that help track issues, etc. Since project management methodology and practices are so dependent on corporate structure and culture, there is always customization to the text-book version of the methodology in each company. So, a good PM will be able to recognize this and adapt what he learnt from books to what works in that particular context.
Anyway, staying true to the topic, I will just illustrate how I morphed from being a software developer to a PM and hopefully you will see some pattern here that you can follow or not follow to become a PM yourself.
- Move from Developer to Sr. Developer/Track Lead: As I mentioned earlier, I started off my career as a software developer. I was part of a team and pretty much worked on tasks that my team lead/PM assigned to me. During those innocent/naive days of developership, my team lead once gave this advice to me when I was hassling about some technical solution, he said 'Focus on the business goal and how that is being represented by our system. Once you keep that in mind, the right solution follows naturally'. I thought this was very useful because it forced me to think about the big picture more and more. I started asking more questions, taking on more ownership and the leads also started trusting me with more ownership since they were confident that I knew the context and would be able to take the right steps. Don't get me wrong, I think there is definite merit in focusing on the technology and understanding them/experimenting with them in depth, but somehow its probably my natural inclinations that came to play here that I started enjoying the business aspects, people coordination aspects of the project and took on ownership of such tasks. Once I got comfortable doing things much wider/larger in scope than that of a developer, I was given the opportunity to step up and play the role of a Sr. Developer/Team Lead
- Track Lead - Now, I started playing the role of team/track lead and quickly realized that this means being both the project manager and technical lead for my team. My team was responsible for some pieces of the big puzzle that the whole project was building. So, as I was playing this role, here are specific aspects of project management that I learnt:
- Estimation: How do I accurately estimate the work involved. I learnt from books about different ways to do bottom-up and top-down estimates, but I learnt the hard way that estimation is as good as the estimator. At that time, we had very little in the form of past metrics and so had to rely on what the developers say as their estimate and learnt the hard way that I need to make some adjustments to compensate for aggressive vs. conservative estimates. How to make those adjustments --- I think this is where background in the domain and experience as a PM become relevant and help in making those adjustments.
- Planning: Books taught me how to create a project plan in Microsoft project and figure out critical path and resource balancing, etc. Tracking to that plan and figuring out how to adjust for variances in estimates vs. reality, addressing real life issues like unplanned vacations, time-offs, change requests, etc is not something you can learn from books, but on the job itself.
- Proactive issue/risks tracking: This is something a book cannot teach you again. Books will show some templates on how to capture these issues/risks and how to communicate them. Its only while being on the job that you can grasp the true essence of what this means.. how do you draw the balance between being proactive vs. over-reactive.
- People management: Although my team was relatively small, this experience as a team lead taught me on the job about how to handle/respect different personalities, identify and adjust to differences in communication styles, how different people get motivated differently, how different people need different levels of management, etc
- Taking ownership: Learnt first hand what it means to take ownership for not just my work, but for my team's work as well.
- Track Lead to PM: So, once I played the role of track lead multiple times, I got the opportunity to play the role of PM for a small team..more specifically a Support team (team that was supporting an application). If you notice, as the track lead, a lot of my tasks were mostly internally focussed and this was the first time i picked up some of the external facing aspects of the project manager's role. Some of the key skills I learned during this time are:
- Delegation: Until now, as track lead I was both the tech owner and the PM for my track. Given, I took on the role of the PM for the entire team, I had to make sure the tech ownership was delegated to the tech lead and he was empowered enough to do the right things as a tech lead with enough support from me. This is another time when domain knowledge helps so you can complement the tech lead appropriately and also guide the technical decisions with enough business input and know when to question vs. when to let go.
- External communication: Being the communication hub for my entire project team and owning all communications going out of the team was a completely different ball game to what I was used to as track lead. I learnt how communicating even simple things like weekly status has to be paid attention to and how I need to keep the audience in mind and taper the level of detail in the message. In order to ensure the right message is being conveyed, I learnt how to figure out different communication preferences people have and how to keep these differences in mind while communicating.
- Building trust: This is by far the most important aspect of a PM's job. There is one thing about leading a team and whole another dimension to earn their trust and respect. This is definitely not something you can learn from a book or in any training. But, a combination of having the domain knowledge, competence and experience in the project management core tasks and a lot of people management skills is what will get you there. Building the client/business's trust is also another important aspect and again business domain experience, competence in your job, effective communication, integrity and honesty and lot of people skills will get you this.
- Business Negotiation: While playing this role, I also got to learn how to negotiate tricky issues like priorities, timelines, resources, etc effectively to be in a win-win situation. It is not as easy to communicate estimates and plans to business communities without overwhelming them and this needed a lot of practice and time before they started trusting me.
-Team Motivation and Drive: There comes a time in any project's life lovingly called 'Crunch time' when we have more tasks and less time and we need to use lot of motivating skills which in some cases may mean being the "food deliverer" or the "resident clown"...but, I learnt what it means when people say 'do whatever it takes'
- PM again and again: So, now that I was labelled a PM, I started doing it over and over on projects of different scales, different complexities and different problems.
Its hard to enumerate what each project taught me, but atleast this gives you an idea on how I first traversed from software developer to project manager.

It didn't happen overnight, it certainly didn't happen by reading books or writing exams, it was a combination of learning some basics from books, lots of learning on the job and being open and attentive to the feedback.

Chapatis and SEO

2009-08-26T07:23:00.000-07:00

This is a link to a post from my other blog. Although, it has nothing much to do with 'Project Management' as such, it helps in gaining some understanding of how websites operate and what helps drive traffic to websites.. definitely useful for project managers who manage web development related projects.

The Project Management Triangle - Not as mysterious as the Bermuda Triangle

2009-08-24T09:04:00.001-07:00

So, lets say you are now a new PM on a new project or an established PM on a new project or new to the company and so obviously new to the project... you get the idea.. you are new on this project as a Project Manager. When you think of all that the PM shoulders and owns, the thought of embarking on the journey on a new project can be quite daunting especially if its also a new company. As I have tried to articulate in my previous posts, there is no single recipe or even single set of recipes for Project Management that can assure you success. So, each project is almost like parenthood and all your past experiences only help to some extent in making the journey less painful. Here is another perspective on why I think each project is unique in its own way.

Anyway, in this post I would like to highlight three things that any PM needs to focus on to make this journey as PM as efficient and as productive as possible. These are outside of, but contributing to the actual core tasks that any typical PM performs like project estimation, planning, tracking, etc.

1. What? - The most important thing to have a full handle on as a PM is the 'what' the project's charter is - What is the business problem or opportunity at hand, why is it important for the business/client? What are the constraints within which the project needs to operate in? How is 'Success' defined for the project? From a project artifact standpoint, this helps you create the project's scope and understand the priorities for each scope item being requested. Once you clearly understand these you will be able to make more intelligent/informed decisions with regards to what is important and what is not and at crunch time what can be compromised and what cannot, etc. More importantly, the business/client will begin to trust you and view you as a true partner.

2. How? - Once you know the 'what', next is to understand the solution itself. This is why having a good foundation in the domain is very important for the PM so he/she can clearly understand the complexities involved in building solutions and be able to guide both the business/product groups as well as the implementation groups towards the right solution. Understanding the solution well also helps the PM in breaking down the project into smaller chunks that can be effectively distributed among the team, tracked and delivered to fit into the full solution. This also helps the PM understand the pain points or the risky areas and make sure lot more time and energy is focussed in those areas to tackle the issues before they start impacting the project's bottom-line.

3. Who? - Once you understand the 'What' and the 'How', the next key piece is the 'Who'. As a PM you need to be able to understand your team, the key decision makers, the stakeholders, extended teams, etc. Increasingly, corporate hierarchies are being more and more matrixed and it is often not as straightforward to understand all the players and their priorities. So, it is very important as the PM to take the time to know who all the players are and also build some relationships with them. Typically, a PM needs to interact with three groups of people -
a) the core delivery team on the ground that is fully assigned to and contributing day to day to the project,
b) stakeholders and decision makers and
c) interested parties who have some interest in the project and need to be kept in the loop.
The PM being the central communication hub needs to keep the interests of all these three groups in mind and keep them well informed at all times. In addition to the transactional business communication that goes to these three groups, the PM is also the one that is expected to keep the core team motivated and all contributing members aligned towards to the same end goal. In order to do this the PM needs to take the time to understand the individuals separately, understand their strengths and weaknesses, modes of communication/escalation, motivation factors, etc. I can write on and on about team dynamics and how to align teams for maximum efficiency and that is a different lengthy subject in its own, but clearly people management is a key part of PM's day to day job and taking the time to do it right can make a world of difference both for the teams themselves and also the PM and will be the difference between a team that works well like a well-oiled machine vs. a team that is limping through one post to other.

Again, what I tried to highlight here are the three most important aspects of a project that the PM needs to focus on that will make his core tasks follow naturally and will make his core job function as a project enabler/deliverer follow naturally also.

Is Project Management your cup of tea?

2009-08-14T11:20:00.000-07:00

I got into the Project Management position accidentally and was kinda doing the job even before realizing it. I know not many get into it this way and at some point before wanting to become or wanting to try this position, you may wonder what it is and what it is not. A lot of people want to become a Project Manager for the glamour of the title or with other pre-conceived notions associated with that career path. Depending on your personality, strengths and weaknesses some people are very well suited for this role and others not only not fit in but, can be miserable in this position and can bring other people down with them as well. In this post, I would like to list out some of the aspects in the day in the life of a PM that can help you evaluate and self-reflect if "PMship is your cup of tea' or not:

 Do you enjoy multi-tasking? This is key for a successful PM. At any single time, you will always have more than one priority to juggle. In addition, it is also important that you never lose sight of all these priorities and keep a clear head regarding the top ones for the moment and not get bogged down in one direction or the other.
 Do you enjoy working with people? As a PM, most of your time will be spent in working/coordinating tasks with others and very little time spent in doing your ‘own work’. In most organizations, the teams that the PM manages don’t necessarily have any reporting relationship with the PM and so the job of the PM to get people motivated and all aligned to work towards the same project goal becomes lot more tricky. Inherently, you need to enjoy working with people and to take it a step further, a good PM should thrive in team/matrixed environments and should be very much a people person who can bring the best out of each and every team member.
 Can you handle unpredictability in your daily schedule? A day in the life of a PM can get very unpredictable and you will have to spend most of your time in not just basking in the glory of things going well, but putting out fires and shielding the team from random events and external 'noise' that can distract the project. In other words, your life is very event driven.
 How organized are you? I am not trying to be judgmental here, but some people are just more organized in their presentation and communication and some others are very abstract and thrive on some amount of chaos and abstractness. As a PM, if not for you, you will need some amount of organization skills to be able to gather/collect disparate sets of data/information from disparate sets of people and distill all that into something that is relevant and easy to understand in the context of the project at hand. For this, you will need to have some core organizational skills and tendencies within you
 Taking responsibility: As a PM (or maybe true with any leadership position), you are responsible for your team’s work. How comfortable are you in taking on this responsibility and shouldering the stress involved in representing a team that is most often not chosen by you.
 Acting with an edge: I realize nobody voluntarily likes to handle difficult people or difficult situations. But, the difference is some people can easily accept that these situations are part of life and can take them in their stride and handle them calmly while others stress over them, lose sleep and health and just cannot get a grip over them. As a PM, you will have to deal with such situations regularly. You will be the one who has to handle any people or project related conflicts and communicate the tough message either to the team/individual members or even communicate bad news to the people up and down the chain.
 How well can you handle stress? Just like difficult situations, I know nobody voluntarily wants to get into stressful situations to enjoy them, but some people seem more prepared to handle them than others. An experienced PM is always prepared for the worst and hopes for the best and more importantly during those stressful/crunch times, he doesn’t lose his cool and can work with the team in a productive manner to get to solutions.

All in all, it takes a special kind of person to enjoy being a PM and excel as one. I am sure I must have missed few other traits or aspects... please comment or email me if you think of those.

3C's of Project Management

2009-08-13T10:16:00.000-07:00

What is a Project?: A project is a temporary endeavor, having a defined beginning and end, undertaken to meet particular goals and objectives, usually to bring about beneficial change or added value. Most people view a project as a designated set of tasks needed to accomplish a particular goal.

What is Project Management?: Project management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.

Who is a Project Manager?: : The person responsible for the project.

As you can see the definition is a Project Manager is very broad and vague. This is exactly why this skill or job is often misrepresented and misinterpreted too. Each organization defines this role differently, each project within the organization may have a different definition for PM, each PM carves his/her role differently... so on and so forth.
Whatever may be the exact role definition of the PM on a particular project, here are the 3 C's that make an effective PM:
1. Competency: By competency, I am referring two different competencies:
a) Industry/Domain Knowledge: Although the pure definition of project management is industry neutral, it is very important for the PM to have the domain/industry knowledge so he/she can ask the right questions to the right people to get the right answers and truly understand what is it that needs to be done, how to do it and within what constraints. It is the industry knowledge that lets the PM anticipate the pitfalls that can happen and be able to guide the team around them and also be able to prepare and plan for them proactively.
b) Core Skills: By this I mean expertise in the core project management tasks like project estimation, planning, resource planning, etc and the skills to use the right tools to accomplish these tasks.
2. Communication: It is key for a Project Manager who is the 'Go-to' person/communication hub for all people directly and indirectly involved with the project to be an effective communicator. He/She is the one who needs to be able to communicate up and communicate down and at each level make sure the right message is being conveyed so the right actions are taken.
3. Courage: The PM is the one who is viewed as the objective body that is ultimately responsible for the project and hence needs to be able to keep a clear head and judge the status of the project impartially and objectively all the time. He/she needs to not only know the details of what is happening now, but also keep looking ahead to be able to steer the ship in the right direction. He/She is the person who needs to have the courage and integrity to communicate not just the good but also the bad and ugly and be able to act with an edge and make the difficult decisions, have the difficult conversations that are needed to steer the project out of trouble.
It is ultimately about understanding a business goal, understanding how to get it done in the most optimal way within the constraints of the situation, being able to communicate at all levels, being able to motivate and direct people, being able to deal with stress, problems and being organized enough to make sure all that needs to be done is getting done at the right time.

What is this blog?

2009-08-13T09:59:00.000-07:00

As mentioned in my profile, I am an Engineer by education and started off my career as a software developer and have contributed to the delivery of many a product in various capacities and eventually settled down in the Project Management/Program Management (difference between the two will be a different post) space. As I have myself grown and learned this domain and witnessed many different good and bad PMs, I have come to recognize and appreciate the many different nuances of effective project management and now believe that 'Project Management is NOT for dummies'. Project Management is a discipline or skill that is needed in every industry and most of the tools, techniques, skills used to perform this job effectively are not domain/industry related. This skill or competency is often not fully understood and also the one that is very hard to measure which makes it kind of tricky to rank Project Managers and figure out who is good and who is not. I intend to use this blog to share a lot of my experiences and thoughts on this subject to help current PMs learn something new, prospective PMs think thoroughly and figure out if they are cut for it and all others to be able to understand and appreciate this skill.