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