One Page Project Estimates

The questions this post is providing an answer to are:

• How can a project manager provide visibility to his / her stakeholders when he / she wants to pitch to them a new project? 

• How can he / she highlight the risks associated with staffing and estimations and play with just a few variables so that risk is brought to an acceptable level?

The method (and its associated Excel-based simulated model) is intentionally simple, its goal being to have the outcome fit on a one or two page sheet and keep the number of variables low so that iterations are easy to make. It does not aim to provide an accurate representation for the risk nor to be used when the required precision is high.

I decided to write this post few days ago, when reading this article [Harvard Business Review] I realized that, in many ways, I have been proceeding in roughly a similar manner when providing high level estimates for my projects.

For the document that exemplifies the method I used, I kept the same example, the book store, for simplicity. Please note that:

• Numbers in the example are totally random

• This is a simplified model, designed to draw high level conclusions, and not a project management tool per-se. The aim is to fit all the information on a single sheet of paper, mostly communication and quick iteration purposes. Here is how:

 

Step 1:

• Fill the "Budgets" column with the main features of the project.
• In the "timeline" section add your estimation in terms of total headcount that you expect to have working on each specific feature. 
• In the "confidence" level add your "gut-feeling" estimate on how accurate your estimation is. In the simulation, the duration / budget will be considered to take somewhere between:

• Min: confidence% * estimation
• Max: estimation / confidence%, thus a a 50% confidence will lead to Min of 50% of the men-months needed and a Max of double the men-months needed, thus prolonging the time needed to finish the work.

Therefore, padding the estimations or taking extra safety precautions are not recommended.

• In the risk level add color coded where the uncertainty is drawn from (technology, backlog (scope), or management-related unknowns like external dependencies).

 

Step 2:

• Fill the resource breakdown in the second sheet of the document - this shows how you plan to allocate staff to the project. First start off with the initial breakdown (the one that came from estimating each of the features from the first page)  
• Look at the available resources and see how many people you can 100% commit to allocate according to the resource needs.  Then compare to the resource needs and add fill the "Min availability at ramp-up" column.  
  

 

Step 3: 

Evaluate the results - every time you press CTRL-S, a new simulation is performed.

Look at the basic simulation for resource availability:

The model is very basic. It takes into consideration the resource needs and the initial allocation probability and then randomly adds headcount to try to catch up with the needs. It assumes that, once a resource is allocated it is not deallocated until the end of the project. The basic idea is that staff may not be available in time (due to assignment to other projects or inability to recruit in time)

Look at the following section of the first table:

• In the green square it shows how much resource buffer you have (or you need to recover from somewhere - if it is a negative number).

Look at the execution simulation results:

The most important line is the DEBT MM. This shows how much you need to recover (negative numbers) or have the capacity to be ahead of the plan (positive numbers) on a monthly basis.

 

Step 4: 

This is the most important step - iterate and play with the numbers:

• Check what needs to be done to improve your estimates and what would be an acceptable confidence level in order to start the project.
• See what can be scheduled earlier in order to use the extra resources that you might have in the beginning and reduce the risk towards the end of the project.
• Play with the resource plan - after you run the simulation with the initial estimates, add / remove staff to each line to see how that will impact your buffers. Find a resource plan that you and your team feel comfortable with.

 

Step 5:

As time goes by, update the excel file with real data and see how your predictions match the reality. Don't forget that this is just a road-map simulation and a proper Agile process should be followed with the team.

End note:

Please always remember that this is a model, it is designed to help you ask yourself questions. It is simple by design because adding more variables would only make iterations cumbersome and relations between data points harder to grasp. Use the model to express to your stakeholders what you have in mind and identify some optimal resource and estimation targets that need to be met in order to proceed safely ahead.

If you need more depth, play with the formulas and add more data points to the model. If you have any questions, please ping me as well. I'd love to discuss your findings and your ideas on how to pitch and estimate risks more clearly, preferably on a single or maximum two page document. :)

Again On Multisite Collaborations - Various Setups

While writing the previous post, more ideas came to my mind about multisite collaborations. 

