Success and failure are difficult to define and measure since they may mean different things to different people. An assumption that success can be quantified seldom holds true in the face of an ever-changing yardstick used to measure success. What might be considered to be a successful attribute today can be rendered unsuccessful under the influence of dynamic and multi-dimensional constraints.  A project is primarily implemented to target a predefined outcome, and it is imperative to measure the output in order to determine the benefit derived through the project. However, benefits realized do not necessarily add up to success. Project ‘success’ is different than ‘benefits realization’.

“Well it just so happens that I have a question about tools.”

"What tools do you suggest a business analyst use in pursuit of his or her vocation? What tools can be used as best practices for business analysts?”

How do you become a business analyst and where do you begin?  So you want to cross over to the land of analysis? A land of ‘schizophrenic’ people who need to possess multiple skills and make meaning out of ambiguity. You'll need to break down complex problems into bite-size chunks that can be easily understood. You'll also need to manage different stakeholders and break down knowledge barriers formed by these stakeholders. (Most having been in their organisations for decades) Finally, you'll need to develop a thick skin to stand in the firing line.

One of the key aspects to be considered before implementation of Agile methodologies is the degree of agility suitable for the organization. Due consideration should be given to the ‘current state’ before we create a proposal for the ‘future state’ of agility desired. Neglecting this aspect may invalidate the very purpose behind the endeavor.  Degree of agility refers to the relative ability of an organization to adapt to the lightweight methodologies in conjunction with an assessment of current state process maturity.

A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.