September 2008 - A Project to remember
By harvey.saks on Sep 25, 2008
Last month I promised I would write about a project where everything went wrong and still managed to be considered a success. The customer was a major bank that had gone through 5 mergers in 6 years. They were looking for a way to consolidate their business and bring together data segmented across many different banking applications. On this project the implementation team did too many customizations, wrote too much code, came in over budget, and delivered the project late. Despite all of these problems our customer had the solution they needed and saw the project as a success.
The bank wanted to start two Oracle Siebel CRM proof of concept prototypes. These prototypes needed to be completed in a short period of time. If the two prototypes were successful then the bank was going to commit to a full implementation of a Siebel CRM solution in all of the banking branches. The two prototype projects ran independently of each other, one to automate the call center and the other a sales application for field sales agents. While the prototypes were running we began planning the needs of the big branch project that we hoped would be approved.
I came onto the project as the larger of the two, the Call Center prototype was already beginning configuration. Developers were already on the project beginning the customizing process before any design was completed. Our CTI specialist was busy integrating to the banks communication infrastructure. The project manager of the Call Center proof of concept was told to give the customer what they wanted and he tried to do just that. This meant that while we were in configuration, we were still getting new requirements for our go live date.
There are few diseases that can derail a project like Scope Creep. I define Scope Creep as a project disease where new requirements continue to flood the development team with changing specifications. I liken this problem to that of a professional dart player stepping up to the line. Eyeing up their shot, they take a breath, and throw the dart. The moment the dart leaves their fingers to go sailing through the air, somebody races over and moves the dartboard. There is no way the dart will ever land where they planned it to go. There is no possibility to run a project this way and expect it to be on time and within the budget constraints.
Changing requirements increase both development costs and implementation time. To compound the problem, the project was due to complete a month after the first Siebel CRM Financial vertical application was being released. Many of our modifications were features that were not in the current release but would be in the next release of the product. The customer could not wait for the new release before beginning the project.
The Call Center team was understaffed with many people coming fresh out of training. Needless to say morale for the project was low. The saving grace for the project was a pipeline to Senior Management via a dedicated high level business analyst who was consulting and appointed to the project by the management team.
On the second proof of concept the Field Sales application, I discovered that only 1 of the 3 people on the project had gone through any training. Thankfully the requirements were simple though difficult to define as reorganization put a new Vice President in charge of the sales offices. While the team members were new to Siebel they had a good foundation in sales related applications.
In preparation for the potential Banking Branch Office project I met weekly with the companies Database Administrator to review their Corporate Customer data model and map it to the current Siebel data model. At the end of this effort we delivered a dictionary mapping the banks terminology to the Siebel terminology, and identified changes needed to the out of the box Siebel database structure. Of course this effort ran parallel to the two prototypes, which were unable to use the deliverables produced.
The objectives set for the project teams were unrealistic with heavy pressure from management to show results. We had several challenges to overcome the first being a lack of knowledge on the part of the project team. This was our most critical issue and needed serious consideration. We had to get creative as we were not getting additional recourses in the needed time frame.
In order to solve the problem of experience we took advantage of Siebel’s Expert Services team. While Expert Services was typically used to support projects through reviews at key stages in the project lifecycle, we retained their services on a weekly basis to fill in the holes in the team’s knowledge. Each Tuesday, I would collect from the team the most important technical issues that they faced. Arranging this content and prioritizing the most important topics, we sent our questions to Expert Services. On Thursday of each week we scheduled a phone call with an Expert Services Consultant who could discuss the topic in depth. The consultant submitting questions would then attend the Thursday conference call and get the direction they needed. This turned out to be highly effective solution, keeping us on track and moving forward.
At that point I was now the central point of contact for technical issues. Frequently I would get questions on how something worked or why something did not work. I never felt smarter or more knowledgeable then the other team’s members, but I did have a knack for finding answers to their questions. What I discovered was that spending 15 to 30 minutes looking through the Siebel electronic documentation (Siebel Bookshelf) or the online Support system now called Metalink3, I was able to resolve over 75 percent of the teams questions. I guess they thought it was easier to give the question to me rather than doing their own research...
I thought it a bit funny as I looked for answers to questions I barely understood. What I learned were keywords that could help refine my searches to return a manageable number of hits to review. It was rewarding for me seeing the smiles or my coworker’s faces as I provided potential solutions to problems they were struggling with. It also helped improve morale of the team as the little help I provided in finding solutions combined with the enormous support we received from Expert Services provided them a safety net and a place to turn rather than letting the stress continue to grow.
To this day I believe that implementing a buddy system or mentoring program for new developers can significantly improve their productivity and moral.
My role on the project as Technical Account Manager marked me as the one point of contact for all the projects needs for support and guidance, but I was not free from doing some serious work as well. My first week on the project the project manager asked me to document the current implementation. My mouth dropped when I heard this, first, what should I document, second, writing documentation was not what I was brought there to do nor was it a pleasing task to sit in front of a word processor for a week.
I am a basically lazy person and would have to discipline myself to do something as tedious as documenting an application, especially when I knew that the documentation was a deliverable that would probably sit in a drawer and never again looked at.
I realized that the documentation would have to cover the three layers of objects that made up the Siebel Repository. This included objects in the Data Layer that covered the structure of tables and columns used by the application to store information. It also included objects in the Business Layer that transformed the discrete tables and columns into Business Entities (Siebel Business Components) and defined their relationships to each other. The documentation would also need to identify the objects in the User Interface that determined how the business data would be presented to users.
The Siebel application is different from many older style products where customizations are made to program code. The Siebel Application is an object-processing engine. The objects work much like a child’s building block set where pieces snap together to form more complex structures.
Since these objects reside in human readable form as records in the database it meant that I could mine that information to produce my documentation. These objects when modified by developers are compiled to form the Siebel Repository File, which is used by the Application Object processing engine to produce the application functionality. Since these object define application functionality, they represented the documentation needed by our customer.
I believe that I learned more about the Siebel application architecture that week than any other week in the last 10 years.
As there was no tool to document the application as the customer wanted it and the structure of the data in the database was not oriented to produce the needed documentation, I needed to transform the repository data into a more manageable structure. To this day I do not know why others have not made use of this technique, as I simply built a data mart based on the Oracle Siebel repository data.
I started by developing a query that filtered the repository User Interface objects to identify the applications that we were implementing. I then identified all of the screens in the application. Screens are a way that the application User Interface groups major areas of business functionality to facilitate easy navigation. Once I knew all the screens available in the application, I identified those screens we would be implementing in our prototype.
Now knowing the Screens we needed, I returned to my query writing expertise and mined all the Siebel Views associated to the selected Screens. Again I proceeded to identify which Views we would implement. In the product a View represents a User Interface function the user would perform, such as adding new people as contacts or companies as accounts or relating the activities performed as part of the sales process to the Account or Contact.
Once I had identified all of the Views we would implement, I really got busy. I continued my data mining by identifying how our Business Entities (Business Components) were presented in data windows called Applets. The Applets determined how the data supplied by the Business Components would be presented to the user.
The smile on my face soon disappeared as I finished this process and discovered that there were some Business Component data Fields that did not map to any columns in the data layer Tables and Columns. I was confused, how could this be, I was down but not beaten. I looked deeper at the problem and saw a break between the Business Layer and Data Layer for special Calculated Fields. In the property that defined the calculation I found the details needed to map them to data layer tables and columns.
Yet this still left me with holes. My final challenge came when I discovered that none of my Multi Value Fields were showing mappings to the data layer. Multi Value Fields enable a Business Component to have data with multiple values. What I noticed is that Multi Value Fields actually embed a child Business Component with a one to many or many to many relationship inside the Parent Business Component. By looking sideways from the parent to the child mapping of Business Component Fields to table columns, I was able to build my data mart representing the objects in the three layer object architecture that would be used in our implementation.
The rest was easy, developing a report off the Data Mart I was able to press a few buttons, run 20 minutes of queries, and print 80 pages of customer documentation. In the same time it would have taken me to type in all the documentation, I managed to automate the process with the net benefit that I could reproduce updated documentation in less than 20 minutes.
At the end of the project when the customer saw the number of hours worked by the project team, they asked the natural question, where did the time go. This time it was the Engagement Manager that the Project Manager reported to who asked if I could help. I sat down with my queries and added a filter to identify which objects had been modified since the project team started. As all Siebel Data and Repository records stored in the database capture the date of last update, I was able to locate all the changes made by the project team providing the Engagement Manager with the information needed to satisfy the customer’s questions.
Since working on this little tool, I have had the knowledge of how repository data is organized in the database and have used this information to help with automating tedious tasks like building the Responsibilities used to determine what users have access to views in the application. I have also used this to help identify configuration requirements like identifying all applets that need modification in response to changes in Business Component Field configuration.
I have not yet gone all the way with my idea, but I am currently working on a tool that would make it easier for Business Analysts to mine application configuration knowledge. I believe that if the Business Analyst could tie a user requirement to the views in the Siebel Application then analyzing gaps between what the users wants would be an easier process.
I have stayed away from getting too technical in this article as I thought it might put my readers to sleep. If you are interested in a deeper discussion of the details of these queries then add a comment to my blog and I will respond in future articles with more of the details.
The project turned out to be a success though much of the work done on the 2 prototypes would be discarded and replaced by many of the features and functions of the next release of the product. It turned out that the developers generated over 9,000 lines of custom Visual Basic script, many of which would be discarded as new configuration features like Applet Toggles and Dynamic Drilldowns reduced the dependency on scripting to accomplish the same functions. Using the prototype deliverable and the Data Modeling activities with the customers Database Administrator, we were able to bring in an Expert on the new Vertical Product and implement many of the customization in a fraction of the time.
While the project cost a bit more than expected and took a bit more time, we maintained our partnership with the customer and user department delivering them what they needed in a time frame that was acceptable.
Next month I will talk about an approach to using repository data in the Requirements Gathering and Design stages of an Oracle Siebel CRM implementation.