90 Percent

Project management, productivity, change management, and more!


Leave a comment

Remove contingency

How many times have you heard this while creating estimates? Or how many times has the thought of doing this crossed your mind?

Regardless, contingency is needed in all your estimates, and it’s important to protect it.

A few typical misconceptions about contingency

It’s so we can give stakeholders added value throughout the project
Contingency is often seen as this bundle of money we can use to give stakeholders some freebies as the project evolves and they make requests. Although in some circumstances it can help improve or maintain the relationship with the stakeholders if used wisely, it is still scope creep at the end of the day and can have a larger impact on your project then you think.

It adds unnecessary costs
Some people simply do not know what contingency is and think it’s added costs that could prevent a potential contract to be signed.

Without it, we simply need to be efficient with our hours
This one is by far my favorite of them all; when it’s suggested to drop contingency, knowing how important it is, but compensating by “Being efficient with our budget”.

The first thing that comes to mind when I hear this is that we should always be efficient with our budget…But maybe that’s just me 😉

A few facts about contingency

It’s used to compensate the fact that an estimate is a guess
No matter how much time we spend on estimates, and how detailed and beautiful it is, it is still a guess. Short of seeing into the future, there is no way to 100 % accurately predict stakeholder feedback, project evolution, issues, or even actual time needed for all tasks.

An estimate is a guess, therefore we can expect to be over or under our estimate and contingency is there to help us prevent overage in these cases.

It’s expected to be spent
There are exceptions of course, but most project will use the contingency that was planned, keeping this in mind will make you focus on making sure your project has one.

It varies per project
Contingency is often calculated as a percentage of the total effort/costs or it can also be fixed amounts. For example, you can calculate 15% of hours estimated for the project, or apply the same percentage to your external costs for vendors, but you could also calculate a fixed amount for procurement based on your judgement or what makes sense.

Regardless, it varies depending of the project just like an estimate will vary, and must not be an amount that’s fixed across all projects (unless they all have the same budget of course).

How to do something about it?

Explain

One of the main reason contingency is often put aside is because it’s not properly understood. One of the best way to protect it is to explain to colleagues what it truly is, and how it should be used. Contingency’s definition or uses varies depending of people’s own experiences.

Depending of your role, it might be something you can do agency-wide, or it might be something you can do one person at a time as they tell you to remove it.

If you take the time to explain, you will be surprised how the team members can jump to other alternatives to reduce costs instead of removing contingency.

Be reasonable
Contingency is still more costs to your project, although needed, it still needs to be reasonable, based on knowledge on stakeholders, scope clarity, level of team’s expertise on that type of projects, and many other factors that can influence it. If you exaggerate the amount of contingency needed, you will then create a natural tendency for people to want to remove it, or your costs will be simply too high.


Leave a comment

5 tips to help control your project’s budget

Controling your project’s budget can be challenging; there are many obstacles that can lower your budget’s health but there are many tactics you can use to keep it healthy.

Here a are a few tips to help:

1. Reduce scope

As simple as this may sound, we may be so focused on the client’s requests that considering to reduce scope skips our mind. However, often the scope includes lots of “nice to haves”, which means that your project could be just as successful without a few of the requested features .

By identifying and removing those “nice to haves”, you can reduce costs and focus on what’s really necessary.

2. Leverage past work

Leveraging work from other projects can save a lot of time in a new project. This is often an overlooked strategy and for 2 main reasons:

  1. Lack of visibility of what’s been done: We cannot be aware of everything that is available within an agency. Therefore, there may some parts of past projects that could be re-used that you are not aware of.In order to help with that, communicate with your colleagues, or search through the agency’s archives.
  2. Lack of actual available materials: Not everything that is created is made with flexibility in mind. This means that the chances you can re-use most elements can be very low. Creating something that is re-usable generally takes more time initially, and people will often use the faster path due to tight deadlines or simple lack of time. This approach is good for short term, but on the long term you can leverage less work.

3. Use experienced resources

Resources with more experience are bound to cost more, however, they will execute the work in less time. Furthermore, they will require less effort to manage them. All of this will save

Be mindful that depending of the work, experienced resources may not be motivated and render them less cost-effective; make sure it is interesting or challenging enough for them.

4. Reduce meetings

