90 Percent

Project management, productivity, change management, and more!


Leave a comment

5 tips to give great project briefs

Briefing your team on the new project is a very important step and one that will give your team a good/bad first  impression on how things are going to go until the closure of the project.

Recently, I wrote about a few examples on how to give a very bad first impression ( and headaches) by giving very bad project briefs, now let’s concentrate on how great ones are given:

1. Think of it as a story

A colleague of mine gave me this great tip and I couldn’t agree more! A story is built so that anyone can jump in and understand what is going on by reading it; the same should apply to your project brief.

Setting

Describe the context of the project so that anyone can understand what they will be working with. In other words, describe  the current situation and summarize why things are as they are.

For example: a website has been build 8 years ago, back when  responsive design did not exist, and no CMS could be afforded. Today technology has evolved and CMS are more affordable with open-source platforms.

Conflict

What is the issue or what causes this project to exist all of a sudden? If we use our website example, then the issue could be that the website is not mobile friendly and the client cannot make any simple modifications without the need for a developer.

This creates the need, and gives birth to the project just like it would with a story.

Plot

Explain what will happen so that the project can be completed. In other words, list deliverables and what’s expected for each. For example: the team will deliver a concept idea for a new contest, than layouts of the contest, and then the team will develop it.

Characters

Talk about all stakeholders (team, client, third-parties, etc.) and everyone does.

2. List clear, measurable objectives

The objective of the project will guide the team towards the right path. If one of the objectives is to “create brand awareness” then the social media campaign they build will differ from a campaign that used to gather emails to send future promotions.

Make sure the objectives are measurable, if they are not, then they will be open to interpretation and you will not be able to assess properly if they are met or not. A good example of measurable would be “Gather 5000 new fans on the Facebook page” versus “Gather new fans…”.

3. Make sure it’s clear who does what

Here you want to make sure to explain what the team will be doing; is it a website? social media campaign? Mobile app? Is it more than one thing?

Within this, list what needs to be done is not implied/guessed; list it clearly.

Keep in mind that third-parties or clients are also stakeholders that have responsibilities within the project and listing their responsibilities is important to the team; both to make them understand the full context and also to know who to talk to during the project.

4. Answer all questions

The team will ask questions when they are briefed, that’s practically inevitable; you have to make sure all questions are answered. If you cannot answer right away, list all questions  so that you can speak to who you have to in order to get the answers as quick as possible.

If you do not answer your team’s questions, how can you expect them to deliver what is needed?

5. Keep it simple to read

Just like every document you create, if it’s too long and hard to read and nobody uses it, then even if all important information is available, the goal of the document will be skipped. Makes sure it’s well formated including proper titles, use lists, you can even highlight key information, and keep sentences as short as possible.

In conclusion

How a project starts gives a good idea of how the project itself will be throughout it’s life-cycle which is why it’s important to give good project briefs so that the team can be confident the project will go well. This will not only make sure they know what they are expected to do, but also it will motivate them to deliver.

 

If you have more tips, don’t hesitate to share below!

Documents


Leave a comment

IT projects: The challenges of documentation

To complement a previous article on 7 tips for well documented projects, here is a more in-depth view on challenges we face with documentation and how we can face them head-on.

Documents

Source: imelenchon

Laziness with updates

Let’s be honest, updating documents in not fun, especially if we update it 5 times in one day because lots of changes occur. Furthermore, depending on the available documentation (documents, software, etc.) and how fast/efficient it is to update it, we tend to justify our laziness with the fact that it wastes too much time.

What this causes is that all the documentation becomes unreliable because nobody knows what’s good and what’s outdated, so nothing will be used.

To reduce as much laziness as possible, it’s important that the documentation can be updated very quickly, without too much of a hassle. This can be done by taking into account the next items below in this article.

Too much information

Just like speaking, the document must communicate a message that must be received and understood by the receiver. If that is not being accomplished then whatever was written becomes useless. Amongst other factors, this can be caused when there is way too much information available, and people can’t find what they are looking for quickly. If someone talks a lot, and way too fast, he may have given you all the necessary information, but if you didn’t understand it, then it’s not successful communication at all; it’s the same with documents.

Imagine this scenario: you have spent hours accumulating information, and documenting everything in a nicely done 35 page document. You are so happy it’s done because this document can now be used by everyone to execute their work. What typically happens? People will open the document looking for information, then they will see that there are 35 pages filled with information. What happens then? Most of the time, they will close the document and ask you for the information instead. That is when you will go have a look, and since you need to answer your colleague, you will spend 30 horrible minutes trying to find the information, and once you find it, you will email it to your colleague. All this could have been avoided if your colleague knew how to find the information quickly.

So how can we make it better? 2 things:

  • Keep documents short and sweet: avoid long sentences when 2-3 words could be used; and
  • Keep in clean: Put aside information that is not relevant anymore and make sure only the needed information is available right away.

