A Case for Professional Project Management

There have been more than 4 years since I've started managing projects, one year since I took my PMP and 4 months since my PMI-ACP. I have shipped 4 big projects so far, I've been involved in many others and I have recently been appointed as the head of video game production in Ubisoft Kiev. All my professional life I have been involved in projects, most of them with many stakeholders, distributed around the world.

Whenever I think back to what I could have done better in various circumstances, two things stand out: I could have better controlled my area of responsibility through more standardized PM practices and, by being more in control, I could have acted more responsibly on various occasions. While clear, standardized processes do not guarantee neither project success nor the sense of ownership and responsibility that every project manager should have, they are liberating. They free the PM from the burden of reinventing the wheel and let him focus on the project at hand - contrary to the wide spread belief among unexperienced PMs that standardization is a burden the corporate management enforces on them.

Throughout this post I will discuss why Project Management is so important and why standardizing its practice within the organization can be of benefit to everyone involved. At the end, I will discuss the two blockers one can face when trying to spread the practice.

The promise of Project Management:

“Today, project management is more than a position or a career. It has become a mind-set, and it turns up in every corner of the business world. Every company is trying to manage its resources as closely as possible and project management is an essential part of that effort” - Project Management For Profit, Joe Knight 2012

In one sentence, the discipline of project management is about acting preventively, proactively and responsibly when leading a project. While great PM still has many intangibles related to human interactions, intuition, communication, talent, the discipline has evolved from magic to science, with tons of best practices, patterns and processes.

So, before asking yourself whether you need PM in your organization, ask yourself if you can afford:

• Multimillion Euro projects being led without a certainty that they will ship on time and on budget.
• Bad reputation of not being able to deliver. Mistrust.
• Poor communication and unhappy stakeholders
• Not learning from past mistakes.
• Not utilizing the investment put in past experience.
• Leaving managers without proper support when they manage multimillion euro budgets.
• Overtime, the cost of burnout or that of leaving personnel.

The promise of project management lies in having a scientific, measurable solution to the problems above. Great project managers are not magicians. They don't have a magic wand.They are trained professionals that you can trust. They will be able to explain you very clearly what value they bring to your organization and how they do it. They will talk about objective measurements, they will talk about process, about best practices. Their promise and their craft is to show you transparently what they do with your money and what to realistically expect in return. In a word, deliver expected results, transparently. Among others, they will talk about:

• Building and managing budgets and plans
• Following completion
• Identifying and managing risks
• Communication and keeping stakeholders happy
• Continuous development of staff
• Organization, structure, process

Why standardize? What if projects are going on well already?

The first question that comes to my mind is "what do you mean by "going well?"". How do you measure it? How do you know that a project is achieving maximum performance in terms of cost, schedule, quality, stakeholder satisfaction, risk, staff development? How do you know that you are getting the maximum from your investment and how do you compare projects?

In order to survive, a company needs to lead. Leading companies are the ones that have the initiative, the vision and the means to succeed. Profit and talent follow the leaders. Ideas worth nothing without being materialized, so leaders excel at execution. As PM sets the framework for delivering results, leading companies have PM as one of their core competencies - either explicitly or implicitly. Leading companies:

• have trust from our peers (ship on time, stick to commitments)
• learn from their past experiences
• secure the learning process and reuse it in future projects
• secure the talent
• optimize talent usage
• optimize budgets and timelines
• predictably deliver value

The promise of standardizing project management is to achieve all that, including:

• induction of newcomers to PM (and not only) and short, predictable ramp-up for them
• easier access to PM knowledge and lessons learned
• less burden on project managers who do not have to reinvent the wheel (processes / forms / metrics)
• a baseline for common understanding and expectations
• tracking of performance based on objective measurements
• continuous improvement

Above all, it shifts the emphasis from magic to science and process across all projects. Because of this extra transparency, everyone with an interest invested in the well being of the company have only to gain:

• Company management
• Visibility on progress
• Trust in their teams
• Less administrative burden
• Extra value added for customers
• Project managers
• Lessons learned
• Proven, transmittable processes
• Knowledge base
• Standardized forms and metrics - not have to reinvent them
• Simplified induction of new PMs
• Learning and sharing among PMs
• Team members
• Continuous learning
• Visibility, clarity, predictability, security
• Ground rules
• Trust in the company
• Customers
• Trust
• Clear deliverables
• Clear expectations
• Clear view on progress
• Involvement

Therefore, I personally do not see any reason not to standardize PM across all projects within a company or department.

What stops companies from standardizing their PM practices?

I believe that the blockers lie mostly in two areas:

• Misunderstanding about the role and the job description of the PM.
• Resistance to change.

