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

Monday, December 21, 2015

Case Study: How A Government Agency Saved 2 Million Dollars By Solving The Right Problem

Here's a good example of how requirements issues can really hurt your project and, more importantly, your reputation.

We have a client who was looking to migrate a lot of documents from System A to System B while also consolidating them into the new storage paradigm. The current process depended heavily on using Excel, a time consuming and error prone process.

The client originally thought that the bottleneck was in the actual migration. However, once we met with them and applied the User Experience (UX) methods, we realized that the majority of the time spent migrating was not in the actual moving of documents. It was in the mapping, that is, deciding where does each of the source documents and folders from System A would end up in the new System B.

The business process proved unmanageable because the client was using Excel to track all these mapping.

To solve this, we built a mapping tool that brought in over $2 million in savings.
Before the tool was developed, each business area was taking about 4 months of a Senior Information Management (IM) person and one support person. At that rate, complete migration was going to take 16 years, and it was hard to add people because of the complexity and risks of errors in Excel mapping.

The new tool removed the complexity, making it much easier to bring in more people.

The time required to migrate was reduced to about 1 month of support person and less than a week of Senior Information Management member is now required for supervision. That’s a 400% improvement for support staff and 2,000% improvement for senior staff members.

Here are some key lessons I want to emphasize:

1.      Your Business/Functional Requirements may not be describing what your business users really need. (In our client's case, they were looking to speed up migration instead of figuring out the mapping part)

2.      Asking your business users what they want may also be futile. In our case, they asked for a faster migration tool. Later on, when we tried to 'explore deeper' using traditional methods - they asked for a an Excel Macro to better track the source to target relationship. Even with the best possible macro, the project was going to take up to 7 years with their current people at hand, while the Mapping Tool we developed allowed them to complete all migration in just over a year.

3.      Be clear on your project's primary business objective and what key activities you would like to optimize, then have your Business Analyst watch the business users perform these key activities. It's many times more revealing to watch them do it rather than asking them what would they would like to see improved.

4.      Most of the scope creep comes out of allowing your business users to 'design' the system functionality. A more effective approach is to observe them using their systems to collect accurate data, then validate the data with prototyping and usability testing before building the system.

5.      When using Scrum and other Agile methods, don't jump into implementation. You'll pay the same price for the scope creep, only you'll pay it in small installments in each of your sprints. Have your first sprint solely focus on UX activities validate that you’re understanding the real problem.

This case study is not an isolated incident. A study by PMI (Project Management Institute) confirmed that 47% of software projects are running into issues with requirements. As I (hopefully) demonstrated here, this new UX methodology is ultimately effective in combating these risks.


Thinking of getting your Business Analysts to use these processes but just unsure where to start? Get in touch to discuss your specific situation.

Slashing Risks with User Experience Engineering (Part 2)

This article was originally published on ProjectManagement.com:

http://www.projectmanagement.com/articles/311807/Slashing-Risks-with-User-Experience-Engineering--Part-2-


In Part 1, we introduced the idea of User Experience Engineering (UX) and the core tools and processes we use today to conduct user research. Let me continue by showing the core principle that all user research is based on--and how you can use it to combat scope creep and other requirements-based risks right now.

What's Wrong with Requirements Management?

As I mentioned, last year's PMI study shows that 47% of unsuccessful projects fail due to poor requirements management, so let's see if we can figure out why is this happening. Let me ask you: What are the two key characteristics of great business requirements? Complete and traceable, correct?


We wanted to make sure that all 100 percent of the user requirements are captured and nothing is missed. Then we wanted to make sure that each of the use cases is there to implement a specific user requirement.


Then the biggest risk inherent in requirements management is the scope creep. That's when new requirements are “discovered” after the implementation phase has started, throwing a monkey wrench into your schedule and your budget. Scrum and other agile methods then came to the rescue with splitting the project into a number of small iterations, reducing the impact of these after-the-fact revelations.


But small things still add up to big numbers. So wouldn’t it be nice to figure out why users just keep on coming up with these insights late into the project? Is that because we forgot to ask users the “right” questions? Or because business users are not properly managed and should not be allowed to interfere with our projects by mistake?


Let's look at an example…


10,000 Songs in Your Pocket

Remember what brought Apple back to life in 2001? The iPod. And what made it so successful? The big promise: "10,000 Songs In Your Pocket" (which quickly became 40,000 songs, as the photo below shows).


Picture credit: Engadget


Do you think users have asked Steve Jobs to give them 10,000 songs to go? No, they did not. They wanted a better mp3 player.

Now do you think they asked Apple to put a mini hard drive into an mp3 player to cram more songs in there? Most people didn’t even know what the “hard rive” actually was! It was the designers at Apple that found the mini hard drive that the iPod could use, and designed its friendly user interface. Then they were watching people use it and found that they were able to figure it out immediately without any explanation.


Users did not design the iPhone, either. They can't even tell you where they spend the most of their time during the day. That's the job of a UX practitioner. We watch users engage in their daily activities and document where the time is spent, what activities were easy and where people were struggling.


So we never want to ask users what they want. We want to ask them what they don't want and what problems they are facing. It then becomes the job of the designer to put tougher a solution for them. And then you want to watch them using it and see if it's working as expected.


Sony mp3 players had great battery life and they looked awesome, but it's the iPod that made history. You would've never known it if you asked the users at the time--they loved the Sony one just as much.

The Big Flaw

So that brings us to the big flaw in traditional requirements management. You can be more or less organized, you can do a good job at capturing everything your users are saying and linking these statements to use cases. And if you use Scrum, you can get away with a lot of things. But most of the trouble could be easily avoided if you can only change one thing: Stop asking users what they want. They can't give you the right answer, even if they really, really wanted. And it's not their job to design a solution--it's the designer's job. So that is the main flaw.


Users can easily tell you what they don't want. They can easily explain what makes their lives difficult. But if you ask them what do they do need to make it all better--this is when you run into all sorts of issues. And that's why the scope creep is here--it's when you ask your users to design the solution, something they have never signed up to do.


So instead of asking users what they want, user research focuses on carefully observing people's current behavior and interviewing them about their current situation. When we see the problems people are facing right now, we can use our training and experience as designers to put forward the solutions. We can then bring it full circle by watching people “use” our prototypes and see how successful we were at addressing current concerns.


Coming up next: I hope I was able to explain the big idea that makes the latest UX methodology so successful. As it stands now, I'm planning to start exploring the actual steps involved in prototyping and usability testing first, followed by reviews of the popular tools to use and other UX activities I mentioned in Part 1 of these series. I would love to see your thoughts in the comments section below. If anything is missing or you'd like me to cover something first, please do speak up!

Thursday, December 10, 2015

Slashing Risks with User Experience Engineering (UX): A PM's guide to User Experience - What is it and why should you pay attention?

This article was originally published on ProjectManagement.com:
http://www.projectmanagement.com/articles/311337/Slashing-Risks-with-User-Experience-Engineering

Just over a year ago Capital One has acquired Adaptive Path, one of the most prominent User Experience Engineering (UX) firms of the recent years. About the same time Accenture acquired Fjord, another UX leader, and IBM is on track to grow their in house UX team to more than a 1000 people. So what does "UX" really mean and why should PM's pay attention?
Even though, the term 'User Experience' has been coined in the 90s, today's UX 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 enterprise applications and industrial equipment to consumer products and mobile apps.

Risk Reversal - is it even possible?

Recent PMI study quotes that 37 percent of projects fail due to a slip in requirements management. So Agile development came into existence, because it allows project teams to adapt and succeed in the face of changing requirements.
But 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 all of the screens of your app in just a few days?
What if you could also do this with your end users? Your key stakeholders may be a bit too close to an app and when development is complete and the app is handed over, many projects are up for a few shocking surprises.
So if I could show you how you can also avoid these - wouldn’t that just slash this 37 percent project failure rate down to low 5s? And what would that mean for your current project in terms of dollars saved and improved user productivity?
One last question - what if I could show you how to get all of this done in just a few days, often, as part of the Project Initiation? Wouldn’t that be something you'd like to learn?
Well, this is the reason IBM is being so aggressive with building up its UX team. And this is exactly the reason why I'm so excited to show you how you too can implement these same UX tools and methodology on your own project in very close future.

UX - short introduction

Unless you're developing an internal component of a bigger system, that has absolutely no user interaction, the truth is, your team is already using UX tools, and they do so with various degrees of knowledge and confidence, producing various results.
This article will help you get the most of the time spent and steer clear of the common pitfalls. You'll understand the key UX activities, their goals, deliverables and what kind of outcomes you should be expecting to receive.
We will also look at the degree at which each of these activities are affecting your risk breakdown structure, and your schedule, their typical durations and typical manpower requirements.
Here're the top 7 key UX activities that we found to be the most relevant from Project Management point of view:
  1. Stakeholder Review. This is a series of one-on-one interviews with key stakeholders and project sponsors. Yes, this is something you normally do as part of Project Initiation, only this time you focus on user experience.
  2. Usability Review. A set of baseline usability tests of your sites or software. This is done if you're looking to improve an existing site, product or app.
  3. User Interviews and Observation. These are exactly what the name implies, when you interview your users to determine their needs and goals. These can be done in-person or remote, scheduled or onsite intercepts. Observation, not surprisingly, is when you observe users as they interact with sites or software in their normal daily environment.
  4. Persona Development. Personas are fictional characters or 'avatars' that represent key categories of users. Thinking from 'their point of view' helps us make better decisions and makes it easy to validate user needs, motivations and tasks.
  5. Task Analysis and User Journey Maps. Task Analysis helps uncover the scope and complexity of a given user's or group's needs for an application or site. Journey Maps then help condense this data into a compelling visual summary, making it easy to analyze.
  6. Prototyping and Wireframing. The meat and potatoes of UX process, where the findings from all previous steps a fleshed out in a life-like interactive application mock-up. If done right, this and the next activity, Usability Testing, is where the most benefits and risk reduction are taking place.
  7. Usability Testing. Another potent risk-reducing activity that helps catch problems early on, without having to spend a lot of time and resources.

These activities fit into four phases, that help you gain knowledge, plan, apply and quickly test your insights:




Stakeholder Review, Usability Review, User Interviews and Observation are there to extract maximum amount of insight from your stakeholders and your users to avoid unpleasant surprises down the road.
Persona Development, Task Analysis and User Journey Maps help mapping these requirements to user interface, that you could rapidly prototype with Wireframing Tools, producing a live interactive application prototype. The power of wireframes is that they are simple enough be produced in minutes instead of days or even hours - yet they are close enough to the real thing to be life-like and fully convey the features and the meaning to your end users. (See screenshot below)


Then finally, Usability Testing provides robust way of obtaining true user feedback based on the built prototypes. The kind of feedback that most organizations are only beginning to realize years after the app has been in production, the feedback that could've saved countless post-production failures and prevent most (if not all) user adoption issues.

Conclusion

So far we looked at the reasons why PMs should care about User Experience and reviewed major UX activities and their outcomes.
In the following articles I'll walk you through each of these, step by step, and show some practical steps that you can take right away, which tools to use and what pitfalls to avoid.

Monday, November 23, 2015

Can you take most of the risk out of software development and slash 50 to 95% of cost with this insanely simple technique?

If you're developing or modifying your intranet, your public site, an enterprise or mobile app or anything else with user interface attached to it, chances are, your team will go make this mistake too, and you will be paying the price.

Let's say, your business users want to add a loan calculator to your site.

So your BA goes ahead and asks developers to do this, right?

Most likely (to be honest), they will start with 'competitive analysis' and ask developers to copy the one that XYZ Co has on their site and just add a field for the trade in value.

Development comes back two days later and BA to check.

(See screenshot below)

 



They like how the results appear on the side panel, but the duration field is below the edge of the screen - so you see a Lamborghini payment on a Honda Civic - (because the widget has defaulted you to a one year term!)

Development makes the changes quick and is back for retest in another 2 days.

The calc looks better now and your BA just wants to fix the fonts here and there...

Another day of fixing and touch ups and it looks really good!

And then BA realizes that they haven't tested that on a mobile!

There goes another 3 days of development.

Let's say, internal developers cost you $100/hr, so you've just spent $6,400 to basically steal a ready to go widget, that was already done by competitors!

Now what if you BA has printed out your site' page - before adding the widget - and drawn up the calc on top of it? BEFORE talking to Development...

Hear me out.

What if they done that for your mobile page as well?

Printed the XYZ Co page with a calc that they like, cut the calc out with scissors and stick it on top of the printout of your page?

How long would that take? 5 min?

Probably less.

Yes, it's low tek and it doesn't seem like something a BA would do.

But if they did - in just 5 minutes they would've gotten themselves a prototype to see exactly how that calculator will look on a page - without spending a penny on development!

And, the most important thing is - these five minutes would've saved 8 days of Development time!

So why not waste some paper instead, when it makes a really good sense?


When ready, have them snap the thing with their phone camera (BYOD in action!) and THEN send it to development for coding!

2 days of work instead of 8 and 5K in savings... Not bad for a 5 min task.

I hope you're seeing the benefits.

Well, it doesn't have to be all napkins and scotch tape. We actually use tools like Axure and Balsamiq to create these mock-ups, but the main idea is the same.

In just a few minutes, often, with a client on the phone, I can create multiple versions of designs, forms and widgets, saving thousands of dollars and weeks of work, creating the insights that are impossible to come up with in the world where every change you make can takes days and cost thousands of dollars!

Are you using these quick and simple prototyping in your organization? If not, get in touch and I'll be happy to help you to get started.

Let me know what you think. Love to see your thoughts in the comments.