Just to have it under our eyes, here is the terminology I use in these articles:

• Multisite collaboration: several teams located in remote locations work together to complete a large scale project.

Multisite collaboration




• Lead site (the buyer): the initiator of the project, the place where the PM resides.

• Associate site (the seller): a site invited to work on the project.

Setup no. 1 - the associate site does not have a dedicated project manager.

No PM in the associate site

It may seem to work at first, especially for small teams in the associate. However, several developments become apparent quite quickly as the team grows:

• If management is done at a task level, most of the time the people in the associate will act in a manner very similar to being independent contractors, without much attachment to the product. There will be little communication or synergy between them. As we cannot speak of a real team, the value the associate will bring to the project will be directly proportional to the amount of time each employee spends on his tasks, focusing on getting the code to work instead of understanding the product as a whole. 

• Communication can become heavy and with plenty of misunderstandings, not only due to the language barrier but also because the engineers in the associate are most likely not hired for their communication skills but rather for their technical skills. Therefore there is a very high risk of rework and frustration on both sides.

• In this case, the associate site acts more like an HR firm providing temporary workforce, without any additional value that may emerge from team cohesion - like innovation and creativity. The setup is as if the associate employees are temps working for the lead site. 

Setup no. 2 - the associate adds a project manager, but the core of the process does not change.

PM in the associate site is excluded from the main communication flow

A PM is added when the lead site and the associate agree that there is something wrong in the collaboration - like low quality of the deliverables, misunderstandings, rework, delays. However, adding a PM without putting him or her in the main communication loop or not giving him or her decision power does not change the situation much. Satisfaction will not improve dramatically and the PM will mostly feel useless.

Setup no. 3 - PM on the lead side, PM on the associate site

Both the lead and the associate have dedicated PMs to follow the collaboration

While I strongly believe that engineers should not be impeded from communicating to each other directly, the main decision loop should go through the two PMs (one on the buyer's side, the other one on the seller's side). The associate now has a real chance of leveraging their potential and building a team. With its own backlog, own objectives and freedom of choosing their own internal processes, management is done based on clear KPIs and clear acceptance criteria. The associate has a champion on site, the project manager, who will lobby on getting on its plate higher value business cases and providing not only bare bones engineering services, but also securing the delivery, securing a certain quality standard, participating in the product design or offering additional creative services. The focus moves from tasks to features and added value. 

The last setup works particularly well when there are language barriers, process differences or different organizational maturity levels in the two sites. The PM from the associate acts as a facade, abstracting the development process that happens behind him or her and making sure the discussion does not deviate from the concrete, measurable objectives set for the collaboration. His aim is to protect the team, get acceptance on deliverables and spot opportunities for the associate to bring additional value to the project (entrepreneurial spirit).

To answer one of the questions from PM Days, what is the number one thing that can lead to a successful multisite collaboration, I would summarise everything by saying that my opinion is that PM proficiency (practice + formal) for the associate site project manager, coupled with a modest, outgoing, growth-oriented and curious personality should prevent a lot of problems.

On Multi-Site Collaborations

Now that the PM Days 2013 conference is over, I thought of assembling my notes and posting them here - more like a collage of thoughts, supported by slides from the presentation.

PM Days 2013

Why speak about multi-site collaborations? 

Well, for several reasons. One is that the topic is actual and that chances are that every professional project manager will, at one point throughout his or her career, have to organize a project that spans across several geographically distributed locations. If you are not convinced, just check the image below. :)

Globalization

Of course, the collaboration setup comes with its share of risks that we need to be aware of. It is my belief that anyone who had formal PM training, qualification and also practical experience should be well equipped to handle such a distributed project. PMBOK is a great reference and it was one of the aims of my presentation to look at multi-site collaborations through the PMI lenses: identify the patterns and build a collaboration model inline with what we already know.

As I am an engineer by trade and I like things clear, I need a model to rely on, a model that is discharged of emotional mess, that it is conceptually simple and from which I can easily draw my own conclusions as the project develops. Such a model should scale easily and it should be independent of the project specifics (like methodology, scope, stakeholders, initial risks and assumptions) .

