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. 

Few Points On Multi-Site Development

I've been involved lately in significant multi-site game development efforts - large projects, high stakes, distributed teams, many stakeholders spread around the world. Here are some observations I've made, most of them quite obvious but, sometimes, difficult to put in practice. Based of what I've seen so far, they are prerequisites for successful distributed development:

• Clear organization / clear responsibilities / low number of  cross-site communication channels. 

It is quite obvious that communication becomes more difficult in a distributed scenario. Therefore, effort should be put in designing a clear organization, with clear roles and responsibilities, accepted by everyone. As it takes more time to reach common understanding and since it is more difficult for the project manager to keep an eye on the team dynamics, the number of cross-site communication channels should be kept to a minimum. The risk of misunderstanding is high. A good communication plan, role definitions and responsibility assignment matrices are priceless tools for drawing clear boundaries, limiting spam and clarifying the structure. From my perspective, in order to support a multi-site scenario, a project needs more administrative effort and better formalized processes than a co-located one. It also needs more internal PR to make everyone aware of achievements, risks, progress and goals.

• Investment made in creating a distributed team should be preserved. 

Building a functional global team is more difficult, especially when the project consists of co-located sub-teams and tasks require cross-site collaboration. Making collaboration work involves expensive trips for the team members to start knowing and trusting each other. Such an investment is lost if the team is disbanded at the end of the project and people are spread back across the organization.

• Cross-site dependencies should be kept to a minimum and sides should work as autonomously as possible.

This makes life easier for the teams as it diminishes the communication effort between members. However, dependent tasks should be scheduled as early as possible to minimize the risk of having conflicts appear later in the project. Teams should be built by having them work together since the beginning on common goals, especially that the risk of higher pressure closer to the end of the schedule is significant.

• Team members are responsible for solving the conflicts themselves.

Managers should help teams understand that pointing fingers is not acceptable and bounce back problems when they feel not enough effort has been put into cooperation. Ideally, everyone should be trained in emphatic communication and active listening. Collaboration ground rules, escalation paths and conditions should be clearly defined.

• Atmosphere needs to be relaxed. 

Pressure in production leads to less collaboration, less communication and to finger pointing. People should feel comfortable taking time to talk and put problems on the table.

• Good project management practices should prevent most of the problems.

The root causes of conflicts are usually priority / schedule / scope creep / misunderstandings. These should be covered if managers follow standardized project management practices. Standardization and training help simplify the communication between leaders from the different sites, as they use the same set of procedures and performance criteria. 

• Face-to-face discussions (video-calls, meetings, traveling, every day communication) should be the norm. 

The more people know each other, talk and have fun together, the less likely it is for difficult conflicts to arise. Team members start trusting each other and are able to predict each other's reactions. They talk more openly and raise concerns earlier.

• Problems should surface early. 

Obvious, but also more care should be put into identifying issues because a significant part of the team is not in the same room and it is more difficult for the local managers to understand their situation. Processes should be put in place for constant risk assessment and planning.

• For a collaboration to work, it is important to have skilled and experienced people in core positions. 

Communication overhead is high and having experienced leads / project managers in both sites is a very important prerequisite for success. Management skills and knowledge seem to be more critical in a distributed setup than in a co-located project.

• Collaboration overhead needs to be acknowledged and supported by management. 

It may be hard and frustrating for everyone, especially for the teams. Management should openly a support, allow time and training for this extra effort. Management should acknowledge that the personal productivity will be impacted, to ease up the pressure and diminish defensive tendencies. On the other hand, people should be aware that it is in their mandate to collaborate and their success (both from the perspective of the project and personal) will be tied by how well they work together towards the same goals.

Even if multi-site development is difficult and poses tough challenges, today is almost impossible for me to imagine huge projects being developed only in one site. It is impossible for me to imagine how a company can bring all the needed talent to a single location or find already there so many people with the required expertise available (either externally or internally). And even if it could, having so many persons involved still generates a significant interpersonal distance between team members and teams must still be  split because, otherwise, they would be impossible to manage. Thus the notes above still apply. 

The list is not even by far exhaustive; it is merely made up of personal observations. Please feel free to send me more factors for project success in a distributed environment. I'd love to chat and share about this subject.

