Awesome Discovery Sessions – It’s Not Magic

Trond FrantzenTrond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

I’ve been studying and teaching Business System Analysis for many years. I’ve delivered courses and seminars to over 35,000 professionals. I hope others have enjoyed them as much as I have.

At the end of the day, the only way you can “do” Business System Analysis is to actually get together with clients, users, subject-matter experts and ask them what it is they need for their system. Sounds straight-forward. But we all know it isn’t. If it was, everyone would be doing it, without it being a big deal, and our business system requirements would be a breeze. But it just ain’t so.

In my courses and seminars I spend a lot of time addressing how to go about doing the business requirements analysis. I demonstrate. We discuss. We deal with the theories and practices. We do more demonstration.

But the reality is, a classroom course or a seminar is not the real world. And we can never spend enough time on the foundations and principles … the “how do I do this” … of sitting down with clients, users and subject-matter experts.

Discovery_Sessions_cover_(Kindle)My best-selling book, “How to Run Awesome Discovery Sessions” is about the “how do I do this” of sitting down with clients, users and subject-matter experts, to figure out what they really want and need for their system.

If you haven’t read this book yet … It will put into context the nature of your questions, the environment you need, how long it takes, who should be involved, and the tools you need.

You’ll also learn how to do it quickly, without missing a thing.

You’ll really find out what “real agile” means – with the results, the specifications, the documentation; but without the chaos.

Join the others who made this my best-selling book. It’s available on Kindle, so it’s an easy digital read.

Trond FrantzenTrond Frantzen is Managing Partner & Chief Business Analyst with the PowerStart Group. He specializes in rapid business requirements analysis, team development, and “bail-in” on challenged projects. His best-selling book, “How to Run Awesome Discovery Sessions” should be standard reading for all business system analysts.

Tagged with: , , , , , , ,

The First Principle of Business Analysis

Trond FrantzenTrond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

PowerStart Precision ConsultingSeveral years ago, Gerald M. (Jerry) Weinberg coined what he called The Lump Law, which stated: “In order to understand anything, we shouldn’t try to understand everything all at once.” In other words, if we want to understand anything at all, we should learn about it in tiny, understandable chunks, and synthesize it chunk by chunk. It’s frustrating and self-defeating to try to understand everything all at once – to try to get the big picture right away – especially if the subject is complex or new. It only leads to information overload.

This same principle applies to all aspects of business analysis. That is, if we try to understand everything about the target business all at once (i.e., linking all the stuff that’s to be integrated in a business), we’ll suffer from serious brain sprain. And we certainly won’t get the full set of business requirements right the first time, because it will simply be too complex. This is usually what happens when we try to figure out the solution first and then try to extract the business requirements to fit that solution.

Accordingly, I have restructured Weinberg’s Lump Law into The First Principle of Analysis, because it is so fundamental to any type of business analysis:

“Partition the effort to minimize complexity.”

Here’s another way of thinking about this:

Break down the work required to produce the requirements of the business into small, non-redundant, manageable and understandable pieces.

When doing business analysis of any kind, you will need to apply this principle often. Partition the effort to minimize complexity.

Trond Frantzen photoTrond Frantzen is Managing Partner & Chief Business Analyst with the PowerStart Group. He specializes in rapid business requirements analysis, team development, and “bail-in” on challenged projects.. His best-selling book, “Requirements Analysis for Non-Technical Business Analysts: Business Requirements Elicitation” can be found on Amazon.

Tagged with: , , , , , ,

Customer Failure 101 – Or, How to Kill Your Business without Even Knowing It

Trond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

A fine lunch indeedA few days ago I made reservations for four of us to have a working lunch. It was a nice restaurant in a beautiful brand new building. I had been there before with Linda, and had liked it quite a bit.

When I arrived, I was seated immediately and a server (who was there faster than you could say “nice day”) immediately had a menu, asked if I would like a drink to start (all the while knowing there would be 3 others arriving) and, when I said “no, thank you” she asked the obligatory up-sell question of whether I’d like some “still water”. Since I had been there before (and enjoyed it) I knew where this would go. If you say “yes”, a lovely large bottle of water imported from Italy arrives, and an additional unannounced $5 shows up on your bill. Since I knew this, I declined this fine offer.

I fully expected to enjoy a wonderful, tasty lunch with my colleagues once they arrived. My anticipation heightened as I patiently waited.

A server came to my table and asked if there was anything she could get for me. I said, “no thanks, my colleagues should be here any minute”. I then told her that we would like to have separate bills.

She looked at me awkwardly, apparently not certain what to say, then finally announced, “We can’t do that. It makes our computer crash.”

For a moment I didn’t quite know what to think or say. Mmm … “We can’t do that. It makes our computer crash.” Finally, I said, “I think you’ve misunderstood your billing capabilities. Certainly you can do that.” She insisted it was impossible, and said she would find the manager.

A manager arrived promptly. She reiterated that multiple bills would be impossible. Once again, she told the tale of “it will crash our computers”. She insisted they’ve had their tech support team look at it many times, and a new system would cost $20,000 so it wasn’t in the works. I felt she was making their problem (which I really didn’t believe) into my problem. As a customer, I really didn’t want their problem, whatever it was.