Another reason is the personal opportunity. I honestly believe that collaborations open the gates of the world to the people involved in them. They are an amazing chance for learning, sharing, reaching out to other people and experiences and contributing to significant projects. By collaborating, we can build on each other's strengths while minimizing our weaknesses.

While the pessimist and the optimist fight over whether the glass is half full or half empty, the opportunist steps in and drinks it (thank you, Anca, for this joke)

The third reason is the business need  - the case of having to ramp-up quickly to a large number of people (hundreds), with very specific talents (composers, artists, specialized programming, etc...), which may not always want or can relocate. Without such collaborations, large scale projects may have not existed at all or smart professionals located in various corners of the world might have never had a chance to contribute to them.

S-curved ramp-up

To conclude, I will quote the presentation description from the conference website: "we live in a globalized, hyper-competitive world, where companies need to constantly reinvent themselves, their products and their processes in order to survive – all at an incredible speed. Talented people are key to organization success and thousands of papers and books have been written about how to acquire, retain, train, motivate and best use them. “Our employees are our most important assets” are not just buzz words; they are a realization that without the proper use of their human resources, then even the best strategy will fail.

Talented people are hard to find. What do we do when we need hundreds of them? Fortunately, globalization and the age of Internet have provided an answer: distributed teams and multi-site collaborations." 

What is a multi-site collaboration?

Multisite collaboration vs distributed team

To avoid confusion, just a few words about the terminology I will use from here on: 

• Multi-site collaboration: several teams, located in different geographical regions, working together on a project. The main characteristic is the asymmetric access to information. It is much easier for a team member to build a relationship with a colleague sitting next to him/her than to connect with someone remote. Due to our tendency to favor social comfort, team members will favor local relationships at the expense of distributed relationships, thus local tribes appear. This setup is characterized by a high communication bandwidth locally and a low communication bandwidth between sites.

• Distributed team (think of open source model): team members are distributed across the Internet. Access to information is symmetric, thus people will tend to build their social networks online. The tribes will form based on common interests and less based on proximity (because there is no such proximity).

The topic presented here is multi-site and not distributed teams (as per definition above). 

• Lead site - the site that initiates the project or where the project manager resides. 

• Associate site - a site that was invited to assist in the development of the project.

1. A buyer-seller relationship

Probably the most important conclusion we can draw by looking at the diagrams is that, even if the project happens under the umbrella of a single company, it still resembles very much to a buyer-seller relationship. And this is good news, as we have a model on how to approach it - the Procurement Knowledge Area from our beloved PMBOK. Thus, we already know that we need to perform several steps and end up with a contract between the sites. How should the contract look like? It depends on the scope of the collaboration but, somehow, it should be aligned along the lines of Fixed Price, Cost-Reimbursable or Time and Material. It can follow the Agile guidelines or more traditional ones. 

This leads to at least three main corollaries: 

• The lead site is the client for the associate - thus the associate should treat the lead site with a client-oriented mindset. Key words are "being of service" and "delivering value".

• The relationship should be a little bit more formalized than in a collocated setup.

• The associate should manage itself  (and have a good project manager on site) and that there should be a project manager on the buyer (lead) side as the main point of contact for the seller (the associate). 

I believe that the conclusions above are independent of the methodology employed or the scope of the collaboration. The exact details of the process should be clarified in the contract.

Project managers on both sides - buyer / seller relationship

2. The associate (seller) should take full responsibility for the collaboration 

LS - lead site, AS - associate site; the rest are various stakeholders

While one side should take full responsibility for the collaboration, I believe that the seller (the associate) should step in and guide the buyer (the lead) on how to deploy a successful process. Here is why:

• If there isn't a very strong motivation on the seller side to collaborate, the project is doomed to fail. The seller should have a very strong incentive to develop further, secure a constant stream of work for its people as well as a constant revenue flow. I believe it is healthy for the seller to aim at getting a bigger piece of the pie.