Unfortunately, PM is a very misunderstood practice. I have seen a lot of people calling themselves project managers when what they really did was process work. The person who is providing the same technical service, over and over, to multiple projects is not a project manager. There's no such thing as office project manager for someone who is doing office maintenance work. I believe some people add "project manager" to their title just because it sounds nice, without knowing what it is about and contributing to global misunderstanding about the term. Doesn't help much either the fact that projects vary widely in size and impact, ranging from school-type assignment to multimillion, multinational enterprises.  Thus, in real life, the term "project manager" has been diluted and it does not say much about what the person's expertise is. To counter any doubt, I believe that it is up to the true PM professionals to explain what they do and by what metrics they should be measured.

Other than that, even in well established project organizations where PMs drive significant projects, it is not always clear why the practice should be standardized. Instinctively, nobody wants a new manager, nobody wants to be directed on how to do his / her job, nobody wants audits and process rigor. It seems easier to escape in the fog of "the magic practice", without clear measurements and standardized processes. Even more, as standardizing involves more work in the beginning (after all, it is a project per se), people are reluctant to take it on when their schedules are already fully loaded.  PMs would need to learn more - which is not always comfortable - and be evaluated on new metrics - on which they may not succeed that well. All these trigger the resistance to change especially in the people that would benefit the most from the standardization.

Standardizing PM is a project per se.

In order to succeed in standardizing PM, proactive managers should convince top management about its benefits and gather support for their project. They need a strong sponsor and an experienced PM. They need to provide a plan, they need to provide metrics for measuring success and progress. They need to have an approved budget and time for the people involved. Standardizing does not come free, as it requires employee time, trainings, materials. Its objectives need to be very well defined and monitored and have a designated responsible with enough power to set things in motion. Of course, it needs to be properly managed so that it becomes a success story, an example of a "perfect project" for the organization. 

Companies need to be aware that standardization is not a one-time effort. After all the practices are set in place, a budget should be allocated to maintain a structure to monitor continuous deployment of PM internal standards, audit projects, evaluate PMs, archive lessons learned and dispatch them, train new employees and evolve the practice within the organization. As with everywhere, quality, security and trust come at a price. The good news is that the price should be far less than the benefits.

Good luck! :)

My Story - The Beginnings

Early next month I will turn 10. 10 years of professional employment, in various roles, industries and working on various technologies. I am also turning 13 since I've discovered Java, 14 since I've started with C++ and 15 since I've first laid my eyes on a programming article out of conscious free will (see note 1). While my last 7 years were mostly dedicated to game development from which 4 to management, I remember my first days with great pleasure.

I woke up this morning remembering my past experience with computers. It is not something I highlight in my CV anymore because it happened already too long ago but, nevertheless, it is still a fundamental part of who I am and how I've shaped myself.

Spectrum days:

It all started when I was very young (I would say 8-10), when my parents brought home a Spectrum-compatible personal computer. Back then, programs were loaded onto audio tapes and programming was done in Basic. I got a book with games (source code) and I remember typing them in and trying to run them. I had no idea what debugging meant, so all I did was to input the instructions one by one, as carefully as I could. I remember how my father helped me debug some of the programs. I was also writing some small programs by myself - again, taught by my father who was hooked by the possibilities opened by the personal computer. I remember drawing cones from a series of radius-decreasing circles - the "for" loop. It was more than 20 years ago.

Fast forward 4 to 6 years and, in 1995, I got my first real PC. I was 15 and I started using it for playing games and composing music.

First lines of code:

Two years later, in 1997, I met a real programmer. I was visiting an aunt and she introduced me to one of her former students who was a professional developer. I had a brief introduction into the world of Delphi and Windows rapid application development. Around the same time (July-August 1997) I first laid my eyes on a computer magazine article on Javascript and dynamic content in web pages. It was the time of Netscape Navigator and client-side Javascript was absolutely cutting edge. I was fascinated. I remember reading the same article over and over again for hours. It made sense for me.

Few months later my parents brought home Visual Basic 5 and a Visual Basic book. I took the book, I installed Visual Basic and started to learn. My first complete application was a drawing Paint-like program which used the native Win32 function FloodFill to fill shapes. I particularly remember this detail because, for me, being able to access the powerful native Win32 functions was like magic. It was what real programmers did. Immediately after, I wrote my first game - a Tetris clone.

Visual C++

I don't remember exactly how, but I remember stumbling upon a Visual C++ book in my personal library (Visual C++ For Dummies). Soon, I got hooked by the power of native code and the promise of absolute speed. I knew that if I wanted to be a real programmer I had to go the C++ way. I was 18 and the year was 1998.

I remember clearly reading about input and output streams, about linked lists and pointers. Linked lists in particular were a major stroke of insight because, at that time, they seem so hard-core, so close to the machine, such a powerful data structure. I remember that I was in vacation, that it was summer and very hot.

