90 Percent

Project management, productivity, change management, and more!

Leave a comment

Need help with a tight schedule? – Part 1

Source: dhester

Source: dhester

One of the main concerns for project managers  is delivering the project on time. More often than we would love to admit, this can be hard, and a variety of reasons explain why it can be a challenge (events, client expectations, business need, etc.).

Either while we’re planning the initial schedule, or as the project evolves, there are many different ways to help shortened a schedule so you can deliver your project on time.

In the past, I’ve written an article that listed a few tips to help you out, here is complementary information and more alternatives:

The two typical tools that can applied to all projects are the following:

Fast Tracking

Fast Tracking consists of starting a phase of a project sooner, overlapping with the previous phase.

For example:

  • If design is only partly approve, development could start earlier with what is approved;
  • If only parts of the projects are developed, QA can start for those pieces instead of waiting for the very end of development. This could be considered more of an agile approach.


  • The duration that the 2 phases overlap is the duration removed from your overall schedule.


  • The more you fast track, the more risk you add to the project. For example, unapproved design parts that are being finished might have an impact on what was approved, and if development was started, there is a risk of rework. If you decide to fast track even more and develop before any design is approved, you add risk of rework if the client approves only parts of it (or none of it!).


Crashing is adding more resources to tasks so their duration is reduced. If you are working with external resources, it could also mean paying more to have a deliverable done faster.

For example:

  • If a website requires 240h of back-end development, and was planned with 2 resources for  3 weeks; you could add a third developer;
  • Overtime.
  • Third-party is developing the website you designed, they will deliver 2 weeks sooner, but at a cost.


  • Tasks will get done faster, meaning the project’s duration can be reduced.


  • Adding more resources can be costly, meaning the budget will take a hit. In our example above, separating 200h of work between 2 developers does not necessarily mean 100h each, just like you will not get your website done in 1 hour with 240 developers. There is added management time to communicate information to more people, there is also overhead between these people so they can communicate who does what, and if whatever they are working on is linked to one another, one’s code affect the other’s;
  • Too much overtime will tire the team, and if abused, might have worst consequences like team members leaving or left unmotivated to go on.

There are also  several other ideas that can be applied to some types of projects:

Separate project into different phases

Applicable for many types of projects, its scope can be separated into more than one delivery until the project’s completion.

For example:

  • If a software is due in 2 months since a conference is being held shortly after, only part of the software might be realistic to be delivered. You can decide to include fewer features for example, planning to roll-out updates in the subsequent weeks;
  • If a massive social campaign is starting on a certain date and you have an absurd quantity of posts to create, they do not need to be all created for the launch of the campaign. A first batch could be ready for the launch, and while those are being shared with the community, a second batch can be done, and so on.


  • Allows the on time delivery of what is realistic. This can give an enormous amount of flexibility with a project that has an unrealistic deadline, or a typical client expectation to get a project out the door as soon as possible.


  • This can add costs to your project. If a website is going live with half its pages, and you plan updates every week to add more pages, this creates the need for more deployments, which adds costs;
  • This may not fully satisfy your stakeholder(s), so it is important to manage this expectation as early as possible, ideally at the very beginning.

Reduce scope

A scope might be defined by stakeholders’ requests, or might be defined by what the team thinks is ideal for the project’s success. However, sometimes, there is just not enough time to do everything, and splitting the project might just not work. In these cases, reducing the scope might be your best bet.

For example:

  • A client asks a contest in time for summer, and they have enough budget to do something “cool” where users play a mini game to enter the contest. Unfortunately, they have decided to go forward with this last-minute, leaving very little time before the deadline. This might be a case where even if budget permits it, the idea of the contest might need to be reduced to something simpler like a simple contest where users fill a form.


  • Less work means the project can be done faster.


  • The client might not be fully satisfied with the reduced scope;
  • The grade of the project is diminished since it wasn’t built as it originally should and might not satisfy objectives as much as it could have been.
  • This removed work will also reduce the budget, meaning the organization will benefit less from this project.

Stay tuned for part 2.

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?

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?


4 tips to help you face tight deadlines

Tight deadlines are part of many projects, but some deadlines are harder then others, here is how you can maximize your chances of making sure you have a satisfied client:

1. Make sure the official date is the right one

Tight schedules are often linked to events or media blast they cannot be pushed away and a certain product must be ready before it.

Be careful when identifying the real last day that your team has to finish the work. You may have been given February 15th for the event, but maybe it must be ready 2 days before the event.

Be 100% certain of the deadline.

2. Prioritize

When a lot of work is due in a small amount of time, we tend to work on anything we can get our hands into so we can finish as much work as possible as quickly as possible.

The problem is, the work we do in those conditions may not be the most important, and you may simply not have time to finish everything whether you want to or not.

Make sure tasks are prioritized and tagged as either ‘Must have’ and ‘Nice to have’.

A very important task may not be all that urgent for the deadline and could wait while other tasks must be done, no questions asked.

3. Phase the scope

Most often, the client will agree to phase the project, meaning that it will only be partly available for the tight deadline, and can be updated later on.

Reducing the scope means less work, which obviously makes it easier to meet the deadline.

It is important to consider #2 above when phasing a project.

4. Schedule compression techniques

If your schedule or resources available offer you some kind of flexibility, you can:

  1. Crash the project: Don’t worry, it does not mean to destroy it! It means adding more resources to particular tasks so they can finish sooner. Note that this may add hours to your estimates: a task done in 30h by one resource will not be done in 15h if we add a second resource, so be careful.
  2. Fast tracking: Ideally, certain tasks need to wait for other tasks to be finished before we start them. Sometimes, we can start those tasks a little sooner, meaning that at some point, both tasks will be executed at the same time. For example, although not all the design is done, HTML development can be started. Note that this adds risk: the design may require major changes near the end which affects what was already done, that may mean that the development that was started earlier may have to redo a part of the work.

With tight deadlines, keep calm, and do your best!