Clarity at Symbian Copyright    2007 Symbian Software Ltd.    Page:
Agenda Why Symbian choose to implement Clarity? Scope Approach / Outcome Recommendations
Why Symbian choose to implement Clarity? Background Symbian’s core products are operating systems for mobile phones. Traditionally the business culture has been driven by engineers with a R&D focus rather than necessarily a deadline focus Planning (particularly resource and project management) done via Excel spreadsheets New senior management were appointed. There was a view that: Departmental planning was disjointed  There were multiple versions of processes / documentation / approach The methods of estimating costs and man-days per project were unclear / inefficient There were legacy applications that needed to be upgraded or replaced Choosing a product Gartner – upper quartile products 2 products were shortlisted -  IBM and Clarity 10 week Proof of Concept  (POC) to prove core functionality were user group – Q4 2007 No quantifiable business case – instead there was a document of high-level benefits. This was a deliberate decision as the sponsor did not want the project to be seen as cost / head-count saving, but rather a means of better planning
High-level scope X Decommission legacy  applications Engineering Managers Capacity planning Resource planning Scenario planning Clarity – 4 distinct areas of functionality  Project Managers Project and portfolio plans / Dependencies / Budgeting / Risk / Issue  Timesheet users Electronic timesheets based on project  tasks Integration team Functionality for ensuring mile-stone and software quality gates are properly assessed Data interfaces from other applications (3) People data Requirements data Holiday/absenteeism Business Objects XI (BOXI) Graphical reports
Approach / Outcome Approach POC  – 10 weeks / 15 users from all areas of the business  / formal sign-off  Vendor selection  – approached 4 vendors with simple selection criteria / interviews to ascertain  functional and technical knowledge – as a result CQC were selected Phasing  – tactical 4 month phase 1 delivery to the engineering managers, followed by a more structured design for all other users in phase 2 Process  – loosely followed Prince2  Stakeholder management Regular steering group  – key decisions, time / cost / quality User group  – regular updates and consultation throughout Formal sign-off  – e.g. Documentation, UAT, handover Outcome  Strong partnership between Symbian, CQC and independent contractors Ultimately – successful design, build, test , deployment and training of all super users / support teams / business owners
Recommendations (1) Phase 1 – Start with an out of box implementation / Do customisation later Personal view: For projects over 6 months in duration the ability to forecast an end date drops off dramatically due to ongoing business change  e.g. Symbian was impacted by: Company re-org / changes in roles Company considering change in project process – AGILE (Clarity Prince 2 based) Acquisition by Nokia / change freeze An out-of-box deployment could have been done within 3 months. Symbian chose to build vast amounts of customisation. As a result the project took 13 months. Clarity is a very rich application functionality-wise without bespoke work.  As a result some of our users are now saying that with the customisation there is too much functionality! / too much cultural change to adopt in one go Consider gearing your business processes to fit the application rather than the other way round. This is difficult as users are often reluctant or feel aggrieved at having to change. This could be largely addressed by getting senior buy-in up front for the approach and having a Change manager covering the cultural change whilst the implementation is in progress
Recommendations (2) Choice of consultancy Clarity knowledge is a niche market. During the vendor selection: circa 50% of the consultants interviewed did not have the in-depth technical skills required to get the best out of Clarity e.g. Configuring portlets, batch, writing triggers etc.  Most over-pitched and under-delivered in both resource availability and understanding Therefore, technical interviews are essential. As a result Symbian selected CQC, which has proven a fruitful and successful relationship Performance Slow performance of certain functions (pulling back large quantities of data) has been a constant problem throughout the project . This has been caused in part by: Symbian not adhering in full to the architectural recommendations of CA / CQC Users requesting access to too much in searches / combining too many data views It would be advisable to secure performance targets from the end supplier before commencing an implementation.  It would also be advised to seek clear guidelines on server set-up, indexing etc to maximise front-end and back-end performance.

