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.

Wednesday, April 27, 2016

Why is the industry taking so long to catch on?

This article has been originally published on ProjectManagement.com

Why so few organizations have mastered these Design Thinking processes yet?

If these Human Centric Requirements and applications of Design Thinking to project management so powerful, how come the PMI has not yet included these tools and techniques into the PMBOK guide and so many companies are still unaware of them?

There are two reasons: organizational and political.

Organizational reasons

Human Centric Design is not new and Apple, Google and other mega successful companies have been quietly applying these processes to requirements management for years now. But for a lot of enterprises, these powerful tools are still kept confined in Web Design areas and only for their externally facing sites and apps.

In my recent webinar presented on ProjectManagement.com we introduced five levels of corporate design mastery. Basically, if you look at companies like Capital One who invested millions of dollars in acquiring leading design firms, so far they have only achieved a small fraction of potential ROI, because they have only been using this talent around Web Design and only on projects for their externally facing sites and apps. The business logic components of these apps are still being designed the old way and so are the countless other sites and apps they're using internally to conduct business.

That said, teams around the world are waking up to these methods and a lot of BAs are now trying to apply these tools in their daily work... And a lot of things are NOT working because people are taking a simplistic, mechanical approach.

Here's an example. A BA red an awesome article written by an interaction designer, teaching them to use wireframes for communicating ideas with stakeholders. He tried that and saying that UI team is not allowing him to show these to a client out of a fear that they may not be complete!

But wasn't that just a better way to present ideas, not commitments?

So you can't just sprinkle these tools in organizations like magic dust and expect them to transform your processes. You start with implementing processes and then see better outcomes, better apps built or procured, lower budgets, better benefits realizations.

And that brings us to the second reason why the industry is taking that long to catch on:

Political reasons

Scope and direction are the most critical component of any business requirements. Getting them just right creates most dramatic savings and biggest improvements that these Design Thinking processes could possibly achieve.

Most stakeholders formulate requirements in a form of solutions. These initial solutions may not be the most optimal and complete, so Design Thinking is calling for 'stepping back' and discovering business goals behind these requirements, then re-designing and validating solutions.

So a lot of people are doing it wrong. They try to challenge authority and get into all types of political traps and get themselves in trouble.

Done right, these processes do not require challenging of anyone's authority and there's no need to disrupt anything.

Instead of saying that your business sponsor is wrong and the goal will never be achieved or that their solution will not work (or embarking on a suicide mission to implement it), asking why was it important to achieve those goals turns a conversation down a much more productive path.

In my recent article on CIO.com I'm providing a practical five point checklist to see if your BA is doing their job or if they're adding to your risk charter.

Are you hearing about "requirements" more often then you'd like to? Seeing 'new' requirements in your projects a bit too often, causing time and budget discrepancies? Any other signs of your BA area needing improvement? Let's discuss how these active BA processes can bring positive changes quickly.

Would love to see your thoughts in the comments area below. 

"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 requirements trouble in your organization?
  • Confusion around scope and direction…
  • Unstable, not measurable, conflicting requirements…
  • 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…
If you are - your Business Analysts are most likely taking what we call the 'passive approach' and simply 'downloading' requirements - asking stakeholders what would they like to build. 

This may sound clear and logical, but results in missing requirements, late and over budget projects, poor alignment with core business goals and a lot of stress.

We help organizations use an active approach - to get a lot more (if not all) requirements upfront.

Many times this brings almost immediate results. 

For example, directly as a result of using these processes, an Alberta Government agency saved over $2 million in their content migration costs, is on track to complete the project 10.7 times faster and are now enjoying 20 times better use of senior resources.

We only spent a week on this project and were able to discover that the focus of their software solution should be on improving mapping, not the migration part of the process.

“Excel method is a real drain on your senior IM people, whereas the new Migration Tool provides much higher leverage of senior time.” says Stephen Madsen, Program Manager at Alberta Agriculture and Rural Development

These proven processes are based on decades of user research and result in less scope creep, less blame, better focus and much better project success rate. Apple, Google and other 'design' leaders have been using these processes for years now, and enjoying wild success as a result. 

