Cura PMO System Manual

CuraSM Services Manager User Guide Page 1 of 20

PREAMBLE

Welcome to CuraSM CuraSM (Cura Services Manager) is a custom configuration of the Cura Assessor product designed to administer, record and produce reports surrounding the various service activities found in the Cura Services Business Unit. The various functions can be defined as Projects, Training and Support, all falling under the Services B.U. banner. CuraSM breaks up these 3 functions into their individual domains and allows Cura service personnel to perform management tasks for each process and its related activities. Further to this, the Services B.U. issue Work Orders, which are also created and maintained in CuraSM. Cura Projects, Cura Training and Cura Work Orders are managed in CuraSM. The customer support function of the Services B.U. is managed within Salesforce, and is not managed by CuraSM. However, where the customer support team need to raise a Work Order, CuraSM will be utilised. Projects – Project Management Tool This domain of CuraSM allows for complete capturing of all project details, tracking of progress, and reporting of all aspects of the project scope. This would be use primarily for the service personnel in the Projects section i.e. Business Analysts, Project Managers and Services Consultants Training – Training Management Tool This domain allows the trainers in the Services B.U. to record basic details regarding training requirements relative to customers who are serviced by the B.U. It summarises training activity in the Services B.U. and allows for reporting on client training efforts. Work Orders – Work Order Management Tool This domain allows users to create and track Work Orders, which are sent to customers as confirmed billable work hours upon return.

INTRODUCTION

This document aims to cover the basic use of the CuraSM system. It assumes the reader has an intermediate grasp of the Cura Assessor user principles. It is not a Cura User Guide, but rather a guide to the use of CuraSM in everyday practice. Management derive key project information using the CuraSM reports. Therefore, it is of critical importance that any user of CuraSM ensures that all details recorded in the system is accurate, complete, comprehensive, and up to date. Failure to do so will result in exrtracted reports being inaccurate and unusable, and the system’s performance and value will be severely compromised. It is recommended that all CuraSM users agree with line managers and staff a particular day and time of each week when reports will be run from CuraSM, so that users can put aside dedicated time to ensure all project, work order and trai9ning data is accurate and updated prior to extracting the needed reports. The value of CuraSM lies only in the quality of data it contains. All users are to remember this core principle.


ACCESSING CURASM

The CuraSM database resides at Cura in South Africa. The details to establish a connection are as follows. Server Name : PHOENIX-SUP2005 Database Name : CuraSM Database Version : SQL2005 Cura Version : 3.4.0.2 (October 2009) You will need to have a user name configured in order to log in. Furthermore, you will need to be running v3.4x of Cura Assessor. A connection packet and user setup can be requested from [email protected]

Fig 1: CuraSM Connection packet settings

Depending on your configuration, you can choose your Security configuration options (Cura or Windows authentication), and after logging in, you may or may not be able to edit, view or administrate certain portions of CuraSM, in accordance with user policies.

THE CURASM DOMAIN STRUCTURE

CuraSM utilises a very simple domain structure which follows the 2 of the 3 Service functions (Projects and Training, excludes Support), as well as the issuing and management of customer Work Orders. Each will be discussed and explained. Each Domain uses a different methodology and workflow to suit its functional area. Each will be analysed and explained below. The domain structure is shown below (October 2009):

Fig 2: CuraSM Domain Structure

mailto:[email protected]


THE CURASM PROJECTS ASSESSMENTS

The Project portion of services as managed in CuraSM uses a methodology called “CuraSM - Projects”. We will not delve deeply into the methodology (this will be done when we describe the various fields), but the assessment layout is shown below and an overview description is provided thereafter.

Fig 3: CuraSM Projects Assessment Structure


Breakdown of the Assessment Structure for Projects Domain in CuraSM:

The “Assessment” level is used to record named customer/clients relevant to each project

The “Context” level we use to simply group Projects by year (e.g. 2009, 2010, 2011 etc.)

The “Risk” level is used to record the project details (therefore multiple projects/”risks” can be assigned to one customer/”assessment”)

Every project is auto-assigned a tracking number and prefix. For South Africa, the prefix is “CSA-PM” which is a prefix for “Cura South Africa – Project Management”. It is recommended to utilise your own prefix for each region – this will require methodology changes to be applied to each region using CuraSM.