• The lead outsources part of its work because it doesn't have the resources to do it. By having the associate provide the full service to the lead, the lead offloads itself further while it shortens the communication chain, thus reducing the associated communication risks: misunderstandings, delays, things left out.

3. There are specific risks associated with multi-site collaborations

Let's look at the setup again:

The model

As said before, there are two main characteristics of the setup above:

• Asymmetric access to information due to the huge difference in communication bandwidth between the local and the remote, which leads to local "tribes". As a side note, I believe that it is healthy to acknowledge the existence of such tribes and celebrate their existence within the main project. This can be done by simple means, like customised T-Shirts with the geographical location imprinted next to the project name or cultural newsletters.

• The lead site has much more knowledge about the project then the associates.

These spawn several risks, some of them highlighted below:

Risks

• Unrealistic expectations from all sides:
• Top management - "collaboration should work"; this is especially true if the organization is new to such collaborations and does not have a uniform PM and risk methodology.
• Lead site - "we will not be challenged"
• Associate site - "we are welcomed with open arms and our ideas will be embraced from day one".

• Challenge to existing hierarchies and the associated resistance:
• For the lead site, the new guy on the block (the associate) expects to be part of the decision making process.
• For the associate, people that were once regarded as authorities in their field will now be subjected to test and will have to prove once again their value to the organization. Some of them will not be able to adapt as their position is challenged.

• The associate being out of the circle of trust:
• It is normal that there already exists an established decision making process in the lead site. It is not obvious why it should change, thus the associate needs to prove its value in order to get the necessary trust to be part of it. 

• Misunderstandings due to remote communication and language barrier. Assumptions

• The things "we don't know we don't know":
• I particularly like this one. These are the things that are so obvious for one site that it forgets to mention them to the other, like technical shortcuts, changes in technology or changes in the plans that were not propagated - the tacit knowledge in the project.  Because of these, the associate should never rely on the lead site to tell them when something happens. I believe that the associate should be on a constant lookout for changes and have a very proactive process to identify what they don't know they don't know. The excuse "I have not been told" is not acceptable.

4. To mitigate the risks, we need specific profiles as key players

In order to mitigate the risks above, I believe that the persons that take key roles in collaborations should have several personality traits that should not be treated easily:

• Modesty: 
• To listen to the other side and be willing to admit that he/she may be wrong or not have all the information.

• Outgoing: 
• "Everyone communicates, few connect" - J. Maxwell
• Because of the short time spans that teams spend together, key players should be skilled into quickly building relationships. There's no time to lose and there are so many things to find out.

• Questioning skills:
• As mentioned before, key players need to dig out the information themselves and not rely on what they are told. They need to be able to uncover project scope, identify stakeholders or find risks quickly and effectively. They need to be very good active listeners.

• Assertiveness:
• Sometimes things get out of hand and, at that moment, key players need to show self confidence and control the conflict. They need to be able to stand by their positions. 

In addition, they should not be afraid of putting things on paper because, in the absence of a healthy base of tacit knowledge and personal relations on which to rely on, security should be given by process:

Relying on process in the absence of another solid base

5. Successful collaborations need support from top management

Because collaborations are never easy, top management should be on the side of the collaboration:

• Time and money and the assignment of additional roles (like the collaboration manager) invested with enough authority to challenge the PM on collaboration topics.

Collaboration manager acting like a coach and supervising the collaboration

• If multisite collaboration is a strategic direction and not a one time initiative, there should be collaboration KPIs in place which, I dare to say, should not only sit side by side with the rest of the project KPIs but, in terms of priority, score even higher. The PMs should have strong incentives to make the collaboration work. These collaboration KPIs should be followed throughout the duration of the project and archived. No surprises at the end and no post-factum blame if the project is not successful. 

Project report which also includes follow-up on collaboration KPIs

• Clear escalation path which supports communication to the other side first, favoring problem resolution not complains.

Escalation path: talk first to the other side

6. Some tools (hacks) can help a long way

