90 Percent

Project management, productivity, change management, and more!

PMBOK guide 5th edition

Leave a comment

PMP exam adjusted: 5th edition of the PMBOK guide

The PMP exam is now updated with the fifth edition of the PMBOK guide. It is very important to take that into consideration if you are thinking of taking the exam from now on.

PMBOK guide 5th edition

PMBOK guide 5th edition

In general, the adjustments are great, I love them! Amongst other things, the processes are more consistent amongst each-other, and have been adjusted to make sure we concentrate on the values and goals of the organizations while planning. In addition, some elements are less confusing, so it’s easier to understand the logic between processes and ITTOs.

Here is a summary of the changes:

  • A 10th knowledge area was added: Stakeholder management;
  • 5 new processes going from 42 to 47; and
  • 13 processes were changed, moved, or both.

Integration management:

  • “Direct and manage project execution” is now named “Direct and manage project work”.

Scope management:

  • Now has 6 processes;
  • “Plan scope management” is a new process; and
  • “Verify scope” is now named “Validate scope”.

Time management:

  • Now has 7 processes; and
  • “Plan schedule management” is a new process.

Cost management:

  • Now has 4 processes; and
  • “Plan cost management” is a new process.

Quality management:

  • “Plan quality” is renamed “Plan quality management”; and
  • “Perform quality control” is renamed “Control quality”.

Human resource management:

  • “Develop human resource plan” is renamed “Plan human resource management”.

Communication management:

  • 2 processes were moved (Identify stakeholders, Manage stakeholder expectations);
  • “Distribute information” is renamed “Manage communications”;
  • “Plan communications” is renamed “Plan communications management”; and
  • “Report performance” is renamed “Control communications”.

Risk management:

  • “Monitor and control risks” is renamed “Control risks”.

Procurement management:

  • “Plan procurements” is renamed “Plan procurement management”; and
  • “Administer procurements” is renamed “Control procurements”.

Stakeholder management:

  • Completely new knowledge area with 4 processes;
  • “Identify stakeholders” was moved from communication area;
  • “Manage stakeholders expectations” is renamed to “Manage stakeholder engagement” and moved from the communication area; and
  • The two other processes are “Plan stakeholder management” and “Control stakeholder engagement”.

The new knowledge area focuses on one of the most important element of project management (in my opinion at least), and manages stakeholders, their expectations, and engagement. It used to be part of a simple process inside the communication area, but now, it is much more elaborate and receives the attention it deserves.

Data-Information-Knowledge-Wisdom model:
They clarified some terms by aligning them with the D-I-K-W model to reduce confusions between “Work performance measurements” and “Work performance information” and how they are used.

It now becomes “Work performance data”, “Work performance information”, and “Work performance reports”. At first glance it may seem more complicated but their relationship with the processes are more logical and easier to understand.

Agile project management:
This is becoming more and more popular, and the PMBOK guide now mentions it in 4 areas:

  1. Adaptive project life cycle;
  2. Enterprise environmental factors;
  3. 2 tools inside the “Collect requirements” process; and
  4. “Control schedule” process.

It’s not much, but it’s better than nothing. This is because PMI offers a completely different certification called the Agile Certified Practitioner (ACP).

And that’s it! For those who have studied the 4th edition, what do you think of the changes?

Leave a comment

6 reasons you shouldn’t use trickery with your team

Card sharp

Card sharp (Photo credit: totallyfred)

While managing projects, we try all sorts of techniques or methodologies to manage them as best as possible. One “idea” amongst many is to trick your team by feeding them false information to stay on budget or on schedule. For example, you will tell your team the deliverable is for the 15th when it’s actually for the 22nd, so they will work under pressure, or do overtime, and you know you have a week of buffer.

While it can sometimes work, here are several reasons it shouldn’t become your way of managing your projects:

1. You will get caught

It may work at first to trick your colleagues, but they will eventually catch on.

For example, you are probably going to need some of them to estimate your project. Those resources will than have an idea of the budget (or part of it), which means that if they question the official amounts that you give them, you will either have to explain why you’re using false numbers and hope they don’t talk, or you will have to use additional lies to trick them. Either way, your trick will stop working with them, and the others will simply find out sooner or later.

What happens then? Your colleagues won’t trust you anymore. Either they will confront you or what may happen is that they will stop taking your budget/schedule seriously and you will have a hard time managing your team.

2. Wastes time

Managing budgets and schedules can be time-consuming, especially if there are a lot of changes in the project. So imagine if you have to double that time since you also have to maintain a false budget/schedule!