Active (unclosed) projects are marked as “Active” assessments to differentiate them (Green) from closed projects, which are not marked as active (Red). This status should be taken note of and applied when running CuraSM project reports.

The “Control” level is used to record weekly activity on each project (therefore multiple activities/”controls” can be assigned to one project/”risk”).

Tasking and notifications can be used where desired, but usually is not used as the project teams are static and usually small. However, for large enterprise projects, tasking and notifications may prove useful to some project managers.

The assessments are easy to understand, and we encourage users to create and use assessment templates. Always name the assessment as the customer name, as Cura alphabetizes the list of projects in the domain structure, and doing so will make projects easier to navigate.

THE PROJECTS METHODOLOGY FIELDS

To create a new Project or edit a Project, the normal Cura commands apply i.e. click “Add Project” or “Edit Project”. The following steps are simply representative of the fields, and each will be explained. The following Workflow Steps apply to CuraSM Projects:

Fig 4: CuraSM Projects Workflow Steps

The Workflow Steps are described as: General The standard Cura fields to enter the project title and description Project Summary Capture details regarding the project resources, salesperson, and client Project Financials Capture all details regarding the project invoicing and financial information Project Tracking The most common project tasks are listed for checking through execution, as well as recording

resource time spent against budgets and project plans/scope Project Updates These are the “control level” weekly entries regarding the project activities, progress,

challenges and overall progress details Project Milestones If milestones are applied to the project during the scoping or agreement phase, the full details

thereof must be captured and tracked here according to their various elements Project QA Analysis At the end of each project the QA Manager reviews the project outcomes and rates the overall

execution. This is a secure workflow step only accessible to Cura QA Managers Project Documents Various project documents can and must be uploaded for each project. Users must ensure their

Cura license file allows for database uploading to the database and not only URL linking, so that all users can access the documents

Links Standard Cura Links tab Paths Standard Cura Paths tab


CURASM PROJECTS: TAB 1: GENERAL

This is where we enter a brief overview of the project as a summary. It is important to enter accurate and relevant information and title your project well.

Fig 5: CuraSM Projects General Tab

Context (Drop Down)

When creating a new project, simply select or create the context (year) the project began. Name (String) Assign the risk a title in the ”Name” field. It is not necessary to name the customer in the name field as this is referred to in the project’s assessment (customer) name. Keep the title concise, but informative. Remember that there may be many projects under one assessment or customer name and you will need to differentiate between them as they grow. Description (Memo) This is a very important area of information. A full description of the project, in its entirety, is to be entered here, in a manner that briefs any reader as to the overall goals, mandate, reasoning (business case) and core outputs, elements, goals and challenges of the project are – a 1 page synopsis. It is often acceptable to copy and paste the project’s business case, taken from the project’s sales proposals, design documents or similar existing information, into this area. It should never be empty or poorly completed. Reference (Automated) A prefixed project reference number will be assigned to the project once it is saved by the user.


CURASM PROJECTS: TAB 2: PROJECT SUMMARY

You will notice that most of the fields in this tab are compulsory (signified by the yellow icon alongside the field), since

they store fundamental project information.

Fig 6: CuraSM Project Summary Tab

Customer Name (Drop Down) CuraSM should store a manually maintained full list of all Cura customers. This is then accessible via a drop down list in the Customer Name field. Select the customer name for the project from the list. It is recommended that when a customer needs to be added to the list, it is done via a methodology addition and not a parameter addition, to ensure the integrity of the assessment parameters. You may opt to only allow your CuraSM administrator to edit the assessment parameters to achieve a similar goal.

Customer Contact Person (String)

Capture the name(s) of the customer project sponsor or main contact person. Contact Person Number (Integer) Capture the contact number of the customer project sponsor or main contact person. Contact Person eMail (URL) Capture the email address of the customer project sponsor or main contact person. Cura A.M./Salesperson (Drop Down) Select the name of the Cura Account Manager / Salesperson responsible for signing the customer on for the project, or assigned as the account manager.