• Linked-in & sharing of professional CVs early in the collaboration: 
• It is one thing to be challenged by John Doe whom you don't know anything about and a totally other thing to know that your peer has 10 years of relevant experience. 
• Link to CV can be added to email signature or to internal messenger status to be easily accessible. 

• Video conference:
• Not much to say - it is one thing to discuss face to face and look into the other person's eyes and smile, and a totally different thing the cold, impersonal email communication. 

• Clear collaboration charter - the contract between sites:
• Not to underestimate! In a collaboration things need to be agreed upon and then put on paper. 

• OPPM report: a great tool!
• Not only that it is clear and easily readable (after all it is only one page), but it should also include regular follow-up on the collaboration KPIs, like the satisfaction of the other side.

• Recognize group identity
• Groups (local tribes) exists and it is in the power of the project manager to position them in the context of the project, thus leveraging their potential. 

• Recognition of the collaboration overhead
• The carrot.

Instead of the final conclusion:

I believe that collaboration comes natural to us, we just need to be open to it. We've managed to work together since ancestral times, thus ensuring the survival of our species. We should be able to adapt this innate ability of ours to the modern times, as long as we embrace it as an opportunity.

To collaborate is natural to our species

(Thank you Andrii Shafetov and Google for the artwork).

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! :)

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.

Tools And Perpectives On Time Management

Saturday, Alina held a seminar on time management at the British Council, in Bucharest. I was invited to talk about the tools I use and about my perspective on the subject.

The why's of time management:

• Freedom
• Productivity: accomplish something of value by staying in the flow
• Peace of mind
• Time to learn and think - secure your future
• Focus on the important

Contents:

• The tools I use.
• Scalable vs non-scalable. Take time to think.
• Some pictures from the event.

The tools I use:

I prefer tools that give me the freedom to work from anywhere anytime and that are well designed (easy to use, simple, very good performance, nice looking). The idea is to gain time by focusing on what I want to do rather than on the "how"'s, and to leverage the moments of inspiration. For everyday use, I find very useful:

     - Evernote

     - Google docs

     - Google calendar

Always connected. I prefer tools that have the ability to sync across multiple devices: iPhone, Windows desktop at work, my Mac at home,  the Mac I use in Kyiv. They give me the freedom to work and spot opportunities wherever I am, whenever I choose, without having to carry a big luggage with me - most of the time, the iPhone should be enough.

I want my data with me all the time, yet I don't like carrying it around. Luckily, in the world of today, it is easier than ever to have access to my important documents from anywhere; much easier  than it was 3 or 5 years ago. Because of the interconnected devices (phones, tables, laptops, desktop computers), hard drives and local storage are technologies that fade out in the past, in favor of the new cloud model. Cloud or web-based applications allow me to travel light yet instantly take notes whenever something interesting crosses my mind.

Usability and beauty. I like to be surrounded with easy to use hardware and software so that I can focus more on the "what"'s instead of the "how"s and spend more time in the flow. I also like to be surrounded with things that look good and feel right. Beauty is important as it makes work more pleasurable - the environment where I spend my time, my computer, my phone. Simplicity, beauty, usability, speed are all in the same pool of features that make my day brighter.

I don't like to be surrounded by too many objects.  Complexity makes life sluggish. It stops me from focusing on the important. 

When I have too many objects, applications or documents to manage, I waste time. Being disorganized wastes time and frustrates me. It is much easier and less time consuming to maintain order when I have only a few things around. It gets me productive, helps me stay in the flow, reduces the activities I have to perform. Simplicity is key to focus for me.

Take notes. Remembering stuff is extremely time consuming  and inefficient. I gather all my thoughts, ideas, plans, in a note taking app (Evernote) or in a calendar to be reminded later. I see that stress comes from trying to remember what I have to do. If I keep the list only in my head, the only thing I accomplish is to be stressed that I will forget something. Taking notes keeps my peace of mind. Fortunately, today I can take notes anytime, anywhere: my iPhone, my laptop, my computer at work are great devices to sketch ideas for future review. And if I have them all interconnected and synchronized, then I am not bound by location.

