Tuesday, 30 November 2010 09:58

How to Handle Tight Deadlines as a Business Analyst

Written by  Sergey Korban
Rate this item
(0 votes)

BA_Nov30_FeaturePicWhen 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:

BA_Nov30_Article_cropped

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.

Conclusion

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.

Don't Forget to Leave Your Comments Below


Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of innovative visual learning resources for business analysts. We think business analysis should be easy to learn! We deliver practical knowledge visually, with a minimum of text, because that's an efficient way to learn. Find out more at http://aoteastudios.com

Read 7969 times Last modified on Tuesday, 27 March 2012 13:46

Comments  

 
0 # Justin R 2010-11-30 06:33
This is very true Sergey. What some people don't understand is that deadlines can be moved. It is better to be realistic about the deadline and negotiate what can be delivered than to try and reach the tight deadline and not meet expectations.
Reply | Reply with quote | Quote
 
 
0 # Charu 2010-11-30 07:13
Better strategy than moving the deadline is to negotiate which requirements are absolutely mandatory on that day 1, which ones for day 2, so on. Most of the times, it will be easily possible to deliver what is required for day 1 to 10 ....on the original deadline once the stakeholders / business teams understand that hundreds of "nice to have" requirements were in the set .....that can be met a bit later. Some requirements also get into the priority list just because X thinks that his/her requirement should be given priority over Y's requirements... ....make good relationships with both X and Y ......once they understand that both their requirements could be ultimately met, it becomes a bit easier.
Reply | Reply with quote | Quote
 
 
0 # Jim Adcock 2010-11-30 07:48
Under Determine Business Context - "If done right, it also gives a business analyst an opportunity to find ways to add value to the business" This can also open opportunities to alter constraints in your favor... if you can make a business justification, you might be able to get additional resources dedicated to the project if your project has benefits and synergies initially missed. yes, in tough times with resources pared to the bone (or beyond) this isn't likely... but it never hurts to try!
Reply | Reply with quote | Quote
 
 
0 # Sergey Korban 2010-11-30 08:18
Thanks for the comments! Char u: absolutely, prioritising requirements is essential and I touched on that in "Define Solution Scope". Sometimes the deadline needs to be adjusted even if you're down to must have requirements though. Maintaining relationships is very important too! Jim: you're right, I also think business analysts should be on the lookout for possible business improvements even if they are beyond the scope of the project. They may not get included in the current project but perhaps they will turn into another project down the line.
Reply | Reply with quote | Quote
 
 
0 # Nagarjuna Mallipeddi 2010-11-30 21:30
Thanks for very Good Information, Mr.SergeyK I have a small doubt: I am new to Project Management, Doe s really the scope changes, if we are dealing with deadlines?
Reply | Reply with quote | Quote
 
 
0 # Sergey Korban 2010-12-01 02:49
Nagarjuna: the idea with scope is that you must determine which requirements are absolutely essential, and which ones aren't, and decide what to include to meet the deadline. The project could be delivered in stages in order to start providing benefits to the business as early as possible.
Reply | Reply with quote | Quote
 
 
0 # Kenix 2010-12-05 18:02
I do agreed with the conclusion "what can be done to change the deadline" and "what is the best way to organise your work to meet the deadline." But, unfortunately my company was always unable to meet the deadline....rea son being lack of manpower in IT dept...although we had organise our work properly but there are some external factors which is beyond our control....
Reply | Reply with quote | Quote
 
 
0 # Sergey Korban 2010-12-07 07:07
simpleplan: There is only so much you can do of course. If you're seriously understaffed, you have to adjust the scope of the projects or deadlines accordingly. Unforeseen circumstances can arise as well, so you need to be aware of the risks and have a plan to mitigate them.
Reply | Reply with quote | Quote
 
 
0 # Kenix 2010-12-07 11:16
Thx Mr.SergeyK...wi ll try my best to adjust the scope of the project/deadlin es.
Reply | Reply with quote | Quote
 
 
0 # Vidya Sagar Obulam 2011-01-17 23:35
Yes i do agree sergey, Any scope change to the scope of the requirements will leads to the slippage of the project dead lines. It all depends on the how the total team is working towards the deliverable' S ergey, correct me if i am wrong, If the scope creep is from the client end, Do we need to considered that slippage as project slippage. In that case, we cannot meet the deliverables. Sagar Obulam
Reply | Reply with quote | Quote
 
 
0 # Sue Wilder 2011-01-24 06:50
You say, "Face to face communication is essential to make short iterations work..." How many of your readers are lucky enough to have all their team members/managem ent in the same state, let alone the same building? One of my recent projects involved working with team members (and management) in a half dozen states from coast to coast. Face to face meetings are almost a thing of the past with my organization.
Reply | Reply with quote | Quote
 
 
0 # Sergey Korban 2011-01-25 08:26
Thank you for the comments. Saga r: if the client is changing their requirements, it should lead to re-assessment of the project schedule. It doesn't always happen in practice, unfortunately. Wildeks: The reality is that distributed teams have extra communication overheads, so making short iterations work in a distributed setting is harder, e.g. due to time zone differences and the difficulties in setting up meetings. This can be mitigated to an extent but requires a lot of discipline.
Reply | Reply with quote | Quote
 

Add comment