Crisis Management

Its been a while and despite a lot of requests i have missed out on updating this Blog for a while... though i hope i could do better now and continue to update this page more regularly...

SO talking of crisis management... i have certainly got a crash course if not and elaborate one on Crisis management, Though i guess the precise definition of crisis mangaement might make it sound more like a natural disaster, i honestly think working as a business analyst, one has to encounter & manage Crisis management more then once for sure, crisis could be uncalled for or even a foreseen one, where we know we are heading towards it, but there is little or no control in a BA's hand to avoid it, how ever i think an analyst is amongst the first (And i whole heartedly agree to this) to be singled out for a failed project / task, though a successful task usually goes unnoticed or should i say unappreciated... Though thinking on a larger level, the argument can be made that the whole team has to work together to make any team / project successful, how ever it is more or less in the hands of a functional person, who of course is leading the project / BA /dev teams, to make sure of the team is going awry then to steer it to the correct path. By hook or by crook, Job on hands has to be taken care of for sure...

so first, lets see how crisis management can be avoided in a project management situation -

1. Weekly goal definitions / milestone checks should provide a good indication of progess, how ever these could be deceiving too.

2. Burn down charts - A brainchild of SCRUM Methodology, sounds and looks way complicated, but is rather a simple chart which when used effectively could help you identify your most and least productive resources

3. Refactoring - No project is perfect, no coding will ever give you an output which will please every one, either the client has more expectations or the testing team is much more efficient then expected, in any case one should be prepared, I have seen in general for most projects 20-25% of the total time should be allocated to refactoring... trust me you will need it.

4. Meeting expectations - One of the most common grievance the client side / management / stakeholders seem to have is that final output of project leaves these people with a lot of questions and unmet expectations, which might or might not have been conveyed to the project team, best way to ensure this is by elaborating on the requirements to granular level, outlining each step that will be taken and if possible getting the stakeholder to sign off on the same (Even though a functional spec should take care of this, in the world i work i have seen this issue coming back to haunt us)

5. Scope creep - It is important to understand that nothing that has been planned for should be worked on unless it is of critical nature or the BA has messed it up in requirement gathering, its easier said then done, how ever working on things which haven't ever been planned and also asking the team to work on requirements that were never discussed is not only a distraction, but also affects the productivity and output of the entire team

6. learning to say NO - It sounds difficult and of course more often then not its at the cost of giving yourself a bad name, how ever saying NO to recurring change requests from the stakeholders is not just about saying NO, its more about explaining the person responsible for such changes that either this change will have to take priority over any other ongoing development or it will delay the entire process / project, its important to make sure when you say NO, the connotation should be positive. The best way to convince a stakeholder is by explaining the consequences rather then threating about the same.

7. Be prepared to put in the extra effort

8. Team involvement

9. Do not Tinker the process

10. Do not PANIC