Featured in these publications:

Featured in these publications:

Featured

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

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.