Mommy, where do requirements come from?

January 19, 2010

Getting True Requirements has gotten more difficult than it once was. Noted author Spencer Johnson wrote a book called “Who Moved my Cheese?”.  It was about a couple of mice who kept looking for cheese where they’d always found it, even after the cheese had been moved”.

Well, guess what, someone has moved your requirements, so that they now come from a different place.  Didn’t you get the memo?  Or are you still looking in the same places?

The true source of requirements has changed.  Yet, we continue to gather, solicit, elicit and survey requirements as if the source remains the same.  The end result is that they are harder to find, their quality is deteriorating and they are getting both more complex and more expensive.  Analysts are stressed, subject matter experts (SME) are frustrated and projects fail to deliver the results needed.

How did this come to be?  From the early days of computers until about 1990, the opportunities were mainly functional.  In those days you would walk into a department (single functional unit) and easily find hundreds of people performing identical clerical jobs.  So the opportunity was to replace expensive clerical people with computer applications that performed their relatively simple and repetitive jobs.  When I was an analyst we would go into a department and we would work with a number of users to define those clerical jobs in enough detail that they could then be automated.

What we were automating was basically one job after another, each job being relatively well defined.  In the majority of cases we didn’t have much cross functional issues to deal with.  Programmers, analysts and project managers received skills type training and we all pretty much did things our own way.  No one cared because the opportunities were large.  Few projects failed to deliver financially.  It was quite common to implement a particular application system and see headcount drop by 50 or 100 people.  The ineffeciency of different methods and approaches mattered little because the returns were quick and large.  I vividly remember working for a large bank having just implemented a new computer system.  The president of the company visited the department the day we launched.  He walked up to the department head and asked “Was it worth it?”  to which the department head replied “by end of day we will have paid back the entire cost of the project”.  It’s tough to get that kind of result today.

Of course as more and more functions were automated, the big opportunities began to diminish and disappear.  So suddenly, there was pressure to reduce costs.  And so, standardization began as a response to cost pressures.  Organizations began to focus on standardizing and improving their processes.  And who did the standardization?  People like myself who had  experience on many projects.  The problem was that we all pretty much took the same approach.  We based our standards on practices that had proved successful on our past projects.  This led to the concept of best practice.  So what’s wrong with that, you might ask?

The problem is that methodologies, approaches and skills were defined based on solving a set of problems which had largely disappeared.  Few organizations are automating or improving strictly functional processes.  They have turned their attention to bigger, larger, more complex, cross-functional processes.  Functional processes were equivalent to jobs. And jobs had experts.   So if you spoke to the job experts (subject matter experts) they had a very good understanding of that job.  Therefore, we could elicit requirements from them, because they were a good source for those requirements.  The subject matter expert as the primary source for requirements, is at the center of virtually all current approaches.

However, subject matter experts rarely have a deep understanding of the cross-functional process in which they participate.  Although the job may have been designed, the cross-functional process evolved much like a cow path evolves.  It is simply the result of many job decisions.  And so, in fact, few people, sometimes no one, has an understanding of how the cross-functional process works.  In other words, there is rarely a cross-functional process expert.  In today’s world it is those cross-functional process requirements that we need.  But there is no subject matter expert for that process.  The requirements have moved to a place where there is no expert. 

And so we continure to try to collect requirements from subject matter experts who don’t know what they are.  The results are poor and frustrating to everyone involved.  We still use strategies, approaches and methodologies which are based on the subject matter expert being the authorotative source.  They no longer are.  Therefore, trying to elicit from them something they don’t have is like trying to get blood from a stone.  It’s a lot of hard work, that yields very little.

So what should we do?  As with any change two things need to happen:

1. Acknowledge that things have changed, that the opportunity areas have moved from functional to cross-functional.
2. Redesign our approach based on the new location of the opportunities and revise the roles based on the new source.

Well I’ve run out of space for this week.  Next week I’ll explore some key changes that need to be made if we are to again achieve True Requirements.

Angelo Baratta

(905-270-7591)

www.PerformanceInnovation.com

Why is change so difficult?

 

January 12, 2010

When I was younger, I used to think of myself as a pretty smart guy, smarter than most.  But then I kept meeting people smarter than I am, so many, in fact, that I changed the way I view the world.  For example, when I come across a problem which has yet to be solved with satisfaction, but has been attempted by others, I don’t try to solve it head on.  My reasoning is that at least some, if not all, of the people who have tried to solve it are smarter than I am.  So if they haven’t answered the question, then there’s not much chance that I’ll be able to answer it.  I reason that the problem isn’t with the solvers, but rather with the question.

Today, I came across the question “Why is change so difficult?” and because last week’s blog was on Change Management (see below), I decided I wanted to take a shot at this question.  But of course I can’t answer the question directly because I’m not as smart as all those people who have tried to answer it before.  I also assume that because the question is still being asked, the answers are not quite satisfactory.

