How to handle tight deadlines as a business analyst


How to handle tight deadlines as a business analystWhen you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It's like driving a racing car - you have to push close to the limits but any error can throw you completely off the track.

The first thing that I do when I get a project like that is considering the reasons for the deadline. You can end up with a tight deadline for a variety of reasons. The deadline may be mandated by the management. It can be determined by interdependencies between projects. It can be defined by market compliance rules. In other cases it's estimated using the work breakdown structure for the project but ends up being too short because of wrong assumptions.

So how can you as a business analyst make sure that circumstances don't control you and your team, and you deliver your project successfully? Keep in mind that sometimes you can be successful even if you don't meet the original deadline!

Here is a visual summary of deadline causes and ways of handling them:

Let's look into the ways of handling deadlines in more detail.

Manage the manager

Management sometimes sets up deadlines with a good "buffer" to allow themselves time for decision making at the end of the project, or because they don't expect to get results on time and want to push things along by moving the deadline forward. This can be best mitigated by having good communication with the management.

However, what can you do if your manager does set an unreasonably short deadline? Find the tolerance level of your project sponsor (management) and of the key stakeholders who can influence the sponsor. Talk to end users to understand the severity of not delivering on time. There can be scope for negotiation.

Shuffle dependencies

If your deadline is constrained by dependencies, you can talk to project managers of the upstream and downstream projects to get a better understanding of the interconnections. You might be able to find a way to reorganise things and either get what your project needs delivered earlier, or move the deadline for your own project.

Be smart about compliance deadlines

If you're working on a compliance project, it may have a firm deadline established by the market bodies. In this case find out if there is a transition period. It is usually provided because market participants have differing levels of compliance and don't have the same resources available to make the transition. You can also evaluate the impact of breaching the deadline (such as fines for non-compliance), and prioritise the parts of the project which would have the highest financial impact if they are overdue.

Double check estimates

When it comes to deadlines defined by estimation, it's a good idea to double check the estimates. Ask what facts and assumptions were taken into account when the task was initially estimated.

Watch out for changes

Once the project starts, you have to watch out for changes in the project environment. Changes will affect project completion time, so work with the team and stakeholders to update the WBS and the schedule.

Organising work on projects with fixed deadlines

After you've applied the practices above and you are sure that you've done everything you can to negotiate a reasonable deadline for your project, the next phase is organising your work in the best possible way to meet the deadline.

I've found that the following practices help me complete projects on time:

  • Determine the business context which will be affected by the change to status quo

  • Define the scope of the solution required to satisfy the identified business need

  • Plan short iterations to verify the project direction

  • Align the solution with the existing business processes and IT infrastructure

Each of these practices is discussed in more detail below.

Determine business context

Completing this step successfully often determines the success or failure of the project.

Many organizations that operate in a competitive environment have well defined and standardized processes. Many others don't however, so be prepared to discover them. Explore the business processes which may be affected by the new solution. Learn which systems are used by the business within these processes. Embedding new solutions into these business landscapes should be considered thoroughly to reduce resistance to changes and exclude redundancy in project management, solution delivery and transition to the new state. If done right, it also gives a business analyst an opportunity to find ways to add value to the business.

The rationale for the project should be identified by the project manager, while the business analyst should identify business drivers and actual business needs.

Define solution scope

This is the exciting part of the project, but defining solution scope has never been an easy task. Short timeframes and technological changes which may occur during your project make it even more challenging.

In general, to cope with this task the project team needs a solid foundation to build on - well documented processes and good infrastructure. Knowing and using best industry practices can often point you towards defining a sustainable solution and save exploration and research time.

When it comes to defining solution scope, my approach is to use only the "must" requirements for the "initial" solution, and prioritise the remaining "should" requirements into subsequent phased releases ("final" solution).

You must work closely with the solution architect and play an active role in exploring available options. Often the overlap between business analysis and system architecture saves a lot of time - I have saved up to a third of project time by ensuring that the architect could use my documents as a useful starting point in producing a detailed design of the solution.

Plan short iterations

I'm still on the fence with regards to the Agile method. Its value is clear in software development (at least for certain kinds of projects) but when it comes to business analysis, I'm not so sure. However, short iterations are one useful technique in Agile which can reduce project time. Use them to get a summary of the completed and outstanding tasks, evaluate changes to the project scope, and identify feasible shortcuts.

Project manager and business analyst need to present a unified front in dealing with business stakeholders. Face to face communication is essential to make short iterations work for analysing the current situation, required changes and making decisions on the next steps. Informal communication style helps too - really, there's just no time for strict formalities if you want to get things done. It's very important for the project manager to arrange a "green corridor" for access to authorities and clear the way for the team to focus on delivering rather than struggling with bureaucracy.

As a business analyst, you also have to do your share to deliver results quickly by being professional and active in all your activities (industry research, compliance requirements and so on). Make sure that communication is well maintained between everyone involved in the project.

Align business and IT infrastructure

Most of the time new solutions are embedded into the existing environment. It's a good idea to make maximum use of the existing components and processes to make the introduction of the new solution less intrusive and to minimise the number of temporary patches and business interruptions.

