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.

Friday, March 11, 2016

Is it BAD to be an Order Taker?

This is a copy of my post published on ProjectManagement.com

I've been talking to a lot of readers lately and a lot of people are seeing frequent changes in scope and direction on their projects. Users come at them from different directions. Right when they just completed a change request and had a chance to regroup and do a little planning, another two are coming down on their laps. And it sends schedules and our budgets way out of the ballpark again.

And there's a lot of followers of the Servant Leadership style, who are trying to play along. "At the end, users will use the system, so they better tell you what they really want". And yet another change request goes down to development or another RFP is issued for a new vendor solution and the cycle continues.

Some years ago I personally was involved in a project where a vocal BA has been bullying project managers into constantly accepting new features into a project, until 3 years later they have finally ran out of ways to expand their budget and got themselves shut down.

And a lot of PMs out there have seen this happening or have been beaten on the head with similar horror stories, so they fight their users tooth and nail to keep these additional requirements out.

Being an Order Taker

So is this ok to be an Order Taker or is it your job to protect your scope and your budget from poachers?

The answer comes when you "step back" and ask yourself a question - where do all these 'additional' requirements are coming from?

You see, many times, when a stakeholder is asking us to initiate a project, more often than not, they are also 'recommending' a solution. And if you're a consultant, you probably should not try your luck at proving them wrong right there and then.

And even if the solution was not prescribed by your stakeholders initially, chances are, your Business Analyst has been asking them questions like "What would you like us to build?" - and that leads the project in a wrong direction.

More often than not though, your users will be almost right, but pieces will be missing and some of these requirements, forgotten or omitted in analysis, would resurface later on as change requests.

So you may have to take orders, but being a PM worth your salt, don't just assume that your business requirements are complete or perfectly accurate when they hand them off to your team for implementation. Do your own analysis.

Watch business users follow the processes that you're trying to improve. See how they're doing things right now... Ask them about the biggest issues they facing in their jobs. Don't ask them what they would like you to build. It's not their job to design a solution!

Have your team start with a prototype. And you can get a lot of mileage with paper, Visio or other quick and easy visualizations of what will your completed product be like.

Then ask your business users to 'use' it. Don't tell them how. Just put them in fro

nt of the prototype and see how they do.

Taking action

Your user research activities would most definitely bring results. You may end up finding holes in your requirements and occasionally you'll find your project going in the wrong direction altogether. What were they thinking?

Don't jump the gun. Consider the circumstances, your role and the local politics. If you want to make a difference and really help your org - don't get yourself fired!

It may be a slow process and you may need to be politically correct and keep on asking non-threatening questions and use your soft voice for a while, slowly guiding your stakeholders and your sponsor in the right direction.

You'll succeed in the end and they will appreciate your contribution. Just remember, it could be a lot easier to find the root causes and real reasons behind things then to get people to admit things and get them on board.

Were you in a situation like that? Have you tried any of these approaches in the past? Would love to see your thoughts in the comments area below.

Thursday, February 25, 2016

Design Thinking Doesn't Work

This article was originally published on ProjectManagement.com

Here's the deal. When it comes to User Experience, a lot of stuff just doesn't work. Think of all the stuff you tried...

You tried stuff. I tried so many things. There's so many books I red. And a lot of stuff sounds really good...

In a book...

Design Thinking has been an elusive concept for a lot of companies over the years and yet very few have been able to make it work. And when I say "work", I mean - pay off and produce tangible results. Better products. Lower project risks. Smoother delivery and happy stakeholders...

The term itself is over 25 years old, yet almost everybody is having trouble getting the thing to produce results. Millions of dollars invested in Design Thinking every week just to produce no tangible results. Why?

You see, there's no magic to making Design Thinking work. If you do it right, it will jack results through the roof for you. It will burn your scope creep, slash uncertainty about requirements and project direction and make your difficult stakeholders easy and friendly...

...if you do it right.

The problem is in the term itself. There's actually a silent word in the term that most people assume when they pronounce it. And that one word is what takes the most people into trouble.

The word I'm talking about is "JUST".

People believe that if you JUST THINK DESIGN, the things will turn out for the better. Scrum teams will magically fish out requirements out of your market and your business users and everybody will love your apps.

No, this will not happen!

Think Design all you want. Visualize.... until you blue in the face! Nothing will ever happen.

If you do it long enough, cobwebs will form and still nothing will happen. And they will put a flipchart in front of you and leave you there to die.

You see, there's no rocket science to making Design Thinking work in your organization. Integrate repeatable processes in Requirements Management. Integrate UX processes with development.

Yes, this implies work and that's why a lot of folks are saying to themselves "no, I'll just think" and they're keeping positive attitude... all the way until their projects get into familiar requirements management issues.

Are you falling into this trap?

Don't guess. We built a quick self-assessment tool that produces your custom detailed report about exactly where you are with your repeatable requirements management processes and your Design Thinking implementation and what specific next steps will bring fast and tangible results.

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

Thursday, February 18, 2016

A 3 Step UX-Inspired Process for Achieving High Benefits Realization

This article has been originally published on ProjectManagement.com

Benefits Realization Management or BRM is a hot topic. It's a new discipline, that is getting increasingly popular and provokes lively discussions. It holds a great promise of helping organizations monitor and validate ROI over time to close the feedback loop and stop throwing good money after bad one. But do we have to wait until after the project is delivered and handed over to operations to see if it was a good investment? This article will provide practical advice and a proven User Research process you can use today to improve your benefit realization.

Flip Side Holds The Real Key