It is now your turn to install these Active BA processes and reap the benefits in your organization. Reach out to Dmitri to discuss your situation or browse these posts for practical tips, tools and processes

Monday, April 25, 2016

Looking for a Superhero BA?

(Article published on CIO.com)

Picture this. A financial services company employs a number of advisors who spend a most of their time on the phone with current and potential clients. They're using their CRM system to get relevant client information that may be needed in a conversation - client's notes, address and the important dates.

The company undertakes a project to add client portfolio and other relevant information to their CRM. Business Analyst (BA) on the project carefully defines all the additional fields and arranges them in clear and logical manner.

Developers take the requirements and implement them. The system passes the QA with flying colors and rushed into production... Financial advisors are trying to use it but it just doesn't work.

No, the queries are executed fairly quickly and correct information is coming up on the screens, but to get to the relevant information, advisor has to follow several steps and drill down, and it's really difficult to do... with a client on the phone! So they now end up excusing themselves to look up client's information and then having to call them back!

What happened? The system brings up relevant information, response times are adequate and all of the forms look good, so weren't business requirements recorded correctly? Were business users wrong to ask to add portfolio information?

One man at the helm

A while back when I was a development Team Lead I noticed that, to paraphrase the God Father, one BA with a pen can create more value (or damage) then a gang of developers with latest computers. And the same is true today. We have cross functional teams, automated testing and requirements validation in place yet one person, the BA, can easily send the entire team down a wrong path.

As I mentioned before, most business people tend to express business requirements in a form of solutions. And good BAs know to look for the real business goal behind them, learn how users are going about their daily tasks, and come up with better solutions. In our example, watching advisors talk to their clients on the phone could provide important insight and help design a much more usable system. 

Is your BA a strong one?

Clients often ask me if they need to replace a BA, and many times it's a tough decision. BAs take time to get up to speed, so organizations are often slow to replace them. Training helps to a degree, but most of the critical qualities that make up a good BA are difficult to develop.

One BA error may literally cost millions of dollars when a large team is sent down a wrong path or a wrong solution is procured. And when some of the critical requirements are missed upfront, they are discovered later in the project and treated by PM as 'new requirements'. This makes projects fall behind, cost more and introduces a lot of waste in the process.

So here's the list we offer our clients to help assess the skills of their BAs and gauge the degree of requirements related risks they have in their projects.

Five most critical BA skills

Here’s a list of most critical skills a successful BA must possess. If one or more is missing - your projects may be at risk:

Skill #1. Attention to details.

No surprise there. A missing column in a report may seem like a small thing but may take weeks to add later on, after the back end is built... A missing search box may cause weeks and months of combined time lost across your user base. So the system needs to be airtight and business requirements captured exactly and nothing left to chance.

Skill #2. Personal organization skills.

Time management, getting things done without being reminded, focusing on priorities, communicating ahead of time when they feel that they may be late on commitments...

Competing priorities is a reality of today's enterprises and ability to focus on critical tasks, make judgements and come through on commitments is not to be taken lightly - especially when a large team or a vendor is on the other end waiting for these requirements.

Skill #3. Empathy, interviewing and facilitation skills.

A good BA needs to be able to conduct effective meetings. They need to be asking to a problem and be able to get to the key business goals - preferably, measurable goals. They need to be able to facilitate meetings and elicit ideas instead of merely taking notes. 

Skill #4. User research skills.

Observation is an essential part of any requirements gathering phase. It doesn't need to take long, but taking note how business users are interacting with systems, notice details about the environment - noise, temperature, light, stress level, interruptions etc may make a difference between a productive user and a user who refuses to use your system, a successful system and a failed one.

Still #5. Communication skills.

It's kind of obvious, but I still see this overlooked often enough... and cause serious damage. An elaborate requirements document or a detailed user story is all good and fine, but many times a BA needs to be able to communicate their ideas effectively to development teams and external vendors.