Furthermore, if you are using a software to manage budgets/schedules, then you will be able to enter one budget or one schedule per project, and if the team can have access to the data, that means you have to use the false one, leaving you to use other means to manage your real data, which will waste even more time.

3. Creates confusion

If you use trickery a lot, chances are you are becoming good at it. Nevertheless, at some point, you will probably confuse your fake numbers with your real ones. That confusion could have a serious impact on your project.

For example, if you mix up the real budget with the false, you may think you have less money available than you think, forcing you to make horrible decisions to manage project changes, resulting in your client’s unhappiness.

4. Adds stress

If you use pressure created by false schedules, you inevitably add stress to your team. I will not go into details of the negative impact stress can have on efficiency, but to sum it up: it’s not good!

A little stress here and there can have a positive effect on productivity, but if you constantly stress out your team, they will leave, or stop working properly. Not to mention the anger that can be created.

5. Reduces project quality

There are two sides to this point:

  1. The first one is concerning stress by using a false tighter schedule (previous point): the negative impact the stress creates on your team’ effectiveness will result in poor quality work overall, and it will worsen with time; and
  2. If you feed false budgetsyour colleagues will try to stay on budget by using smaller amounts than they should. The result will be that they will take minor or major decisions along the way to “cut corners“, obviously reducing the quality of your project.

6. Chain effect

When trickery is used by more than one person, this can amplify the false data and multiply the negative impact.

Here is an example that I witnessed: A project was recently added about 30h worth of budget for maintenance to execute a series of small tasks. The account manager told the project manager the team had about 20h. The project manager, who thought 20h was the real data, used the same trickery with the team, telling them they had about 15h to do the work. The team immediately told him they wouldn’t have enough time. The project manager had to go back to the account manager and tell him that, and that’s when they all had to tell one another they were sharing false data, and they actually had 30h. The project manager then told the team they magically had twice the time all of a sudden…imagine the look on their faces!

What a mess…

In conclusion

If you want to build a solid team based on trust, than trickery is not the way to go. Unfortunately, I’ve seen many use those “techniques”, pretending it works. To some extend, it does work, but it’s not worth it in the end if you take everything into account (resources leaving, lack of trust in the workplace, lying and deceiving, etc.).

To each his own way of managing project; what do you prefer, honesty or trickery?


7 tips for a well documented project


Source: dhester

A project without documentation is a sure path towards problems. Whether it’s a few documents for a small project, or a great amount of documents for a large project, documentation is important to make sure relevant information is available when needed to complete the project.

Keep in mind that the goal is to have information available for your team when they need it, so having documentation is important, but it must be organized too. Here are several tips to help you with all this:

1. Document everything that’s important

A lot of information is transferred during a project, whether it’s oral or written. It’s important to note everything that is relevant to the project.

For example, every meeting should be documented into “meeting-minutes” and sent to everyone. That way, everyone can refer to those conversations, and that will avoid terrible conflicts in the future.

At the same time, too much useless documentation is not going to help. The important information will get lost amongst the rest. Make sure you note what is useful for the project. If you are unsure, then have special locations for secondary information. For example, have a separate section at the end of your document that list miscellaneous information just in case. Just make sure it doesn’t get in the way.

2. Keep it accurate

Your documentation is like your project’s instruction manual. If the information is wrong, then it’ll bring your project to disaster. Have it double-checked by colleagues to make sure everything is perfect, or if your colleagues documents some parts of it, then make sure you validate everything.

Even if just a small portion of the information is unreliable, then the team will stop referring to ALL the documentation since they won’t trust it.

3. Keep it updated

This complements the previous point. Non-updated information is the same as not accurate information. This means that it can bring your project in the wrong direction and can have colleagues lose trust in your documents.

Always keep it updated as soon as new information is available.

4. Format for easy reading

If your documentation is hard to read, or too time-wasting because it’s awfully long, people will not read it or will waste a lot of time finding the information they need.

Read my article on TMI when communicating is just as bad as not enough for more information.

5. Make it easy to find

It’s so easy sometimes to transfer the information in several mails here and there, not gathering it all at the same place. What happens when you do that? You end up with lost information, or it’s scattered everywhere and you waste time finding it.

Instead, have one place where you store all documentation, including simple quick information like a FAQ for your project (people will have questions, and answers will be forgotten!). If you always use the same logic with your projects, and organize them the same way, your team (even you) will find the information more quickly. Time will be saved and everyone will appreciate it.

6. Avoid duplicates

There are rarely any good reasons to have the same information documented more than once. If so, try analyzing if you could document differently to avoid this.

What can happen if you duplicate information is:

  • You waste time documenting more than once, and you will waste the same time updating the information afterwards; and
  • Adds the possibility of error; if the duplicates are not maintained correctly, it may lead to confusion.