Scattered information

The more people are involved in a project, the more scattered the information will probably be. It could be inside mails, chat, documents, software, while speaking, etc. All this information becomes hard to find, if not lost, and the probability of error is enormous.

To avoid or reduce this, the solution is to gather information very few strategic locations and avoid duplicates of information. Whether it’s in several documents in the same folder, or inside a software; all important information should be stocked somewhere easy to find.

At the same time, avoid the previous item (Too much information), so make sure you keep everything clean when gathering everything. Keep in mind that this may use up time, especially if you are gathering information from various mails everyday, but if you compare to the time wasted searching for the information when it’s scattered, not to mention the time wasted on errors/confusion, you’ll notice it’s all worth it.

Lack of standards

Many agencies have to face this, whether there is a PMO or not, there are lots of cases where each project manager can manage the way he pleases, with some (or none) constraints like for example which software to use. However, when it comes to documents, it may be a little more loose, or they will use the same templates, but not use it in the same way.

This may create confusion and negate the possibility of developing good habits. Team members will tend to ask PMs for the information since they don’t know where to find what they since it’s never the same with the different projects or PMs.

By working with the same tools, and using same practices, people will be able to create great habits that will be timesaving. For example, if they know that the schedule is always available in a software, that all necessary milestones are identified there, and it can always be quickly opened for every project, with every PM; they will create a habit of checking the dates themselves instead of having to ask the PM 4-5 times during a project’s execution.

That’s just one example, but lots of habits can be created for the whole team in various places if documents are done the same way, and available at the same place.

In conclusion

Documentation is important for every project but it’s not always easy having the best documentation ever, and having everyone using it just like they are supposed to. Keep in mind that the more you fine-tune it, and communicate with the team to receive their feedback, the better it will get.

Have you ever faced other challenges with documentation?


Leave a comment

5 reasons to K.I.S.S.

Keep It Simple Stupid

Photo credit: Hey Paul Studios

An old colleague of mine once told me “K.I.S.S.!!!”, as in “Keep It Simple Stupid“: one of the best advice I ever got, and here is why:

1. People will jump onboard

Whether it’s using your documents or your tools, if they are so simple that there are no reason to skip them, people will use it. This means an incredible amount of collaboration is added versus when you have to force people into using them.

2. Less confusing

The more paperwork, or information, or anything for that matter, that is available, the more likely people will get lost, and simply “run away” from it all. This means, keep everything clean and stripped to the minimum people need.

3. Faster

Time is money and it’s faster when things are simpler. It’s faster for people using it and also for people putting it in place. If everything is faster, that means more money!

This is also a good thing to consider when looking for a new applications, or platforms to use to manage projects, issues, or anything for that matter; the simpler it is, the faster people will be able to use it properly, the more efficient people will become.

4.Complex is not necessarily useful

As cool as it is to have 2500 functionalities in a tool, or as efficient it may seem to have written 30 pages of documentation; if people don’t use it, it’s not useful. It’s a waste of time actually and will make you reluctant to doing it again.

 

Has keeping it simpler help you in any way?


Leave a comment

To “Project plan” or to not “Project plan”, that is the question

books

Source: lensfusion

Project management plans are more often than not, either scattered documents/emails, completely not existent, or too huge. The result: it’s not being used properly, or not even useful.

Let’s have a look why, and what we can do about it:

Scattered documents/mails

A project plan is actually a combination of several subsidiary plans, carefully stored/combined so it’s easily found/accessible. If all those documents do not have a common location, then they will tend to be scattered on a network, or locally on someone’s computer. Even worse, the information will be scattered through mails that the team will waste time finding again and again.

What’s important is that everything is combined, whether it’s inside one document carefully tailored to the needs of the project, or several documents well stored in one folder, each well named and identified by version. It may do the job to scavenge through mails, and if you manage one or two small projects at a time, then fine, but usually, it’s not efficient at all. You will raise the percentage of confusion, errors, and waste of time if you leave things scattered.

Simple: all at the same place!

Completely not existent

A common practice is to simply “go with the flow” thinking it would be a waste of time to gather it somewhere safe when it’s been forwarded in a mail. What happens then? Some changes occur, some questions rise up, you look at the mails, send more mails, look at even more mails, etc, etc, etc…. You get the point!

Avoid all this. Start a plan, but always keep simplicity in mind; if you feel it’s getting complex, than it’s probably time to take a moment and try to simplify before it gets out of control. If you are unsure whether it should be part of plan or note, have it in, but it aside so it doesn’t get in the way but you know it’s there, and as you gain experience, you will get the hang of identifying useful VS not useful information.

No plan: No good!

Too huge

