Deriving Scope from Goals

From the Slashing Risks with UX Engineering Blog
Data-driven UX tools and processes have brought wild success to Apple, Google and other top players, and it has been increasingly popular ever since. But it's not just the design part of UX that makes it so effective! Stop by my blog to learn about these not-so-glamorous but extremely effective and proven UX tools and processes. They will help you gain accurate user insights and discover "missing" requirements and hidden underlying problems--the ones that business users would really like to see resolved first, even when they have not been clearly articulated.

About this Blog


Recent Posts

Why is the industry taking so long to catch on?

Deriving Scope from Goals

Is it BAD to be an Order Taker?

Developers and UX?

Design Thinking Doesn't Work

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. 

Posted on: March 31, 2016 01:33 PM | Permalink

Comments (2)

Please login or join to subscribe to this item
Thanks for sharing

It is a sad fact that we often build products that our client wanted but do not need.

Please Login/Register to leave a comment.


"Nothing travels faster than the speed of light with the possible exception of bad news, which follows its own laws."

- Douglas Adams