7. Keep versions

Keeping versions is important if you have to go back to validate information, or answer questions you may have. Documents are not going to take too much space on a hard-drive, so keep versions, just in case.

Name your documents correctly when numbering them; version 2 should be used over version 1. I’ve worked with colleagues to whom numbers didn’t matter, and version 1 was to be used instead of version 2 or 3. Guess what happened? We often used the wrong documents and lost hours. It’s very frustrating so be nice to your team, use the right numbers 🙂

In conclusion

A well documented project simply runs better overall. It does take some time to do this correctly, but the time you and your team save is more than worth it: Less confusion, less wasted time looking for information, fewer errors,etc.

Do you have any tips to add? Have you had good/bad experiences with documentation in past projects? Please share!


5 reasons you should embrace conflicts


conflict (Photo credit: verbeeldingskr8)

First off, to make sure everyone is one the same page, by “Conflict“, I’m referring to a disagreement, and not a “fight” or something like that.

Here is the definition from Wikipedia:

Conflict refers to some form of friction, disagreement, or discord arising within a group when the beliefs or actions of one of more members of the group are either resisted by or unacceptable to one or more members of another group.

Conflicts, when managed properly, become vital to teamwork and projects, so it’s important to keep them coming, and not avoid them. Obviously, it can have a negative impact if you let it get out of control, but let’s focus on the positive here.

Creates or finds the best ideas

Typical conflicts in IT projects would be the balance between design and programming; designers will tend to prioritize the visual aspect, and developers, the functional aspect. Generally, concentrating on only one aspect is not the best option for a project, you always have to take everything into consideration, which is why a “clash” of ideas between visual and functional can bring out the best idea that no one would have found on their own.

It’s by discussing and challenging other’s ideas that the team gets a creativity boost. By avoiding the conflict and taking only one colleague’s side, you skip the chance to find those ideas.

Of course, there can be conflicts of any kind; design VS programming is just one example amongst many others.

Improves teamwork and communication

If conflicts are managed correctly, the team will develop a sense of camaraderie when communicating disagreements. Instead of going on the defense, they will become more and more open, they will learn to trust their colleagues, and even start having fun when they disagree.

It’s normal to notice that when a team just formed, conflicts start off less efficient; as the team go through the different stages of team building, it will improve. It’s important to manage each stage accordingly.

I used to have a colleague (artistic director) who was more focused on the design (obviously), and I have a developer’s background, so I tended to focus more on the functional aspect of a project. When it came to meetings where we validated a project’s design before it would be sent to the client, we always had several conflicting opinions. Although at first it used to be more of a debate to win, it became cooperative discussions on how to meet the other half way, for the best of the project of course. The results were always greater than if we only took one’s idea as-is.

Improves one’s efficiency

I’ll use my example above once again. My colleague and I started off each more focused on one aspect of the project; as time went by, and we did many projects together, we became more easily aware of the other aspects we used to neglect. By opening our minds to the other’s ideas, we became able to find new ideas on our own, before any conflict even rose. We developed new reflexes, and learned more and more as we communicated.

My point here is that we each evolved with the other’s knowledge and ideas. It helped me concentrate more on the visual aspect of projects, and for him, he could design his interfaces with the functional aspect more in mind generally resulting in less changes in his design when we spoke. Furthermore, conflicts were actually less and less present, and at some point, conflicts really just became simple discussions.

Makes sure everyone as a say

In every team, some have more “strength” when it comes to affirming their opinion or selling it. What happens, whether everyone wants it or not, is that their ideas seem more important or better, and are more prone to being use, even if it may not be the best idea.

By having a team environment where conflict are well-managed and accepted, people will be more comfortable sharing their opinion instead of letting the others talk.

Indicates something is wrong

If people disagree on something, that means that something may not be clear enough, or several solutions are available and the best one must be used. Either way, it suggests that your attention is required, and a decision must be taken.

If their were no conflict, it would mean that only one true path is available all the time, and no problems whatsoever are present; that wouldn’t be much fun 🙂

In conclusion

Conflicts have positive outcome when managed correctly. It can easily become negative, es

pecially when the team is new, so it’s important to keep that in mind.If you have any stories related to conflicts, please share!

Leave a comment

Project plan VS project schedule


Photo credit: Wikipedia

Those two terms are amongst the many that bring a good amount of confusion. So let’s try to clarify everything!

Project plan

The project plan is the mother of all documents for your project, the one that documents everything from initiation to closing. It includes several subsidiary plans gathered from all knowledge areas, including the schedule.