Plan your week. A powerful tool I use is the calendar - it helps me plan the week ahead and also keep track of the activities I want to perform. It allows me to free my mind to execute what I have planned - the important items on my checklist - and eliminate the noise of urgency. A hidden advantage of the corporate calendar (Outlook) is that, if I plan my work week ahead using it, I can add there my own free slots for meetings, thus securing non-interrupted spans of time for important tasks. Also, having the week ahead organized in advance helps me say NO - another very powerful tool for managing my activity. Having a plan makes it easier for me to understand why say NO and explain it to the people around me. Of course, like any other tool, planning is useful if it is used on a regular basis.

Although I am a huge fan of communication technology (I have 2 phones, facebook, linked-in and twitter accounts, at work I use instant messaging, emails, etc, etc), I see technology as a double edged sword: on one hand it simplifies communication yet, on the other hand, it makes people consider that others are always available to interruptions. Answering all the requests on the spot, although rewarding in terms of instant gratification, have only the result of fragmenting time and put me out of flow - google "why work doesn't happen at work" on TED. Also, it places me in the "urgency" spot, in reactive mode. This is why sometimes, in the evening, I get home tired yet, when I think back, it seems that I have done nothing relevant that day. Managing interruptions is part of the time management routine and it is very important for me to consider flow when I plan my day. 

Scalable vs non-scalable. Take time to think:

Very few people are constantly aware that consistently increasing their output does not come from working more but from working smarter. Ask yourself "if I want do double my value on the labour market, is it smart to work twice as much or find a different way of doing things that would allow me to work the same amount of time but produce twice the result?" That is the difference between scalable and non-scalable. 

Many jobs, like ditching, are not scalable - that is, of course, until someone invents the excavator which renders every professional ditcher obsolete. Today, the hunt for scalable is fiercer than ever, as we need to be more productive, smarter, faster, more creative. 

For managers it is handy to ask people to work more because it is something that can easily be measured - it can produce some foreseeable results NOW, whereas investing in planning, brainstorming, learning and thinking ahead for each member of the team are more difficult to estimate in terms of practicality. However, on the long run, working long hours daily does not generate a boost of productivity - maybe only a 10% increase which, for sure, does not sound at all impressive.

Why this talk? Because the underlying purpose of time management is to get more stuff done which, in terms, is linked to finding time to think deeper, learn more, search for new ways of doing the old in more productive ways. Time management is about making your work become scalable.

Many people say "I don't have time to plan or learn". Well, they don't because they are caught up in urgency. Ask yourself: how valuable is the work you do NOW? To whom? Is it really needed? Does it really matter? I believe that, because of frequent interruptions, emails, poor planning, a lot of the work we do is useless as it only creates noise, generates chaos and bad decisions - in a word, waste. 

Plain execution is not scalable unless it is done by a machine and not a person. For the average employee, he or she simply cannot work twice as long as there is no daylight time to do so. Important is to work smart and say NO to the unimportant so that he or she can concentrate on adding true value. 

Execution takes large amounts of time, most of the time underestimated. (I've heard "it is easy" so many times that I just can't believe it anymore). The best advice I could give someone, is to SELECT HIS EXECUTION WISELY and make sure it is, indeed, the most valuable thing he can do. To do this, she needs to think and learn - to reinvent her job.

People expect us to do some factory-style labour all the time because it is something that we are used to see. School teaches us to be busy and it surely is tempting to think that this is the easiest thing to do to increase productivity - work more. This is the "factory" culture and we need to find a new frame of mind to scale our work.

Today, perfect execution is more important than ever. The polish and quality needed to create products that sell is obtained through intellectual sweat and long hours put into them, in addition to passion and knowledge. I am a huge fan of perfection when it comes to execution. Learning also comes from doing and communication is extremely important although it adds another layer of complexity. So pick your battles wise, so that most of the effort is put in the right place.  To do this, one needs constant thinking, planning, learning, reflection - to actively manage his or her time.


Some pictures from the event:

Alina Buzatu, my host and trainer at this event held by Empower

Myself, discussing the subject 

Showcasing some tools: Google Calendar and Evernote