Symbian Case Study

  • 1.
    Clarity at SymbianCopyright  2007 Symbian Software Ltd. Page:
  • 2.
    Agenda Why Symbianchoose to implement Clarity? Scope Approach / Outcome Recommendations
  • 3.
    Why Symbian chooseto implement Clarity? Background Symbian’s core products are operating systems for mobile phones. Traditionally the business culture has been driven by engineers with a R&D focus rather than necessarily a deadline focus Planning (particularly resource and project management) done via Excel spreadsheets New senior management were appointed. There was a view that: Departmental planning was disjointed There were multiple versions of processes / documentation / approach The methods of estimating costs and man-days per project were unclear / inefficient There were legacy applications that needed to be upgraded or replaced Choosing a product Gartner – upper quartile products 2 products were shortlisted - IBM and Clarity 10 week Proof of Concept (POC) to prove core functionality were user group – Q4 2007 No quantifiable business case – instead there was a document of high-level benefits. This was a deliberate decision as the sponsor did not want the project to be seen as cost / head-count saving, but rather a means of better planning
  • 4.
    High-level scope XDecommission legacy applications Engineering Managers Capacity planning Resource planning Scenario planning Clarity – 4 distinct areas of functionality Project Managers Project and portfolio plans / Dependencies / Budgeting / Risk / Issue Timesheet users Electronic timesheets based on project tasks Integration team Functionality for ensuring mile-stone and software quality gates are properly assessed Data interfaces from other applications (3) People data Requirements data Holiday/absenteeism Business Objects XI (BOXI) Graphical reports
  • 5.
    Approach / OutcomeApproach POC – 10 weeks / 15 users from all areas of the business / formal sign-off Vendor selection – approached 4 vendors with simple selection criteria / interviews to ascertain functional and technical knowledge – as a result CQC were selected Phasing – tactical 4 month phase 1 delivery to the engineering managers, followed by a more structured design for all other users in phase 2 Process – loosely followed Prince2 Stakeholder management Regular steering group – key decisions, time / cost / quality User group – regular updates and consultation throughout Formal sign-off – e.g. Documentation, UAT, handover Outcome Strong partnership between Symbian, CQC and independent contractors Ultimately – successful design, build, test , deployment and training of all super users / support teams / business owners
  • 6.
    Recommendations (1) Phase1 – Start with an out of box implementation / Do customisation later Personal view: For projects over 6 months in duration the ability to forecast an end date drops off dramatically due to ongoing business change e.g. Symbian was impacted by: Company re-org / changes in roles Company considering change in project process – AGILE (Clarity Prince 2 based) Acquisition by Nokia / change freeze An out-of-box deployment could have been done within 3 months. Symbian chose to build vast amounts of customisation. As a result the project took 13 months. Clarity is a very rich application functionality-wise without bespoke work. As a result some of our users are now saying that with the customisation there is too much functionality! / too much cultural change to adopt in one go Consider gearing your business processes to fit the application rather than the other way round. This is difficult as users are often reluctant or feel aggrieved at having to change. This could be largely addressed by getting senior buy-in up front for the approach and having a Change manager covering the cultural change whilst the implementation is in progress
  • 7.
    Recommendations (2) Choiceof consultancy Clarity knowledge is a niche market. During the vendor selection: circa 50% of the consultants interviewed did not have the in-depth technical skills required to get the best out of Clarity e.g. Configuring portlets, batch, writing triggers etc. Most over-pitched and under-delivered in both resource availability and understanding Therefore, technical interviews are essential. As a result Symbian selected CQC, which has proven a fruitful and successful relationship Performance Slow performance of certain functions (pulling back large quantities of data) has been a constant problem throughout the project . This has been caused in part by: Symbian not adhering in full to the architectural recommendations of CA / CQC Users requesting access to too much in searches / combining too many data views It would be advisable to secure performance targets from the end supplier before commencing an implementation. It would also be advised to seek clear guidelines on server set-up, indexing etc to maximise front-end and back-end performance.