>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:
- 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.
- 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.
- Identify how things pass between people and, more importantly, between groups.
- Help the project manager set the project scope and the relative priorities of the project requirements.
- Help work changes from the business perspective.
- 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.