I have worked in a relatively small corporate Information Technology department for about four years. During that time I have seen many applications installed, both successfully and unsuccessfully. There are some key factors that seem to play into whether an application install and launch are successful. I will detail each of these factors further in the paper, but I believe that strong management support, user support, a reliable set of plans and at least a basic adherence to an SDLC plan is necessary for a good application launch.


    I am going to write about an unsuccessful launch that took months to complete and integrate correctly. The installation was for ACT! 2009/2011. Our company has had a bad habit of not keeping a centralized database for our sales crew. Several versions of ACT! were implemented on individual machines starting with the version just prior to ACT! 2000. This was a great solution for an individual salesperson because he or she could keep all of their contacts in a centralized location that was easy to access. In March of 2008, our company implemented a full Windows 2007 Active Directory and Microsoft Exchange 2007 environment. It was a wonderful upgrade that increased stability dramatically for our aging Windows NT 4.0 and Exchange 5.5. However, the update to Exchange 2007 was not well tolerated by ACT! 2000. The program collects its contact information from both its own flat file database and from a live connection to an Exchange or Domino server. As part of its increased security initiatives Exchange 2007 only allows what it considers unsafe programs to establish a connection to it in user established connections of not more than 3 minutes. It will warn the user every 3 minutes that they are performing a task that Microsoft does not recommend.  The warning required a click intervention by the user to establish the next 3-minute connection. This was a rather infuriating complication for ACT! 2000 users. The decision was made to stop using ACT! and instead implement Blackberry units which could also store sales contacts. The VP of sales was not quite content with the Outlook contact setup or the Blackberry contacts. We tried several low-end programs that were competitors to ACT! but they all had the same problem of needing authorization from Exchange to access the mail store. The CEO at the time was not willing to spend any money to improve our contact services on an enterprise basis so I was relegated to looking at low cost solutions.


     In January of 2010 the board of directors fired the CEO and one of the first mandates of the new CEO was to improve the tools available to the sales crew. All of my co-workers had had bad experience with ACT! at previous companies and had heard horror stories about the software installation for the newest versions of ACT! that promised support for Exchange 2007. I was given the task of implementing ACT! 2009 enterprise-wide and with only the help of a marketing assistant. The intended purpose was not only to track contacts, act as the primary e-mail client, and have Blackberry support but also to track pipeline data. The budget was meager; I was given enough money to purchase the software ($16,000) not enough to hire the recommended consultants for $1600.00 for two days that would help install the program and get it operational. The marketing assistant had used act at his previous job, but had no IT or form creation experience. We had to roll out the software to 55 users that were spread throughout the United States and utilize a central database. I had no SQL or database skills either leading into the exercise. I think this led to what turned out to be a more costly venture than if the consulting fee had been paid which if appropriate planning had been done by the steering committee would have been caught. According to the Software Program Managers Network: (SPMN)

Estimate Cost and Schedule Empirically

Practice Essentials

  1. Initial software estimates and schedules should be looked on as high risk due to the lack of definitive information available at the time they are defined.
    2. The estimates and schedules should be refined as more information becomes available.
    3. At every major program review, costs-to-complete and rescheduling should be presented to identify deviations from the original cost and schedule baselines and to anticipate the likelihood of cost and schedule risks occurring.
    4. All estimates should be validated using a cost model, a sanity check should be conducted comparing projected resource requirements, and schedule commitments should be made.
    5. Every task within a work breakdown structure (WBS) level need to have an associated cost estimate and schedule. These tasks should be tracked using earned value.
    6. All costs estimates and schedules need to be approved prior to the start of any work.


    I think that if this level of planning and staging would have been allowed to be performed a better handling of resources would have resulted. This in turn would have reduced the overall cost of the implementation as well as now, the sales personnel are still sometime belligerent with some of the elements that were decided haphazardly at the beginning by two software program manager rookies.


    In an environment where proper SDLC (systems development life cycle) is implemented all aspects of the software implementation are planned in advance. It starts with project planning and feasibility. It ends with identifying the maintenance requirements to maintain the system for years to come. Here are the steps of a properly performed SDLC implementation. (Computerworld)

Project planning, feasibility study

Systems analysis, requirements definition

Systems design


Integration, Acceptance

 Installation, deployment and testing


    In an optimal environment this would have been fully planned out. Unfortunately, I was not prepared to perform the installation myself and did not know the scope of the work until after I installed the program for the first time on a test server. I let the marketing assistant in to play with the test environment and then I left it alone for a while to work on other projects. A couple weeks later more information was handed out and the scope of the project was laid out. The user count would be 55. More than Act! Premium the best version available is able to support (50 max recommended). By that time the test server I was using had been utilized at the same time to provide a test bed for our new $1,000,000.00 accounting software Great Plains. I was not allowed any money to purchase new hardware so I had to make due with the Great Plains test server which is also a SQL based application as is ACT! 2009/2011. There were conflicts like crazy as the software packages did not agree with being on the same server using separate instances of SQL. I was then given a rush deadline to have the application installed before the end of the year. I rushed out CD’s to all the salesmen and estimators with copies of the software, our VPN client and an icon with path and environment information to our test database and installation instructions. The marketing assistant who was creating special forms for tracking pipeline information meantime had changed the test database tremendously and was unwilling to move his work to a new database now that so much work had been put into it.

    The software arrived at the different sales personnel’s houses and it was a nightmare to support over the phone. The MSDN client installed locally on each box was a terrible hog of system resources and the software would randomly not install correctly and required a time consuming un-install by the closest IT staff member for the geographic area of the salesman. Troubleshooting synching problems was also a nuisance. It was taking approximately 30 minutes to synch even over high-speed internet connections as our T1 was simply bogged down by the volume of data being pushed out. Meantime, the test environment for Great Plains was becoming bloated and was also not installed in the best manner with log files and database files residing on the same raid 5 array as the virtual memory page file.


    The system is working now in full production status. It took months of concentrated meetings between the marketing assistant and myself as well as poor quality tech support and even high-level technical support on appointment only from Sage. It was still a slow and cumbersome program with 15-minute daily synch times for the salesmen, but it is working exceptionally now. The Great Plains program was divided from the Act! server  and the size of the contacts has been managed into small groups of contacts based on record manager for each of the salesmen. The data has now been used for the last 5 quarterly announcements in predicting potential backlog. It was an awful implementation!


    From that experience I have learned that following a plan is essential. It would have also been in my best interest to utilize some of my supervisor’s time better to help me with crucial speed generating database optimizations. I have also learned that an enterprise wide implementation should not be handled by two inexperienced personnel without guidance from consultants or at least from a steering committee. In the end I think the time wasted and the sometimes-futile effort placed into the program cost more than the initial upfront and flat fee for hiring consultants for a couple days to help with the implementation. They are well versed and while costly would have taken substantially less time than we did to implement the product.



References formatted for Infobarrel  (Not MLA or APA)

Kay, Russel “QuickStudy: System Development Life Cycle” Computerworld. Retrieved on November 19th, 2010 

Anonymous. “16 CRITICAL SOFTWARE PRACTICESSoftware Program Manager Network. Retrieved Novemeber 19th, 2010