Ability to create mock-ups, diagrams, wireframes is also very valuable. Especially in fast paced environments where documentation is minimized and it's way too easy to just assume that it's kind-of obvious and that developers will figure it out.

Coming up next

There you have it. Hope I was able to communicate how easy it is to overlook the role of a BA, how big of a difference a strong BA can bring into a project and how to tell a strong BA from a weak one.

Wednesday, April 20, 2016

Why 'Design Thinking' is becoming a game changer for many enterprises

This article was originally published on CIO.com

Can these techniques really be the future of business requirements management?

Just over a year ago Capital One has acquired Adaptive Path, one of the most prominent design firms of recent years. About the same time Accenture acquired Fjord, another design leader, and IBM is on track to grow their in house design team to more than a 1,000 people. What's going on?

Even though, the term 'Design Thinking' has been coined back in the 90s, only in recent years Apple, Google and other "design leaders" have been able to achieve astonishing success. Why?

Design Thinking has grown past its original applications in Product Design and Website Development. It is now a standalone discipline with clear set of methods and wide spectrum of application - from traditional consumer products and mobile apps to enterprise systems, construction, procurement and vendor management. So look and feel is no longer the only focus.

In this blog we will be diving into the practical aspects of Design Thinking, it's tools and repeatable processes - processes that Apple and Google have been quietly using to became world's most valuable companies... processes that help government agencies achieve better benefit realizations and reduce waste... processes that help project managers around the world to keep their projects on track and their business users happy.

Introducing human-centric design

The term 'Design Thinking' is often associated with David Kelly, Stanford professor and the founder of IDEO, one of the leading design firms established in 1991. Design Thinking started as a problem solving approach and differs from traditional analysis in that it doesn't attempt to fully define a solution upfront. Instead of taking business requirements as marching orders, designers were encouraged to seek better understanding of the situation, reasons why, core drivers and business goals.

Fast forwarding to this day and over 20 years of research, "Design Companies" have learned to appreciate what now called the Human Factors -- facts like that business requirements are created by humans and often given out in form of solutions, which may or may not be ideal and represent just one of all possible options... facts like asking business users what they want may lead a project going in a wrong direction... facts like that different types of users, different roles and personalities may have completely different ways of interacting with your systems and very different requirements.

Latest advances in Design Thinking now offer a human-centric approach and repeatable processes to take all these into account and focus on just the right problems and the most efficient solutions.
All about requirements

I always liked to paraphrase the God Farther and say that one business analyst with a pen can save a problem faster than a dozen genius developers with latest computers. It's really is all about requirements.

Recent PMI study quotes that 47 percent of projects that are in trouble today are there because of a slip in requirements management.

Think about it. Out of all projects that failed to hit the mark -- across all industries -- virtually every second one is in trouble because of requirement management.

Business users are called upon to do something that they have never signed up to do -- design solutions. Business Analysts just come and ask them what would they like to see in a finished product...

Placing business users on development teams helps to better translate their vision to code but offers no protection against ineffective solutions and occasionally, going after completely wrong business goals.

Wrong solutions are being procured, implemented and developed. Years of effort are spent creating customizations, just to realize that they don't fit very well with the way users are interacting with the system or that they're solving the non-critical issue, while the most critical ones are left unaddressed. And that also creates confusion about scope and direction...
The scope creep

If you hang out with PMs, you hear a lot of complaints about the Scope Creep common phenomena - when new requirements are coming out of the woodwork long after a project is initiated and wrecking havoc in schedules and budgets. There's also another related project risk - stakeholder management. That one is about managing expectations and dealing with 'difficult' people who cause Scope Creep by coming up with all of these 'unforeseen' requirements.

But why are they doing this?

You see, when business requirements or an RFP is created based on a 'download' from one stakeholder, there's a very good chance that they will later realize that they've forgotten something. Other stakeholders and other business units will also pick up on missing pieces. And you have little control over when these insights can occur and whether or not this process based on spontaneous realizations will lead you to a complete and effective solution in the end.

