Database Reference
In-Depth Information
If you research these titles, you will find that there are many different names for these roles as well as
additional roles beyond what we have listed. You will need to define your own list depending on the type of
solution you are trying to create. Simple solutions do not demand as many roles as more complex ones.
Keep in mind that these represent roles rather than a specific number of people. One person may play many
roles. The solution manager may also be in charge of coordinating user acceptance and working with the solution
sponsor.
When Will We Need It?
Nobody likes to wait for things that they want, but it is an unpleasant fact that we usually have to. In our industry,
every year seems to bring more opportunities for instant gratification. If somebody doesn't answer an email by
the end of the day, we can feel slighted. It is hard to remember that only ten years ago people expected to wait for
letters to come by mail over a few days' time. Because you cannot change our culture, you will need to plan for
the inevitable desire for the project to be done sooner rather than later. Estimate how long the project will take,
track its progress, and disclose your adherence or delinquency to the given timeframe.
Key things that you need to define at the beginning of the project include how you are going to monitor
the progress and who will sign off on the solution's completion. In a fully staffed team, project managers will be
involved in tracking development progress, and you may even have a liaison to interact with customers to get a
sign-off document. On smaller projects, team members tend to shoulder many responsibilities that cross these
boundaries. When the boundaries of job responsibilities blur, it can be easy to forget which roles are assigned to
which team member. Establish these roles early, and make sure that the actions associated with these roles are
carried out within the timeframe allotted for the task.
How Will We Finish It?
The completion of a BI solution is just as important as its beginning. In the beginning, you should document
what you are trying to accomplish. At the end, you will need to document what has been accomplished. With this
document in hand, you will be able to validate that the end users also feel you have accomplished your goal. We
have found a 100% buy-in on projects to be an unrealistic target, but the 80/20 rule works pretty well. If you can
get everyone to agree that you have accomplished 80% of the most important aspects of the solution and that
the other 20% will be worked on in the next version of the solution, chances are that you will have happy clients.
Remember that if you set expectations at the beginning of the project correctly, the end of the project is much
more likely to be deemed successful.
Like most developers, including one of the authors of this topic, you may hate documenting what you
are doing. (Of course, this means that the other author enjoys this sort of thing.) Nevertheless, for the sake of
everyone involved, even if this task is disliked, it is quite necessary. Creating good documentation can help you
track what you did right and what you did wrong on a project. This information is vital for your long-term success
as a BI consultant. Think of it as an investment that will pay of over the course of many years, because that is
exactly what it is. The good news is that you will see dividends immediately when you begin your next solution
and are able to avoid many of the pitfalls that were uncovered in the previous solution.
Another task many developers are not wildly enthusiastic about is testing. Yet testing is fundamentally
important to your success. It can be very tempting to skip this portion of the BI solution. Resist this temptation!
Undoubtedly, you have found mistakes already in this topic. Can you imagine how many there would be if we
never had an editor review it?
Even with the best intentions, an author will make mistakes. Without a good editor, these mistakes will be
missed and passed on to you, the reader! This analogy mirrors the relationship between a developer and tester.
The developer creates the content and the tester reviews and approves it. The feedback given from the tester to
the developer makes a project better and more efficient, an investment that will pay off long-term.