A Few Words About Communication In Projects

Too much email.

Most of the time my inbox is flooded with information I could very well live without, just because someone thought of adding me in CC or I am in too many email lists that are spammed with messages that only concern a few people. Most of the time, I receive a message "just in case I might be interested". And, of course, a two page long, unstructured document follows. This creates a lot of information overload and noise and thus the risk of missing relevant facts is significant. I know that this is a common problem to many managers. Many of them try to find solutions to limit the spam and channel the communication only towards the relevant people. Not only that it wastes time, but spam also generates a significant risk on the project because the project manager gets caught in a reactive loop instead of taking the proactive, look-ahead stance.

Solution.

The solution is quite straight forward but, just like any PM area, requires a little bit of planning ahead. It is called "the communication plan". Among others, the communication plan tries to answer the following question: who are the stakeholders and what are their information needs: level of detail, frequency, matter of interest, preferred format, the kind of information that can be obtained from them. The communication plan tries to identify important channels of communication and direct the flow of messages across those lines. By structuring the communication we aim to:

• Reduce the amount of spam in the project
• Focus on relevant matters
• Escape the need of digesting unimportant messages
• Less meetings

Basically the aim is to shift focus from quantity to quality and, instead of spending hours or scanning unnecessary reports, focus.

Focusing the communication is not only to help the PM and the team reduce their information overload, but it is also a matter of respect towards the recipients and of their time. Above all, it significantly increases the quality of human interaction and the chances of actually getting timely answers to your needs. (Yes, it is significantly harder to write clear, shorter and focused messages than it is to quickly type 1 page of text and throw it away to 100 recipients).

Reporting.

As there are many guidelines out there on how to hold effective meetings, I will focus my attention to another important part of the communication plan: reporting. All project managers and team leaders are bound to send reports and mastering this art can significantly improve their image, the image of the team and increase the chances of getting support.

The aim of reporting is to:

• Provide a clear picture of what is happening in the project.
• Acknowledge / celebrate successes and recognize errors.
• Identify risks and propose solutions.
• Involve stakeholders by providing relevant information and asking pertinent questions.
• Provide a single reference of the project status and reduce spam.
• Bring everyone on the same page.

As with any other communication means, visual reports are more appealing and easier to understand. Instead of  throwing in a long list of items and actions, the more pictures, charts, tables we have, the better we are. And, of course, we all love statistics thus, when we have numbers, we should never hesitate to use them. Beside the visual dimension, a good report is a short, concise one.

Emphatically writing a report means acknowledging that most stakeholders have a superficial understanding of what the actual situation is and thus it is of extreme importance to provide a context. If a PM complains that his reports are never read, it is because people don't understand them. Nobody bothers reading lists of items that don't make sense for him because he cannot relate them to a bigger picture. A report that presents information in context generates understanding and thus increases the chances of being read, generating reassurance and trust even if it brings bad news. What the reader wants to grasp is:

• How the work relates to the global objectives of the project. (again, context / plan)
• What the objectives of the project are - better say, does the team have the same understanding of the objectives as I, the reader, do?
• Everyone is busy with relevant work.
• The team knows what to do next and why. The possible blockers that prevent them from proceeding according to plan have been identified and solutions have been proposed. 
• What the team actually does - this is probably the least significant. 

Therefore, the purpose of the report is to show (of course, all the information must be true!):

• The project team knows what to do and is in control.
• The project team has a plan that is approved, clear, with tangible objectives.
• The project team knows where the (possible) problems are and has solutions to them.
• The project team is proactive and focused on attaining results.
• The project team has results that are celebrated and the morale is high.
• The project team is not afraid of bad news and talks about them openly.

If the recipient doesn't get all that information  or if he  needs to perform a significant effort to understand the report, he will become less confident and we expose ourselves to the risk of having doubts spread about our work to other stakeholders. Then, the effort of counteracting and gaining the confidence again is really high. It is by far easier to keep everyone correctly informed right from the start instead of trying to set things straight after we have an image issue.

One more thing before I end.