This one can be tough since people like to set meetings. They give the illusion of being productive when in reality they are known for the exact opposite; unproductive, and often useless. If you have regular status meetings with your team, consider reducing the amount and fill the gap with a few quick emails or maybe even just making sure whatever PM tool you use is updated properly and you can simply have a look.

If you do some quick math, imagine a weekly 1h meeting with your team consisting of 10 members. This goes on throughout your 6 month project. That’s 260h hours spent in meetings. Opinions vary but meetings are often up to 80-90% inefficient, this means that around 200h are potentially wasted on your project.

5. Use a smaller team

Smaller teams cost less and they are easier to manage. Furthermore, if no two people share the same role, than there is no need to spend additional time to make sure the team members do not overlap their work.

In order to be able to have a small team, this requires a realistic schedule that enables the team to work with a smaller velocity.


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?

Calculator


2 Comments

7 tips when estimating a project

Estimating a project is a very important part of your project, and can often be taken lightly. Truth is, if you avoid having good estimates, you will likely have a hard time staying on budget, and during your project (or after), it may be hard to analyze why you are outside your budget.

There are some key tips that can help you with that:

1. List what is being estimated

Seems obvious at first glance, but bear with me. Listing what is being estimated is more than simply writing: Programming = 40h. If you review your estimate 6 months later, you will have absolutely no idea what was included inside that 40h.

It is important to list each specific item of your project (home page, contact form, shopping cart, login,etc.).

How detailed must you go? Detailed enough for you to be able to understand it in 6 months, but also, detailed enough to be able to estimate each item easily. It will be more accurate to estimate separately “Contact form, Google maps, description of each team members” than just “Contact page“.

It will also become very useful when you are managing changes inside your project because it will be clear what was included in your estimate.

2. Estimate hours depending of type of resource

Once your items are listed, you must make sure you estimate the resources needed separately. Here I mean people, although expenses should be separated too. For example, avoid something like this: Home page: 40h.

Make sure you can plan your different resources during your project. It would be wiser to separate like this: Home page: Design 15h, Front-end 15h, Back-end 10h.

3. Include the accuracy of the estimate

This one is important and can actually save you some trouble in the future. An estimate can be accurate or it can be a general idea. It is important that your estimate includes that information.

For example, someone could ask you for a quick estimate and you tell them around 30K. There is a chance that this amount will become your final budget. When the project starts, you will estimate more in detail and may have to flag that the budget makes more or less sense, and that’s when you will be told that it came from your estimate, and now it is too late. Sounds familiar?

Include the accuracy in your estimate, if it was a quick estimate to give your colleague an idea, then 50%-75% might be the range of the estimate, and instead of simply 30K, you will tell your colleague 15-45K. A more accurate estimate might have a 5-10% range instead.

4. Include assumptions

An assumption is considered a “fact” at the time it’s being identified. Thus, it justifies the estimate of the particular item and it’s important to include it.

For example, if you estimate a registration form, you assume there will be 12-15 fields. Generally those assumptions should also be listed in your company’s offer to the client so you can control scope easily if the form ends up with 30 fields.

Remember that you may review this later in your projects, you want to make sure what was estimated is clear.

5. Do not forget time for project management

You wouldn’t dare forget that right? 🙂

Generally, it’s calculated using a percentage of the rest of the estimate. It could range around 10-20% or higher depending of type of client, type of project, type of team, etc. You may also want to list all project management tasks, and estimate each of them separately if you prefer. However, it will take more time, and I doubt you know exactly how much time you are going to “talk” during the project.

If you use a percentage, it is important to take outsourcing into consideration. If you estimate 200h of work and 20 000$ of outsourcing for development, you want to make sure you include time to manage the external resources too and not only add 20% to the 200h.

Note that depending of the company’s maturity towards project management, they may challenge the time estimated for project management. In other words, it may not be understood. If that is your case, then listing/estimating each task separately may be a good idea to explain your point of view.

6. Plan a buffer

If you are lucky, you may be able to include a small budget for unexpected events, or small changes, or errors, etc. If so, a 5-10% percentage could be applied to your overall estimate.

If it is a small simple project, then a buffer may not be justified, you want to avoid costing too much too.

7. Plan risks

This applies to project that have a large risk potential. You may have to manage closely the risks, create prototypes, or execute any other mitigation plans.

If that is the case, having a budget to manage/execute all this can easily be justified and should be included.

Note that it should be avoided for standard projects that show no real risks, or where your buffer could do the job.