I left the best for last! In my opinion, this is probably one of the main reason people avoid project plans or are scared of them. Why do I think this one is the worst of the cases? Because an actual plan was done (yay!), all the good intentions was there, and a lot of work was put into it, only to have it rendered useless! Imagine how the PM feels when all the work/effort is going to waste.

Here, what is happening is the plan becomes a big ol’bucket of information. Whether it’s pertinent, used, old, new….Everything is there! The more, the merrier, right? NO! Why does that happen? When people open a blank Word sheet, their fingers just start typing SO MUCH words that a simple website objective becomes a large paragraph that nobody wants to read. So if you scale this to a whole project’s plan, then you have yourself a dictionary, ready to be read by…No one!

This being said, to avoid all this, are here some tips:

  • Use a quantity limiting tool: Instead of having big blank pages for you to fill, use Excel for example. The fact that you are limited to cells that make it hard to put in a lot of formatting will automatically make you create lists or shorten the information. Yes you could still fill it up as much as you want, but hopefully it’ll help you work on that.
  • Archive old information: Versions and old information is good to keep for reference purposes, but if they are not stored properly, by that I mean out-of-the-way, then it will clutter the pertinent information and people will less and less find the information they need.
  • Clearly separate the information: Tabs in excel, several well named documents, etc. Anything that prevents everything to be dumped at the same place. That way, if someone is looking for a particular information, he should be able to navigate quickly to what he is looking for instead of painfully searching through all the information.
  • As mentioned above, keep it simple!

In conclusion

Many reasons may give the illusion that project management plans are not necessary, and there is also a decent amount of chance that the project can go well without it if it’s small and if the PM doesn’t have too many projects on his desk, but the plan will make your life easier and the project’s life easier. So why not?

Got any more tips? Experience to share?


Leave a comment

4 reasons to have a stakeholder register

A box full of business cards

Photo credit: Wikipedia

A stakeholder register is the list of everyone that affected by the project’s outcome. For example, it could be a client. This list includes all the necessary information gathered from your stakeholder analysis like contact information, roles, influence on project, any requirements whatsoever to meet towards them, communication preference, etc.

Some may be tempted to simply keep some emails from them which have their contact information in their signature, and think that this is enough. While it can do the job, here are several reasons having a real well-made stakeholder register can help you with your projects:

1.Manage the right expectations

Whether you manage expectations like an expert or not, if you do not manage the right ones, it won’t do you any good in the end. One situation that can completely devastate your project is communicating with one person throughout the execution of the project, and finding out later that your contact does not take any real decisions and his boss has the last word. What can happen is that the work, although validated by your contact, is not actually validated by the boss. If your contact regularly communicates everything to his boss, then it may be just fine, but it once happened to me where the boss had never seen the work done, and only saw the project once almost done. That’s when my contact called me to announce that it’s not at all what he expected and we had to make serious changes.

If I had known all along that another stakeholder, one with actual decision power over the project, was behind all this, I could have made sure that he was satisfied. By making a stakeholder register, you are forced to ask the right questions like “Who holds power?”, which can avoid situations like the one I lived.

2.Have requirements/preferences available

No matter how well you communicate, or how often, if it doesn’t meet requirements or other’s preferences, it will not be optimal. By including such information like “Send a status on the project schedule each Tuesday to Joe.”, you can then easily make sure he receives the status. If you have no idea, or if you do not document the information and forget, you may disappoint some clients.

3.Have all contact information in one place

If you don’t gather all information in your register, chances are, they are going to be scattered in mails, or on business cards laying around. By having all the information in one place, you always know where to look if you need to contact anyone. You save time, and most of all, you avoid losing the information.

4.Easier for a PM if the project is transferred

It may be easy sometimes only to think about ourselves when we document or gather information, especially if it’s information usually only we use, but it may be possible for you to have to transfer the project to another project manager; whether it’s because you are leaving the company or a colleague will take your place on a specific project, you have to consider that having a stakeholder register will help them in knowing who to call, whose expectations to consider most of all, and anything worth knowing to help manage them.

I once got a project transfer where there was about 10-15 people to contact, each on different occasions. Sometimes I had to contact 5 of them in one afternoon. Fortunately, the previous project manager made a list with names, emails, and when to contact each of them. At first, it can be hard to remember everyone at once, and what they do exactly, so having this list really helped me contact the right person at the right time.

At some point, you learn by heart who to contact, and when, but it’s still important to keep it updated even if you don’t use it much anymore, keeping in mind that the project may be transferred again.

In conclusion

The stakeholder register may not seem the most useful document of all. If you have a lot of work on your plate, you may be tempted to skip it. Nevertheless, in the end, it doesn’t take that much time to create (presuming you do not have 100 stakeholders) and the documented information may save your project if it helps you manage the right expectations.

Do you create stakeholder registers? Do you find it useful for your projects?


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?


2 Comments

7 tips for a well documented project

document-piles

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!