Leadership & 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.

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the “Rearranging the deck chairs on the Titanic” phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms.

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.

I recently saw the "The King's Speech," a movie about the relationship between the stammering King George VI of England and his speech therapist... how is this commoner able to help the monarch and become his life-long friend? He is a master at influencing with absolutely no authority.  There are some lessons here for those of us business analysts and project managers whose jobs depend on our ability to influence without authority.

More and more organizations are taking advantage of business process management (BPM) solutions. And yet, it is often the case that, after an initial success or two, the growth of BPM within a company stalls.

Most business analysts will never interview a CEO and many don’t understand how a company’s real objectives cascade down to the little bit of requirements they’re doing for a particular system.

How does my system fit into the company’s business strategy? What is my role in the big picture?

We can probably all agree that Knowledge Management is generally A Good Thing and that we should do more of it. But what does “doing Knowledge Management” actually involve, and how as BAs can we ensure we effectively reuse our knowledge?

In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

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.

There are as many types of business analyst personalities as there are organizations and projects. The million-dollar questions is, how can a manager match an analyst’s unique skills to the projects that can really benefit from them, helping to ensure a project’s success? How can a manager build stronger, perhaps more suitable skills in his analysts?

Can the same business rule be enforced differently in different contexts? The answer – an important one for re-use of business rules – is yes. This article explains. It also outlines what business analysts need to know to specify contexts of enforcement for a business rule effectively.

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?

Many organisations hire external consultants with no experience of their business to shape strategies and propositions. In doing this, they are unconsciously ignoring internal resource with exactly the same skills but additional knowledge and experience of the business – namely their Business Analysts. BAs have a unique skillset, offering holistic insight, analysis and recommendations.

In many organizations, Centers of Excellence, PMOs (Program/Project Management Office) and PQA (Process & Quality Assurance) teams use a variety of manual techniques to vet documentation that are time consuming and manual; leaving room for unintentional mistakes, missed steps and delays in catching errors with regards to governance and best practices. In the spirit of delivering the project on time and under budget, many times these quality review processes are rushed and reduced to cursory checks. Like ensuring documents exist with the right naming convention, rather than reviewing the internal contents of documents and ensuring the contents are of high quality.