90 Percent

Project management, productivity, change management, and more!

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.


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


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


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


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


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


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


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


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


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


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


Why QA is important for your project

QA (Quality assurance) is what makes the difference between a satisfied client and an angry one. It makes sure you deliver what your client is expecting.

Different aspects require different resources

There are different aspects of your project that you have to verify before presenting it. Depending of which type it is, different team members should take care of it since they will be able to focus on the right parts of the project. By making sure you use the right resource for the right QA, you maximize your project’s quality. There are probably more, but those below are the main ones I’ve come across in IT projects:

  • Visual: Here I mean everything related to the design once the front-end developer as finished coding. You must make sure everything is aligned correctly, and that it follows the design approved by your client. The best people to test this are designers. The worst people are the front-end developers who coded the interface.
  • Functional: This makes sure that everything “works” and actually does what it should do. For example, does a form actually send the information? The best people to test this are beta testers. The worst people are the developers who coded the features.
  • Texts: You wouldn’t want to send your project that includes a huge typo in your client’s company’s name would you? Well here you concentrate on texts. Unless it’s included in your contract, I’m not talking about correcting the texts the client sent you, but there always are sentences or words scattered in your project that may not have been provided by him. Error messages inside forms are a good example. The best people to verify this are proof readers or translators. The worst people are anyone weak with grammar or it’s not their primary language.
  • UI/UX: This is the usability of the interface and the experience in general. It may have been coded exactly like planned, but maybe it’s hard to use, or there are some key elements missing that prevents you from using a page or feature correctly. The best people to test this and give valuable feedback are people outside the team. The worst people are the ones in the team since they know the project by heart, and may not be able to put themselves in the user’s shoes.
  • Client’s expectations: This one is tricky but if expectations are managed correctly during the project execution, it should not be a problem. Still, here you basically need to predict the client reaction. You must know your client, and you think anything will pose a problem, fix it or temporarily remove it from the deliverable if applicable. The best people are the closest to the client like the project manager. The worst people are anyone not in contact with the client.

Don’t get me wrong, when I mention “best people” or “worst people”, I’m talking in general so you can obtain the maximum efficiency possible. As a project manager, you could check the UI, but having been in the project since the beginning and knowing every detail about it, you may not notice that it’s confusing to use the navigation for example, but someone not familiar with the project will tell you within seconds. Know your resources and use them accordingly.

What may happen

There are two main scenarios which will make it hard to execute a great QA:

  • Managers underestimating QA: Managers have a tendency to think they save money by not investing in QA. If that is the case, explain to them that it risks sending your clients poor quality products, and therefore, can force the client to terminate the contract. You may want to make them read the first part of this article too to prevent them forcing the “worst people” to test so they may to save a dollar here and there.
  • Lack of time: My favorite! No matter how you plan QA inside your schedule, there will always be something that will try to take more time then planned, and QA is often the first thing that you think you can remove. If you absolutely need to send something to your client, assuming it’s not the final delivery, explain to your client that the QA will be done later, and not to worry too much if they find something that does not work properly. It’s not ideal, but at least your are managing your client’s expectations, and explain to them that the quality is to come instead of them imagining that what they are receiving is perfect and end up disappointed.

In conclusion

QA is crucial for your project. Plan it in your schedule from the beginning. Assign the right resources for the right type of QA and you will always have happy clients!