Featured in these publications:

Featured in these publications:


"Can you really fix most of these common requirements issues by using an 'Active' approach to Business Analysis?"

According to PMI , 47% of projects that missed the mark are there because of requirements management. Are you seeing any of these signs of r...

Friday, May 20, 2016

You can't get there with Scrum

(Article originally published on CIO.com)

A lot of business units and a lot of organizations today are obsessed with Agile. Even in departments where all development is outsourced. Even those that never build their own software and always rely on procurement to get what they need. They're asking that of their vendors, their business analysts and even their business users.

Everyone is excited with Scrum and beating folks over the head with it.... And they expect marvelous results.

Unfortunately though, most of these companies will never get what they want. And here's why.

Nineteen-page Use Cases

We were recently engaged with a client where IT has been notoriously slow and the CIO was getting a lot of heat from the business side. After digging a little deeper we found that roughly 60% of business requirements produced had never got into development, simply because development never got to them in time.

We looked at the development team and found out that they have in fact implemented Scrum and their output per iteration and their quality of code was good. At the same time, the business was complaining that these guys can't even get one use case implemented.

We looked at a Use Case document and found some really long Use Cases. One of them took the BA 19 pages to explain what the system was supposed to do. And after digging a little deeper we also found some missing requirements!

So was the IT really the problem?

The broken pipe

Let's 'take a step back' and look at the entire process. Let's see what it takes for a business goal to materialize in a form of a working and effective software.

It all begins with an idea. Someone on a business side requests a change to an existing process, tool or an application. Business Analyst is then engages in a number of activities, filling in all of these important additional details, validating the requirements and making sure that implementing them will actually produce an effective solution.

You see, it's almost always possible to validate with a high degree of accuracy whether the solution will actually meet business needs or it won't.... before the first line of code is ever written.

And in the rest of the cases, you actually can validate the solution much, much sooner than it would take to fully deliver it.

Once the requirements and designs are complete, they're handed over to development team. So will it help if we turn the knobs and look at your development team under a microscope? Will it make your end to end implementation that much better?

Turning the wrong knobs

It actually won't as a lot of things is happening way before someone on development side will ever know about the new project!

In another client's case it was taking 6 to (in some cases up to) a year to get the requirements ready and then up to 4 months to deliver a project.

So will it matter if you optimize the hell out of your development and deliver in 2 months instead of 4? What will it do to your time to market? And will getting user feedback in 14 months instead of 16 make a dramatic difference on your business decisions? (When you can get that feedback in just a week or two!)

You see, almost all Business Analysts are following the BABOK Guide, but how well and is there a metric? How good are your BAs?

Are they 'downloading' requirements and just writing down what a stakeholder is saying? Are they looking to understand the realities of the end user workspace, things like the attention span, noise levels and dealing with interruptions? Do they use prototypes and user testing for validating requirements or are they just relying on document walkthroughs and obtaining signatures for their validation?

Are you seeing confusion around the scope and direction or lack of project alignment with business needs? Are you seeing developers getting stalled looking for perfection and missing the mark or trying to anticipate business needs instead of getting the facts?

All of these are the early warning signs of serious requirements trouble.

Now, in most companies it's always the business side that gets the blame for requirements issues, so no action is required on your side and you can continue to try to optimize and squeeze the last little bit of extra efficiency out of your development team... Or you can take a step back, look at the big picture and get a 'plumber' to fix that huge leaky pipe between your business and your development side - pipe where a lot of stuff gets piled up and even more stuff gets missing.

Am I describing your situation or you're seeing something entirely different? Did Scrum alone get you where you wanted to go? Would love to hear your thoughts. Please lay them out in the comments area below.

Monday, May 9, 2016

New Requirements? No, Weak BA!

(Article published on ProjectManagement.com)

Are you still blaming users for new requirements? We're getting an overwhelming amount of feedback about common requirements trouble - from projects of all sizes, across all industries. Trouble like confusion around the scope and direction, lack of project alignment with business needs, getting stalled looking for perfection and end up missing the mark, trying to anticipate business needs instead of getting the facts, and many more.

