111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 The MobileFrame Implementation Methodology (MIM)Definition The MobileFrame Implementation Methodology (MIM) defines the management processes that will be used on all MobileFrame-managed engagements.Background MobileFrame uses the Statement of Work (SOW) as the primary methods to both define the scope and effort of a project and to communicate standard operating management procedures for executing a project. In doing so, each SOW is tailored for each project, requiring unique effort for construction, review and approval. The MIM formalizes the management procedural components in order to provide consistency and to streamline the SOW development process.Scope of Effort Critical Success Factors The most critical success factors for the MIM standard operating procedures are as follows: MobileFrame team members understand and adhere to the MIM The client has reviewed, understands, and is a proponent of the MIM In Scope The following items will be considered in scope for definition of the MIM for the client: MobileFrame’s Project Management and Reporting process Plan Management Communications Management Issues Management Quality Management Risk Management Change Management Acceptance Management Out of Scope The following items will be considered out of scope for definition of the MIM for the client: Project Request and Background Project Scope Technical Requirements and Approach for a specific project Specific deliverables for the client’s project Project Roles and Responsibilities Project Schedules and Time and Costs Estimates Client specific exceptions to the management component of the MIM that are communicated via the specific project’s SOW.
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 Management ApproachProductivity Management To manage a project MobileFrame implements its Project Management and Reporting process. PM includes six principles that, when applied to project situations, greatly increases the likelihood of the project being completed on time and within budget. The Six Principles of PM and MobileFrame’s approach to implementing them during the project are: 1. Define the job in detail. MobileFrame’s Project Managers will develop a detailed statement of work (SOW) for this effort clearly documenting the background, scope, approach, roles and responsibilities, deliverables, time and cost estimates and project plan of each phase of the effort. This MIM is part of that SOW. 2. Involve the right people. MobileFrame will staff the effort with resources that understand MobileFrame’s methodologies and have experience implementing them. In addition, MobileFrame will involve the client’s staff in the effort in a way that ensures project success while minimizing time commitment. 3. Estimate time and costs. MobileFrame will produce a detailed project plan for the project reflecting progress to date and effort and resources required to complete the effort. MobileFrame will update and report on the project plan weekly, keeping the client informed of progress and issues. 4. Break the job down. As stated earlier, MobileFrame will produce and maintain a detailed project plan, consistent with its process methodology, that breaks the effort down into reasonable amounts of work (usually 80 elapsed hours or less) that can be measured (result in a deliverable to be produced). 5. Define acceptance criteria. MobileFrame will work with the client early to define acceptance criteria for each deliverable to be produced. 6. Establish a change control procedure. MobileFrame will setup and manage a change process to address and resolve any issue that may impact the project’s budget and delivery dates positively or negatively. The process will be defined for this project when the statement of work for the project is created. As with all MobileFrame projects, MobileFrame will use its Project Management and Reporting Process (PMRP) to ensure that this project starts successfully, remains on schedule, and completes successfully. PMRP is MobileFrame’s project quality assurance process developed and managed by MobileFrame’s branch, area and corporate project offices. PMRP involves four activities that are performed at the beginning of the project, 10 activities that are performed during the project and 3 activities that are performed at the conclusion of a project to ensure and assess project performance. The specific implementation of these activities is as follows: At the beginning of the project: 1. MobileFrame’s Project Manager will develop a detailed Project Plan for the project. 2. MobileFrame’s Project Manager will develop a Project Risk Assessment Matrix (PRAM) report identifying potential risks to project schedule and budget and actions that will be taken to minimize them. 3. MobileFrame’s Project Manager will develop a detailed Statement of Work for the project and obtain approval from the client and MobileFrame to proceed. 4. MobileFrame’s Branch Project Officer will conduct a pre-audit of the project to ensure the project has started successfully and that the SOW and PRAM are of high quality. During the project: 1. MobileFrame’s Project Manager will conduct a weekly project team work plan review meeting to discuss project status, schedule and issues with MobileFrame’s team.
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 2. MobileFrame’s Project Manager will prepare a weekly project status report documenting planned progress for the prior week, actual progress made, impact on schedule, progress planned for the following week, current project risks, change requests status, deliverables acceptance status, and project issues. 3. MobileFrame’s Project Manager will conduct a weekly project status meeting with the client to discuss project progress, status and issues. 4. MobileFrame’s Project Manager will maintain and update a project plan and provide the client and MobileFrame management with a current copy of the plan on a weekly basis in electronic document form and in a password protected area of the MobileFrame web site at www.mobileframe.com. 5. MobileFrame’s Project Manager will implement and manage the change control procedure documented in the statement of work for the effort. 6. MobileFrame’s Project Manager will ensure that acceptance criteria for each deliverable is determined early in the deliverable’s development and that deliverables meet or exceed the criteria. 7. MobileFrame’s Project Manager will report on the status of the project during monthly branch project reviews. 8. MobileFrame’s Project Manager will provide MobileFrame with standard MobileFrame Project Reporting documentation on a weekly basis. 9. MobileFrame’s Project Officer will conduct project audits on a quarterly basis. 10. MobileFrame’s Project Manager will maintain a project notebook. At the conclusion of the project: 1. MobileFrame’s Project Officer will conduct a post-project audit. 2. MobileFrame’s Project Manager will prepare final project status reports. 3. MobileFrame’s Project Manager, with guidance from the Project Officer, will archive the project notebook and supporting materials.Project Management Project Management defines the reporting process from the MobileFrame project team to the MobileFrame Project Manager and the process of reporting by the MobileFrame Project Manager to the client Executive Sponsor or his/her designee. MobileFrame Project Team Status Reporting Process Weekly progress reports are submitted by each MobileFrame team member to the MobileFrame Project Manager every Friday. The report consists of: (a) Accomplishments during the week (b) Planned accomplishments for the following week. (c) Time lost during the week (d) Problems/Issues that may cost future lost time (e) Hours billed summary by assigned task Effort and task duration tracking is performed using Project Timesheets from a project tracking software product such as Microsoft Project. The particular tool to be used will be specified in the SOW. A weekly MobileFrame project team meeting is conducted in order to review project progress, issue status, and to provide assignments and goals. The day and time of this meeting will be defined in the SOW. Status Reporting to the Client The MobileFrame Project Manager summarizes the accomplishments for the week and submits a summarized status report to the client Executive Sponsor on a weekly basis. The report consists of:
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 Tasks completed and products delivered during the week Individual plans to complete and deliver the following week Status of Change Requests submitted and Deliverable Acceptance/Completion (d) Time lost during the week (e) Problems that may cost future lost time The MobileFrame Project Manager conducts a weekly status meeting with the client Executive Sponsor to discuss the items contained in the project status report. These meetings include a discussion of: (a) Status Review of deliverables, milestones, issues/action items and accomplishments (b) Review including schedule variance, analysis of variance and action plans (c) Status of Acceptance (d) Status of Change (e) Plans for next week Project Notebook and Repository The MobileFrame Project Manager establishes a Project Notebook for each project for a client. This is a repository for all relevant project reporting and control materials. One of the keys to good communication is being able to refer to past situations or agreements in an objective manner. The Project Notebook allows project information and documentation to be managed easily. It is accessible to MobileFrame and the client as a reference document throughout the Project, and is accessible in a password controlled area of the MobileFrame corporate web site at www.mobileframe.com.Plan Management Plan management will follow MobileFrame’s Principles of Productivity Management. Specifically, the MobileFrame Project Manager and the project team will: Monitor progress of the project against a Product Status Summary (internal MobileFrame document) and the Project Schedule using an agreed upon project tracking tool such as Microsoft Project. Actual time expended and estimate to complete will be recorded in the project schedule weekly. Provide weekly individual status reports that will contain as previously described in the MobileFrame Project Status Reporting Process Document changes submitted and their status Identify items that may impact the project schedule Control changes to the project through use of a change procedure as described in the Change of Scope section of this document Track successful completion of each deliverable through the use of an acceptance procedure as described in the Acceptance Procedure section of this document Conduct weekly project status meetings between the Project Team and Client management in the manner indicated under the Status Reporting to the Client sectionCommunications Management Communications management is one of the most critical components of a well-managed Project. Project communication is conducted through: 1. The production of Individual Status Reports as previously described 2. The development of the Project Status Report. This report is not only provided to the client, but MobileFrame Management at the local branch is given a copy as well. 3. Team meetings will be held weekly to share overall project status.
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 4. Client Status Reviews will be held weekly, usually on Fridays, to go over the Project Status Report.Issues Management An issue is defined as any item adversely affecting execution of the project schedule. Issues may adversely impact the cost, time frame and/or quality of the deliverables of the project. Resolving issues is an on-going process throughout the life of any project. The keys to effective issue resolution are early identification, communication and management. Our process is as follows: 1. Any team member may raise an issue to the MobileFrame Project Manager. Team members should document issues on the Individual Status Report. However, issues may also be raised during the Client Status Meeting, Team Meeting or via e-mail. 2. Issues are recorded into a Project Issue Log. Issues are retained for the life of the project. Every record in the Issue Log contains a description of the issue, actual or potential impact if not resolved, who raised the issue, when the issue was raised, updates, and final resolution. Every issue has a target date for resolution after which the project is impacted. This impact may, and often does, result in a change request. Every issue has an owner responsible for driving resolution and keeping the MobileFrame Project Manager up to date on progress. Every closed issue will have a documented resolution/decision and the date the issue was closed. 3. An extract of the Issue Log is attached to the weekly Project Status Report. The extract includes open issues and issues closed since last status. 4. The extract of the Issue Log is reviewed in the weekly Client Status Review and weekly Team Meetings. 5. Issues are closed only when the initiator is comfortable that the resolution addresses the problem satisfactorily. The following describes an example of issue escalation. Specific individuals responsible for resolution are named in each respective position. MobileFrame Resolution Responsibility Escalation Criteria Client Resolution Responsibility Project Manager (Dmitri Prozorov) <=3 days Client Manager (Name Names) MobileFrame Chief Technical Officer >3 days and <=5 days Project Sponsor (Name Names) (Glenn Wickman) MobileFrame Executive Sponsor >5 days ** Client Executive Sponsor (Name (Lonny Oswalt) Names) ** Additionally, any issue that is two weeks old regardless of resolution date, any issue that has missed its target date and a new resolution date cannot be agreed upon, or any issue that will negatively impact the overall project completion date or budget will be escalated to the attention of MobileFrame Executive and Client Management.Quality Assurance MobileFrame believes that quality is one of the key components that differentiate it from its competitors. MobileFrame not only advocates quality, but practices it as well. During the Project, we will establish and Quality Control (QC) for the project by defining and planning for these functions. In larger projects these functions may represent separate groups or bodies or, as with smaller projects, they are functions performed by existing members of the team. QC is critical to project success and must be integrated into a project at its inception.
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 The MobileFrame Project Manager and the Project Officer work together to develop a quality environment that meets the project’s business and technical needs and provides value to both MobileFrame and the Client. During the Project, QC functions will be established in terms of the approach, procedures and standards. The roles of the Project Office and Quality Assurance staff (if merited by the size of the Project) are defined relative to the quality assurance and control activities to be performed. Each SOW will define within its Quality Management Section those quality measures specific to its effort.Risk Management MobileFrame’s Risk Assessment Methodology defines risk as the probability of an undesirable event occurring and the impact of such an event should it occur. Risk will be managed using MobileFrame’s Project Risk Assessment Method (PRAM). There are five steps in mitigating the impacts associated with risks: 1. Identify the risks to encourage active management of risks by MobileFrame and our client 2. Prioritize each risk, both in terms of probability and impact to the project timeline, costs, and/or scope 3. Plan actions we can take for mitigating the negative consequences or maximizing positive benefits. Take proactive actions to mitigate both the high-impact and the high-probability risks 4. Put in place a process to monitor, assess, and deal with known risks and to uncover new risks as they arise. This process will be defined by each individual SOW 5. Establish a Change Budget to deal with authorized changes resulting from the mitigation or realization of a risk. The size of the change budget is determined by estimating the likelihood of various risks occurring and projecting their impact on the project schedule A Project Risk Profile will be developed as one of the first work products after acceptance of this Statement of Work. Using this method, risks will be identified, assessed, mitigated and tracked throughout the project. The Risk Profile is the basis for establishing the project change budget discussed in the following section. The Risk Profile will be reviewed and modified at least monthly during the course of the project, as new risks are determined. Depending on the complexity of the project, the Risk Profile will be tracked via a spreadsheet or as specific activities and tasks within the project plan.Change Management MobileFrame recognizes that changes are a normal part of the project life cycle. MobileFrame believes that managing change is critical to the project’s ultimate success. There are two basic types of changes. The first type is design/definition change, which can be viewed as an opportunity to improve the system or approach. Criteria for this type of change typically involve a procedure for defining the opportunity and a mechanism that the client can use to procure the change, taking into account the timing of its effort and its impact on the current project scope, project schedule and cost. The second type of change is non-compliance (lost time) change. Lost time can have a disastrous effect on project costs and deadlines because it is impossible to forecast and requires constant control and analysis. Criteria for this type of change typically involves system downtime, hardware unavailability, slow turnaround of documents or programs, or almost anything that is out of the control of the MobileFrame team. Since non- compliance changes are usually a combination of many small items, any lost time over 30 minutes will be recorded and tracked. Lost time will be posted to the project schedule and reported on in status reports and meetings. The change procedure will be used for instances such as: Any change that is outside the scope of effort defined in the project SOW. Addition of a deliverable not defined in the SOW, or changes to an accepted deliverable. Modifications to the technical or management approach defined in the SOW and this MIM.
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 Addition of an activity or task not defined in a project SOW for a planned deliverable. A contradiction to items, assumptions or responsibilities stated in the individual project SOW. Changes in the personnel identified in the Roles and Responsibilities section of the individual project’s SOW. Realization of high impact risks contained in the Risk Profile (previously described) Time spent to investigate and/or estimate any change request. Time lost due to reasons such as: Unavailability of equipment, software, or access to environment/infrastructure needed by the project team. Unavailability of client personnel. A delay in turnaround of approvals, information, answers to questions, etc.Change procedure The change procedure can be activated for any deviation from the individual project’s SOW or schedule as described above. The purpose of a change request is to provide a formal written communication vehicle among the Client, the MobileFrame project team and MobileFrame management concerning changes. The formality of a notification in writing is critical to communicate that there is a need for discussion, agreement, and planning for handling changes that can and will affect a MobileFrame deliverable.Change Request The Change Request form will include information on the costs associated with the change, if any, and the impact that the change will have on the project schedule. MobileFrame or the client can initiate changes. When a change request is made, MobileFrame will document the change on a Change Request form. MobileFrame will send a copy of the Change Request form to the Client Executive Sponsor (or equivalent approval authority), for review and acceptance. A maximum number of working days as specified in the project SOW will be allowed for approval of the change request. If a change request is not acted upon within the specified number of days, it will be resubmitted and entered in the project Issues Log. All change requests will be logged, tracked in a Change Request Log, and will be reported on in status reports and meetings.Change acceptance Formal change acceptance is required before working on any changes outside of the scope of the project’s SOW. Change acceptance is given when both the Client Executive Sponsor, (or equivalent approval authority), and MobileFrame formally approve the change by signing off on the request form. Approved changes will immediately be included in the project schedule. Only signed, approved Change Requests will be implemented, default approvals are not acceptable.Use of change budget MobileFrame recommends that the client establish a change budget for each project. The change budget will allow for approved changes to project scope and additional work to be performed. The change budget may be activated when a change occurs to the scope of work outlined in the project’s SOW. Changes of scope will be documented as detailed in this section and will be submitted to the client for approval prior to any work being performed. The change budget will remain under the exclusive control of the Client Executive Sponsor, (or equivalent approval authority). The client is the only party authorized to approve use of the change budget. It is the responsibility of the MobileFrame Project Manager to track the depletion of the change budget and the associated changes tied to the budget depletion. The MobileFrame Project Manager will report the status of the remaining change budget to the client on a weekly basis. Whenever the client authorizes change, the amount estimated and authorized for the change (dollars and/or hours) is subtracted from the change budget and added into the
111 West Saint John Street, Suite 900, San Jose, CA 95113 (408) 885-1200 project budget. If the time spent to investigate the impact of a change exceeds 4 hours, investigation time will be charged to the change budget. The change budget for each discrete project is described in the Schedule and Cost Estimates section of the SOW.Acceptance procedure The MobileFrame Project Manager will review for acceptance with the Client Executive Sponsor, (or equivalent approval authority) each deliverable as defined in the project SOW. The acceptance procedure helps mitigate both the client’s and MobileFrame’s risk as the project proceeds by requiring clients to formally declare that products meet the acceptance requirements (criteria) as specified in the project SOW. If a deliverable does not meet the client’s acceptance criteria as defined within the SOW for the project, it must be rejected with specifications of the cause for rejection. Approvals will always be a written sign-off even if a Client team member was an active participant in the creation of the deliverable. Verbal or conditional acceptances are not valid. The acceptance procedure for all deliverables in the Statement of Work is as follows: MobileFrame will attach a Deliverable Acceptance form to each deliverable presented to the client’s Executive Sponsor or equivalent approval authority. MobileFrame will log all submissions of deliverables for acceptance. This log will include deliverable number, submission date, deliverable description, approval authority, rejection reason (where applicable), and date returned. MobileFrame will schedule and conduct a walk-through for each deliverable to be approved. The Deliverable Acceptance form must be signed and returned to MobileFrame upon review of the deliverable within the number of days specified in the project SOW. The form must be marked approved or disapproved. MobileFrame does not allow acceptance or rejection of deliverables by default. “Conditional” approvals are not allowed. If a deliverable is disapproved, a detailed description of why it was rejected must be included on the form. If required, a meeting can be held to discuss the deliverable in detail. All errors and omissions must be detailed in the first rejection. One resubmission will be allowed to modify the deliverable and address the items that were specifically rejected. If additional resubmission is required, the change procedure will be invoked. In addition to the formal deliverable project schedule, MobileFrame employs interim (incremental) deliverable milestones throughout the project. These interim deliverables will be identified as the project progresses. This allows the client and MobileFrame to review draft deliverables and works in process for gradual acceptance of the final deliverables.Final AcceptanceFinal Acceptance will be secured at the completion of the project. This Final Acceptance will indicate that allrequirements as defined in the Statement of Work and amended through approved change requests are complete.