Cura B.A./Project Manager (Drop Down) Select the name of the Cura Business Analyst / Project Manager assigned to execute and manage the project. Cura Q.A. Manager (Drop Down) Select the name of the Cura Senior Analyst / Manager assigned to oversee the project’s quality control and perform the project post mortem review. Cura Consultant 1 (Drop Down) Select the name of the primary Cura Services Consultant assigned to configure the software according to all aspects of the project scope and deliverables (the project’s “Lead Consultant”). Cura Consultant 2 (Drop Down) Select the name of the secondary/supporting Cura Services Consultant assigned to assist in configuring the software according to all aspects of the project scope and deliverables. This is an optional entry used if and when needed. Cura Trainer (Drop Down) Select the name of the Cura Trainer who has been appointed as the designated trainer for the project (this should be done directly after the scooping phase according to suitability and availability of each trainer). This should be a joint decision and agreement between the B.A. / Project Manager and the appointed trainer. Solution Type (Drop Down) Cura’s projects are diverse in nature, and difficult to categorise. This drop down selection offers a few project types relevant to Cura solutions. Select the project type that best applies to the project from:

Enterprise Project

Sdv

Sdf

Cf

Sfc

Zdsfc

Dfv Project Module Selection (Check Boxes) Cura’s various modules are listed for selection. Many projects (especially larger, enterprise projects) encompass the implementation of multiple Cura software modules, and the user can check each that applies within the scope of this particular project Note, as below, that if you select “Other Solution Type”, you are expected to provide details thereof (see next point). Other Solution Type Details (String) If your project type or modules extend beyond the options available, you can select “Other Solution Type”, but are then expected to give a full description of the project type and details in this string field.


CURASM PROJECTS: TAB 3: PROJECT FINANCIALS

These fields store financial data regarding the project, broken down into various components. It is important that these figures are absolutely accurate as they will be used as the basis of project earned value analysis as well as project forecasting and budgeting purposes. It is important to enter data into every field (even if Zero values) in order for Cura to run its financial calculations. All entered values are to exclude any VAT/Tax.

Fig 7: CuraSM Project Summary Tab

Software & Maintenance (Currency) Enter the total value of the software sold as part of the project (including license fees and any other software related pricing that the customer has accepted as per their supporting EULA) PM & Professional Services (Currency) Enter the total value of all Project Management & Implementation/Services fees. This would include any project management fees, configuration time, implementation etc. related to the execution and management of the scoping, building, implementing and signing off the software, reports, configuration and related aspects. This amount must specifically exclude any travel, training and/or software costs. Training (Currency) Enter the total value of the training portion of the project, including resources, time, materials and administration fees. This amount must specifically exclude any travel, configuration, project management, report writing and/or software costs. Included Disbursements (Currency) Enter the total value of any travel or similar disbursement fees which have been specifically included in the agreed overall project proposal/fee. In most cases, travel and disbursements are billed separately from the project as incurred at agreed rates, but some clients wish to implement a fixed total fee for disbursements on a project, included in the overall project fee. If this is the case, this amount must be entered here. This amount must specifically exclude any training, configuration, project management, report writing and/or software costs, only any agreed fixed costs relating to these tasks. Other Project Fees (Currency) If any other project fees are relevant (e.g. purchase and supply of hardware or 3rd party software, contingency values etc.) and agreed to by all parties, this amount should be captured in full in this field, with a supporting description (see following note).


Other Project Fees – Details (String) If “Other Project Fees” have been applied to the project (see above note), the details of these additional fees must be briefly entered in this field, so as to explain what these “Other” fees are. Project Total Value (Currency) Cura will calculate the sum total of the Software, Services, Included Disbursement and any “Other” Project Fees and return a value in this field. Also check this field to ensure it matches all the agreed supporting project and proposal documentation, as they will be used to calculate and track all project billing. Project Currency (Drop Down) Choose the applicable project currency Forex Rate (1 Unit = ZAR?) (Currency) Enter the current exchange rate of the chosen currency’s value against 1 South African Rand (ZAR), e.g. If using USD, enter the current value of 1 USD in ZAR. If the project currency is ZAR, enter “1”. Calculated ZAR Value (VAT Excl) (Currency)

Cura will calculate the project value in ZAR according to the exchange rate entered in the above field.

CURASM PROJECTS: TAB 4: PROJECT TRACKING