Why is this all happening? Isn't that because of the lack of discipline among requirements holders, when they just keep on asking for different things - often late in our projects - throwing a monkey wrench into our schedules and our budgets?

Let's look at Stakeholder Management, one of the top time and energy drains for a lot of PMs right now.

Dealing with difficult people

Why are we seeing constant issues with 'difficult people'? Why are they keep on asking for changes, and new functionality?

Except for a very few cases of anti-social behaviour, most business people are not asking for changes just because they like to disrupt projects. They do that because, in a lack of robust processes for collecting requirements, critical realizations are often missed and they get later discovered as 'new' requirements.

If you're like most organizations out there right now, chances are that your stakeholders too have very little faith in your requirements process and feel the need to constantly interject and check on status and otherwise get involved with the project team.

And these requirements they 'discover' after the fact are anything but new requirements. They are just the ones that wasn't considered before.

So as the project progresses and time is passing by, stakeholders are continuing to unwind their feelings and continue to explain what they really wanted, even though these often perceived by the PM and the project team as net new requirements.

Not only this creates schedule and budget issues, as the project is constantly expanding to accommodate these unplanned changes - following these practices also creates a lot of frustration.

It's one thing when Agile is used to iteratively deliver functionality in small chunks with some changes and new features added with each new iteration. It's totally different thing when the business frequently doubts the value of everything that has been delivered to date because of a change in direction. Do this a couple of times and you're also facing morale issues in your project team.

So the critical realization here is this - all of this scope creep, this confusion, these stakeholder management issues - all of this is happening on our projects simply because nobody has taken the time to get all of the requirements early on - and then work with users to validate them. 

Validating requirements

Now lot of organizations we're dealing with are still relying on a 'download' process -when a BA is sitting next to a stakeholder and simply asks them what would they like to see built or procured. The validation process is then reduced to simply reviewing the Requirements Document in a meeting and having the business sponsor sign off on each individual requirement.

Yes, that creates commitment and accountability but doesn't offer a reliable way for making sure that following these requirements will actually achieve desirable business goals.
If you have a user interface (UI) component to your project, validating becomes really simple. Your BA could start by creating a prototype. And you don't have to be fancy about it. Many times, a paper prototype or a set of rough clickable wireframes, taking a few hours to create, would just do the job. As long as the core functionality you're looking to develop or procure is represented, the prototype is doing its job. And then you could test it with users.

If no UI component is involved, BA can still bring people in from outside your key group of stakeholders and present them with sample outputs from a system you're about to develop and see if that would solve their problems.

Playing it safe

Now what does a typical BA do instead? They just download the requirements.

And I'm not saying this aren't smart. It's nice to be a note taker and then blame it on business users. Won't even have to do that. Just keep quiet, do nothing else and the blame will still land on business anyways!

It's easy and it's safe. And they won't have to face the consequences. It's you, the PM who will have to explain why are you asking for more money yet again and when is the thing going to be ready.

BA has nothing to do with it. They asked what your key stakeholders wanted to do and they recorded it correctly. Look, they even got them to sign off on their notes!

Next steps

Well, I'm not saying your BA is sloppy or malicious. It may just be an education issue... And if you're ok with the situation, no action is required and you could continue with your rocky ride.

But if you're sick and tired of this blame game... of all this confusion and constant changes in scope and direction, if you are looking to build better benefit realizations from the start - you need to fix your BAs.

You see, requirements holders are not trained in business analysis, design thinking and requirements management. Most of them are used to expressing their needs in form of solutions. And it's not their job to take a step back and look for the real business goals behind what they are asking a project to do.

It's a job of a BA to see if directions should be taken literally or they need to be refined. It's not your stakeholder's job to create mock-ups and validate them with users either. It's the BA and the Designer's job.

So there you have it. You can blame and complain or you can take an action and provide your BA with the education they need to be effective at collecting all of your business requirements upfront and use reliable ways of validating them.

Would love to hear your thoughts. Please lay them out in the comment area below.