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

Need help with a tight schedule? – Part 2

In part 1 of the article, we’ve explored two typical ways to speed up projects and a few alternatives that can also help. Here are a few more alternatives:

Reduce stakeholder delays or revisions for feedback

As the project progress, it is a standard practice for some types of projects to have different kinds of deliveries sent to stakeholders to receive their feedback or their approval before moving forward to the next phase.

When the schedule is tight, you might be able to negotiate fewer rounds of revisions allowed or shorter delays to approve some documents.

Foe example:

  • Maybe typically the stakeholders have 5 days to provide consolidated feedback to your team. In case of a tight deadline, you might be able to negotiate 3 days instead;
  • If 3 rounds of feedback are allowed per delivery, maybe it can be reduced to 2, even 1.

Pros:

  • Faster approvals or less revisions means the schedule is shorten.

Cons:

  • This can add risk that stakeholders cannot meet their deadlines given and this might cause some phases to be late;
  • If rounds of revisions are removed, there is also some added risk that they find some issues later on, which you will not necessary be able to negotiate more budget or schedule since they can debate they should have had an additional revision normally.

Combine two deliveries together

This obviously applies to only a few types, but in some cases it’s possible to combien two deliveries into one, this can reduce back & forth and accelerate the project.

For example:

  • A wireframe delivery can be combined with the design phase. The final output are layouts (wireframes are implied within). Both are basically done in parallel with designers & UX designers working together. In this case, stakeholders would approved the user interface at the same time as the design work;
  • Simple website pages that derive from approve pages can be delivered only once developed, without any prior wireframe or design work. All this work is implied inside the develoed pages themselves for the stakeholders to approve.

Pros:

  • Be combining (or removing) deliveries, hence removing approval phases because of the reduced quantity of deliveries, this shortens a schedule quite a lot.

Cons:

  • This adds risk of rework since stakeholders see more of the work accomplished at the same time, therefore can have feedback on more elemets, thus creating more rework. In our example above with layouts, if the user interface itself doesn’t please stakeholders and must be revised, this means the layouts must be revised accordingly as well.

Roll stakeholder feedback into the subsequent phase and/or deliverable

This technique can only be applied to certain types of projects, and also depends of actual feedback. Basically, instead of going through one additionnal round of feedback where you send the revised delivery and wait for feedback, you skip on to the next phase and send the revised work fused with another delivery.

For example:

  • The feedback given on the latest copy sent is that several terminology must be changed and they ask that your team proposes new copy. You could send a revised copydeck, wait for approval, then start integrating the copy inside the project, whether it’s a website, a flyer, a software, etc. Or, you could propose new copy that you integrate right away and the stakeholders can vet it directly within staging or inside layouts (a.k.a. the next delivery).

Pros:

  • This can remove one revision’s delay therefore saving time in the project’s budget;
  • Sometimes this can also help stakeholder approves certain elements (like copy) inside a different context, helping them understand.

Cons:

  • This can add risk of rework if the revised work done according to the feedback received is still not approved. In order to mitigate this, it’s ideal to use this technique when the feedback is fairly straightforward.

Putting case issues aside or reduce the “pixel perfect” expectations

In IT projects, running into issues with a particular OS or browser that affects only a few people is quite recurrant. When these issues are found, it doesn’t mean it’s worth spending time to fix those issues.

For example:

  • Older versions of Internet Explorer show the form 2 pixels more to the left than it should; this is barely visible to anyone and older versions of IE may be used only by a small percentage of visitors;
  • If a user does 4 specific steps to reproduce the issue, only to have a blank space added to his menu until he refreshes the screen; this is not a showstopper, nor does it happen often that a user reproduces it.

Pros:

  • You can save a lot of time trying to find solutions to issues that may never be seen by anyone or will not bother many (if any);
  • You can also reduce costs that way, which is an added perk.

Cons:

  • You still risk users hitting issues and potentially complaining about it; even if the probability is low, you still reduce the quality of the work by using this technique.

Use senior resources

Depending of available resources, some more senior resources might be able to do the work quicker. This allows you to keep the same team size, but still shortened the schedule. It doesn’t necessarily mean it needs to be a senior resource, but basically anyone who can get the work done faster.

For example:

  • One of the resource in the agency is known to be fast but has very little experience with very complex development. He could very well take care of your project that is considered simple, and he’ll be able to do it faster than others;
  • A junior resource on your project thinks he can tackle a task in 35h, but another more senior colleague knows he can tackle it in about 15h;
  • Also, note that senior resources then to provide better quality work, meaning you will most likely also save time long-term by avoiding lots of issues being found in your QA cycle.

Pros:

  • Tasks are done faster by more reliable resources, this can have a positive impact on your schedule since chances are, things will run more smoothly.

Cons:

  • These senior resources may not be available for your project since they are already used on other more important projects;
  • These resources tend to cost more, although they should take less time.

 

I hope these tips can help you when you are stuck in a tight spot with deadlines, do not hesitate to send more ideas below!


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.

Pros:

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

Cons:

  • 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

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.

Pros:

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

Cons:

  • 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.

Pros:

  • 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.

Cons:

  • 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.

Pros:

  • Less work means the project can be done faster.

Cons:

  • 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.