So I looked at the question and opened it up.  Every question has a series of assumptions hidden inside it, so to open up a question is to make the assumptions explicit.  The first thing that struck me was an unstated implication that it would be preferable that change were easy.  Otherwise, why ask the question?  So I played a little mind game called pretend.  I often do this.

Pretend that it is the beginning of time and that I am the original creator.  There I am designing the universe along with my dream team of designers and advisors.  I’ve pretty much got everything laid out: the solar systems, planets, etc.  I’m reviewing my blueprints when one of my advisors walks up to me and says:

 “You know, creator, you’re going to have to establish some policies for your universe, some rules.”

“What do you mean?” I ask.

“Well,”  she says, “for example, there are some behaviours that are contradictory.  What you need to do in those cases is choose which behaviour will be dominant.”

“Can you give me an example?” I ask.

“Sure,” she says.  “Let’s take change and stability.  You can decide that things will tend to remain the same or that they will tend to change.”

“What difference will it make?” I ask.

“If you decide to make things tend to change, then change will be easy.  However, that means that when you want things to stay the same, you will need to apply extra energy to prevent them from changing.  On the other hand, you can make things tend to remain the same and then extra energy will be needed to overcome that tendency and get change.”

I thought about that and I pondered the choice.  I looked at my design.  If the tendency were for things to change, then my universe would quickly go its own unpredictable way.  If I needed things to be stable, then my universe would require a lot of energy to stay the same and overcome the dominant tendency to change.  I reasoned that most of the time I wanted things to be stable.

The creator, having recently attended a conference on energy and sustainable choices, made the sustainable, energy-efficient choice, deciding to make stability the dominant behaviour.  Then it would not require energy to stay the same, thus allowing stability to be energy free.   That meant that change would become the recessive choice.  Change would require energy.  Since change is infrequent compared to stability, this choice would allow the world to operate on much less energy than the alternative.

So, the policy was set.  Stability would be dominant.  You wouldn’t need to apply energy to keep something going the same.  You could set things on their course and turn your attention elsewhere, without worrying about it.  You see, the creator didn’t decide to make change difficult.  Rather, the decision was to make stability easy and energy efficient.  It was simply the responsible thing to do. It’s the better design choice.

What does this mean for us?  We should thank the creator that change is the thing that is difficult.  If it were the other way around, the world would be in constant chaos and we’d be asking a different question. So stop asking “Why is change so difficult?”  Accept that it is part of the creator’s design and begin asking “Does this change lead to progress and for whom?” 

Change is difficult, because the alternative is worse.

If change were easy, your change would be impossible.

If change were easy, constant change, chaos, would be the result.

Thank the creator that change is difficult, and stability not so much.

Stop trying to make change easy.  Instead, make change count.

Angelo Baratta

Universal Laws of Change Management

Tuesday January 5, 2010.

Happy New Year and new decade to one and all.

Do you think it’s time to turn the page?

The last few decades seem to have stressed Change Management.  Personally I believe that we’ve definitely reached the limits of current Change Management theory.

Firstly, is change management really about change?  Or is it about getting other people to conform to something that someone else has already decided?  Are people the only targets of change?

I’d like to propose my Four Laws of Change:

1. Change without progress is waste.

2. Progress without change is an illusion.

3. Change is always rewarding to someone, but not necessarily everyone involved.

4. Change requires emotional energy.  And who is most likely to have that emotional energy?  The one to whom the change is rewarding.  So rewards and energy are related.

Consider these laws and their implications.  I think it’s time we turned our attention from change to progress. 

Although few changes are actually progressive, all progress requires change.

Angelo Baratta

Advancing the modern organization through better thinking.

A simple question to start:

Suppose you are the Director of the Business Analysis group.  You have a choice.  For the same investment you can:

• a) reduce your costs of producing a set of requirements by 30%, or
• b) reduce the volume of the produced requirements by 10%,  but at the same cost.

Which option would you choose?  Hint: Some things are as simple as they look. 

 

Requirements consume about 15% of the development effort.  However, the development is at most 40% of the lifecycle costs of the system.  So Requirements consumes at most 15% of 40% which is about 6%.  Reducing the cost of the Requirements by 30% of that 6% would give us an overall saving over the lifecycle of the system of about 1.8%, an amount which is probably not even noticeable in the greater scheme of things.

On the other hand, if we can reduce the total requirements by 30%, then that means that we would be reducing the size of the system solution by 30%.  That means we would also reduce the lifecycle costs of the system, since there is less to support.  So reducing total requirements by 30% would reduce the 94% of costs that comes after the Requirements.  This amounts to a reduction of 28% of the lifecycle costs.

Conclusion: Requirements is like the tip of the iceberg.  It is much better to reduce the amount of requirements than the cost of producing them.  Anyone who is focussed on requirements costs instead of requirements volume, is going to be highly disappointed by the results.  In fact, if you become more efficient at producing requirements, it might actually work against you.  Why?  With the ability to produce more requirements for the same cost, you might be tempted to undertake more initiatives.  But remember, that the more initiatives you take on, the more development and support you will have to undertake.  That can lead to higher lifecyle costs, rather than lower costs.

Comments? Let me know.