This isn’t 1966. It’s 2016. We put humans on the moon decades ago. We put rovers on Mars. We’ve had a successful human genome project. There are 1.5 million apps available for smartphones. We’ve invented 3D printers; including those that have been used on the International Space Station to “print out” new tools emailed from Earth. And the “crash our computers” thing is simply nonsense. Do they really think most people today know so little about systems that they would buy that story? Really?

Obviously, this is just an old-school, antiquated system, or they bought one with functionality that was based on faulty requirements analysis. So, let’s look at this logically.

Many old-school POS systems are based on a “Table”, regardless of how many people sit at it. Most newer systems understand that you could have several (separate) orders at a table. They isolate bills by food/drink order, and attach that to a location (i.e., a “table”). Most pubs do this. That pretty well solves everything.

When you look around a restaurant, they have no trouble with separate bills for small or single parties. But that’s only true, for those technology laggards, for individual “Tables”. The problem here is how the payment question has been addressed (I’ll get to that in a moment); and the unusual finger-pointing exercise that goes on when something is missed while testing a system. In this case, I have to put the blame on the analysts and designers of the system. They dramatically failed in two areas.

The question, at business requirements analysis time, has to be: “For a single, specific TABLE [this is an Object], how many PAYMENTs might we receive?” This question is followed by “Might we receive no PAYMENT; a single PAYMENT; or many PAYMENTs?”  Each part of this question must be answered by the client in response to the business analyst. Each answer creates a scenario (“Under what circumstances would this be true?” is the follow-on question after each answer.) Any client who stipulates that only one payment is acceptable (such as the restaurant I visited), has signed off on their own business failure.

For the POS software this restaurant purchased, that question was certainly not asked properly; therefore, it limits the restaurant and probably costs them customers.

The other side of this coin arose when the POS software was first tested. The multiple-payments scenarios wasn’t found, so that tells me the functionality found during business requirements analysis was faulty at best. When the flaw is discovered (possible after several tech support visits), this can only lead to a client-IT faceoff where the software design team says, “You didn’t tell me you needed that …” and the client says, “You didn’t ask me.”

In other words, this restaurant got some crappy old-school software (which miraculously might still be selling well) that was based on the debilitating old concept of TABLEs rather than ORDERs with LOCATIONs.

Will I go back there? When I’m dealing with just one bill, I certainly will. The food is good. The restaurant is nice. But, for those business meetings when we need separate bills … absolutely not.

Tagged with: , , , , , , , ,

The Professional’s Success Code

Project Success word cloudTrond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

Every professional, no matter what their industry, must have a foundation that guides all business development and project work. That foundation is based on 9 tested principles.

Be on budget, on time, no problems.  

The team leader or manager must be committed to ensuring that the project is problem-free, on budget, and all deadlines are met. Since what is done up front – the planning we do based on the business requirements – determines all subsequent results, our clear understanding of the business objectives helps make this goal possible.

Foster teamwork and client participation. 

The best relationship you can have with your clients (internal and external) is one of partnership, teamwork and active participation. The best results come when you work directly and visibly with your clients. Never work in isolation from them. Transparency and visibility helps make this partnership possible.

Apply hands-on modern management methods.

Encourage on-project coaching and mentoring.

Get management commitment to the project.

Management commitment and sponsorship is also critically necessary to a project’s success, as is a well-defined and developed professional development program for team members.

Every project should be guided directly by a practicing expert in the tools, techniques and methodologies to be used on the project. It’s a lot easier to advance when everyone is on board and understands how the work is actually done, rather than relying on theory passed on from an absentee practitioner or methodologist. Or after a 2-day “let’s all become experts” seminar.

Be highly visible. Transparency is king.  

An informed and involved client will usually make the best decisions. High visibility – contrary to popular myth – eliminates fear, uncertainty and doubt by the business community. Visibility and transparency in the work always results in interaction and ownership. Don’t hide from sight or work in isolation from the client. Have pride in your work. Success is the only option. Dedicated support and ownership comes from visibility and the client’s ability to contribute.

Use best practices.

Always use the best and most modern methods. This always brings faster results, less money being spent, and the highest quality. “Best practices” are not always best, and they may be decades old, without modern revisions. Always look for better ways. Avoid the Not Invented Here (NIH) syndrome. Look outside your organization. Be devoted to finding the best methods available. And then measure satisfaction by your client community.

Apply the best methodologies.  

Use the most effective and pragmatic methodologies that you can find. Don’t use them because they are popular, or the solution du jour; use them because they have an excellent track-record according to your clients and subject-matter experts. Then, adapt as required to your organization, your industry, and your personal style of working. This will help you get the best results.

Use common sense – and a coach and mentor. 

A popular old saying is, “common sense just isn’t very common.” But I think it is. The first step is to get yourself a personal coach and mentor, and ask for some guidance whenever it’s needed. Take a practical, common-sense approach to all projects. Every situation is unique and each has different needs. Never get bogged down in yesteryear’s conventional approach. It probably wasn’t that good.

Tagged with: , , , , , ,