Completion Report

Project Summary:

   Objectives

The objectives of the project were to upgrade the version of Core Archibus used within Estates and Buildings to version 19.3.This will provide new functionality but the primary motivation is that it is compatible with Windows 7, the new university Windows standard workstation version. Additionally, the database version will be upgraded from Oracle 10g to Oracle 11g. The AutoCAD package used by the drawing office space managers was also upgraded in line with the latest version to run on Windows 7.

   Deliverables

The deliverable of this project will be the fully functioning Archibus 19 system running on Windows 7 against an Oracle database at 11g with an upgraded AutoCAD version for the drawing office.

   Scope

The project delivered the original scope of the Archibus 19 upgrade and database upgrade to Oracle 11g.

In addition, the project co-ordinator tasks normally carried out by Estates and Buildings were assumed by Project Services.

Drawing office requirements proved to be difficult to resolve requiring substantial input from Project Services, USD and MASS.

Additional deployment and testing support , especially around  Web Central

  Schedule

The project was outside the original schedule and budget.

Analysis of Resource Usage:

Staff Usage Estimate: 54 days

Staff Usage Actual: 128 days

Staff Usage Variance: 137%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

The project , as originally defined was based on information which proved to be incorrect. Every aspect of the project has required several iterations of assessment, deployment , testing and problem resolution which has pushed the budget up considerably. Additionally,  the drawing office upgrade has proved difficult with various versions and combinations of software being deployed and tested without success.

1.       The project was originally defined based on the information  (from the business owner) that the Archibus client v19 had been previously and successfully tested as part of Windows 7 and that test plans were in place for all ares affected by the upgrade. This was found to be incorrect

2.       Unexpected issues discovered during the testing resulted in several iterations of assessment, deployment, testing and problem resolution.

3.       The impact of the changes with regards the Drawing Office was not fully understood and testing was in hindsight, wrongly left to the end of the test schedule.  The guidance provided by Mass that the SmartClient would solve the Drawing Office issue proved to be unfounded and eventually the solution was only resolved with the release of v20 client from Archibus that incorporated an 64-bit overlay that would function within the Windows 7 environment

4.        There was a general lack of understanding on the impact of Desktop services producing a virtual client for the Archibus client for the first time

a.       There was an unwillingness for Desktop Services to deal directly with Mass due to previous experiences

b.      Mass had difficulties in troubleshooting problems as they could not access the files within the virtual client

c.       Requirement for added assistance from User Services Division in rolling out the client

5.       A number of upgrade un- related Lease Module issues were reported at the time and had to dealt within the project, due to the delays in signing off the project due to the delays in getting the v20 client tested

6.       Problems were encountered securing resource from the Drawing office to undertake testing resulting in lengthy delays between identifying and re-testing the problems

7.       The departure of the business owner from the project during the project left a knowledge gap and direction within the business that was not fully filled.

8.       A  long standing issue with the Samba drive had to be resolved to create appropriate directories.

Key Learning Points:

 Areas for Improvement

5.1. In future, test plans should be created and maintained for al areas of the business. This has been initiated, for example, within the drawing office area, to ensure the various combinations of software involved were fit for purpose. A comprehensive test plan will be crucial to the ease of change and expedite further large upgrades.

5.2   Engagement rules and SLA for participating staff outwith IS APPS.

The project required substantial input from University departments outwith IS APPS which meant co-ordination of input from USD especially. This can prove problematic as USD have commitments university wide. The decision to create a virtual package for an application requires analysis of the benefits and the time taken to create the virtual package against the cost/time of a straight manual install on to x number of PCs. Need to identify benefits other than ‘it makes the rollout a bit quicker and easier'.

5.3 Availability of Staff.

 Each upgrade, large or small, will require dedicated effort from divisional personnel to test and verify new functionality and that the installations are functioning correctly. Drawing office personnel will be the experts in their area and are the only ones who can test and sign off new functionality. Their time will be planned in to the projects and will be dedicated to the project when required. This will require commitment from management to allow their workload to be altered to allow for any appropriate participation in the project especially where some short term project closure activities require some more dynamic commitment.

5.4 Engagement rules and SLA for third party suppliers.

Regular meetings to discuss any ongoing developments, enhancements or issues are essential. The specification of requirements and sign off of any work requests agreed should use standard agreed documentation. Timescales agreed for delivery, testing and deployment. Any calls or GTMs are documented for purpose, scope and outcome for circulation to the wider support and management groups and not just individual users

The PM has experience in other organisations where third party software systems are supplied. It is essential for the technical departments who will install and support the system to have an understanding of the system and its requirements. On past experience, the supplier is identified and agrees to abide by customer organisation rules. Thereafter, the policy was like this.

Detailed documentation on the suppliers system is requested. The format and information on the documentation will be determined by the customer, not the supplier organisation. This will take the form of a document with questions to define the requirements of the supplier system and all aspects from desktop client, server to database and technology requirements. When completed by the supplier, the document can be passed to and reviewed by the relevant departments involved in the system build and installation namely Desktop Services, Development Technology and Technology Management. Any queries will be passed back to the supplier and when answered, reviewed by the IS APPS departments concerned. Any last questions and queries are dealt with at a call or meeting. When all internal departments are happy, the system can be built out by the internal departments, based on the media supplied. When the supplier rep does arrive, the system can be set up and implemented by the internal IS APPS departments, i.e. those who will be supporting the system day-to day.

Outstanding issues:

It has been raised by Application Management and Development Technology that MASS/Archibus use the afm user for all system access from workstation to WebCentral. It would be preferable for various logins/behind the scenes logins for functionality have their own user which can have varied timeouts and permssioning set to suit that functionality rather than just using the afm user for everything.