Now what if we take most of this volatility out of user requirements? What if you could 'magically' extract the knowledge out of your key stakeholders and flesh out completerequirements in just a few days? What if you could also include the end users in the process to further insure against missing things - without stretching the process a lot longer?

If we do that - wouldn’t that just slash this 47 percent project failure rate down to low 5s for you? What would that mean for your current projects in terms of dollars saved and improved user productivity?

Now what if I could show you the processes your BAs can follow to get all of this done in just a few days, often before a project is started? Wouldn’t that be something you'd like to learn?

Well, this is the reason why IBM is being so aggressive with building up its design team. And this is exactly the reason why I'm so excited to show you how you too can implement these same Enterprise Design Thinking tools and methodology on your projects in very near future.

Coming up next

Thanks for reading the article. Hope I was able to paint a perspective and show you why Design Thinking is now becoming a game changing competency for many enterprises and why we're seeing this trend of acquiring the design talent on such a broad scale - even by the enterprises where design has never been a key focus area.

Did I miss any of the important issues with Design or Requirements Management that you're dealing with right now? Is there a specific topic you'd like me to focus on? Would love to see your thoughts in the comments area below.

Monday, April 4, 2016

Deriving Scope from Goals

This is a copy of an article originally published on ProjectManagement.com

When it comes to risk management, requirements - related risks are usually the toughest. Imagine taking exact business specs and using them to build a system... or select a COTS solution or find a vendor to build it out. And then all kinds of new requirements are beginning to surface. Turned out, business users did not really want the system to work like that. And thiiis and that features are missing and both are really important!

And most PMs are just shaking their heads in disbelieve. "Did we not build exactly what you asked for?" Well, yeah, but...

So agile folks have been really smart about it with short iterations and putting business users on their cross-functional teams, making sure that developers never have to guess about how business processes supposed to work...

And that has been working reasonably well, except that you may still end up building the WRONG THING!

Sure, if you follow agile, you are going to build it right from the technical point of view and all of your business logic will work as it should, but how will you ensure that the RIGHT problem is being solved?

The F-16, one of the most successful military aircraft ever designed, was not built to spec. Designers recall that original requirements were calling for the Mach 2.5 speed yet that speed was never achieved.

The reason why F-16 was so successful (and still is, more than 30 years into production) is because the designers went back to their internal clients and asked why was that speed was important. Instead of just taking on the mission and trying to build an aircraft capable of achieving Mach 2.5 (which was next to impossible back in the day), instead of focusing on "proper processes", designers took a step back and looked at the bigger picture.

Turned out, the greater speed was needed to be able to escape from combat. But that was just one of the possible solutions, so alternative solutions like better view for the pilot and greater agility helped achieve the same or better results.

Taking it all the way down to a seemingly small content migration project where business has asked for a better way to migrate content - when the majority of time was actually spent on mapping of old and new content structures - focusing on the key business goals - faster migration - helped complete the project 8 times faster and save $2Million in the first year.

You see, when business people are asking for something to be built of procured, they tend to 'prescribe' solutions. And the trouble is - many times these gut feelings are taken by development teams and procurement - whatever the case might be - and followed as marching orders for defining scope and starting projects.

Agile has done a great job making business analysts put requirements in a format of User Stories. "As Records Officer I want to capture the document type and the type of vendor In order to determine retention". That does a great job at raising awareness of development team and understanding who and why needs each particular feature. But what if only a small portion of documents are coming in through this particular channel? Maybe capturing document type and vendor now should not be made a priority.

So way too often organizations are spending a lot of time striving for perfection and trying to anticipate needs of their business users instead of conducting proper user research and getting facts.

What if we used User Story format and apply it at a much higher level - at the level of a project or even a program? Who needs that project, what kind of benefits are expected to be realized and why is that important?

And what if we compliment that knowledge by observing users conduct their daily activities? So not only will we focus on correct business goals, but also try to achieve them by solving the right problem in a right way?

That's what making Design Thinking in Project Management such a powerful tool. Use it and it might push your projects into totally different direction - direction where you'll see a lot less scope creep and much higher benefits realization.