I try to present the solution in terms of interacting services to achieve this. I transform business references to applications and systems into services and show how they could interact. This approach allows me to show the business users how all pieces of the business, including external parties and outsourced services, come together and how the new solution will improve overall efficiency.


Whenever you get a project with a short deadline, don't forget that there are two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.

The practices presented in this article should help you address each of these considerations.

Author: Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of  visual learning and reference materials for business analysts.

Our goal is to make business analysis easy to learn by presenting practical information in an engaging way.

Have a look at what we do at 

Top article image © Orlando Florin Rosu -

Like this article:
  26 members liked this article


Tony Markos posted on Tuesday, December 28, 2010 1:38 PM
Very good article.

My honest opinion, having spent a lot of time in the "trenches":

A ways back in in Business Week I read that the primary purpose of top-level management consultants is to help company management set the proper level of parinoia. What better way is there to elevate the parinoia level than very aggressive due dates?

Lets face it, when (as is often is the case) the due dates are beyond any reason, there is often no real opportunity to negotiate them. The project is in trouble and something has to be done to get costs under control. The only solution seen is a lot of free work (i.e., free overtime) induced by fear.

Alex - Aotea Studios posted on Tuesday, December 28, 2010 1:58 PM
Thanks for the comment Tony. I'm sure artificial time pressure is used in some companies, but hopefully it's more of an exception than a rule. If your manager is completely unreasonable, it's a whole another story and it isn't something that we covered in this article.
Phil F posted on Wednesday, January 5, 2011 9:57 AM
I guess this comes down to a leap of faith. Take more time out to drill into the drivers in the hope that it garners more time/flexibility.

Do you think this is made harder still if you are external?
Alex - Aotea Studios posted on Wednesday, January 5, 2011 1:39 PM
frostp: I consider performing the steps in this article a natural consequence of discovering that your estimates don't agree with what's been set by other people or external forces, so a leap of faith doesn't seem necessary. The alternatives would be either simply hoping that things work out or working overtime, but in either case you'd be increasing risks for the project.

It might be harder if you are external to the organisation because you haven't accumulated a history of how people work there and how deadlines are normally handled.
zarfman posted on Tuesday, January 11, 2011 5:42 PM

Two comments;

There is a phenomenon known as the three part lag. First how much time elapses before the problem is recognized, second how much time does it take to determine a solution to the problem, third how much time elapses before one knows if the solution worked. This time stack up can absolutely destroy any possibility of meeting the deadline.

Dead lines are often at the mercy of the implementers. Substandard programmers, DBA’s and others can absolutely kill any chance of meeting a deadline. Deadlines are sometimes met but the product quality as abysmal.


Alex - Aotea Studios posted on Tuesday, January 11, 2011 5:49 PM
Zarfman: thanks for your comment. We wanted to concentrate specifically on the BA component of the projects in this article, so we didn't look at the broader issues with deadlines for the project as a whole.
zarfman posted on Tuesday, January 11, 2011 7:40 PM

Let us consider only the BA component.

From the visual summary if I’ve counted correctly we have four possible causes of deadlines. We also have eight ways of handling deadlines. If the four possible causes of deadlines change in a manner that is hard to foresee. We can ask the question how many BA's are required to reduce the action reaction time to one day? Interesting problem, sounds a lot like a queuing theory problem.

If management changes its mind about some facet of the undertaking how much time elapses before the BA finds out, what action does the BA take and will management agree with the BA’s suggested actions. I would suggest that these various actions and reactions do not take place instantaneously. The foregoing reminds me a lot of the three part time lag.

Of course we have management priorities, indifference, turf wars, BA’s with poor communication skills, stakeholders with poor management and communication skills and other problems.


Alex - Aotea Studios posted on Tuesday, January 11, 2011 9:51 PM
Zarfman: Adding people to a late project is likely to delay it even more because they have to get up to speed and because of the increase in communication overhead.

I agree that various communication delays should be taken into account when estimating the impact of change or the time required for a project.

zarfman posted on Tuesday, January 11, 2011 10:10 PM

Hi AoteaStudios:

I'm not talking about adding people to a late project. I'm suggesting that the Question of how many BA's will be required should be addressed during the planning stages or requirement determination or early on not after the fact.

I remember reading book dealing with what the author caledl the fictional man day or something like that. The author suggested that if the task was total separable and required little if any communication then a person could be added otherwise no.


Alex - Aotea Studios posted on Tuesday, January 11, 2011 10:27 PM
Zarfman: I see. The book you mentioned is called The Mythical Man-Month.
atv posted on Thursday, January 13, 2011 8:47 AM
Very helpful article. Thank you.

Also I think that changing the project approach to iterative may be as complicated task as changing the project deadline.

Alex - Aotea Studios posted on Thursday, January 13, 2011 1:29 PM
Thanks for the comment Tanya.
Shweta posted on Wednesday, December 11, 2013 4:27 AM
Great article!!
I particularly like the part - two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.Thanks!!
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC