90 Percent

Project management, productivity, change management, and more!

Need help with a tight schedule? – Part 2

Leave a comment

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 Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s