Offering

Remedy assignments are most likely to be successful if we work closely with the technical leadership of the group. If we have already been involved with the project, so much the better. We can play multiple roles in such assignments — bringing technology, project management and performance skills. It's the client's choice which of those roles we actually play in the assignment.

Specifically, our deliverables would include:

• Analysis of expectations, measurements and the gap. In other words, a clear definition of the problem.
• Technical analysis of the situation.
• Options presentation listing options being considered, their expected benefits, expected costs, risks and recommendations.
• Frequent communication of progress in quantitative terms (% improvement, distance from goal)
• Longer-term recommendations and expected improvements. To implement the recommendations, we can introduce the client to one of our consulting partners if needed. We offer it as a service; we are not paid by the partners for this.

For a technology upgrade and evolution project, our approach includes these elements:

1. Strategy requirements sessions with stakeholders. An assessment of the current state and requirements for evolving it to a new level, resulting in recommendations and an implementation plan.
2. Performance Requirements document. This document would serve as input to system specifications and eventually feed into the Service Level Agreement. In addition, it provides management with a set of key metrics that Performance will likely be sensitive to.
3. Existing system metrics report, collected from log files.
   Performance Models are based on Quantitative Models.
4. Early-stage performance model, documented to an agreed-upon level.
5. Recommendations based results from performance model.
6. Toward the end of the integration phase, a deployment expectations report that sets expectations of what performance levels will be like once the system goes live. It will include recommendations on changes required to get higher levels of performance.
7. Usage report after the system has gone live to monitor actual usage. The usage report provides validation for the workload assumptions from the requirements phase. It also provides validation for the projections in the deployment expectations report.

For a technology strategy project, the engagement might include

1. Strategy requirements sessions with stakeholders. An assessment of the current state and requirements for evolving it to a new level, resulting in recommendations and an implementation plan.
2. An initial training session for your team at the start of the implementation. A 4-hour session for business and technology middle manager is a great way to get the entire team focused on Performance early in the process.
3. Performance Requirements document. This document would serve as input to system specifications and eventually feed into the Service Level Agreement. In addition, it provides management with a set of key metrics that Performance will likely be sensitive to.
   Performance Models are based on Quantitative Models.
4. Early-stage performance model, documented to an agreed-upon level.
5. Toward the end of the integration phase, a deployment expectations report that sets expectations of what performance levels will be like once the system goes live. It will include recommendations on changes required to get higher levels of performance.
6. Updates to the performance model based on actual measurements from the integration phase.
7. Usage report after the system has gone live to monitor actual usage. The usage report provides validation for the workload assumptions from the requirements phase. It also provides validation for the projections in the deployment expectations report.

Is it too late to contact us if your project has gone past the requirements stage? No. At that stage, it may make sense to do an architecture review and have the performance effort "catch up" to the project.