Cura projects must all have defined deliverables in terms of the overall scope. This must include time frames, resources, documentation expectations, testing, training and rollout planning, amongst others. This postion of CuraSM enables the user to track the most common and important aspects of the project in terms of its overall completion stages and status. A few fundamental rules apply in order to ensure the validity of the captured data, and thus, the accuracy and value of extracted reports:

All projects must have a signed EULA and supporting contracts in place before any Services work is performed

All projects are to be accompanied by a Microsoft Project Plan, stipulating the various stages, milestones, resources, dependencies and allocated time frames for all activities (both calendar and resource days)

A baseline project start date, end date and duration must be captured as soon as the project plan is agreed to – these entries may never be altered, without a change control entry being submitted with due explanation.

The calculation of allocated resource days to a project vs. the days incurred/spent to date, must always be up to date, accurate and be reflected against or according to the assessed project’s overall % progress.

The completion and checking off of tasks in this tab may not always follow a logical order, as per the layout of the fields, but efforts should be made to follow these steps in the order they are presented, wherever possible.

Data entered on this tab is to be an honest, accurate representation of the actual project budget in terms of time spent and activities completed. It must tie up with supporting weekly update information and at all times represent a true reflection of the days spent and objectives reached at any point in time during your project.

With the above in mind, we can discuss each entry.


Fig 8: CuraSM Project Tracking Tab

EULA Signed? (Check)

Check this block if the EULA has been signed and uploaded to the CuraSM database (see Project Documents tab). EULA Signed Date (Date) Enter the signature date that appears on the respective EULA Contracts Signed? (Check) Check this block if all applicable contracts, proposals, SLAs and/or associated project agreements have been signed off in addition to the EULA.


1st Scoping Complete? (Check) Check this block if Cura has conducted and concluded the first solution scoping session. Project Plan Signed Off? (Check) Check this block if the project plan has been drafted, submitted to and signed off/agreed to by the client. It must then be uploaded to the CuraSM database (see Project Documents tab). Project Plan Baseline Start Date (Date) Enter the baseline calendar start date of the project as per the first agreed project plan (above). This date should never be edited once agreed upon as per the project plan. Project Plan Baseline End Date (Date) Enter the baseline calendar completion date of the project as per the first agreed project plan (above). This date should never be edited once captured in CuraSM. Changes to the project allocated days must be recorded and explained separately as a change control entry. Project Plan Baseline Cura Days (Integer) Enter the baseline project actual resource days allocated to the project as per the first agreed project plan (above). This date should never be edited once captured in CuraSM. Changes to the project allocated days must be recorded and explained separately as a change control entry. Project Cura Days Spent to Date (Integer) Every time you update your project details, enter the actual, accumulative days that have been spent on the project to date. This figure must be accurate, honest and suitably justifiable, regardless if it extends beyond the allocated project resource or calendar days allocated to the project baseline. Revised Project Plan End Date (Date) If the project plan needs to be revised, this must be done in consultation and agreement with all project parties, and must result in a well documented change control entry into the project records (see below). If the Change Control affects the project’s planned end date, the revised end date must be entered here. This date will subsequently be updated whenever similar changes come into effect during the project. Project Change Control Summary (Memo) Change control process is used for identifying and maintaining changes to baselines of a project. Change Control Procedure is a process of creating a formal method for identifying, documenting, evaluating, and communicating all changes to projects. Change Control outcomes stem from a managed process whereby the existing parameters of an existing project are altered by necessity, to the agreement and overall satisfaction of all the impacted project parties. With this in mind, at any point where your project is impacted in terms of scope, time, quality, resourcing requirements or cost for any reason, these details must be clearly documented to the customer so that they understand and agree to the total impact of such change, as well as the point of deviation from the baseline project plan. This change control entry must be summarized and entered in this memo field. It should be preceded with a date stamp of when the change control entry was made, and chronologically ordered (as many change control entries may be captured in this memo field as continual change control may occur). Spec Docs Submitted? (Check) Check this block if the Solution Design Document (or Spec Doc) has been finalised and submitted to the client for review and ultimate signoff. Spec Docs Signed Off? (Check) Check this block if the Solution Design Document has been signed and returned by the customer. 1st Build Complete? (Check) Check this block if Cura have built the first iteration of the customer solution, configured as per the solution design document and client requirements. Reports Complete? (Check) Check this block if Cura have built the first iteration of the reports the customer is to extract from the Cura solution, as per the solution design document and customer requirements.


