>More on the Business Advocate Position

>It is time to expand on the Business Advocate project role I proposed earlier.  To further explain what I’m thinking, I thought it best to go through a sample project.  And before I do that, I need to go through a bit about what I like for a development process.  While I like the concept of agile, I think the approach has some flaws for much business development.  And, we all know well the flaws that waterfall has.  So I use a hybrid approach though my approach is closer to agile than to waterfall.

The flaws I see in the agile approach is that the development team doesn’t understand the business to the extent required.  And the time required from the business participants on the project can be too high; especially when the business person already has a full time position.  And that’s the hole that I see the Business Advocate role filling.

So, let’s walk through a simple project.  Let’s say it’s a relatively small project to build a new web application for a single business group.  I would be the project manager.  My initial estimate shows two developers will be needed and one business advocate.

To start, I’d assign a single, senior developer to the project and the business advocate.  We’d meet with the business staff to get a good understanding of what they are looking for from the application.  The developer would then start designing a prototype of the UI and the business advocate would start working on use cases.  We’d have additional meetings with the business to fill whatever holes we had remaining from the first meeting.

And, both items would be available to the entire team.  That is, the business advocate should be able to see and review the prototype at any time.  And the developer should have the use cases available at all times.

As portions of the prototype are completed, we’d have some very thorough reviews of it internally.  These will help insure that the use cases and the prototype are in sync.  It will also help us identify questions and holes in our understanding of the business processes.

Once most of the questions are answered, we’d meet with the business and do a thorough review of the prototype.  When we have some key portions of the work flow solidified, I’d assign the second developer to the project and we would start building.

During construction, we’d continue to refine the prototype and the use cases.  We’d also push early builds out to a testing environment.  And this is where the business advocate role starts to break away from the traditional business analyst role.  As the early builds are made available for testing, the business advocate will start testing, looking for discrepancies from the use cases and big bugs (a big bug is one that prevents a portion of the application from being used like unable to save).  Worth noting, because I’ve had questions about this, this testing is focused on the application functionality and the application meeting the needs of the business.  This testing is not a replacement for nor does it cover the same things as unit testing and other types of developer testing; the developers are still responsible for that.

As more of the application completes, the business advocate role starts to move from mostly business analysis to mostly quality analysis.  But it never moves 100% to quality analysis.  If the testing effort is getting to be too big, I’d bring a tester on to the project, working under direction of the business advocate.

For larger projects, I’d have multiple business advocates on the project with one of them being designated as the “lead”.

The goal is to give us somebody on the project that understands and represents the business.  The developers tend to get stuck in the technology.  And this is a good thing; you need developers who understand the technologies and who live them.  But you also need to have a thorough and deep understanding of the business for a project to really be successful.

>Business Advocate – Minor Clarification

>After re-reading my post, I have one thing that I think is worth clarifying.

Even with the role of Business Advocate, the development team has the responsibility, or even the requirement, to talk to business staff.  The purpose of the Business Advocate is not to centralize communication to the business, it is to insure that the development team considers a business-centric view of requests during all phases of development.  In other words, make sure all bases are covered from a business perspective.

>"Business Advocates"

>One of the biggest issues facing any IT development team is how to make sure a project delivers.  And one of the biggest obstacles to delivering is making sure you understand what the business group needs.  Not what they asked for, not what they want, but what they need.

I believe there are two main problems that lead to the development team “missing the boat” on the project.  First, most people have trouble articulating what they need.  Instead, we talk about what we want.  And getting what we want just makes us discover two things.  We discover other things we want and we start to discover what we really needed.  In other words, getting something that we wanted but didn’t need isn’t really viewed as a problem; it’s just part of the path of getting there.

Second, we, as techies, sometimes start to believe we fully understand the business and the problem even though our understanding is superficial at best.  After all, how can a “simple” business process be as complex as building an application.   We can’t see that many business processes are complex in many different ways.  And when we start sounding like we understand things, the business staff likes this because it means less time spent explaining basic things to us and more time spent doing their job.

For me personally, one of the first things I had to learn was not to start designing a solution in my head after I’d heard 10 minutes (or less) of the problem.  I found, through some painful projects, that I needed a much more thorough understanding otherwise it was easy to make some major and fundamental mistakes in the project.  And that many times, the business staff didn’t know what I needed to learn because they would  assume I understood the business much better than I really did.

As I’ve moved along in my career, I’ve experienced these two problems many times.  Based upon what I know, I do many things differently now than in years past but I find these problems still happen.  Especially since it’s a fight against nature.  As developers, we want to concentrate on designing and building quality solutions; we don’t want to concentrate on learning how to do somebodies (non-IT) job so that we can help automate something.

And that’s where I came up with the idea for a Business Advocate.  This is a person with the skill set required for a Business Analyst and a Quality Analyst.  But the most important piece is that this person needs to be business centric, not technology centric.

The Business Advocates responsibilities are:

1. Represent the business within the project.  Stand-up and make sure that what is best for the business and the impact on the business is considered with every decision.
2. Become intimately familiar with the business process(es) being automated.  Gain a thorough understanding of who does what when. Gain an understanding of how critical the data is used.
3. Identify how things pass between people and, more importantly, between groups.  
4. Help the project manager set the project scope and the relative priorities of the project requirements.
5. Help work changes from the business perspective. 
6. Test the delivered system(s) and/or system changes focusing on the flow of the systems within the various business areas.

This role might sound a lot like the Business Analyst role.  But I believe it is a bit different.  First, the job is not to document the business process; the job is to understand the business process and to communicate that understanding to the rest of the project team.  Second, the role is on the project from start to finish and the Business Advocate should be in charge of system testing from a business perspective (the step before UAT). Third, and most important, the Business Advocate should be viewed as the project owner.  This person must be able to identify impacts on the business so that they can be addressed as early in the project as possible.

The real goal here it to make sure that the project team is spending 80% of it’s time working on the functionality that will be used 80% of the time.

In future posts, I’ll go into more detail on some aspects of this role.