Garbage in - Garbage out (or GIGO) was a popular aphorism back in the 80th, at the dawn of the computing era. And this is still just as true today. If you get a project initiated 'on a thin ice', without fully discovering your key user motivations, habits and processes they use to do business today - you're setting yourself up for a disappointment.

You may even avoid the scope creep and have your project delivered on time and on budget, but, more often than not, it will not do so well with business users and your benefits realization numbers will come out negative.

Let's look at a quick example.

Our client invested 2 million dollars into an Enterprise Content Management system, looking to move their content off their shared drives and enforce sound security and retention management policies. They also began to use it to power their internal web sites.

Shortly after implementation, Content Contributors began to complain that, even after attending training, they were still having trouble updating content on the site. Some outright refused to use the new system and some were making arrangements to get transferred out of the role of Content Contributor (true story).

The Project Manager overseeing implementation brought us in to help figure out the problem and how to fix it.

After initial round of interviews and watching Content Contributors work, it became apparent that even though the BAs on the project team had thoroughly identified all needed metadata values and the workflows for content to follow, it was just too tedious to populate them and submit content revisions using the interface that was provided.

Despite the 'smart' validation features and good looking UIs, many steps were required to update a single page element, and users had to save intermediate files on their local file systems. Contributors frequently picked the wrong file, causing site pages to break or display outdated information, and privileged documents were left forgotten on local file systems.

After user goals and task flows have been identified, it didn’t take long to come up with the new interface. In just two weeks the new UI for Content Contributors has been designed, prototyped and validated with users and the development team.

Even though the client collected their requirements and did a good job describing the steps user were following, they forgot to consider how these steps fitted together. The screens themselves were functional and looked good individually, but they just didn’t work well together.

The Hero BA Trap

The reason why this organization forgot to consider the 'big picture' is the same reason why many other organizations make these one-off mistakes in their business requirements, and this is the reason why lots of companies will see spotty benefits realization at best.

At ECM Solutions we like to call that "The Hero BA Trap". You see, a lot of organizations are still relying on a Hero BA - a single person with exceptional human skills - to conduct all of their requirements work. If they make a mistake, there may be million dollar consequences.

Still many CIOs are thinking about the Business Analysis as an innate skill when good BAs are born and not raised.

Another reason this happens is because many organizations don't have repeatable processes in place, to ensure that problem definition statements are complete and that The Real Problems are identified, and they are not chasing down symptoms.

No wonder the PMI is reporting that only 20% of organizations are enjoying high Benefits Realization Rate!

Most companies have their processes in place for managing and verifying requirements, but collecting requirements still relies on Hero BAs and the big 'download' ritual, where they just sit with stakeholders, asking them what they would like to see, and then write it down.

Requirements Validation activities then involve asking their key stakeholders if requirements document looks complete and no unnecessary features present, culminating at getting requirements document signed off.

What's missing is the reliable process for requirements elicitation, making sure we actually get the full picture and complete description of the problem areas and the key processes people are using to do business.

And this is why so many 'new requirements' are still discovered late into the project and then managed as scope creep. Again reported by PMI, we see that out of all unsuccessful projects, every second one fails due to this lack of requirements processes, checks and balances.

Think about it. We invest in Agile to have a cross-functional, collaborative team deliver our projects, and that works really well... but only the delivery part, that has to do with 'on time and on budget' thing...

Then one person - a key stakeholder or a BA - misses an important detail in business requirements - and all of this delivery, fast efficient, on time and on budget - no longer matters and we end up in the ditch.

Even when you put a team of BAs in place or have a team work directly with stakeholders, the chance of missing important requirements or getting them wrong is still very high... unless you have the process in place.

So here's what I'm talking about:

Three Steps For Improving Benefits Realization

Let me share the three steps, that a lot of clients have found very effective in burning these common requirements management risks. These steps are based on 30 years of User Research, and User Research (not the Design) may easily be the main reason why UX is working so well for Apple, Google and other amazing 'Design' companies we all like to follow.

So here are the steps:
  1. Get all of your users involved. Don't limit your requirements elicitation with just your project sponsor or maybe a few key stakeholders. They may be too close to the wheel and may overlook things or never mention stuff they may be considering obvious.
    Yes, it may not be practical to conduct thousands of interviews, but there are high performing research methods that make it easy to get all of these people involved.
    The rule of thumb is to keep involving additional business users into your study until you stop discovering new details, and each additional user just keeps on repeating the things you have already heard.
  2. Ask about problems first. Think about solutions later. Don't start your interviews by asking users what would they like you build for them. Start with their Single Biggest Challenge. Solutions will come later, when the root causes and the key processes get discovered.
    And don't be fooled with traditional surveys. No matter how you present your assumptions - "On a scale of one to ten how would you rate your accounting system?" and "How long on average do the pages of your accenting system take to load?" neither of these two questions will help you figure out that the root cause is bad data coming from manufacturing, not the accounting system itself.
  3. Test your ideas early, don't wait till solutions are fully developed. Test on your prototypes, paper, quick wireframes and so on. Test often and use quantitative methods to base tests on facts. Watching users use the system without teaching them how to use it is the true test and could be very revealing.

So don't be running to your usability consultant after the system is live and users are refusing to use it or your design is crumbling under load. That's backwards thinking. Come to us before you initiate a project. Get some solid User Research done and be clear about the real problems your users are facing.

Don't start projects on thin ice and dump it all on PM's laps to deal with. Yes, it feels good to be doing something to fix the problem, but don't fall into that old trap as activity does not replace productivity.

Does your organization use a repeatable process for project initiation? Did you find it effective for discovering critical details and focusing on the right problem? How do you ensure that your choice of technology will work well? Do you replace assumptions with facts before you start or counting on your development process to clarify them? Love to see your thoughts in the comments section below.