Waterfall, Agile, Six Sigma…. And many other project management methodologies exist. PRINCE, PMP & CAPM and a host of other certifications exist. New ones are added every few years. All of these methodologies teach us how to manage & execute a project. You can get certified and credentialed as a Project Manager (PM). But does a certificate alone make a person a good PM? Conversely, does it mean that if an un-certified PM is less of a project manager?
I started doing project management back in the late 80s when there was no Internet. I do not even recall if there was a project management certification at that time. I remember learning the craft the old fashioned way: I went to the local library, checked out a book, read it and made handwritten notes. I then went on to practice what I learnt. My dear ex-colleagues and now friends, you were the guinea pigs through whom I learnt project management!
My experience with project management spans many years and a range of projects, from one-man to 100+ man projects, single-location to multi-country, with budgets that often went into millions of dollars. I led people located in the Philippines, Singapore, Sri Lanka and countries in the Western hemisphere. At least two of my projects crashed, a few went south but were salvaged, and a lot were successful.
Unlike disciplines that require adherence to a defined process to yield desired results, project management entails technical skills combined with a high degree of awareness of the intangible that the PM must recognize and manage, such as human factors, emotions, and the sensibilities of the people affected, among many.
As I completed more and more projects, I came to learn what worked and what didn’t. Other than learning from the typical mistakes of a rookie Project Manager, I learnt a key lesson: there is much more to making a project successful than ensuring you have the right Gantt charts, statements of work, UAT sign-offs, the burndown chart, the Agile train etc. If this was all that is required, then every project would succeed by simply following the prescribed process. But we know that many projects fail despite a seemingly sound process and certified project managers. Why?
Because project management is more than a science. After having led hundreds of projects, I realized that it is extremely rare for a project to not have challenges. In fact, I cannot recall a project that did not present its own unique set of challenges, like when the customer disagreed with the scope of the project; the expectations of the customer did not match reality; actual costs exceeded the customer’s budget, and the list goes on. No project management methodology or fancy certificates can address such challengs. It is the PM who has to recognize the customer pain points and address these. Convince the customer to buy-in and allay his or her fears. Reset expectations without compromising quality.
An important aspect of project management has to do with your own project team. Many projects are understaffed or do not comprise the right set of skills; the customer may be expecting a project to be delivered in weeks instead of months; and the team may not have the tools they need. So the PMr must use his acumen to motivate the team, manage their expectations and come up with work-arounds to address the lack of tools and resources. These are only examples of challenges a a PM must tackle.
Unlike disciplines that require adherence to a defined process to yield desired results, project management entails technical skills combined with a high degree of awareness of the intangible that the PM must recognize and manage, such as human factors, emotions, and the sensibilities of the people affected, among many.
Many years ago, while working with an IT consulting firm, I was assigned a project in Singapore, where a packaged ERP system had to be modified to meet the specific requirements of a major food manufacturing company. A week before the start of the project, and as I sized up the project, it became clear that the statement of work, the Gantt chart and resource allocation spreadsheets had become artifacts that did not resemble reality. There were two choices: Either reschedule and risk losing the order, or make it happen.
As a PM, I managed to reset the customer expectations by converting a single-deadline driven project to multiple deadlines, i.e. a phased delivery, also known. as “sprints” in today’s world. I convinced the development team that even with the departure of the SME and despite other challenges, they were fully capable of delivering a successful project. And I worked with management to devise means and incentives to help motivate the project team.
After working many weekends, late nights, and with unwavering commitment to the customer, the project was successfully delivered. We were three months late, but the customer still celebrated because we achieved the desired outcome and had his buy-in and input along the way.