UAT Complete? (Check) Check this block if the customer has completed and signed off any applicable system User Acceptance Testing procedures on the Cura solution. Tweaks Complete? (Check) Check this block if any final system (methodology, configuration, reports or other) tweaks have been scoped and completed by Cura, stemming from either project scope changes, UAT outcomes, discovered errors or omissions, or any other final configuration exercise that must be completed in order for the customer to accept the final version of the fully configured solution. Internal QA Complete? (Check) Cura will appoint a QA manager to review progress and quality of the solution at various stages of its execution. This may be 1 or many instances. If the project has passed through at least 1 internal QA session and the QA manager is satisfied with progress and quality, this box may be checked. Installation Complete? (Check) Check this block if the final solution has been installed, completely implemented and commissioned successfully on the customer’s infrastructure, to their satisfaction. This should be accompanied by a customer installation audit sheet, containing all details of the installation performed (see Project Documents tab). Training Complete? (Check) Check this block if all training commitments have been completed as per the project plan. Documentation Uploaded? (Check) Check this block if all the required mandatory project documentation has been uploaded to the CuraSM database for the particular project (EULA, Solution Design Document, Project Signoff Sheet) Signoff Document Complete? (Check) Check this block if the Project Signoff & Acceptance Sheet has been signed off and uploaded to the CuraSM database, signifying project closure. Project Review Complete? (Check) Check this block if Cura’s internal Q.A. personnel have been presented, reviewed, assessed and signed off the final version of the fully configured solution. Project Closed? (Check) Check this block only if all aspects of the project are completed, and all fees may be invoiced. If the project is deemed closed and can be invoiced save for a few minor issues that are known and accepted by all project parties, this is acceptable, but details thereof must be captured in the Outstanding Project Items & Notes memo box (below). Project Signoff & Closure Date? (Date) Enter the actual calendar day that the project was closed. Project Current Progress (Percentage & Reference) This is a subjective percentage that the project manager must apply to the project in terms of its overall completion. The completion of a project may consist of many complex, intertwined phases and dependencies, therefore this figure should be well thought out. A project which is running perfectly on track should view this percentage as a pure calculation of “Project Days Spent / Project Days Allocated”, but this may not always be a true reflection of reality, especially on projects which have had scope creep or are running overdue, or have sporadic time frames of activity. This means that the figure is decided upon and maintained/updated regularly by the project manager as they deem to be a true representation of the project’s progress to date. Remember that while subjective, entered values should always be justified by supporting completed tasks, change control entries, notes, weekly update entries and similar CuraSM project data which support the percentage figure entered in this field. Outstanding Project Items & Notes (Memo) This field should be used to record any project items that remain outstanding even though the project has been signed off, or can be used to capture important information at the end of the project. It is an area to most importantly capture information that would be important should the project be questioned later. These entries should be regularly reviewed and deleted, updated or marked as complete, to ensure no project has lingering outstanding tasks or issues.


CURASM PROJECTS: TAB 5: PROJECT UPDATES

Weekly project updates are to be captured per project, in full, with details that relate to dependent areas of the system (e.g. days spent in each week must total the overall days spent in the Project Tracking Tab). All the weekly updates are presented in the grid view at first. As updates are captured through the duration of the project, this list will naturally grow as a chronological list of entries.

Fig 9: CuraSM Project Updates Tab

You can double click on an update entry to edit or view it. At the end of each project week, click on “Add Weekly Project Update” to create a new entry. You will be presented with the Weekly Project Update screen, described below. Bear in mind there are 4 tabs within the entry window.

Fig 10: CuraSM Weekly Project Update Entry Fields


GENERAL Tab – “Name” (String)