The purpose of any communication is not for me, the emitter, to transmit it easily; it is for the recipient to understand it clearly. Therefore, it is my duty to spend significantly more effort in being concise and clear than to write a lousy message that the recipient needs to put in effort to decipher. Even more, my effort is not only bound to transmitting the correct message. It is my duty to make sure my communication has been properly received and understood. I need to ask for feedback, comments, and spend time to understand the needs of the recipient.

Cross-Site Collaboration And Conflict Management

The first step in solving a conflict is to identify its cause. Then comes finding and applying a solution. For this, the conflict is taken out of the personal space and approached pragmatically, depersonalized. Safety should be guaranteed for participants by forbidding blaming and pointing fingers. Focus, instead, should be put finding solutions collaboratively. In the end, the issue and its resolution must be added to a log for further reference. Lessons and best practices are then extracted and processes improved.



Identifying the source of conflict:

According to PMI, there are seven sources of conflict. In order of frequency, they are sorted as follows:

1. Schedules
2. Project priorities
3. Resources
4. Technical opinions
5. Administrative procedures
6. Cost
7. Personality

The hard fact is that "personality" is the last frequent in reality, although many tend to blame it as the main source of issues in projects. To me, that is because many managers don't know the other 6 and it is easier to blame it on someone you can point your finger at (except the PM :) ). As the Pareto principle applies in this case as in many others, I'd say that  it would be safe to begin by excluding "personality" from the list and try first to fit the issue in the other categories. Beside a better understanding of the real cause, this thinking has the benefit of cooling things down as sides can focus on finding a solution, without feeling the need to guard their personal space.

Finding solutions:

Things can become explosive in a cross site collaboration because it is more difficult to act emphatically, it is natural to think in terms of "us" and "them" and misunderstandings can occur at all stages, even if people seem to agree. Therefore, a set clear rules are mandatory to ensure conflicts surface early and that they are treated up-front, before the situation degrades. Here are a few:

• All teams must understand that it is their responsibility to solve the problems. Their actions are measured and recorded and a post-mortem will be done on how the collaboration went. To support this, the managers should create a set of ground rules and encourage a culture of exchange and free speech.

• When a problem occurs, everyone should look critically at themselves and see how they could have acted better. Acknowledge you can change yourself but you cannot change the other.
• Has my message been properly understood?
• Under what conditions does the other person receive my message? Is he under heavy load? Is he under pressure? Do I understand his point of view and his situation?

• Once the problem has occurred, act immediately. Problems don't solve by themselves. Be assertive, refer to yourself and express your feelings: "Look, I feel like there is a misunderstanding somewhere". Cool temper needs to be preserved even if the other side is acting aggressively.

• If you cannot solve it yourself, raise the problem to your manager and / or to the collaboration coordinator (if one exists). It then becomes his responsibility to interact with the other side. Provide reasons why you could not solve the problem yourself and show the steps you took. Take responsibility for what you have done. 

• In the end, once a solution is found, a written note is archived with the problem and its solution. This written note acknowledges that the problem had, indeed, been fixed. Once the note is acknowledged by all parties, the issue is considered closed.

Managers should find ways to allow people to raise and fix issues safely. Don't blame, but encourage solutions and cool temper. What is measured is the capability of people to collaborate rather than the number of problems they encountered. Accept that problems will occur, but try to learn from them.

Lessons learned:

The issues should be kept in a log. This log will be used for two purposes: to see how the conflicts evolved and to evaluate the capacity of the team to manage conflictual situations. Based on it, processes are improved and people learn to interact and collaborate. The knowledge is then passed to the next project.

Prevention:

While I believe that constructive conflicts are a positive sign that things move forward, it is better to proactively diffuse latent problems before they appear. To do this, management focus should be kept on the following areas:

• Risk management - key to project success. If risks are identified early, acknowledged by everyone and mitigation plans sketched, trust is enhanced. Therefore, people are less afraid, they have a better sense of security and thus will less likely be in defensive mode. 

• Prevent stress / project pressure - the same as above. Pressure raises schedule and priority issues which tend to be explosive as people become more tense. Therefore, management should focus on releasing stress and encouraging a relaxed atmosphere.

• Prevent fear - when management looks for assigning guilt, people will be less willing to confront problems early and they will start pointing fingers. No room for collaboration.

• Prevent directive management - a directive management style will generally not encourage openness and engagement. Therefore, problems can linger around uncovered for longer periods of time, without being solved. Otherwise, pointing fingers and blaming can occur.