The project plan is the go-to document to manage your project until the very end, and it’s the document you want to refer to if you inherit an ongoing project.

Project schedule

The project schedule is part of the project plan, and includes all your project’s important dates, including milestones like a BETA deliverable for example.

The format may vary from a bar chart, to a Gantt chart, to a calendar, but the important thing to remember is that the schedule = dates!

In conclusion

The confusion between those two terms can bring conflict between two colleagues if one asks for a project plan and simply receives a schedule, so it’s important that those terms are the same for everyone.

Hope this helps!



Keep your schedule updated!


Schedule (Photo credit: Marco Buonvino)

Scenario: You take an hour or two to create a schedule for the project. A week after the project was supposed to start, the kickoff meeting with the client is still being postponed so you adjust your schedule. Eventually, the meeting occurs, and at the end of the meeting, it seems some requirements have changed, so it will take longer to do.

You changed the schedule again to find out three weeks later that the client will need more time to send his content than what was previously planned. At this point, you decide that the schedule doesn’t need to be updated again, it’s just the content delivery, and at some point, you just stop updating it until the end of the project… Sounds familiar?

Maybe, maybe not, but it happens! And it may seem to be justified to stop updating the schedule, but it guides the team, sets clear objectives with specific dates, which without, the project can go on and on, and people become confused and unmotivated.

So it’s simple, always update the schedule!

Quick tip: Make sure your schedule can be changed quickly. Avoid schedules that include an hour of beautiful design work around it just so it’s more classy. That may be good for preliminary schedules included in offers made to clients, but when it’s time for execution, keep it simple.

If you’re only pushing farther away some dates, it should take 5 seconds. If you’re adjusting it, it still shouldn’t take more than 5-10 minutes unless you are redoing the whole thing. That way, you’ll be more motivated to keep it updated all the time.

So have you had to update a schedule over and over again? Or did you have to work with an un-updated schedule?


What does it take to be a great project manager?

Inside every agency, many different types of people manage projects everyday even if they are not project managers; some because they were told to, some because they had nobody else to do it for them, some because they wanted to try it and were given a chance.

However, what does it actually take to be a good project manager? To be someone who can make sure projects run the way they should, someone who will bring added value to those projects? Everyone has different opinions on the subject, and a lot of skills are required for this role, but here is my personal top 5 soft skills:

Empathy: It may seem strange for some that this is first, but hear me out. A project manager spends an average of 90% communicating with many different clients, team members, and external resources. This means that you need people skills (2nd point) but to be able to manage the different kinds of personality you encounter, not to mention in many different situations (some involving more stress than others), is hard, and beyond being able to communicate, you have to be able to put yourself in the other’s shoes to try to understand them, and communicate accordingly.

For example, it’s easy to politely refuse a request from a client, and most of the times, but it’s all in the words you use, and in trying to find an alternate solution to the client’s problem. Your reflex should be to think “This client needs this or maybe his boss won’t be happy, maybe another solution could do the trick?.” and avoid thinking “Stop asking me to add features or pay up!”.

That’s why, in my opinion, empathy is really important.

Interpersonal skills: As mentioned above, 90% of the time is used communicating, so it’s natural that being able to communicate is very important! It complements greatly “empathy”; if you can understand the others but can’t talk to them, it’s not necessarily really useful. You must be able to be clear and flexible in your approach, and have the capacity for conflict resolution of any kind.

Leadership: There are a lot of articles out there that talk about management VS leadership, I do not want to get into the details of that here, but want to mention that there is a very large difference between managing a team, and leading one.

A project manager may tell people to do their tasks, but a great project manager will help/motivate the people to do them. A leader shows the way (makes the path clear), rather than simply pointing the way to go. This will raise team motivation, efficiency, and morale when they work with this project manager.

Organized: A project manager manages a lot information, spread through several projects at a time. A great amount of money is at stake, and a lot of people follow him. One missing word in a message can change it completely and break a project.

Therefore, it’s important to be very organized in everything: documents, messages, emails, schedules, etc. The project manager must be able to control all the project’s information, to the last detail, and by being organized, he will be able to find the necessary information quickly when needed.

Calm: Whatever happens during the project (angry client, conflict between team members, task to do for yesterday, etc.), the project manager must always remain calm, and resolve everything that comes at the project.

Being calm will help him resolve conflicts, find solutions in times of need, talk to the client politely no matter what’s being said, and so much more. The team will look up to him and will even more motivated to stick with him than if they see him panic.

There are many other important aspects of a great project manager (pro-activity, positive, curious, etc.) but this is my top 5 attributes for a great project manager. What is yours?