Each entry must be given a name, which must be captured as the calendar week from start to finish date that the weekly update refers to. This must be captured as “YYYY/MM/DD – YYYY/MM/DD”. For example, if your weekly update refers to a period from Monday 21 August 2009 to Friday 25 August 2009, you must name the entry “2009/08/21 – 2009/08/25”. This is mandatory as it creates uniformity as well as orders the entries in a logical, chronological fashion in the grid view. GENERAL Tab – Description (Memo) This is an optional field, you may choose it to capture lengthy information about any particulars of the week’s activities, leave it empty if no important information is needed, or simplay capture a headline description e.g. “A summary of the project tasks, progress and events between Monday 21 August 2009 and Friday August 25 2009”. PROJECT UPDATES Tab - Current Month (Drop Down) Capture the month that you are currently in (the month that relates to the day of the entry, not the week. This is very important for overall month-to-month project reporting purposes. This date must be the actual month in that you capture the entry). PROJECT UPDATES Tab - Current Week Comments (Memo) Enter all the activities that took place during the update period. This should take cognizance of the project plan and be a factual synopsis of the week’s activities. PROJECT UPDATES Tab - Current Challenges (Memo) Capture any information regarding project threats or current issues. These may be standing issues from previous activities, or may have arisen within the update period. This is an important entry as it will highlight any red flags in the project that must be noted by all project stakeholders in reports drawn from CuraSM. PROJECT UPDATES Tab – Coming Week Actions (Memo) In line with addressing the overall project planning as well as targets and challenges, details regarding the activities planned for the coming week should be captured here. PROJECT UPDATES Tab – Project Days Spent in Week (Integer) However many actual resource days have been spent in the week must be accurately and honestly captured in this field. For example, if 2 project resources spent Monday to Thursday working 8 hours per day each, you should enter “8” in this field. If 1 resource spent 12 hours during the week, enter “1.5”. It is recommended to keep the figures rounded to 0.5 increments for simple reporting, but you may use more finite increments if needed. One should always bear in mind that the total number of project days spent in each weekly entry should add up to the total project days spent on the project, as captured in the “Project Tracking” tab of CuraSM.

PROJECT UPDATES Tab – Change Control Week? (Check)

If any project changes did occur and have to be applied to the baseline or current project plan during the week in question, regarding time frames, resources or other project plan items, check this box. If change did not occur in any way on these schedules, ensure this check box is empty. PROJECT UPDATES Tab – Change Control Details (Memo) If the change control check box is checked as true, full details regarding the effected change must be captured here. It must include details of how and why the change was necessary, impact areas, risk areas, and causes. This is a very important entry as it will also feed into the overall project change control register which directly impacts the project baseline entries, which will be compared to change control entries when assessing the overall project success. Change control entries should be copied and pasted as appendices to the “Change Control Summary” memo field in the “Project Tracking” tab of CuraSM.


CURASM PROJECTS: TAB 6: PROJECT MILESTONES

Cura projects may follow a milestone approach in terms of their execution. Milestones should be applied at a point where a project, in terms of its size, extent, timeline or other influential factors, would benefit from points during its execution to review progress and address any issues. Milestones should, as a recommended rule of thumb:

Be discussed with the client at the point of sale as a potential project reality to be discussed during scoping;

Be explained and agreed with the client as soon as possible into the project;

Be addressed and agreed to in terms of their applicable value towards the project in terms of monetary value, resource time consumption, project contribution portion, and/or calendar dates;

Be mirrored on a formal, agreed baseline project plan, in accordance with the project schedule;

Take cognisance of the fact that their contributory portions should add up to the full project values in terms of resources, timelines, financial values and all other contractual project items;

Be used by Cura project managers regularly, even if the client is excluded from/refuses the milestone process;

Be enforced at at least one level on projects with a value of over $40,000/R250,000.00 or extending over a period of more than 15 resource days in total.

Milestone bases are, however, subjective to the requirements of the project and its stakeholders, the above is a guideline and recommendation only. In CuraSM, 5 milestones are allowed for capture. It is rare for a project to extend over more than 5 milestones. The actual point at which a milestone occurs is determined mutually by the Cura PM and the client during or before the 1st scoping phase. Cura recognises, as a guideline, 9 potential project execution points which could be used as standard milestone points on an Enterprise Project to “pick and choose” from, as a recommendation:

1. Signoff of all contracts, EULAs, purchase orders or similar project contractual documents (Although this is often seen simplay as the project start point and not a milestone);

