90 Percent

Project management, productivity, change management, and more!


1 Comment

Change: Before, During, After

Source: jscreationzs

Source: jscreationzs

When planning to move forward with a change that will impact your colleagues, it is important to remember that you must manage what comes before the change, during the change, and after the change.

Before

Before you proceed with changing a process, a tool, or anything else, you have to keep in mind that the more informed the others are, the better. In times of change, people need to feel safe in what’s coming and the more unknown their is, the less safe they will feel. Therefore, explain the reasons of the change, the plan, and how they will be supported not only throughout the change, but after.

Make sure people can ask questions or talk to someone to express their concerns or their ideas. How you communicate with colleagues at this stage will give them a first impression on what’s coming, and you want to make sure they have a good first impression in order to reduce resistance.

Another important aspect to plan before the change occur is training the other, and prepare the proper documentation for them (i.e. tutorials). This could range from preparing them on how a new process will work, to teaching them how to use a new tool.

During

While you are in the midst of your change, this is where many questions will come up since people will start to be actively affected by the change. It’s also when the most frustration or confusion can rise so it’s important to make sure people know they can contact someone who will give them prompt support.

There is also a time where you might need to adjust your change (change the change!). With more people coming onboard, you may find out that there is a flaw in the process that needs to be tweaked, or the tutorial created wasn’t as clear as you thought. Adjust this immediately, people will appreciate that these are being adjusted to accommodate them or improve what is happening.

After

Once the change is completed, a bad habit is to think it’s all over and you can “let go”. That is far from true. Even with a proper training and several questions answered, people will need a good amount of support for a while, and it’s important to still give prompt support as it happens. Fortunately, as time passes, support needed will reduce.

Lastly, like any project, it is a very good practice to have a lessons learned meeting and assess what to improve for next time. It’s also very important to gather feedback from the others to find out how they thought the experience was and how it could be better.


Leave a comment

How to give bad project briefs

Briefing the team to start a project is an important step contributing to the project’s success. How the brief is handled can be very indicative of how the project will
go.

However, even if it is very important, some remain unaware of the impact it has on the team to have an unacceptable project brief.

Here are below a few examples of bad project briefs. If you are guilty of anything similar to this, please review how you brief your team, I know you can do better than this. 🙂

1. The “Pass-by” brief

Situation:

  • You happen to pass by the person you need to brief on the project;
  • You stop him in the middle of the corridor and start briefing him on the project right here, right now; and
  • You give him a very high detail description like “It’s a mobile app”.

Result:

  • The brief takes 5-10 minutes;
  • No notes were taken;
  • No next actions were listed nor discussed;
  • The proper team members were not included; and
  • The person being briefed doesn’t necessarily have time for this today and now is stuck with a “surprise” new project he was not aware of.

2. The “Catch it” brief

Situation:

  • You go speak to the person and tell him a project is starting for a client and he should take care of it; and
  • You leave saying you don’t have more information for him…

Result:

  • The person is left completely clueless as to what to do; and
  • He knows he can’t ask questions since you have no more information.

3. The “high…very high level” brief

Situation:

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need an estimate for a “A micro-site”;
  • The person asks for more information; and
  • You answer… “Well it’s a micro-site!”

Result:

  • The person has no idea what to estimate and is frustrated by the lack of information.

4. The “New service” brief

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need to estimate a “Parade Float”; and
  • The person replies by saying “We do web here…” (which is true)

Result:

  • The person has no idea what to estimate; and
  • The person feels confusion around the new “service” we suddenly offer.

5. The “Client approval forward” brief

Situation:

  • You work hard to win a new client, not involving the team in any steps;
  • After much effort to win this new client, he decides to go forward with the project and sends his written approval in a mail;
  • You forward the approval mail to the team asking to start the project;
  • That’s it…

Result:

  • The team has no idea what is going on;
  • They are also discouraged by the “project brief” they just received.

6. The “When can it be done” brief

Situation:

  • You are in a meeting with a client who just agreed to have his websites done by your team;
  • Happy, you fetch the person responsible for production to meet the client;
  • Knowing he is completely clueless of the websites, you ask your colleague: “When can his websites be done?” while the client remains there, smiling, eager to know the answer.

Result:

  • Your colleague is put in a bad position where he is surprised, cannot answer, and must stay professional in front of the client; and
  • Gives a bad impression to client to see how his project started.

7. The “Client wants something else” brief

Situation:

  • Client gives you detailed information of what he needs;
  • You feel the client needs something else than what he his requesting; and
  • You brief the team according to what you think the client needs, and you do not share the original information the client provided to you.

Result:

  • The team is never able to satisfy the client, no matter how hard they try;
  • They are confused by the difference between what the client feedback says and what you say; and
  • Not only frustration build up, but so much time (and money) is wasted because of this.

In conclusion

Project briefs are the first impression of a project to your team, make sure it’s done right. Not only that, can you imagine if the clients knew how bad their project was transferred to the team? They would not feel confident the team could handle it, and they would be right.

Have you ever received a bad project brief? Share your story!

Freeze


Leave a comment

One great tip to help control scope

Freeze

Source: mparkes

As project managers, controlling scope can be very challenging.

You’ll want to avoid scope creep but if managed properly, scope changes can mean more budget. At first glance, this seems like a good thing, and in a way, it is. But there are a few others aspects to verify.

Be careful

For example, you can negotiate more time to the schedule, but this can result in the project dragging over a long period of time, and actually never end.

Another aspect to watch out more is as scope changes, team motivation diminishes. People need to close down projects and move on to the next challenge.

Still in the subject of team members, depending on how your organization work with resources, team members may not be available past the initial deadline planned. This may result in resource switches that add risk or cost to your project.

Projects should have goals too, and often goals are tied to a time-sensitive subject like an event, a new product, a contest, etc. By dragging these projects, the project goals may not be met.

So the tip? Negociate a scope freeze!

A great way to protect the project is to negotiate a scope freeze with stakeholders. This means that nothing gets changed until the current scope is completed. This doesn’t mean that planning for the next phase cannot start prior to the first one being done, it’s even suggested to start planning phase 2 while phase 1 is being completed, assuming you can secure the necessary resources of course.

Not every stakeholder may approve of this, they might feel secure with the idea that they can ask for any change any time, so it will be important to be diplomatic when discussing this and avoid forcing it upon them. Focus on the success of the project and the dangers of allowing constant changes.

Keep a backlog

If changes are requested or mentioned, it doesn’t mean they should be ignored. Anything that his discussed, even if a scope freeze was negotiated, should be noted in a backlog and reviewed when planning for a future phase.

It would be a great waste to forget all of those ideas.


Leave a comment

New look, new name

Welcome to 90 Percent, the new look for this blog!

The name is inspired from the common saying that project managers communicate 90% of the time which felt right for this place.

Hope you like it.

I also would like to extend an invitation to anyone who wants to write some articles and have them shared here, with full credit of course! Don’t hesitate to use the contact form and let me know you want write articles on anything related to project management, productivity, or change management.