• Having a clear, common set of ground rules to follow - provides a reference for the desired behaviour.

• Having a clear organizational structure, decision process and information flow - standardizes  how people interact and what responsibilities they have. A go-to book for management of expectations.

To sum-up, a healthy, empowering management culture together with good project management practices form a solid basis for a cross-site collaboration. It is more difficult at a distance and, therefore, more records should be kept and more attention should be given to developing a culture of mutual respect, empathy and understanding. Also, a continuous, open learning process should be put in place. Ideally, it should all be treated like a game, so that people feel safe and are willing to explore their boundaries without concerns. 

How I Passed the PMP Exam

Why PMP?


From my perspective, a credential such as the PMP has tangible benefits that can be divided in two main categories: the recognition of knowledge that comes from passing the exam and the process of becoming a better project manager by learning for the exam.

The PMP credential means that one's experience and knowledge of project management is recognized by the standardizing body (the PMI), giving the owner international credibility.

On the other hand, learning for the exam itself has a strong transformational power. It forces the student to mentally walk through a series of scenarios and relive past projects to understand what went right and what went wrong then. It takes all the previous experience and knowledge and benchmarks it against standardized best practices, recognized across all industries - The PMBOK. I've mentioned experience: to qualify for the exam itself, one needs at least three full years of project management practice*.

How does the exam look like?

It is a computer based, 4 hours / 200 questions exam, which is taken at a Prometric site. There is no official break. To get a flavor of how it goes, one can check many resources online that provide test samples. Here is an example:

http://www.oliverlehmann.com/pmp-self-test/75-free-questions.htm

The exam is not very difficult yet it is not easy either. Beside a good understanding of project management philosophy, it requires concentration to correctly identify the problem, then to identify the right project management process that the problem is part of. Besides that,

• Some questions are very long and difficult to read.
• Some questions have very similar answers.
• Some questions have may seem to have all the choices correct.
• Some questions have unnecessary information.
• Some questions may pose more problems and the student is asked to identify what is the most critical to be solved next.

During my learning, I realized that it was a very thin balance between answering the questions correctly  and wrongly. A mere interruption as small as going to drink a glass water for 5 minutes resulted in a higher probability of mistake that spanned across roughly 10-15 questions (10-15 minutes). I made this measurement over many tests by identifying clusters of wrong answers around the same time I had an interruption. 

How did I study?

1. I picked a less professionally demanding period (after the first patch of Assassin's Creed Revelations PC was released) - November - December last year 2011. 

2. I enrolled in a PMP class here. Fortunately, they had a session in December. The course itself was based on the Rita Mulcahy method, which I warmly recommend.

3. Roughly 3 weeks before class, I started reading the materials (The PMP Exam Prep book, by Rita Mulcahy). 

4. I took 4 working days off of work just before the class started, to finish the book and the exercises it contained.

5. I went for 4 days in class.

6. After the class, 1 week - no learning. During this period I paid my PMI membership, completed my application, submitted it and then, after it was approved, scheduled the exam. 

7. After that, for one week, I did 50 questions a day from each knowledge area. At the end of the week I took a 100 questions sample PMP exam. For all these, I used the PMP Fast Track software, also from Rita Mulcahy. This was between Christmas and New Year's Eve.

8. For 4 days after the New Year's Eve party - nothing.

9. 3 days before the exam, I passed through the PMP Hot Topics Exam Flashcards. It took 2 days.

10. 1 day before the exam I took a full 200 questions PMP Exam to see where I stood.

11. On the 8th of January 2012 I passed the exam.

Suggestions for taking the exam:

1. Reading the materials prior to class was of extreme importance. That way, I was able to solidify my knowledge and identify gaps by asking the teacher all sorts of questions.

2. Exam questions are asked from the perspective of a large (100+ people, 1 year+, 1 million+ EUR) international project. Having experience managing this kind of project helps. 

3. It helps a lot being in a less demanding period at work. 

4. Overstudying does not help, nor does taking the exam lightly.

Good luck! :)

Note:

One insight I had while studying for the exam was that project management knowledge alone was not enough for one to succeed. Strong industry experience is also required to become an accomplished project manager.