2. Project 1st scoping complete, and project plan (as output) submitted and agreed to by all parties; 3. 1st demonstration to client of system configuration (may include reports or not); 4. Final (accepted) demonstration to client of system configuration (may include reports or not); 5. Fully configured, populated and packaged solution, including reports, presented to client’s satisfaction; 6. Successful deployment, testing and rollout of fully configured solution on the client’s IT infrastructure; 7. User Acceptance Testing, and resultant configuration/system tweaks, successfully completed, applied and

signed off by the client; 8. All users successfully trained and commissioned as users on the system; 9. Signoff and closure of the project by all parties.

These are in accordance with the known and accepted “Cura Project Methodology” process flow document, where milestones are indicated by yellow stars (see below). When making use of CuraSM’s milestone capturing capability, it is important to remember the following in order for it to deliver successful tracking reports:

Captured milestone data should always be updated to accurately reflect the current project plan, taking into account and accounting for any change control which has been applied;

CuraSM pulls the total project value and baseline project plan resource days into the “Milestone” Tab header area. This is so that the summed days and values assigned to each milestone can be easily cross referenced to the total baseline assigned values and time frames;

Always ensure the total sum of the milestone monetary values and resource days agrees with the total values entered in the “Project Financials” and “Project Tracking” tabs;

5 milestone entry areas must be captured in order for Cura’s calculations to work in terms of the above point. Simply enter “Zero” values if less than 5 milestones areas are being used for your project.

Milestones are only valuable if well maintained and applied through the project plan, and should be discussed, reviewed and agreed upon at every project meeting with all stakeholders. Effective use of milestones will impact the project change control processes in that changes to milestones must be accompanied by change control entries.


Fig 11: CuraSM Project Milestones Tab


Project Plan Baseline Cura Days (Integer) This is the number of days allocated to the project. It is the same parameter entry as per the “Project Tracking” tab, so bear in mind that changing this data will be mirrored on the other tab, and therefore this date should never be edited once captured in CuraSM. Changes to the project allocated days must be recorded and explained separately as a change control entry. Total Cura Milestone Days (Calculated Integer) This is an automatically calculated sum of the days entered into all the milestone day value fields. This allows the project manager to compare and ensure the total allocated days per milestone totals up to meet the project allocated total baseline days (above). Any discrepancies should be investigated and corrected, as they should not exist. All milestone data fields must be populated in order for the calculation to work. Total Project Services Value (Calculated Currency Value) This is an automatically calculated sum of the services values as entered in the “Project Financials” tab. It includes all recorded monetary values associated to the project as captured, excluding the project software value (since this is not considered to have any impact on the project milestone completion dates, unless under special circumstances, where these should be captured separately as “Other Project Fees”). This allows for comparison with the total sum value assigned to the various milestones (see next point). Any discrepancies should be investigated and corrected, as they should not exist. Total Cura Milestone Value (Calculated Currency Value) This is an automatically calculated sum of the monetary values entered into all the milestone monetary value fields. This allows the project manager to compare and ensure the total monetary sum of the values for all milestones matches the project allocated services total fee (above). Any discrepancies should be investigated and corrected, as they should not exist. All milestone data fields must be populated in order for the calculation to work. Total Cura Milestone Completion % (Calculated Percentage) This is an automatically calculated sum of the percentage contribution towards the overall (100%) completion of the project as per the project plan. This allows the project manager to ensure that the sum total of all the percentage entries for all milestones add up to 100%. Any deviation should be corrected, unless under extreme circumstances. All milestone data fields must be populated in order for the calculation to work. Milestone 1/2/3/4/5 Title (String) Give your milestone an explanatory name, associated with the point at which the milestone apportionment comes into effect, according to the project plan. Milestone 1/2/3/4/5 Project Days (if applicable) (Integer) A milestone can be associated with a point in time where a particular amount of the allocated full project duration has been expended. If applicable, enter the amount of resource days allocated to the milestone (the days entered are relative to the start – finish time frame of the milestone portion of the entire project duration only). Milestone 1/2/3/4/5 Value (if applicable) (Currency) A milestone can be associated with a point in time where a particular monetary value of the project has been expended. If applicable, enter the monetary value allocated to the milestone (each value is relative to the start – finish time frame and expended value of the milestone portion only). Milestone 1/2/3/4/5 Contribution % (Percentage) A milestone can be associated with a point in time where a particular project occurrence is deemed to account for a certain percentage of the overall project completion (100%). If applicable, enter the percentage portion allocated to the milestone (each percentage value is relative to the start – finish time frame and expended percentage of the milestone as part of 100% only) Milestone 1/2/3/4/5 Complete? (Check) If the milestone has been accomplished, check this box. Milestone 1/2/3/4/5 Completion Date (Date) If the milestone has been accomplished, enter the actual date on which the milestone was actually completed (not the planned or proposed date on any project plan or schedule).


