Project Management

Software development process is undergoing seismic shift from traditional waterfall software methodologies towards agile methodologies. Agile software development methodologies deliver high quality software products in rapid iterations with high flexibility and adaptability to changing conditions. This article discusses the dynamics of agile projects by comparing it with the SDLC project framework to help the IT leaders and organizations plan effectively for transitioning to Agile software development methodologies.

Congratulations! You've just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold.

Recently, I was watching an episode of "60 Minutes" which discussed the prosecution of a whistle blower at the NSA regarding the development of a major system to be used in the War on Terror, code named "Trailblazer." Although the intentions of the developers may have been good, the project started to spiral out of control almost from the beginning.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of "features, functions, technologies, enhancements, and bug fixes," as "Agile Software Development with Scrum" states. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.

The ownership of business processes is often a bone of contention – with various parties feeling that they should be considered the owner of certain processes and not of other processes. Inability to agree on ownership can lead to turf-wars when there are perceived overlaps, as well as impactful inaction when no clear owner has been identified.

This article analyses the source of ownership conflict, and makes suggestions regarding resolutions to the problem. It considers the issue of ownership, as well as the issue of custodianship.

Abraham Maslow once said “If the only tool you have is a hammer, you tend to see every problem as a nail.” This article provides the project manager (PM) / business analyst (BA) a framework for categorizing business problems as a baseline for selecting a solution development life cycle (SDLC).

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

How far can you take requirements elicitation in a project? Clearly, no one knows the ultimate answer. It would be very costly (if even possible) to capture all requirements, assumptions, rules, relationships, and hidden connections associated with a solution being built, so how do we know when we are done?

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

The product backlog is a beautifully simple artifact – a prioritized list of the outstanding work necessary to bring the product to life. To work with the product backlog effectively, it needs regular attention and care; it needs to be carefully managed, or groomed. Business analysts can play an important role to ensure that this is done well.

There are many qualities that contribute to great business analysis. You have to be a good communicator and be able to analyze problems. It generally helps to have some solid background in the common techniques of business analysis. For some jobs you need domain knowledge, for others technical expertise. All of these are debated and discussed often in BA circles across the web. One of the attributes I don’t hear people talk about quite as much is being results-oriented.
 

 Today it seems like every project is urgent due to time-to-market compression and fierce competition in the global marketplace.  In this article we recommend management techniques that can help you and your team manage the complexities that are most likely present in urgent projects, while establishing and maintaining an environment of adaptability, innovation, and creativity.

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

Great teams, like all great organizations, are those that make a distinctive impact and deliver superior performance over a long period of time. For a project, performance is typically measured in terms of on time, under budget, with full scope of features, meeting quality specifications, and delivering the business benefit that was expected. Project teams do not need to be big to be great...big does not equal great. But all too often contemporary project teams are too large, too dispersed, too diverse, and just plain too complex to manage using typical project management techniques alone. So how can we be successful when a project demands complex teams? Success in the 21st century demands that we acquire new competencies to form, manage, and use large, diverse teams as a competitive advantage.

The purpose of companies creating Business Analyst positions is to improve IT quality and efficiency while reducing project failures. When I first started as an Analyst, coming previously from the position of Software QA and having an education in technical writing (think documentation), I thought I was the perfect mix for the position. I quickly learned that having a job where I prove my worth through project success can be stressful.