I quickly moved to MFC and Win32 programming. I got a new book (Visual C++ 4) and I started the long way of coding native UIs. I remember the book was mostly about all sorts of wizards the environment provided to assist programmers in writing the UI code. I didn't like the idea of having code generated for me that I didn't understand. So I started from scratch to write a MFC application without the help of wizards. Once I got the main window up and running, with menus and the ubiquitous "About" dialog, and I knew I had to do something with it. Around the same time, one of my friends, Iulian Ursache, invented an algorithm for parsing and evaluating mathematical expressions. I had the window, he had the algorithm so we met and worked together to write our first Win32 function plotting application. It was such a breakthrough! We were one year away from finishing high school (1998).

First commercial product:

The same year we had our first entrepreneurial experience - we developed a multimedia CD for our graduation. I remember people looking awkwardly at us when we were asking for money. It was my first experience with a commercial product that had to work on more than my machine. It had an installer, it was distributed on a CD-ROM, it had HTML content and a Visual Basic application that integrated Internet Explorer. I remember that half of our colleagues had problems running it but, in the end, we were able to ship it. Good for us, because we had already cashed their money.

Java days:

Soon after finishing high school I started learning for the admission exam to the University. I remember my parents leaving me home to study and myself sneaking in to the computer. I had discovered Java and I had finished my first Java game just days before the exam. I was 19 and it was a Minesweeper clone.

Briefly afterwards came another Java board game and yet another board game on Linux (C++ KDE application, written with KDevelop). I am mentioning all these technologies because, back then, every time I was stumbling upon a new development environment or operating system I had to write a program for it). While the first application taught me about the branch-and-bound algorithm, the latter opened my eyes towards A* search and heuristics.

While I use the "I" pronoun quite a lot, we were actually a group of friends interested in programming and operating systems, and we talked a lot about these subjects. They, for instance, opened my eyes to Linux and to many algorithms and techniques.

The next two years were mostly dominated by Java - a function plotting and curve fitting application written for the physics department at the University, a second commercial application (a website with database support) for the company my father was working for, and many smaller apps and games. Java was very useful for me as it got me the power level I wanted, the extensive library I was looking for, the ease of coding that allowed me to finish my apps within reasonable time and a simple distribution environment that did not require extra installers or additional dependencies.

My first employment:

In 2001 I got my first summer job as a programmer; I wrote multiple apps that were then sold on the Elance website: an HTML editor with syntax highlight, a visual editor for CSS and a DWG (Autocad) file viewer using the OpenDWG library. I remember perfectly those days as I was excited to work with other colleagues side by side, coding together more for fun than profit. Back then was when I first got introduced to OpenGL and the NeHe tutorials (now in the legacy section) as my former manager was coding a 3D chat application. A new stroke of insight - 3D graphics were not a miracle and, although difficult to work with, not something outside human reach.

In 2002 I landed my first full time job. I was halfway through the University and I had to combine both work and studies. That was exactly 10 years ago. I started off coding C++ on Linux, writing a voice recording application. I remember my first assignment was to develop a driver for a National Instruments data acquisition board that was used by the app. It was kernel development and every time it crashed I had to reboot the system. Around the same time, I got my first lesson in customer management. The job asked us not only to write the code, but also go to the customer, install it and provide support for it. I remember that we had to call him every two days to get information about how the system was functioning and ask if he needed any help from us. We were a team of three, all students, all of the same age, all friends. The company manager gave us free hand and we had no team leader to guide us. Beautiful days, with lots of things to learn; a mixture of Linux, Windows, C++, Java, C# development, more oriented towards fun and interesting technologies than to actual business requirements. Crazy days and some nights spent in the office.

My first 3D game and the move to Bucharest:

During the same period I was involved with some other interesting projects: a regular expression parser and interpreter, a website and my first Perl CGI scripts, a 3D Tennis game (I remember spending weekends locked in my room coding on it), I learned C# and I coded a parallel maze searching algorithm (I was more excited about maze generation than the parallel search, to be honest), and many more.

Then, in 2004, I graduated University and moved to Bucharest. I started as a Web Developer managing an application for a British client. Soon afterwards I saw the job announcement for Ubisoft and I got a job there. In Ubisoft, I participated in quite a few projects, working on physics, animations, AI, pipeline, network synchronization. I got into the lead programmer role in 2007 and then, in December 2008, I became Producer. Soon I am going to finish my 4th project in this position, still working with Ubisoft, but with a team in Ukraine. I am writing this post from my hotel room in Kiev, on a hot summer day, 10 years after I got my first full time employment, looking forward to the new challenges that lie ahead.

Note:


(1) I added Java here because discovering it represented a significant turning point in my professional growth. At the same time I was also discovering the Web and cross-platform development, Linux, productivity and the need for easy deployment. Later, I've mostly abandoned the language in favor of C# (initially) and C++ later. Therefore, it has been many years since I've written a program in Java.