CURASM PROJECTS: TAB 7: PROJECT QA ANALYSIS

At the end of each project, the assigned QA manager for the project must review the project in terms of its overall success. Various inherent factors come into play at this post mortem phase, but the data captured in CuraSM will be the main source of evaluation. This tab is not accessable to non-QA Manager level users.

Fig 12: CuraSM Project QA Analysis Tab

Cura QA Manager (Drop Down) This field is the same parameter as captured in the “Project Summary” tab, and the two are therefore linked. This name should therefore already be entered and should not change, but can be if needed, bearing in mind the change will be reflected throughout. Select the name of the Cura Senior Analyst / Manager assigned to oversee the project’s quality control and perform the project post mortem review. QA Date (Date) Enter the date that the project QA review takes place. Project Baseline Completion Date (Date) This field is the same parameter as captured in the ”Project Tracking” tab, and the two are therefore linked. It is a baseline project date and therefore should not be changed, as per the first agreed project plan (above). This date should never be edited once agreed upon as per the project plan. Project Actual Completion Date (Date) This field is the same parameter as captured in the ”Project Tracking” tab as the “Revised Project Plan End Date”, and the two are therefore linked. It is an actual reflection of the day the project was completed. Project Duration Variance (Integer) Cura will automatically calculate ethe difference between the originally entered resource days assigned to the project, against the revised resource days actually utilised on the project, and display the difference in this field. Duration Variance Comments (Memo) The QA manager, after discussions with the PM, can enter motivation or additional information surrounding the project duration variance in this field.


Outstanding Project items & Notes (Memo) is field is the same parameter as captured in the ”Project Tracking” tab, and the two are therefore linked. This field should be used to record any project items that remain outstanding even though the project has been signed off, or can be used to capture important information at the end of the project. It is an area to most importantly capture information that would be important should the project be questioned later. These entries should be regularly reviewed and deleted, updated or marked as complete, to ensure no project has lingering outstanding tasks or issues. QA Report (Memo) This is a field where the QA Manager enters their full report on the project. Project Score (Integer) The QA Manager enters a subjective overall score /10 for the project, after review.

CURASM PROJECTS: TAB 8: PROJECT DOCUMENTS All projects will deliver a certain amount of related documentation. While Cura is not a tool to manage every project document, there are certain critical items that should always be available, maintained and uploaded to the CuraSM database. The expectation is that uploaded documents, wherever possible and applicable, are scanned original copies with signatures attached, as far as possible, rather than just digital versions. It is important to ensure that your Cura license allows you to upload documents to the CuraSM database, and not simply create links to remote/local files, as these will not work for remote/other users of CuraSM.

Fig 12: CuraSM Project QA Analysis Tab


Project Proposal/Contract (Document Upload) Upload the final, signed and agreed project proposal, bid or similar document of sale. Client EULA (Document Upload) Upload the signed client EULA (if applicable) here. Solution Design Document (Document Upload) Upload the final, signed Solution Design Document here (There may be many iterations of this document, simply maintain/store the latest version up to project completion at all times) Signed Project Closure Sheet (Document Upload) Once the project is complete, a project signoff document must be signed off. This must then be uploaded here. Training Manual (Document Upload) The final customized client training manual must be uploaded here. Other Documentation 1/2/3/4 (Document Upload) Any other relevant, important documentation can be uploaded here.

Date post:	11-Mar-2016
Category:	Documents
Upload:	kevin-willemse
View:	218 times
Download:	1 times