Strategic Planning

I've just returned from a fascinating workshop dedicated to strategic planning - iPlan. It was financed by the European Union, being targeted at developing strategic planning competencies for a selected audience of top and middle managers (btw, for those interested, there are still future sessions open to participants).

The duration of the seminar was three days, two of which were dedicated to Markstrat, a business simulation  game taught at top universities like Harvard or INSEAD. Of course, during the two days we did not get into too much detail, but it was still enough for us to understand the basics of strategic planning and experiment with business decisions in a simulated market. To be honest, it was a lot of fun. Although we were working for roughly 10 full hours every day, I've rarely felt so engaged and energized in my life. At the end, all participants expressed their wish that the simulation would continue, eventually restarted from scratch for us to be able to apply the knowledge gained.

So what were the conclusions? I can't say for everyone but, at least in my case, I've reached some very interesting insights. Of course, as usual, the ideas I am going to list below are subjective, general, and they need to be discussed case by case, matched against specific situations. Why am I so excited about these ideas? Well, it's because I've actually been able to see them at work in classroom dynamics and in the simulation and not just read about them in a book.

• Numbers (hard data) matter:

Before jumping into any new development, you have to look at the facts: where does the revenue stream come from, what is the competition doing, what are the hard facts from the market. Starting new business or assigning project priorities based only on feeling is very dangerous as it can gravely impact established business and alienate customers. After all, a core purpose of running a business is to create revenue. 

• Organization matters: 

A point of differentiation for the winning team was that they organized themselves around a decision making process with roles and responsibilities, established from the start. This cut the debates and they were able to allocate more time and resources to actually running the business. It also helped them draw conclusions faster (learning) and apply them in the simulation.

• Spend time in analysis and planning: 

It helps to clarify the roles and responsibilities and the overall approach to be less tempted to abandon your strategy when faced with unexpected "opportunities" (more on opportunities later). Again, regarding organization, those who planned their organization and strategy early on, won the competition.

• Decide and cut losses early. Hope doesn't help a product become better:

When faced with losses and the realization that you've made a bad decision, cut it and redirect your budget to more profitable initiatives. Decide based on future income, not on past expenses. Sticking to unprofitable initiatives will only bring sub-par revenue, will impact your investment budgets thus adversely affecting all products.

• Focus:

Too much diversity means too many areas to invest and support. A portfolio not adapted to your budget and audience means less money allocated per product and less time allocated to making each product profitable. It leads to mediocre performance which, in terms, means market share and revenue lost to specialized competition.

• R&D is expensive:

Without R&D and new product launch one cannot survive. However, R&D is very expensive and the decision to launch a new product, enter a new market or improve an existing offer needs to be very well planned. You cannot afford too many of these initiatives as they are true money sinks. A solution to overcome this problem is to re-focus, cut existing unprofitable business and re-target budget to support your strategy. Once you decide to go on with an R&D project you need to make sure you have the money to support it in its later life cycle.

• Price reduction is a race to the bottom: 

You cannot afford it too much. A nice approach to maintaining profit margins on such markets (actually all markets become a red ocean at a certain point) is to invest R&D into cost reduction early. The same product developed with more efficient processes will survive longer in a competitive landscape and raise the barrier to entry to competition.

• Advertising is king. Price and quality are not only intrinsic values, but also perceptual values: 

Needless to say: it is not what your product is that drives purchasing intent but its perception. In order to survive in a competitive market with similar products, one needs to support it with promotional budgets above competition (think detergents). He who has the biggest budget gains the largest market share.

• Product needs to be fit for your niche:

As you cannot affect perception too much with advertising, you still need to have a fit product. The more the product is fit for your target niche, the more sales you have. Creating products for a wide audience is not a winning strategy because you will lose in front of the specialized offers. Create a perfect fit for your niche and then advertise it. Advertising only to your niche will keep your promotional budgets lower and also create less confusion. 

• Opportunities - do they match your strategy?

Launching on a market not on your strategic path can be very dangerous, no matter how attractive the opportunity is: you have a competitive disadvantage in front of the companies that have already targeted that niche as their core strategy. Reckless investments can leave your core business without sufficient funds to support it, thus becoming prone to being taken over by competitors.



In the end, every company is free to select its own strategy. Once you select it though, it usually pays off to stay close to your plan in spite of adversities and false opportunities - that is, of course, unless your strategy dictates otherwise. A strategy is a chart, a path to follow, a guide to where you want to go. It comes from your core values and beliefs, from your strengths, weaknesses, from your dreams and wishes. Beside the cost associated with it, abandoning your strategy may mean getting into conflict with who you are or losing your motivation to continue.